AI agent ARTEX quét GitHub: 5 phút lấy secret Azure, cách kiểm tra

Lỡ đẩy một file cấu hình chứa mật khẩu lên GitHub công khai từng là chuyện "hy vọng không ai để ý". Microsoft vừa cho thấy khoảng cách đó đang bị rút xuống còn vài phút. Ngày 5/11/2026, Microsoft Threat Intelligence và Microsoft Security Research cảnh báo tin tặc đang dùng khung AI agent tấn công, trong đó có ARTEX, để tự quét kho mã nguồn công khai, đọc secret rồi tiếp tục tấn công cloud gần như không cần ngồi điều khiển từng bước.

Trong ít nhất một trường hợp, Microsoft quan sát một AI agent đi từ việc tìm secret trên GitHub tới khi lấy dữ liệu từ Azure Key Vault chỉ trong khoảng 5 phút.

Chuyện gì đã xảy ra?

Bài đăng trên Microsoft Security Blog mô tả một chiến dịch kéo dài nhiều tháng. Từ tháng 8/2026, Microsoft thấy tin tặc dùng khung AI agent gửi một lượng lớn truy vấn tới GitHub để tìm secret: thông tin đăng nhập, credential của ứng dụng, và cả API key dùng cho dịch vụ suy luận AI.

Các truy vấn thường ghép tên tổ chức đích với từ khóa về secret, dịch vụ cloud hoặc nhà cung cấp AI. Việc rê secret trên kho mã nguồn công khai vốn không mới, nhưng trước đây bị giới hạn bởi thời gian con người phải tìm repo, đọc nội dung, rồi mới biết dùng credential đó làm gì tiếp. Theo Microsoft, công cụ agentic như ARTEX vừa quét nhiều repo nhanh hơn, vừa tự phân tích kết quả rồi chuyển sang bước tấn công tiếp theo.

Microsoft không nêu tên nhóm đứng sau hoạt động quét GitHub này.

Sang giai đoạn sau, từ khoảng 28/10/2026, Microsoft quan sát các lần đăng nhập service principal thành công từ địa chỉ IP 199.19.77[.]84 trên hàng chục ứng dụng ở nhiều tenant. Có những trường hợp credential của ứng dụng đa tenant do nhà cung cấp sở hữu bị lộ ngay từ nguồn, rồi bị dùng để truy cập nhiều tenant phía sau.

ARTEX tự sửa sai khi gọi API Azure

Điểm đáng chú ý không chỉ là tốc độ, mà còn là agent biết điều chỉnh khi gặp lỗi. Microsoft mô tả chuỗi thao tác trên Azure Resource Manager (ARM) từ IP 199.19.77[.]84 giống hành vi gỡ lỗi thích nghi:

• Một loạt request liệt kê metadata secret trên nhiều Azure Key Vault trả về HTTP 400 vì dùng API version kiểu data-plane cho API control-plane của ARM. Khoảng 28 giây sau, agent chạy lại cùng đường dẫn với ARM API version 2023-07-01 và nhận HTTP 200.

• Request xem firewall rule của Azure SQL dùng API version cũ cũng bị HTTP 400; khoảng 60 giây sau, chỉ đổi tham số api-version thì thành công.

• Request POST tới endpoint Application Insights bị 400 vì API version cũ, rồi được sửa sau khoảng 80 giây.

Theo Microsoft, bộ công cụ mặc định của ARTEX gồm Nmap, curl, wget, HTTP client Python, Norma SDK WebFetch và trình duyệt ẩn (headless Chromium) chạy qua Playwright.

Sau khi có secret, agent làm gì?

Khi đã có credential ứng dụng OAuth bị lộ, agent đăng nhập với tư cách service principal, tức danh tính mà ứng dụng dùng để gọi API với đúng quyền đã được cấp. Từ đó, Microsoft thấy agent:

• Lấy dữ liệu từ Azure Key Vault và tài khoản Storage.

• Liệt kê App Service, Azure Kubernetes Service (AKS), Azure SQL và Application Insights.

• Tìm thêm secret trên Azure DevOps.

• Chạy lệnh trên máy ảo Azure qua tính năng Run Command.

• Truy cập SharePoint, OneDrive và các mục trong hộp thư qua Microsoft Graph.

• Liệt kê kết nối AI/ML, datastore và các lần triển khai model AI.

• Nhắm credential dẫn tới dịch vụ AI, gồm API key của các nhà cung cấp lớn và ứng dụng OAuth có quyền với Foundry Tools (tên cũ: Azure Cognitive Services).

Microsoft cũng ghi nhận hoạt động từ vài địa chỉ khác: 199.19.77[.]18 (nút thoát Tor, có thể gắn với hoạt động độc hại không liên quan), 65.87.223[.]26 (có dấu hiệu nhúng lệnh shell trong user agent và cố lấy token xác thực App Service), và 157.22.126[.]128 (trinh sát workload AI trên Azure AI services). Microsoft cho biết Todyl cũng đã báo cáo một chiến dịch tương tự dùng cùng các địa chỉ IP này. Trong bài "Key Eater" (3/11, cập nhật 6/11), Todyl nêu khoảng 45 bản đăng ký ứng dụng tại 18 nhà cung cấp dịch vụ quản lý (MSP), hơn 33 trường hợp đã xác thực được, lan sang 27 tổ chức phía sau.

Secret đã đưa lên repo công khai vẫn dùng được cho đến khi bị thu hồi hoặc xoay vòng. Chỉ xóa dòng secret khỏi GitHub, thậm chí sửa lại commit, cũng chưa đủ: bản sao vẫn có thể nằm trong lịch sử sửa, cache, bản lưu hoặc log.

Cách kiểm tra repo và tenant

Không phải ai cũng chạy hạ tầng Azure, nhưng hai việc sau nên làm ngay nếu bạn từng đẩy code lên GitHub:

• Soát secret trên GitHub: GitHub tự quét các repo công khai. Ngoài repo do tổ chức sở hữu, Microsoft khuyên bật theo dõi công khai (public monitoring) để phát hiện secret bị lộ ở repo thứ cấp trên toàn nền tảng. Nếu dùng Azure DevOps, cần GitHub Advanced Security for Azure DevOps hoặc GitHub Secret Protection for Azure DevOps; bật push protection để chặn secret trước khi bị đẩy lên.

• Giả định secret đã lộ là đã bị lấy: tìm thấy key trong repo công khai thì coi credential đó và ứng dụng gắn với nó đã bị xâm nhập, rồi xoay vòng ngay. Đừng chờ "may ra chưa ai tải".

Nếu tổ chức của bạn dùng Microsoft Entra ID / Azure, Microsoft khuyên rà thêm nhật ký:

• Xem nhật ký đăng nhập service principal và đăng nhập không tương tác, tìm IP 199.19.77[.]84 và 199.19.77[.]18, kể cả lần thất bại.

• Mã lỗi AADSTS7000215 (secret không hợp lệ) hoặc AADSTS7000222 (secret hết hạn) cho thấy ai đó đang cầm credential của ứng dụng bạn. Một lần thất bại rồi thành công ngay sau đó là dấu hiệu cần xử lý gấp.

• Một địa chỉ IP đăng nhập vào từ ba service principal trở lên với kết quả lẫn lộn, hoặc một ứng dụng xin token cho ARM, Key Vault, Storage và Graph trong thời gian ngắn, cũng là tín hiệu đáng ngờ.

• Đối chiếu thêm Azure Activity, nhật ký Key Vault và Storage, audit Entra, audit Azure DevOps và nhật ký Microsoft 365: lần đọc secret, tải file, đổi quyền ứng dụng hoặc sửa pipeline.

Nếu đã lộ secret thì nên làm gì ngay

Microsoft đưa ra nhóm việc để khoanh vùng và điều tra, không phải chỉ "xóa file rồi quên":

• Chặn đúng dải 199.19.77[.]84/32 (không chặn cả ASN) như một vị trí có tên trong chính sách Conditional Access, áp cho workload identity và cả chính sách chặn phía người dùng để phủ phiên bị phát lại. Chính sách workload identity cần giấy phép Workload ID Premium và chỉ phủ ứng dụng đơn tenant đăng ký trong tenant của bạn; gán theo nhóm không áp dụng cho service principal.

• Với người dùng bị ảnh hưởng: thu hồi phiên Entra, PAT và khóa SSH trên Azure DevOps.

• Với ứng dụng bị ảnh hưởng: gỡ mọi client secret, chứng chỉ và federated credential, kể cả những thứ do tin tặc thêm vào; vô hiệu hóa service principal nếu cần. Token đã cấp vẫn còn hiệu lực cho đến khi hết hạn.

• Xoay vòng mọi thứ lưu trong bất kỳ Key Vault nào mà ứng dụng đó đọc được, cùng mọi credential tìm thấy trong tài liệu đã bị truy cập.

• Nhà cung cấp dịch vụ quản lý (MSP): rà quyền Partner Center, quan hệ GDAP và các tenant khách, rồi thông báo theo hợp đồng.

Về lâu dài, Microsoft khuyên chuyển ứng dụng OAuth sang xác thực bằng managed identity thay vì nhét secret dài hạn vào mã nguồn, siết quyền service principal theo nguyên tắc đặc quyền tối thiểu, và bật các gói Microsoft Defender for Cloud phù hợp (Resource Manager, Storage, Key Vault, App Service, Databases).

Microsoft cũng mô tả lớp phòng thủ dành riêng cho agent tự trị: bẫy mật (honeypot), mồi giả như Microsoft Sentinel Deception, "hố nhựa" (tarpit) làm tốn thời gian và ngân sách của agent, cùng "chiến thắng giả" khiến agent nghĩ đã xong việc rồi dừng. Đây là kết quả thử nghiệm của Microsoft, không phải bảo đảm ngoài thực địa, và chỉ nên xem là lớp bổ sung sau khi đã giữ secret sạch và siết quyền.

Ý nghĩa với lập trình viên tại Việt Nam

Nhiều nhóm ở Việt Nam vẫn để file .env, chuỗi kết nối hoặc API key ChatGPT, Gemini, Claude ngay trong repo, rồi push nhầm lên GitHub công khai. Microsoft nhấn mạnh agent lần này không chỉ tìm credential Azure: chúng còn săn API key dịch vụ AI. Một key bị lộ có thể bị dùng để chạy chính loại agent tấn công này, hoặc bị đốt tiền suy luận trước khi bạn phát hiện.

Nếu bạn không dùng Azure thì các bước Entra/Conditional Access ở trên có thể không áp dụng, nhưng phần GitHub thì áp dụng với mọi repo công khai: quét lại lịch sử commit, xoay vòng mọi key từng xuất hiện, bật quét secret và push protection, và đừng coi việc xóa file là đã xong.

CTDO sẽ cập nhật nếu Microsoft bổ sung nhóm tấn công có tên, hoặc mở rộng danh sách dấu hiệu.

Nguồn tham khảo

• Microsoft Security Blog - Threat actors use agentic AI tooling to find and abuse exposed secrets

• Cybersecurity Dive - Hackers enlist Artex to scan GitHub repositories for exposed secrets

• The Injection - ARTEX: an agent went from GitHub secrets to Azure Key Vault in 5 minutes

• Todyl - Stolen app credentials, real access (Key Eater)