Cảnh báo CVE nguy hiểm từ gói NuGet độc hại

Cảnh báo CVE nguy hiểm từ gói NuGet độc hại

Cảnh báo CVE trong hệ sinh thái NuGet đang cho thấy một mối đe dọa mạng nghiêm trọng đối với lập trình viên .NET và các hệ thống CI/CD. Nhiều gói độc hại đã được phát tán âm thầm, giả mạo các thư viện phần mềm hợp pháp của Trung Quốc nhưng thực chất dùng để đánh cắp thông tin đăng nhập trình duyệt, SSH private key và dữ liệu ví tiền điện tử.

Góc nhìn về chuỗi cung ứng phần mềm trong NuGet

Chiến dịch này không tạo ra các package có dấu hiệu bất thường rõ ràng. Thay vào đó, tác nhân đe dọa xây dựng từng thư viện độc hại dựa trên mã nguồn có chức năng thật, khiến chúng trông giống các công cụ doanh nghiệp quen thuộc. Cách làm này làm tăng rủi ro bảo mật trong quy trình restore package và kiểm tra phụ thuộc.

Việc giả mạo các công cụ như AntdUI giúp gói cài đặt vượt qua bước rà soát sơ bộ. Trong bối cảnh tin tức bảo mật liên quan đến supply chain ngày càng gia tăng, đây là ví dụ điển hình cho việc mã độc được ẩn trong phần mềm hợp lệ.

Danh sách gói độc hại và phạm vi ảnh hưởng

Nhóm nghiên cứu tại Socket.dev đã phát hiện 5 package độc hại được phát hành dưới một tài khoản NuGet duy nhất là bmrxntfj. Tổng cộng, các phiên bản của nhóm gói này ghi nhận khoảng 64.784 lượt tải, ảnh hưởng đến máy lập trình viên và hệ thống build.

Theo ghi nhận, chiến dịch đã tồn tại từ ít nhất tháng 9/2025 và các package vẫn còn hoạt động tại thời điểm công bố. Đây là một trong những cảnh báo CVE theo hướng chuỗi cung ứng có độ bền cao, dù không gắn với một CVE công khai cụ thể.

  • IR.DantUI
  • IR.Infrastructure.Core
  • IR.Infrastructure.DataService.Core
  • IR.iplus32
  • IR.OscarUI

Kỹ thuật xoay phiên bản để né phát hiện

Trong tổng số 224 phiên bản được phát hành, có tới 219 phiên bản bị ẩn khỏi tìm kiếm công khai. Kỹ thuật xoay phiên bản này khiến các dấu vân tay dựa trên hash nhanh chóng mất hiệu lực và buộc đội ngũ an ninh phải cập nhật blocklist liên tục.

Với cách vận hành này, bất kỳ máy trạm phát triển hoặc máy build nào đã thực hiện package restore với các ID nêu trên đều có thể đã bị phơi nhiễm từ cuối năm 2025. Đây là một dạng lỗ hổng CVE theo nghĩa thực tế vận hành, dù bản chất nằm ở hành vi độc hại trong supply chain hơn là lỗi phần mềm truyền thống.

Cơ chế thực thi của payload

Payload kích hoạt thông qua .NET module initializer, một cơ chế mà runtime tự động gọi khi assembly phù hợp được nạp. Điều này đồng nghĩa không cần tương tác từ người dùng ngoài thao tác restore package thông thường.

Sau khi khởi chạy, malware sử dụng JIT hooking để thay thế con trỏ dispatch của compiler, từ đó giành quyền kiểm soát các method được biên dịch tiếp theo. Kỹ thuật này phù hợp với mục tiêu remote code execution trong tiến trình build hoặc tiến trình ứng dụng đã nạp assembly độc hại.

Stage hai: Infostealer we4ftg.exe

Thành phần đánh cắp dữ liệu ở giai đoạn hai có tên we4ftg.exe. Nó tập trung vào dữ liệu đã lưu trong 12 trình duyệt dựa trên Chromium, bao gồm Chrome, Edge, Brave, Firefox và Opera.

Dữ liệu được thu thập gồm:

  • Mật khẩu đã lưu
  • Autofill data
  • Session cookies
  • Thông tin thẻ thanh toán

Payload cũng xử lý cả hai kiểu mã hóa của Chrome: legacyAppBound. Điều này cho thấy mã độc đã được cập nhật gần đây và không phải mẫu cũ bị bỏ quên.

Dữ liệu mục tiêu và các dấu hiệu thu thập

Bên cạnh dữ liệu trình duyệt, chiến dịch còn nhắm tới ví tiền điện tử và dữ liệu hệ thống thường dùng trong môi trường phát triển. Đây là một dạng đánh cắp dữ liệu có phạm vi rộng, ảnh hưởng trực tiếp đến tài khoản và khóa truy cập nội bộ.

Các mục tiêu bao gồm:

  • Ví trình duyệt: MetaMask, TronLink, Phantom, Trust Wallet, Coinbase Wallet
  • Ứng dụng desktop: Exodus, Electrum, Atomic, Guarda, Ledger, Binance
  • SSH private keys
  • Outlook profiles
  • Steam credentials
  • File từ Documents, Desktop và Downloads

Trong bối cảnh rò rỉ dữ liệu nhạy cảm, các mục này đủ để mở rộng phạm vi xâm nhập nếu kẻ tấn công tái sử dụng thông tin xác thực cho dịch vụ nội bộ, kho mã nguồn hoặc ví tài sản số.

Staging, kênh C2 và hạ tầng liên quan

Dữ liệu sau khi thu thập được đặt trong một thư mục giả lập giống đường dẫn hợp lệ của Microsoft OneDrive. Tuy nhiên, OneDrive hợp lệ không tạo file theo đúng tên đó, vì vậy đây là một IOC rõ ràng để phát hiện xâm nhập.

Đây là điểm quan trọng trong phát hiện tấn công: nếu thấy file hoặc thư mục staging bất thường mang tên mô phỏng OneDrive, cần kiểm tra ngay tiến trình đã thực thi package restore gần đó.

Dữ liệu sau đó được gửi tới một command-and-control server được đăng ký trước thời điểm chiến dịch công bố khoảng 33 ngày. Domain chính phân giải tới một máy chủ đặt tại Amsterdam và được vận hành qua nhà cung cấp virtual hosting. Nameserver đi qua Njalla, một lớp hạ tầng thường được dùng để làm khó quy trình gỡ bỏ.

Một domain phụ liên quan đến máy chủ Alibaba Cloud tại Shanghai dường như phục vụ môi trường phát triển của tác nhân, nhưng không ghi nhận nhận dữ liệu bị đánh cắp trong các nguồn công khai.

Tham khảo nguồn nghiên cứu gốc: Socket.dev – 5 malicious NuGet packages impersonate Chinese UI libraries

IOC và dấu hiệu nhận diện

Việc đối chiếu IOC nên thực hiện trong SIEM, EDR hoặc nền tảng threat intelligence. Khi xử lý, cần re-fang domain/IP trong môi trường kiểm soát trước khi truy vấn.

  • Tài khoản NuGet: bmrxntfj
  • Nhóm package: IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, IR.OscarUI
  • Hành vi: .NET module initializer, JIT hooking, staging theo kiểu OneDrive giả lập
  • C2: domain điều khiển đã nêu trong báo cáo gốc, cần đối chiếu trực tiếp từ nguồn nghiên cứu để đưa vào hệ thống giám sát

Kiểm tra hệ thống và ứng phó ban đầu

Mọi máy đã từng restore các package này cần được xem là đã bị xâm nhập. Bước đầu tiên là rà soát file dự án và lock file để tìm dấu vết phụ thuộc độc hại.

grep -RInE "IR\.DantUI|IR\.Infrastructure\.Core|IR\.Infrastructure\.DataService\.Core|IR\.iplus32|IR\.OscarUI" .

Sau đó, cần xoay vòng toàn bộ bí mật đã tồn tại trên máy hoặc pipeline bị ảnh hưởng. Điều này bao gồm credentials, API keys, SSH keyswallet seeds.

Đội ngũ an ninh cũng nên cấu hình cảnh báo cho kết nối tới domain C2 đã biết và theo dõi hành vi tạo file bất thường trong đường dẫn staging mô phỏng OneDrive. Đây là các chỉ dấu trực tiếp hỗ trợ phát hiện xâm nhập trong môi trường build và workstation.

Gợi ý kiểm tra bổ sung trên máy Windows

# Kiểm tra tiến trình đáng ngờ và package restore gần đây
Get-Process | Sort-Object CPU -Descending | Select-Object -First 20
Get-ChildItem -Path $env:USERPROFILE -Recurse -ErrorAction SilentlyContinue | 
  Where-Object { $_.Name -match 'OneDrive' -or $_.FullName -match 'IR\.' }

Trong các môi trường có telemetry, nên ưu tiên truy vấn lịch sử thực thi của tiến trình dotnet, nuget và các tiến trình build liên quan để xác định điểm nạp assembly ban đầu. Việc này đặc biệt quan trọng khi xử lý mối đe dọa từ gói NuGet giả mạo và các hoạt động tấn công mạng theo chuỗi cung ứng.