Storm-3168 trên Azure: tấn công bằng service principal, admin cần làm gì ngay?

Storm-3168 trên Azure là một trong những case threat intel đáng chú ý cuối tháng 9/2026 vì nó không bắt đầu từ headline “có thêm một CVE mới”, mà từ một chuỗi hoạt động cloud destruction có thật do Microsoft Security Research quan sát trong môi trường Azure bị xâm phạm. Theo Microsoft, nhóm này liên quan tới JADEPUFFER — threat actor từng được Sysdig công bố hồi tháng 7/2026 là chiến dịch ransomware mang tính agentic đầu tiên được ghi nhận rộng rãi. Điểm mới lần này là Microsoft đã mô tả cụ thể cách actor dùng service principal bị lộ để do thám tenant Azure, xoá tài nguyên và thu thập khoá truy cập có thể phục vụ các bước tống tiền hoặc đánh cắp dữ liệu tiếp theo.

Với đội IT và SecOps, đây là lời nhắc rất thực tế rằng rủi ro cloud không chỉ đến từ VM public hay app web thiếu vá. Một service principal bị lộ, nếu còn hiệu lực và được gán quyền quá rộng, có thể trở thành “chìa khoá hợp pháp” để attacker xoay trục trong Azure Resource Manager. Vì vậy, bài toán phòng thủ ở đây nằm ở ba lớp cùng lúc: quản lý secret, nguyên tắc least privilege và bảo vệ tài nguyên phục hồi trước các pha phá hoại có chủ đích.

Tóm tắt mối đe doạ: Storm-3168 trên Azure đang làm gì?

Microsoft cho biết họ quan sát thấy hai service principal bị xâm phạm thuộc cùng một tenant. Service principal thứ nhất chủ yếu làm nhiệm vụ reconnaissance và resource discovery. Service principal thứ hai đi xa hơn: vừa dò tài nguyên, vừa thực hiện phá hoại, vừa thu thập thông tin xác thực có thể hỗ trợ các bước hậu kỳ. Điều này rất quan trọng, vì nó cho thấy actor không dùng một tài khoản duy nhất theo kiểu “đăng nhập vào rồi bấm tay”, mà đã chia vai trò vận hành theo hướng có tổ chức hơn.

Trong cửa sổ hoạt động mà Microsoft ghi nhận, một service principal đã thực hiện hơn 300 thao tác đọc để liệt kê Azure Virtual Machines, subscriptions, resource groups và các resource khác trong khoảng 15 giờ 30 phút. Khoảng 90 phút sau khi phase discovery bắt đầu, service principal còn lại đã liệt kê VM và resource groups trên hai subscriptions chỉ trong vài giây, cùng network fingerprint và cùng user agent python-requests/2.34.2. Sau khi kết thúc inventory, cùng identity này chuyển sang các thao tác có tính chất phá hoại và credential collection.

Phạm vi ảnh hưởng: tài nguyên Azure nào nằm trong vùng rủi ro?

Theo bài nghiên cứu của Microsoft, chuỗi tấn công nhắm tới nhiều loại tài nguyên khác nhau trong Azure thay vì chỉ tập trung vào một workload đơn lẻ. Danh sách được nêu đích danh gồm Azure Storage Accounts, Azure SQL databases, Key Vaults, Function Apps, App Services, Virtual Machines và cả các resource/lock liên quan tới backup hoặc recovery. Điều này khiến Storm-3168 trên Azure trở thành một case có ý nghĩa vận hành lớn: mục tiêu của actor dường như là làm rộng bề mặt ảnh hưởng và đồng thời bào mòn khả năng phục hồi của nạn nhân.

• Azure Storage Accounts: bị nhắm xoá hàng loạt và sau đó còn bị yêu cầu ListKeys để lấy access keys.
• Azure SQL databases: bị actor thử xoá song song với storage, dù lần này thất bại vì dùng API version không được hỗ trợ.
• Key Vault, Function App và App Service plan: đã có tài nguyên bị xoá thành công trong cùng resource group.
• Backup và recovery controls: actor cố xoá Azure Site Recovery locks và Azure Backup protection locks, cho thấy ý đồ làm suy yếu khả năng khôi phục.
• Workload identity có quyền rộng: là bề mặt gốc dễ bị lạm dụng khi secret còn hiệu lực và RBAC chưa được siết chặt.

Microsoft cũng mô tả một hướng initial access có giá trị cảnh báo rất cao với doanh nghiệp: client ID, client secret và tenant ID của service principal đã từng bị lộ ở dạng plaintext trong lịch sử chỉnh sửa của một GitHub issue public. Hãng nói rõ rằng việc chỉ xoá nội dung công khai hoặc sửa issue không làm secret mất hiệu lực. Nếu secret từng xuất hiện ở internet public, tổ chức phải coi nó là đã bị lộ và cần revoke hoặc rotate ngay, kể cả khi dòng bí mật đã được sửa lại từ lâu.

Mức độ nghiêm trọng của Storm-3168 trên Azure

Đây không phải một bài CVE nên Microsoft không công bố CVSS, và cũng không có điểm số kiểu NVD để dựa vào. Tuy vậy, nhìn theo góc độ thực chiến, mức độ nghiêm trọng là rất cao. Lý do là actor đã có khả năng dùng identity hợp lệ để quan sát tenant ở quy mô rộng, phát động hơn 150 thao tác liên quan tới phá hoại hoặc credential collection trong 35 phút, và mở một pha phá hoại kéo dài khoảng 7 phút nhằm vào các tài nguyên cốt lõi. Chỉ riêng việc kết hợp phá hoại với ListKeys thành công cho hơn 30 storage account đã đủ để chuyển case này từ “suspicious activity” sang “incident ưu tiên cao”.

Microsoft lưu ý rằng họ không quan sát thấy ransom note và cũng chưa xác nhận successful data exfiltration trong case được mô tả. Nhưng điều đó không làm giảm mức báo động. Khi một actor vừa xoá tài nguyên, vừa cố làm suy yếu backup/recovery, vừa thu thập access keys có thể cấp quyền vào dữ liệu, thì chuỗi hành vi đó đã rất gần với mục tiêu extortion hoặc ransomware-aligned activity. Nói ngắn gọn: nếu đội vận hành chờ tới lúc có ransom note mới coi là khẩn, họ đã phản ứng quá muộn.

Chuỗi tấn công diễn ra như thế nào?

1. Discovery quy mô rộng: service principal đầu tiên liệt kê subscriptions, VMs, resource groups và nhiều tài nguyên khác để dựng bản đồ tenant.
2. Inventory tăng tốc: service principal thứ hai lặp lại các thao tác discovery trên hai subscriptions chỉ trong vài giây, cho thấy mức độ tự động hoá cao.
3. Dò nơi có thể lộ credential: actor kiểm tra App Service configuration stores và tìm Azure OpenSearch resources.
4. Probe trước phá hoại: ngay sau một yêu cầu ListKey thất bại với storage account không tồn tại, actor chuyển sang pha impact.
5. Destructive phase: hơn 100 lần thử xoá storage account, xoá thành công một số tài nguyên như Key Vault, Function App và App Service plan.
6. Tấn công song song vào data services: nhiều lần thử xoá Azure SQL database diễn ra cùng lúc, dù thất bại do API version không phù hợp.
7. Nhắm vào lớp phục hồi: actor cố xoá lock bảo vệ Site Recovery và Azure Backup.
8. Credential collection: khoảng 30 phút sau pha phá hoại, cùng service principal gửi hơn 30 yêu cầu ListKeys để lấy access keys của các storage account, gồm cả storage liên quan tới Site Recovery.

Microsoft còn chỉ ra nhiều tín hiệu cho thấy đây là hoạt động có điều phối bằng automation hoặc script. Hãng quan sát thấy năm token khác nhau được phát hành cho service principal dùng trong pha phá hoại và credential collection; bốn token phục vụ xoá tài nguyên, token còn lại phụ trách inventory và lấy storage keys. Việc nhiều token hoạt động chồng lấn trong cùng một khung thời gian cho thấy actor đang tìm cách tăng tốc và tách luồng công việc, thay vì chạy từng lệnh đơn lẻ một cách thủ công.

Khuyến nghị hành động: doanh nghiệp nên làm gì ngay?

Phần đáng giá nhất trong advisory là Microsoft không dừng ở việc kể lại incident, mà còn đưa ra một checklist giảm thiểu khá rõ. Trước hết, tổ chức nên bật các gói bảo vệ phù hợp trong Microsoft Defender for Cloud cho các workload Azure quan trọng, gồm Resource Manager, Storage, Key Vault, App Service và Databases. Đây là lớp telemetry và cảnh báo nền tảng giúp phát hiện các thao tác phá hoại hoặc lạm dụng identity sớm hơn.

• Kiểm tra secret và workload identity: không để client secret, storage key, connection string hoặc bất kỳ secret nào trong source code, file cấu hình, issue tracker hay kho public. Xem thêm hướng dẫn chính thức về Microsoft Entra Workload ID.
• Rotate ngay secret từng bị lộ: nếu một secret từng xuất hiện công khai, hãy coi như nó đã bị compromise dù bài đăng hay issue đã được sửa lại.
• Áp dụng least privilege: rà lại role assignments và làm theo best practices for Azure RBAC để tránh service principal có quyền vượt quá nhu cầu thật.
• Bảo vệ backup và recovery resources: giới hạn truy cập, giám sát chặt thay đổi với lock/protection controls và theo dõi hướng dẫn Azure Backup security best practices.
• Hunt theo chuỗi hành vi: ưu tiên correlation giữa ARM destructive operations, ListKeys bất thường, thay đổi backup locks và token activity chồng lấn thay vì chỉ săn IOC rời rạc.

Nếu đội cloud security còn đang dùng một số service principal “legacy” với quyền Owner hoặc Contributor rộng ở scope subscription, đây là lúc nên xem lại ngay. Microsoft Learn nhấn mạnh một nguyên tắc rất cơ bản nhưng thường bị bỏ qua: chỉ cấp đúng lượng quyền mà ứng dụng thực sự cần, ở đúng scope mà ứng dụng đó phải vận hành. Với case Storm-3168 trên Azure, least privilege không phải lý thuyết compliance, mà là lớp giảm blast radius rất thực tế.

Checklist 24 giờ cho đội Cloud, IAM và SOC

• Rà toàn bộ service principal/workload identity có quyền rộng ở scope subscription hoặc management group.
• Kiểm tra nơi lưu secret: repo public, issue tracker, wiki, pipeline variables, file cấu hình cũ và artifact lưu trữ lâu ngày.
• Hunt các thao tác Delete, ListKeys, thay đổi lock/protection control và hoạt động ARM bất thường phát sinh gần nhau.
• Xác minh xem storage account, Key Vault, App Service và backup resources nào đang thiếu lớp bảo vệ từ Defender for Cloud hoặc policy giám sát.
• Kiểm tra lại quy trình rotation cho client secret và ưu tiên chuyển dần sang cơ chế giảm phụ thuộc vào long-lived secret khi workload cho phép.
• Đưa case này vào playbook tabletop nội bộ để bảo đảm cloud team, IAM team và SOC có cùng ngôn ngữ ứng phó khi identity bị lạm dụng.

Kết luận

Storm-3168 trên Azure cho thấy chỉ một service principal bị lộ nhưng còn hiệu lực cũng có thể mở ra chuỗi do thám, phá hoại và thu khoá truy cập trên nhiều lớp tài nguyên cloud. Điểm đáng sợ không nằm ở một lỗ hổng đơn lẻ, mà ở việc attacker đang khai thác chính những identity và quyền hợp lệ mà doanh nghiệp tự cấp cho workload của mình. Nếu tổ chức của bạn đang vận hành Azure ở quy mô lớn, đây là lúc cần siết secret hygiene, RBAC và bảo vệ recovery infrastructure như một chương trình ưu tiên, không chỉ là việc dọn dẹp định kỳ. Bạn có thể theo dõi thêm các bài Security thực chiến khác tại Office365Vietnam.info.