Trong năm qua, chúng tôi đã chứng kiến một loại cảnh báo mới xuất hiện trong các trung tâm điều hành an ninh doanh nghiệp (SOC) và phát triển nhanh hơn bất kỳ thứ gì khác: các cảnh báo được kích hoạt bởi các công cụ và AI agent. Đây không phải là các cuộc tấn công chống lại AI, mà là dấu vết thông thường hàng ngày của một tổ chức sử dụng nó, từ các lập trình viên sử dụng coding agent đến các nhân viên không chuyên về kỹ thuật đăng nhập các công cụ AI tiêu dùng bằng tài khoản công ty.
Chúng tôi đã xem xét hoạt động liên quan đến AI trên nhiều môi trường doanh nghiệp. Hai con số sau đây sẽ định hình toàn bộ vấn đề. Các cảnh báo liên quan đến AI vẫn chỉ chiếm 0,43% tổng số cảnh báo SOC. Nhưng tỷ lệ đó đang tăng lên hàng tháng, tăng 685% trong khoảng thời gian từ tháng 2 đến tháng 6 năm 2026. AI hiện là một phần nhỏ trong luồng cảnh báo nhưng đồng thời cũng là phần tăng trưởng nhanh nhất.
Điều làm cho những cảnh báo đó xứng đáng với sự chú ý của nhóm an ninh không phải là khối lượng mà là thành phần của chúng. Chúng tôi phân loại mọi thứ mà một AI agent kích hoạt trong SOC thành ba nhóm: tấn công thực sự (real attacks), rủi ro (risks) và nhiễu (noise), với tỷ lệ là 94,1% nhiễu, 5,8% rủi ro thực sự và 0,02% tấn công thực sự. Có nghĩa là trên toàn bộ dữ liệu chúng tôi điều tra, các cuộc tấn công thực sự sử dụng AI agent chỉ là một giọt nước trong đại dương. Chi phí của AI trong SOC cho đến nay không phải là các vụ vi phạm dữ liệu. Đó là một làn sóng cảnh báo trông có vẻ đáng báo động nhưng hầu như không bao giờ nguy hiểm, và một nhóm nhỏ các lỗ hổng thực sự mà những cảnh báo đó có xu hướng che lấp.
Bài viết này sẽ đi sâu vào từng danh mục trong số ba danh mục này với các ví dụ đã được ẩn danh.
Hình thái mới của luồng cảnh báo
Việc áp dụng AI trong doanh nghiệp không phải là một hành vi duy nhất, mà là hai hành vi rất khác nhau xuất hiện cùng lúc.
Thứ nhất là về mặt kỹ thuật. Các lập trình viên cài đặt các coding agent để tạo shell, đọc credential stores, mở các network tunnels, tải xuống các gói và chạy các công cụ bảo mật—tất cả đều là công việc hợp lệ, và tất cả đều không thể phân biệt được với các giai đoạn đầu của một cuộc xâm nhập bởi các công cụ phát hiện. Đây là phần "ồn ào" và chiếm ưu thế trong dữ liệu.
Thứ hai là khi nhân viên cấp quyền OAuth cho các ứng dụng AI của bên thứ ba, chia sẻ thông tin và dán tài liệu vào các công cụ generative-AI. Đây là phần "yên tĩnh". Nó hiếm khi kích hoạt các phát hiện trên endpoint, nhưng lại là nơi dữ liệu rời khỏi tổ chức.
Cả hai phần này đều đổ về cùng một nơi là SOC, và thoạt nhìn cả hai đều có vẻ đáng lo ngại. Việc phân loại tín hiệu từ nhiễu là toàn bộ công việc cần làm.
Qua những con số
AI chiếm một phần nhỏ trong khối lượng nhưng đang tăng trưởng nhanh chóng. Trong số khoảng 16,9 triệu cảnh báo SOC mà chúng tôi đã xem xét, khoảng 73.000 (0,43%) có liên quan đến AI. Xét riêng lẻ, con số đó nhỏ một cách trấn an.
Sự gia tăng mang tính đơn điệu. Mỗi tháng sau đều cao hơn tháng trước và tốc độ tăng trưởng đã tăng tốc mạnh mẽ vào tháng 5 năm 2026. Trong khoảng thời gian báo cáo ổn định trên các khu vực (tháng 2 đến tháng 6), khối lượng đã tăng 685%. Con số 0,43% nên được hiểu là "sàn" của ngày hôm nay, chứ không phải "trần". Một nhóm thiết lập quy trình xử lý cảnh báo AI theo khối lượng hiện tại sẽ bị thiếu hụt nguồn lực chỉ trong vòng một quý.
Thành phần cảnh báo cũng chênh lệch như tốc độ tăng trưởng. Gần như tất cả các cảnh báo do AI tạo ra đều là nhiễu.
Đối với nghiên cứu này, chúng tôi đã điều tra nhóm cảnh báo liên quan đến AI và phân loại từng cảnh báo theo hoạt động thực tế. Một cuộc tấn công thực sự là một vụ xâm nhập đã được xác nhận. Rủi ro bảo mật không phải là một vụ xâm nhập nhưng là một lỗ hổng thực sự (ví dụ: một coding agent chạy với các biện pháp bảo vệ quyền bị vô hiệu hóa). Nhiễu là hoạt động hợp lệ nhưng kích hoạt các phát hiện vốn được viết trước khi AI agent tồn tại. Theo tiêu chuẩn đó, gần như tất cả các cảnh báo liên quan đến AI là nhiễu (94,1%), một phần nhỏ là rủi ro bảo mật thực sự (5,8%) và các cuộc tấn công thực sự chỉ chiếm một phần cực nhỏ (0,02%).
Thứ hai là cách những cảnh báo đó được xử lý trong thực tế mà không cần sự can thiệp của con người. Khi một cảnh báo đến một nền tảng phân loại tự động, hai quyết định riêng biệt sẽ được đưa ra:
- Phán quyết (Verdict) cho biết mức độ nguy hiểm của hoạt động: có thể là lành tính (benign), nghi ngờ (suspicious) hoặc độc hại (malicious). 79,8% nhận được phán quyết lành tính.
- Phản hồi (Response) cho biết điều gì sẽ xảy ra tiếp theo: cảnh báo có thể bị triệt tiêu (suppressed - tự động đóng), đánh dấu để theo dõi hoặc chuyển lên cho con người xử lý. 81,7% đã bị tự động triệt tiêu.
Trong nhóm liên quan đến AI, chỉ có 5,4% được chuyển lên cho chuyên gia phân tích; số còn lại được đánh dấu để theo dõi.
Một cảnh báo có mức độ nghiêm trọng cao không nhất thiết có nghĩa là một mối đe dọa thực sự. Ví dụ, một phát hiện duy nhất tại một khách hàng chiếm 55% tất cả các cảnh báo phán quyết "nghiêm trọng" gắn cờ một tệp tin Windows binary (Expand.exe) là lateral-tool-transfer. Khi kiểm tra, người ta thấy rằng coding agent của một lập trình viên đang thiết lập môi trường shell, và hành vi này là bình thường đối với loại công việc này.
Bài học cho bất kỳ SOC nào cũng giống nhau: các nhãn mức độ nghiêm trọng đối với hoạt động AI phải được xem xét một cách thận trọng, không nên chỉ tin vào vẻ bề ngoài.
Nhóm 1: Các cuộc tấn công thực sự
Một cuộc tấn công thực sự là một vụ xâm nhập thực tế hoặc một hoạt động của kẻ tấn công được hỗ trợ bởi việc áp dụng AI. Đây là danh mục mà mọi nhà quản lý đều hỏi đến đầu tiên, và nó lại là nhóm nhỏ nhất, chiếm khoảng 0,02% các cảnh báo do AI tạo ra.
Trong số các mối đe dọa thực sự được phát hiện, không có vụ nào là xâm nhập do chính AI agent của tổ chức gây ra. Mọi cảnh báo có tiêu đề "AI agent running mimikatz", "reverse shell from a coding tool" hoặc "credential theft" đều được giải quyết khi kiểm tra, cho thấy đó là lập trình viên đang làm việc hợp lệ hoặc công cụ phát hiện bị lỗi. Chúng ta sẽ quay lại vấn đề này trong phần Nhiễu.
Mối đe dọa thực sự là các cuộc tấn công dựa trên AI thay vì thông qua AI: một chiến dịch phishing trực tiếp sử dụng tên thương hiệu AI làm mồi nhử. Chúng tôi đã quan sát thấy các email độc hại với tiêu đề theo chủ đề AI mang tên những "ông lớn" trong ngành. Mồi nhử này hiệu quả chính vì việc áp dụng AI đã làm cho các thương hiệu này trở nên quen thuộc và các thông báo của họ trở nên bình thường. Nhân viên hiện mong đợi email từ các sản phẩm này, đó chính xác là những gì kẻ tấn công đang tính toán.
Dưới đây là một số ví dụ về các sự cố mà chúng tôi phát hiện việc thực thi các công cụ hoặc lệnh thường chỉ ra các cuộc tấn công thực sự, nhưng trong các trường hợp này chúng được gọi bởi Claude, Codex, v.v. Vì vậy, người điều tra cũng cần đặt câu hỏi tại sao các agent lại chạy các công cụ này và liệu đó có phải là một phần của cuộc tấn công thực sự khai thác agent hay không.
- Anthropic được sử dụng làm mồi nhử trong bối cảnh kinh doanh. Email giả mạo thông báo về việc phê duyệt và thanh toán hợp đồng với Anthropic để yêu cầu thanh toán một khoản tiền lớn trông có vẻ hợp lệ.
- Một email sử dụng mồi nhử lời mời Google/Gemini Ads giả mạo. Nó tự giới thiệu là một lời mời không gian làm việc liên quan đến kinh doanh, nhưng cơ sở hạ tầng người gửi lại dựa trên tên miền đáng ngờ gemini-advertisers[.]com.
- Email mạo danh OpenAI (“OpenAI Partner Summit 2026”) nhưng nguồn gốc từ [email protected]. Mặc dù sử dụng cơ sở hạ tầng zoom.us hợp lệ, nhưng nội dung và quy trình đăng ký được sử dụng để tạo uy tín cho một lời mời gian lận.
Mô hình chung là: càng xem xét kỹ, các "cuộc tấn công" càng hòa tan vào ngữ cảnh công việc. Đó là đặc điểm định hình của việc phân loại trong kỷ nguyên AI.
Nhóm 2: Sử dụng không an toàn
Khoảng 5,8% các cảnh báo liên quan đến AI là những cảnh báo mà chúng tôi nghĩ rằng xứng đáng được chú ý nhất. Những cảnh báo này phát hiện việc sử dụng các công cụ AI không an toàn, không nhất thiết là một vụ xâm nhập (chưa). Đó là khoảnh khắc một agent, hành xử chính xác như được hướng dẫn và không có kẻ tấn công nào tham gia, làm điều gì đó gây rủi ro cho tổ chức hoặc người dùng.
Rủi ro chính là các agent chạy với cờ permission-bypass, tùy chọn yêu cầu agent ngừng hỏi người dùng trước khi thực hiện hành động. Nhiều người dùng chọn tin tưởng agent sẽ không phá hủy máy móc của họ hoặc thực thi các lệnh nguy hiểm, nhưng dữ liệu cho thấy trong nhiều trường hợp, agent sẽ thực hiện các lệnh gây rủi ro lớn. Khuyến nghị là nên sử dụng thêm các cấu hình bổ sung (harnesses) để ngăn chặn agent thực thi các lệnh rủi ro theo lập trình.
Sử dụng không an toàn khác bao gồm:
- Một reverse tunnel được mở bởi một AI IDE: Một trình chỉnh sửa mã AI đã khởi chạy PowerShell, sau đó chạy ngrok và mở một reverse tunnel ra internet công cộng bằng auth token của người dùng.
- Một agent trích xuất (dump) toàn bộ macOS keychain để đọc một token: Để truy cập các thông tin đăng nhập đã lưu, agent đã chạy lệnh bảo mật dump-keychain, ghi mọi bí mật đã lưu vào một tệp tạm thời.
- Cấp quyền truy cập OAuth cho AI agent có nghĩa là nhân viên có thể chia sẻ thông tin nhạy cảm với các nhà cung cấp dịch vụ bên thứ ba, làm tăng rủi ro truy cập dữ liệu trái phép thông qua prompt injection.
Nhóm 3: Nhiễu (Noise)
Nhiễu là danh mục lớn nhất, chiếm 94,1% các cảnh báo do AI tạo ra. Nhiễu ở đây không phải là ngẫu nhiên. Đó là các phát hiện được viết trước khi AI agent tồn tại, hiện đang kích hoạt ở mức độ nghiêm trọng cao đối với các công việc agent thông thường.
Ví dụ rõ ràng nhất là phần mềm của chính các nhà cung cấp AI. Trình cài đặt Anthropic Claude Desktop chính chủ đã kích hoạt các quy tắc EDR lớn như “Ransomware Operations detected” và “Encoded PowerShell Download and Run”. Trình cài đặt là hợp lệ, nhưng hành vi của nó giống với cách thức của ransomware trong mắt các công cụ phát hiện.
Các ví dụ về kết quả dương tính giả (false positives):
- Việc cập nhật một coding agent đã kích hoạt cảnh báo "Ransomware Operations detected" do hành vi của trình cài đặt Electron/Squirrel.
- Một tiến trình từ node.exe thực thi OpenAI Codex CLI agent với cờ --yolo đã kích hoạt các phát hiện ClickFix, DisableTools và DLL-injection.
- Tự động hóa của lập trình viên kích hoạt phát hiện “PowerShell created possible reverse TCP shell”.
Đội ngũ bảo mật nên làm gì
Bước đầu tiên cho mọi SOC là tinh chỉnh các phát hiện cũ đang gây ra quá nhiều nhiễu. Tiếp theo, hãy xác định các chính sách về thông tin nào có thể được chia sẻ với các nền tảng AI bên thứ ba và chủ động săn tìm các cờ permission-bypass, các đường hầm không được phép và các quyền OAuth rủi ro.
Bước thứ hai khó hơn: thay đổi cách phân loại (triage). AI thực thi lệnh trên máy người dùng, với thông tin đăng nhập của người dùng. SOC cần xác định xem một hành động được thực hiện bởi người dùng hay bởi một AI agent. Chúng tôi gợi ý nên chạy các công cụ AI trong một môi trường cô lập như Docker container hoặc máy ảo (virtual machine) để hạn chế những gì agent có thể tiếp cận.
Ý nghĩa đối với SOC
Thực tế hoạt động của việc áp dụng AI trong doanh nghiệp như sau:
- Tấn công thực sự (0,02%): Không có cuộc tấn công nào được thực hiện bởi chính các agent của tổ chức. Các hoạt động tấn công thực sự chủ yếu là phishing sử dụng tên thương hiệu AI.
- Rủi ro bảo mật (5,8%): Thực tế và phần lớn vô hình trước các cảnh báo. Các agent chạy không có biện pháp bảo vệ, mở tunnel ra internet và gửi dữ liệu công ty ra ngoài.
- Nhiễu (94,1%): Chi phí chiếm ưu thế. Hành động giá trị nhất hiện nay là tinh chỉnh các phát hiện cũ để việc chạy coding agent không tạo ra cảnh báo mức độ nghiêm trọng tối đa.
Việc áp dụng AI cho đến nay chưa mang lại một làn sóng vi phạm dữ liệu do AI gây ra. Nó mang lại một làn sóng cảnh báo, phần lớn là sai lệch, che lấp một nhóm nhỏ các rủi ro thực sự. Một SOC coi mọi hành động của agent là một vụ xâm nhập sẽ sớm kiệt sức vì các dương tính giả.
Về Intezer
Intezer là một nền tảng AI SOC tự trị được xây dựng để giải quyết chính xác khoảng cách giữa khối lượng cảnh báo và khả năng của chuyên gia phân tích. Thay vì tinh chỉnh từng phát hiện một, Intezer tự động điều tra mọi cảnh báo, áp dụng phân tích cấp độ pháp chứng để xác định điều gì thực sự đang xảy ra trên endpoint hoặc trong email.
Lưu ý: Bài viết này được viết bởi Nicole Fishbein, Chuyên gia nghiên cứu bảo mật cấp cao và Chuyên gia phân tích mã độc tại Intezer.
