Microsoft ghi nhận một agent dùng framework ARTEX có thể đi từ quét GitHub tìm secret bị lộ đến lấy dữ liệu trong Azure Key Vault chỉ trong năm phút. Điểm nguy hiểm không nằm ở một kỹ thuật khai thác hoàn toàn mới, mà ở việc AI nối các bước dò tìm, xác thực và di chuyển trong cloud với tốc độ máy.
Từ GitHub đến Azure Key Vault trong 5 phút: ARTEX cho thấy AI agent đang tăng tốc đánh cắp thông tin xác thực
Một secret bị đẩy nhầm lên GitHub vốn đã là sự cố bảo mật quen thuộc. Điều thay đổi trong các chiến dịch mới không phải là cách lập trình viên mắc lỗi, mà là khoảng thời gian giữa lúc lỗi xuất hiện và lúc kẻ tấn công biến nó thành quyền truy cập thực tế. Microsoft cho biết trong ít nhất một trường hợp, một agent đã đi từ quét GitHub để tìm thông tin xác thực đến lấy dữ liệu trong Azure Key Vault chỉ trong năm phút.
Năm phút là khoảng thời gian đủ để một nhóm vận hành chưa kịp nhận cảnh báo, chưa kịp xác định secret thuộc dịch vụ nào, nhưng chuỗi quyền truy cập phía sau đã có thể bị mở rộng. Đây là điều khiến chiến dịch được Microsoft mô tả đáng chú ý: AI agent không chỉ giúp tìm nhanh hơn. Nó có thể đọc kết quả, thử thông tin xác thực, gọi API cloud, nhận ra yêu cầu thất bại và điều chỉnh cách gọi để tiếp tục.
Microsoft Threat Intelligence công bố nghiên cứu ngày 5/11/2026, mô tả một framework tấn công có tên ARTEX được dùng để tìm credential, application secret và cả API key phục vụ suy luận AI trong các repository GitHub công khai. Theo Microsoft, hoạt động truy vấn khối lượng lớn đã xuất hiện từ tháng 8. Khi tìm được secret còn hiệu lực, công cụ có thể chuyển sang các bước tiếp theo mà không cần người vận hành ngồi trước bàn phím liên tục.
Từ một secret bị lộ đến danh tính ứng dụng có quyền trong cloud
Một client secret của ứng dụng OAuth không giống mật khẩu người dùng. Nó là thông tin xác thực để một ứng dụng chứng minh danh tính với nền tảng, thường thông qua service principal hoặc workload identity. Nếu ứng dụng được cấp quyền rộng, người giữ secret có thể thực hiện thao tác bằng danh tính của ứng dụng — đôi khi không cần xuất hiện bất kỳ tài khoản người dùng nào.
Microsoft ghi nhận các lần đăng nhập service principal thành công trên nhiều tenant, sau đó là hoạt động dò tìm tài nguyên Azure, lấy thông tin trong Key Vault và Storage Account, truy vấn Microsoft Graph, rồi truy cập tài liệu trong SharePoint và OneDrive. Các đối tượng bị tìm kiếm gồm storage key, connection string, thông tin xác thực của App Service, kết nối AI/ML và credential của Azure Kubernetes Service. Ở một số trường hợp, agent còn thử dùng các tài nguyên AI bị chiếm quyền để hỗ trợ hoạt động tiếp theo.
Chi tiết đáng chú ý là cách công cụ xử lý lỗi API. Microsoft ghi nhận những yêu cầu đầu tiên bị trả về HTTP 400 vì dùng sai phiên bản API hoặc nhầm loại endpoint. Chỉ vài chục giây sau, yêu cầu được gửi lại với phiên bản hoặc phương thức phù hợp và nhận HTTP 200. Đây là dấu hiệu của một quy trình có khả năng thích nghi: thử, đọc phản hồi, sửa tham số rồi thử lại. Một kịch bản tấn công viết cứng thường cần người vận hành cập nhật khi môi trường thay đổi; agent có thể thu hẹp khoảng trống đó.
Tuy nhiên, không nên hình dung ARTEX như một mô hình AI tự nghĩ ra toàn bộ cuộc tấn công từ đầu. Microsoft mô tả framework này sử dụng các công cụ quen thuộc như Nmap, curl, wget, HTTP client viết bằng Python và trình duyệt Chromium chạy headless thông qua Playwright. AI nằm ở lớp điều phối và phân tích kết quả; phần lớn thao tác vẫn là công cụ bảo mật và API thông thường. Sự nguy hiểm đến từ việc kết nối chúng thành một chuỗi có thể chạy ở tốc độ máy.
Microsoft ngày 6/11 công bố thêm một nghiên cứu về nhóm Storm-3358, một cụm xâm nhập có động cơ tài chính mà hãng theo dõi, nhắm vào các tổ chức tài chính ở Đông Nam Á và một số tổ chức lớn khác. Trong chiến dịch này, ARTEX được kết hợp với công cụ tự động truyền thống để quét hệ thống công khai, khai thác các lỗi như tải tệp ẩn danh và SSRF, sau đó cài remote access trojan để duy trì truy cập và di chuyển ngang. Đây là một hoạt động khác được Microsoft mô tả, không nên mặc định mọi dấu vết trong các báo cáo ARTEX đều thuộc cùng một nhóm hoặc cùng một chuỗi xâm nhập.
Tốc độ tấn công làm thay đổi cách đội phòng thủ phải nhìn log
Todyl, đơn vị cung cấp dịch vụ giám sát an ninh, cho biết họ phát hiện một chiến dịch sử dụng credential ứng dụng để đăng nhập vào Entra ID và Azure DevOps. Trong bản cập nhật ngày 6/11, Todyl nói Microsoft đã đối chiếu và xác nhận cơ sở hạ tầng liên quan với nghiên cứu về ARTEX. Dữ liệu telemetry mà Todyl quan sát được cho thấy khoảng 95% lượt đăng nhập đến từ client chạy script, có đợt lên tới 24 lượt trong 10 giây và tải tệp với nhịp độ khoảng một tệp mỗi giây. Đây là số liệu trong các môi trường mà Todyl theo dõi, không phải thống kê toàn bộ nạn nhân trên thị trường.
Hai báo cáo cũng cho thấy dấu vết mạng không đứng yên. Tác nhân thay đổi user-agent, chuyển từ curl và Python sang giả dạng trình duyệt, thậm chí chuyển từ secret ứng dụng sang phát lại refresh token của người dùng. Vì vậy, chặn một địa chỉ IP hay một chuỗi user-agent cụ thể chỉ có thể giúp phát hiện một giai đoạn của chiến dịch. Microsoft lưu ý framework có thể thay đổi các dấu vết này; điều đáng săn tìm hơn là hành vi: một ứng dụng vừa đăng nhập đã lần lượt xin token cho Resource Manager, Key Vault, Storage và Graph; nhiều service principal ít dùng xuất hiện từ cùng một nguồn; hoặc các yêu cầu thất bại được thử lại với tham số mới trong thời gian rất ngắn.
Cũng cần thận trọng với suy luận về nguồn gốc của cuộc tấn công. Todyl cho biết một số tổ chức thấy mức sử dụng API AI tăng đột biến và chi phí phát sinh trong vài phút. Điều đó phù hợp với khả năng khóa API bị dùng để chạy agent của kẻ tấn công hoặc bị bán lại, nhưng bản thân việc token được phát hành không chứng minh một nhà cung cấp AI đã bị xâm nhập. Todyl nói họ chưa xác nhận nền tảng của bất kỳ nhà cung cấp AI nào bị xâm phạm. Sự khác biệt giữa khóa của khách hàng bị đánh cắp và hạ tầng của nhà cung cấp bị tấn công là rất quan trọng.
Xóa secret khỏi Git không đồng nghĩa đã thu hồi quyền truy cập
Bài học vận hành rõ nhất nằm ở một lỗi nhiều đội phát triển vẫn mắc: khi phát hiện secret trong repository, họ xóa dòng cấu hình rồi cho rằng sự cố đã được xử lý. Nhưng bản sao có thể còn trong lịch sử commit, fork, cache, log hoặc bản lưu trữ. Quan trọng hơn, credential đã lộ vẫn còn hiệu lực cho đến khi bị thu hồi hoặc xoay vòng.
Microsoft khuyến nghị rà soát repository, bật secret scanning và push protection, sau đó rotate ngay các khóa hoặc credential bị lộ. Nếu ứng dụng dùng client secret dài hạn, nên chuyển dần sang managed identity hoặc cơ chế xác thực workload không phải lưu khóa trong mã nguồn. Quyền của service principal cần được thu hẹp theo nguyên tắc least privilege; một ứng dụng chỉ cần đọc một kho dữ liệu không nên có quyền liệt kê hoặc tải toàn bộ tài nguyên của tenant.
Khi đã có dấu hiệu bị truy cập, đội vận hành phải kiểm tra cả service principal sign-in logs lẫn audit log của Key Vault, Storage, Azure DevOps và Microsoft 365. Nếu ứng dụng bị xâm nhập có quyền đọc nhiều vault, cần xoay cả những credential mà nó có thể đã lấy được, không chỉ secret ban đầu trong GitHub. Với API key AI, nên đặt quota và cảnh báo chi phí để một lần lộ khóa không biến thành hóa đơn bất thường hoặc kênh tiêu thụ tài nguyên ngoài kiểm soát.
AI không tạo ra lỗ hổng mới trong OAuth hay Azure. Nó làm cho một lỗi cũ — secret bị lộ — có thể được phát hiện và khai thác theo chuỗi nhanh hơn, đồng thời giảm nhu cầu can thiệp của con người ở từng bước. Với doanh nghiệp, điều đó khiến thời gian phản ứng phải được tính bằng phút chứ không còn bằng ngày. Và với đội phát triển, bảo vệ secret không nên dừng ở việc giữ kín file .env; nó phải bắt đầu từ cách ứng dụng được cấp danh tính, giới hạn quyền và thu hồi credential khi có sự cố.
Nguồn tham khảo
- Microsoft Threat Intelligence & Microsoft Security Research — Threat actors use agentic AI tooling to find and abuse exposed secrets, November 5, 2026
- Microsoft Threat Intelligence — ARTEX abuse expands as cybercriminals target financial sector, November 6, 2026
- Nicholas Koken, Todyl — Stolen App Credentials, Real Access: An Actor Is Signing Into Entra ID and Azure DevOps as Your Workloads, updated November 6, 2026
