Vào đầu tháng 8, các nhà nghiên cứu của GitGuardian đã phát hiện ra rằng một biến thể sâu infostealer Shai-Hulud gần đây đã phát triển để quét credentials tại 469 vị trí trong các môi trường lập trình, công cụ CI/CD, cấu hình cloud và thậm chí cả cấu hình công cụ AI.
Các biến thể trước đây của sâu infostealer này chỉ kiểm tra 189 đường dẫn. Sự gia tăng đột biến này nói lên rất nhiều điều: Kẻ tấn công đã ngừng cố gắng phá vỡ các mối quan hệ tin cậy và bắt đầu sử dụng chính các credentials vốn đang duy trì những mối quan hệ đó.
Chuỗi cung ứng phần mềm luôn phụ thuộc vào sự tin cậy.
Các nhà phát triển tin tưởng vào package registries. Các tổ chức tin tưởng vào những người duy trì mã nguồn (maintainers). Hệ thống CI/CD tin tưởng vào các credentials và danh tính (identities) mà chúng được cấp. Các ứng dụng tin tưởng vào các phụ thuộc (dependencies) mà chúng tải xuống trong quá trình build.
Kẻ tấn công nhận ra rằng chúng không cần phải phá vỡ bất kỳ yếu tố nào trong số đó. Chúng chỉ cần tìm ra nơi các credentials và đặc quyền hiện có (standing privileges) đang trú ngụ.
Đây là lý do thúc đẩy sự tập trung hiện nay vào việc phòng thủ chuỗi cung ứng phần mềm trên nhiều hệ sinh thái. Việc bảo vệ package registries và dependencies vẫn quan trọng, nhưng cốt lõi của vấn đề — yếu tố thực sự cần thiết để sâu infostealer thành công — lại nằm bên dưới những hệ thống đó.
Kẻ tấn công đang săn lùng quyền hạn có thể tái sử dụng (reusable authority). Việc ngăn chặn Shai-Hulud tiếp theo bắt đầu bằng việc giải quyết và bảo mật lớp credential.
Shai-Hulud biến credentials bị đánh cắp thành cuộc tấn công chuỗi cung ứng kéo dài
Shai-Hulud thuộc về một loại hình tấn công chuỗi cung ứng đang gia tăng, chuyên tìm kiếm các credentials trong các môi trường bị xâm nhập để tiếp tục cuộc tấn công.
Một token được tìm thấy trên máy trạm của nhà phát triển có thể mở quyền truy cập vào mã nguồn. Chính mã nguồn đó có khả năng chứa các cloud credentials, cung cấp quyền truy cập vào hạ tầng. Một GitHub token có thể cho phép quyền ghi vào các kho lưu trữ (repositories) bổ sung. Một credential dùng để xuất bản gói (package publishing) có thể cho phép kẻ tấn công phát hành phần mềm thông qua một kênh mà các nhà phát triển đã tin tưởng. Credentials trở thành mô liên kết giữa môi trường bị xâm nhập này với môi trường tiếp theo.
Hệ sinh thái rộng lớn đã thấy con đường đó trực tiếp đến mức nào. Một lần quét nhanh qua bất kỳ trang tin an ninh mạng nào cũng sẽ thấy vô số câu chuyện về các đợt lây nhiễm mới trên nhiều ngôn ngữ, trình quản lý gói và hệ điều hành.
Thu thập credentials mang lại cho kẻ tấn công đích đến tiếp theo
Môi trường phát triển hiện đại chứa nhiều tài liệu xác thực hơn là chỉ riêng kho mã nguồn. Credentials xuất hiện ở những nơi dễ đoán như tệp .env, lịch sử shell và cấu hình trình quản lý gói. Nhưng cũng có những bí mật (secrets) trong bộ nhớ đệm CLI, cấu hình CI/CD và cài đặt IDE. Ngày càng nhiều đội ngũ tìm thấy các khóa truy cập (access keys) trong cấu hình được sử dụng bởi các công cụ phát triển AI.
Đây là lý do tại sao những kẻ tạo ra mã độc thu thập credential liên tục mở rộng bán kính tìm kiếm. Kẻ tấn công không nhất thiết phải biết credential nào quan trọng nhất trước khi thu thập; chúng có thể thu gom bất cứ thứ gì có sẵn và phân loại sau đó.
Các nhà phòng thủ nên giải quyết vấn đề theo hướng ngược lại. Đội ngũ bảo mật phải xác định credentials nào quan trọng nhất và xử lý rủi ro lộ lọt của chúng trước khi kẻ tấn công có cơ hội sử dụng.
Quyền xuất bản tạo ra con đường lây lan
Credentials dùng để xuất bản gói (Package publishing credentials) đáng được chú ý đặc biệt vì chúng biến việc trộm cắp thông tin xác thực thành hành vi phân phối phần mềm độc hại, đẩy cuộc tấn công đi xa hơn.
Các tokens mà nhà phát triển dùng để xuất bản mang theo quyền hạn đối với một gói phần mềm tin cậy mà các nhà phát triển khác, hệ thống build và các tổ chức sẽ tự động tiêu thụ. Sự tin cậy đó là thứ kẻ tấn công lạm dụng. Điều này tạo ra ưu tiên hàng đầu cho các nhà phòng thủ: giảm số lượng publishing credentials có sẵn để bị đánh cắp.
Các tổ chức cần cắt giảm sự phụ thuộc vào các tokens xuất bản có thời hạn dài. Chúng ta nên khuyến khích tất cả các nhà sản xuất phần mềm áp dụng phương thức xác thực có thời hạn ngắn, được xác minh qua OpenID Connect (OIDC) hoặc các cơ chế tương tự. Các bản cập nhật gần đây của Docker và GitHub Actions đã thúc đẩy hệ sinh thái đi theo hướng này, bao gồm xác thực mạnh hơn và sử dụng trusted publishing nhiều hơn.
Bất kỳ publishing credential có thời hạn dài nào còn tồn tại đều phải được xử lý như một hạ tầng cực kỳ nhạy cảm.
Credentials kết nối các hệ thống vốn được quản lý riêng rẽ
Các đội ngũ bảo mật thường nghĩ về tổ chức theo các loại bảo mật: bảo mật kiểm soát nguồn (source control security), bảo mật CI/CD, bảo mật cloud, bảo mật endpoint và bảo mật ứng dụng. Credentials trải dài trên tất cả các phân vùng này. Một nhà phát triển duy nhất có thể xác thực với GitHub, npm, AWS, Kubernetes, APIs nội bộ và hạ tầng build chỉ trong một ngày làm việc bình thường, và các đường ống CI/CD cũng thường mang theo một bộ đa dạng tương đương.
Một credential bị bỏ lại trong môi trường phát triển có thể đại diện cho quyền hạn ở một nơi hoàn toàn khác. Tệp có thể nằm trên laptop trong khi credential điều khiển tài nguyên cloud hoặc cấp quyền xuất bản gói phần mềm.
Việc phát hiện ra bí mật ở đâu chỉ kể một phần câu chuyện. Các tổ chức hướng tới sự trưởng thành trong quản lý bí mật (secrets management) cũng cần biết liệu credential đó có hợp lệ hay không, thuộc về danh tính nào, hệ thống nào chấp nhận nó, nó mang đặc quyền gì, nó tiếp cận môi trường nào và ai chịu trách nhiệm khắc phục.
Điều đó biến việc phát hiện bí mật thành quản lý rủi ro credential (credential risk management).
Không phải mọi bí mật bị lộ đều tạo ra rủi ro như nhau
Một danh sách chứa 100.000 phát hiện về bí mật không có nghĩa là 100.000 sự cố khẩn cấp như nhau.
Một số credentials đã mất hiệu lực. Số khác chỉ tiếp cận được các môi trường phát triển dùng một lần. Một số lượng nhỏ hơn cung cấp quyền truy cập vào cơ sở dữ liệu production, hạ tầng cloud, hệ thống triển khai hoặc quyền xuất bản gói. Việc xử lý tất cả các phát hiện này như nhau chỉ tạo ra sự quá tải thay vì giảm thiểu rủi ro.
Một chiến lược khắc phục hữu ích bắt đầu bằng cách hỏi xem kẻ tấn công sẽ chọn gì đầu tiên. Câu trả lời cung cấp một thứ tự ưu tiên thực tế.
Ưu tiên 1: Loại bỏ các khóa xuất bản gói khỏi văn bản rõ (cleartext)
Đây là hành động then chốt mà các nhà phát triển và đội ngũ cần thực hiện để ngăn chặn các biến thể Shai-Hulud và các sâu infostealer khác. Các tổ chức duy trì các gói phần mềm nên xác định nơi các publishing tokens tồn tại và xác định xem liệu các credentials hiện có còn cần thiết hay không. Việc tìm kiếm này cần mở rộng ra ngoài các kho lưu trữ.
Tìm credentials xuất bản ở bất cứ nơi nào nhà phát triển và pipeline để lại
Thông thường, các tác giả gói phần mềm ghi các khóa xác thực vào các tệp cấu hình cục bộ như một phần của quy trình làm việc thông thường. Nhưng một bí mật không cần phải được commit vào Git mới bị mã độc trên máy nhà phát triển tìm thấy. Đó cũng là lý do tại sao các cuộc tấn công chuỗi cung ứng gần đây ngày càng nhắm vào chính môi trường làm việc của nhà phát triển.
Các đội ngũ bảo mật và phát triển cần có cái nhìn tổng quan về nơi các publishing credentials thực sự tích tụ, sau đó lập kế hoạch để loại bỏ chúng.
Thay thế credentials xuất bản có thời hạn dài khi có thể
Credential khó đánh cắp nhất đối với kẻ tấn công là credential không tồn tại. Nhưng nếu chúng phải tồn tại, cửa sổ truy cập càng ngắn càng tốt.
Mục tiêu luôn là loại bỏ quyền hạn xuất bản có thể tái sử dụng nằm dưới dạng cleartext. Các tổ chức nên chuyển việc xuất bản gói sang các cơ chế dựa trên danh tính, có thời hạn ngắn như OIDC. Hầu hết các nền tảng cloud đang chuyển hướng sang các dịch vụ federated security token như AWS STS.
Ưu tiên 2: Loại bỏ các credentials production bị lộ
Ngăn chặn con đường lây lan giúp chặn đứng sự lây nhiễm nhưng không làm ngừng thiệt hại hiện tại. Sau các publishing credentials, các tổ chức nên tập trung vào các credentials cung cấp quyền truy cập vào các hệ thống production quan trọng.
Mỗi tổ chức nên có hệ thống phân cấp riêng về những gì được coi là quan trọng, nhưng một danh sách ngắn có thể bao gồm:
- Tài khoản cloud production
- Cơ sở dữ liệu chứa thông tin khách hàng
- Hạ tầng ký số (Signing infrastructure)
- Cụm Kubernetes
- Công cụ triển khai (Deployment tooling)
- Giao diện quản trị
Xác định blast radius thực sự sẽ giúp bạn ưu tiên hệ thống nào cần giải quyết để loại bỏ các bí mật dài hạn, hoặc ít nhất là hệ thống nào cần thực hiện xoay vòng khóa (rotate secrets).
Ưu tiên 3: Xếp hạng mọi bí mật bị lộ còn lại theo rủi ro
Khi việc xuất bản gói và quyền truy cập production đã được xử lý, tổ chức có thể làm việc một cách hệ thống thông qua danh sách credential còn lại. Mục tiêu không phải là xoay vòng mọi thứ một cách ngẫu nhiên, mà là xây dựng một kế hoạch hành động liên tục loại bỏ các credentials hữu ích nhất khỏi con đường của kẻ tấn công.
Tính hợp lệ là điểm bắt đầu tốt, nhưng không phải tất cả
Một credential còn hiệu lực xứng đáng được chú ý ngay lập tức hơn một cái đã hết hạn. Theo nghiên cứu State of Secrets Sprawl của GitGuardian, có tới 28,65 triệu bí mật mới được hardcoded vào các commits GitHub công khai chỉ riêng trong năm 2025, tăng 34% so với năm trước.
Khối lượng đó khiến việc phân loại thủ công trở nên phi thực tế. Các tổ chức cần xác định những phát hiện nào vẫn đại diện cho khả năng xác thực sử dụng được và đưa chúng lên đầu hàng đợi.
Giảm thiểu rủi ro credential cần một quy trình lặp lại
Làn sóng tấn công Shai-Hulud mới nhất này cho thấy phản ứng cần trở thành một chu kỳ lặp lại: Phát hiện, Khắc phục và Phòng ngừa.
Các tổ chức trước tiên cần có khả năng hiển thị rộng rãi về những gì họ có — một danh sách kiểm kê duy nhất cho tất cả các credentials. Điều đó bao gồm mã nguồn và lịch sử Git, nhưng các cuộc tấn công hiện đại cho thấy cần phải xem xét xa hơn, vào các hệ thống CI/CD và môi trường của nhà phát triển.
Mục tiêu của chúng ta là đảm bảo rằng mỗi khi một sâu (worm) mới xuất hiện, sẽ có ít chìa khóa hơn để chúng có thể lạm dụng.
