Các AI agents được tích hợp vào các nền tảng doanh nghiệp đang trở thành mối đe dọa bảo mật tiềm ẩn. Khi được cấu hình để hoạt động thay mặt người dùng thực, các agent này có thể gây ra rủi ro nghiêm trọng trong lớp định danh của tổ chức.
Rủi ro từ AI Agents trong Môi trường Doanh nghiệp
Một nghiên cứu mới đã phơi bày cách các bản ghi Microsoft Entra Agent ID ghi lại các hành vi đáng ngờ liên quan đến các assistive agents, còn gọi là interactive agents. Các agent này hoạt động thông qua luồng ủy quyền (delegated access flow), nghĩa là chúng thực hiện hành động sử dụng quyền của người dùng thực thay vì thông tin đăng nhập độc lập của riêng chúng.
Các assistive agents được thiết kế để hỗ trợ người dùng bằng cách thực hiện các tác vụ theo yêu cầu thông qua giao diện trò chuyện. Chúng có thể bao gồm việc đọc email, truy xuất dữ liệu lịch hoặc trả lời các câu hỏi hỗ trợ với sự can thiệp tối thiểu của con người.
Vấn đề là, trong một số trường hợp, các agent này có thể bị thao túng hoặc xâm phạm và sau đó được sử dụng để thực hiện các hành động độc hại trong khi vẫn giả dạng là một nhân viên đáng tin cậy. Đây là một hình thức tấn công mạng mới cần được quan tâm.
Phân tích Chi tiết Hoạt động Đáng ngờ
Các nhà nghiên cứu tại Red Canary đã xác định được hành vi này và công bố một báo cáo chi tiết về cách thức một cuộc tấn công như vậy diễn ra trong môi trường Microsoft 365 thực tế. Theo báo cáo, quá trình điều tra đã mô tả một kịch bản trong đó một AI agent đã gửi một email đáng ngờ thay mặt cho một người dùng hợp lệ, với toàn bộ hoạt động này không bị các công cụ giám sát định danh tiêu chuẩn phát hiện.
Vụ việc xoay quanh việc người dùng cấp quyền truy cập cho một agent thông qua quy trình On Behalf of flow. Khi sự đồng ý này được cấp, agent sẽ nhận được một token liên kết với các quyền của người dùng và có thể đưa ra yêu cầu tới các dịch vụ của Microsoft như Exchange hoặc Graph API.
Các quyền mà agent nhận được đại diện cho sự giao thoa giữa những gì agent được phép thực hiện và những vai trò mà người dùng đã nắm giữ. Điều này cho phép agent thực hiện các hành động phức tạp dưới danh nghĩa người dùng.
Ví dụ về Cuộc tấn công Email Lừa đảo
Email đáng ngờ được gửi đến một liên hệ cấp CFO bên ngoài với dòng chủ đề “Here is your invoice.” Thoạt nhìn, nó giống như một tin nhắn bình thường từ một nhân viên thông thường. Tuy nhiên, phân tích sâu hơn các bản ghi đã tiết lộ rằng danh tính của agent, Agent001, hoạt động thông qua Microsoft Graph API, là người gửi thực tế, hoạt động một cách thầm lặng thay mặt cho tài khoản người dùng.
Việc theo dõi email đáng ngờ này đòi hỏi sự tương quan của ba nguồn nhật ký riêng biệt: nhật ký Purview Exchange, Nhật ký Hoạt động Microsoft Graph và nhật ký đăng nhập người dùng không tương tác.
Nhật ký Purview ban đầu hiển thị một địa chỉ IP thuộc sở hữu của Microsoft là nguồn gốc, một chi tiết có thể dễ dàng đánh lừa một nhà phân tích. Việc truy xuất nhật ký Graph API tương ứng bằng trường AppAccessContext.UniqueTokenId đã làm nổi bật địa chỉ IP nguồn gốc thực sự, 51.3.97.221, cùng với lệnh gọi API chính xác đã kích hoạt email.
Nhật ký đăng nhập đã xác nhận rằng agent hoạt động thông qua luồng On Behalf of flow. Các chỉ số chính là hai trường nhật ký cụ thể: Agent.agentType được đặt thành agenticAppInstance và Agent.agentSubjectType được đặt thành notAgentic.
Phát hiện và Giám sát Hành vi Agent
Microsoft không gắn nhãn rõ ràng các luồng này trong nhật ký, vì vậy việc nhận dạng mẫu này đòi hỏi kiến thức trước về cách thức hoạt động của từng loại xác thực. Nhóm nghiên cứu lưu ý rằng các chuyên gia bảo mật phải tái tạo các kịch bản này trong môi trường thử nghiệm để hiểu sự khác biệt về hành vi.
Một trong những điểm quan trọng nhất là các chuyên gia bảo mật không thể chỉ dựa vào một nguồn nhật ký duy nhất để hiểu những gì một AI agent đã làm. Sự tương quan giữa nhật ký Purview, Nhật ký Hoạt động Graph và nhật ký đăng nhập là cần thiết để xây dựng một bức tranh hoàn chỉnh và chính xác.
Các nhóm bảo mật nên tìm kiếm hoạt động Add delegated permission grant trong bảng AuditLogs để phát hiện khi người dùng đồng ý cấp quyền truy cập cho agent thông qua phạm vi access_agent. Sự kiện kiểm toán này là tín hiệu sớm nhất có sẵn để phát hiện mối đe dọa mạng tiềm ẩn.
Các Chỉ số Cần Lưu ý (Indicators of Compromise – IoCs)
Các chuyên gia bảo mật cũng được khuyên nên theo dõi trường Agent.parentAppId trong nhật ký đăng nhập, trường này liên kết một phiên bản agent với nguồn gốc của nó. Khi có điều gì đó đáng ngờ xảy ra, trường đó sẽ liên kết một hành động cụ thể với danh tính ban đầu của agent.
Các nhóm nên ghi nhớ rằng ngay cả các quyền cấp thấp như Mail.Send cũng có thể gây ra thiệt hại nghiêm trọng nếu bị lạm dụng. Việc xây dựng các quy tắc phát hiện xung quanh các email gửi ra bất thường thông qua Graph API vẫn là một điểm khởi đầu thực tế để phát hiện sớm hành vi độc hại của agent.
Indicators of Compromise (IoCs):
- IP Address:
51.3.97.221 - Agent Identity:
Agent001 - Log Field Indicators:
Agent.agentType(value:agenticAppInstance),Agent.agentSubjectType(value:notAgentic) - Audit Operation:
Add delegated permission grant(inAuditLogstable) - Scope:
access_agent
Lưu ý: Địa chỉ IP và tên miền được cố tình làm mờ (ví dụ: [.]) để ngăn chặn việc phân giải hoặc siêu liên kết ngẫu nhiên. Chỉ hiển thị lại đầy đủ trong các nền tảng tình báo mối đe dọa được kiểm soát như MISP, VirusTotal hoặc SIEM của bạn.
Việc hiểu rõ cách các AI agent hoạt động và cách chúng có thể bị lạm dụng là rất quan trọng để cải thiện an ninh mạng. Theo dõi các bản ghi chi tiết và tương quan thông tin từ nhiều nguồn là chìa khóa để phát hiện và ngăn chặn các cuộc tấn công tinh vi.
Để có thêm thông tin chi tiết về các phát hiện này, bạn có thể tham khảo báo cáo gốc từ Red Canary tại Red Canary Blog.
