CVE-2026-59310: Chiến dịch VMware vCenter đã tấn công 361 IP tại 47 quốc gia

Broadcom đã cung cấp các phiên bản đã sửa lỗi nhưng không đưa ra biện pháp giảm thiểu thay thế. Vì vậy, cập nhật lên bản phát hành được nhà cung cấp liệt kê là cách khắc phục chính thức.

Bản vá có trước, cuộc tấn công đến sau 5 ngày

Broadcom công bố CVE-2026-59310 và phát hành bản vá ngày 29/7. QUIRSO sau đó báo cáo các dấu hiệu khai thác thực tế bắt đầu từ ngày 3/8, rồi nhanh chóng mở rộng.

Mốc thời gian này đặc biệt quan trọng với đội ngũ ứng phó sự cố. Một hệ thống được cập nhật sau ngày 3/8 không thể mặc nhiên được xem là sạch chỉ vì quá trình cài bản vá đã hoàn tất. Doanh nghiệp cần tách bạch hai việc: khắc phục lỗ hổng và đánh giá khả năng đã bị xâm nhập. Hãy vá lỗi, sau đó điều tra xem kẻ tấn công có kịp tạo đường truy cập trước thời điểm cập nhật hay không.

Quy mô chiến dịch: 361 IP tại 47 quốc gia

Các nhà nghiên cứu liên hệ hoạt động này với 361 địa chỉ IP nạn nhân được quan sát tại 47 quốc gia. Đức, Mỹ, Thổ Nhĩ Kỳ, Iran và Pháp được cho là chiếm hơn một nửa tập hợp quan sát được.

Tuy nhiên, con số này cần được hiểu đúng: một địa chỉ IP không nhất thiết tương ứng với một tổ chức, nên “361 nạn nhân” không đồng nghĩa với 361 doanh nghiệp hoặc cơ quan riêng biệt. Dù vậy, các báo cáo hiện có cho thấy đây là chiến dịch trên diện rộng nhằm vào những hệ thống vCenter có thể truy cập từ Internet hoặc bị phơi lộ trên mạng.

Vì sao QUIRSO nghi ngờ mối liên hệ với Trung Quốc?

QUIRSO đánh giá mối liên hệ với Trung Quốc của chiến dịch ở mức độ tin cậy vừa phải. Các chỉ dấu được nêu gồm hiện vật và công cụ bằng tiếng Trung, việc tái sử dụng nghiên cứu công khai, hoạt động phù hợp với giờ làm việc theo múi giờ UTC+08:00 và tập hợp nạn nhân dường như không bao gồm Trung Quốc đại lục.

Những dấu hiệu này có thể hỗ trợ nhận định về khu vực hoặc ngôn ngữ, nhưng không xác định được một nhóm nhà nước Trung Quốc cụ thể và cũng không chứng minh chiến dịch do chính phủ chỉ đạo. Việc quy kết dựa trên mã độc, khung giờ hoạt động và cách chọn mục tiêu vẫn có thể thay đổi khi xuất hiện thêm bằng chứng. Cách mô tả thận trọng nhất hiện nay là “tác nhân bị nghi có mối liên hệ với Trung Quốc”, không phải một chiến dịch được xác nhận là do nhà nước tài trợ.

Chuỗi xâm nhập được ghi nhận

Chiến dịch dường như đã khai thác CVE-2026-59310 để thực thi mã ban đầu, trước khi cài nhiều lớp duy trì và truy cập:

1. Directory traversal: Các yêu cầu được tạo thủ công nhắm vào dịch vụ Syslog nhằm thoát khỏi đường dẫn được phép và ghi nội dung do kẻ tấn công kiểm soát.
2. Duy trì bằng cron: Kẻ tấn công được cho là đã tạo các mục cron bất thường để tác vụ định kỳ thực thi lệnh tiếp theo.
3. Phát tán backdoor: Theo các báo cáo về vụ xâm nhập, curl hoặc wget được dùng để tải backdoor linuxFile, vốn sử dụng WebSocket và cơ chế làm rối XOR.
4. Reverse SSH: Công cụ reverse SSH được cài đặt để tạo kết nối đi ra tới hạ tầng do kẻ tấn công kiểm soát. Shadowserver cho biết cơ chế duy trì này xuất hiện trên toàn bộ nạn nhân trong báo cáo chuyên đề của họ.
5. Lạm dụng tài khoản và thông tin xác thực: Các nhà điều tra ghi nhận tài khoản quản trị vCenter và ESXi trái phép, cùng việc lạm dụng thông tin xác thực của VMware Directory Service.
6. Triển khai ransomware: Ít nhất một số báo cáo liên hệ hoạt động này với biến thể ransomware bắt nguồn từ Babuk, sử dụng phần mở rộng .babyk.

Phát hiện về reverse SSH có ý nghĩa đặc biệt nghiêm trọng. Shadowserver kết luận rằng những hệ thống đã triển khai cơ chế này nên được xem là bị xâm nhập hoàn toàn. Chỉ xóa một tệp thực thi hoặc một mục cron mà không xây dựng lại mức độ tin cậy của thiết bị và thay đổi thông tin xác thực đặc quyền là chưa đủ để khôi phục an toàn.

Ransomware có thể được dùng để che giấu dấu vết

Hoạt động liên quan đến .babyk không nhất thiết là một chiến dịch ransomware truyền thống, trong đó mục tiêu chính là mã hóa hàng loạt và tống tiền. Các nhà phân tích cho rằng việc mã hóa có chọn lọc nhật ký ESXi có thể nhằm cản trở điều tra và che giấu bằng chứng.

Đây vẫn là suy luận về ý đồ của kẻ tấn công, chưa phải kết luận được xác nhận. Dù vậy, bên phòng thủ nên điều tra đồng thời hai khả năng: máy ảo bị ảnh hưởng bởi ransomware và nhật ký bị can thiệp có chủ đích để làm mờ dấu vết xâm nhập.

Kho GitHub giả dạng công cụ dọn tệp tạm

Các báo cáo cũng liên hệ chiến dịch với một kho GitHub, trong đó các tệp nhị phân reverse SSH được giới thiệu như một tiện ích Linux để dọn dẹp tệp tạm. Việc ngụy trang công cụ duy trì quyền truy cập thành chương trình quản trị hoặc dọn dẹp có thể giúp mã độc dễ được phân phối hơn và ít gây chú ý trong quá trình kiểm tra thường kỳ. Tuy nhiên, bằng chứng hiện có chưa độc lập xác định ai vận hành kho này, vì vậy sự tồn tại của kho GitHub không thể được xem là bằng chứng quy kết.

Tác động đối với Broadcom và VMware

Cổ phiếu Broadcom giảm khoảng 5–6% trong ngày 14/8 khi các báo cáo về việc khai thác VMware vCenter được thị trường chú ý. Một nguồn mô tả giá cổ phiếu giảm từ 417,82 USD xuống 392,99 USD trong phiên.

Các báo cáo an ninh mạng là một yếu tố của đợt giảm, nhưng không nhất thiết là nguyên nhân duy nhất. Những tin tức cùng thời cũng đề cập các mối lo rộng hơn, trong đó có mức độ phụ thuộc vào nợ liên quan đến AI. Vì vậy, không thể quy toàn bộ mức giảm giá cổ phiếu hoặc một con số chính xác về vốn hóa bị mất chỉ cho CVE-2026-59310.

Các dữ liệu hiện có cũng chưa đủ để kết luận chiến dịch đã gây ra mức sụt giảm doanh thu VMware có thể đo lường được. Những tác động kinh doanh trước mắt có cơ sở hơn gồm chi phí khắc phục cho khách hàng, nguy cơ gián đoạn vận hành và sức ép lên danh tiếng. Muốn đánh giá ảnh hưởng dài hạn đến doanh thu cần có công bố của doanh nghiệp hoặc thêm bằng chứng tài chính.

Quản trị viên vCenter nên làm gì?

Cài bản vá là bước đầu tiên, không phải bước cuối cùng. Các tổ chức nên:

1. Lập tức áp dụng các bản phát hành đã được Broadcom sửa lỗi cho mọi máy chủ vCenter bị ảnh hưởng, ưu tiên hệ thống hướng ra Internet và thiết bị có thể truy cập từ các mạng nội bộ rộng. Broadcom không liệt kê biện pháp thay thế nào.
2. Coi hệ thống có dấu hiệu xâm nhập là đã bị thỏa hiệp, đặc biệt khi phát hiện thay đổi cron bất thường, dấu vết reverse SSH, linuxFile, lượt tải không giải thích được qua curl hoặc wget, tài khoản quản trị vCenter/ESXi lạ hay hoạt động bất thường của VMware Directory Service.
3. Cô lập thiết bị đáng ngờ và bảo toàn ảnh đĩa, nhật ký cùng dữ liệu biến động trước khi dựng lại hệ thống, nếu điều kiện vận hành cho phép.
4. Thay đổi toàn bộ thông tin xác thực đặc quyền, gồm vCenter SSO, VMware Directory Service, tài khoản ESXi hoặc root, tài khoản API, tài khoản dịch vụ và các tài khoản quản trị liên kết. Đồng thời vô hiệu hóa các phiên đang hoạt động và rà soát đường liên kết liên miền hoặc liên kết liên hệ thống.
5. Dựng lại hệ thống thay vì chỉ “làm sạch” đối với thiết bị đã xác nhận có cơ chế duy trì. Việc xóa tài khoản trái phép, cron, tệp nhị phân, khóa SSH và đường hầm phải nằm trong quy trình ứng phó sự cố được ghi nhận đầy đủ.
6. Tìm kiếm trên toàn bộ hạ tầng ảo hóa các dấu hiệu .babyk, kết nối SSH hoặc WebSocket đi ra bất thường, tài khoản lạ và bằng chứng nhật ký ESXi bị can thiệp.
7. Khôi phục dữ liệu và khả năng giám sát đáng tin cậy từ bản sao lưu bất biến, đã được xác nhận an toàn, nếu nhật ký hoặc cấu hình bị thay đổi.
8. Giảm phơi lộ trong tương lai bằng cách giới hạn quyền quản trị vCenter vào các mạng quản trị được phân đoạn, đồng thời giám sát kết nối đi ra từ vCenter và máy chủ ESXi.

Kết luận vận hành rất rõ ràng: hãy cập nhật mọi hệ thống vCenter dễ bị tấn công, nhưng đừng đồng nhất việc cập nhật thành công với một môi trường sạch. Tốc độ khai thác, cơ chế reverse SSH duy trì quyền truy cập và dấu hiệu lạm dụng thông tin xác thực cho thấy các thiết bị từng bị phơi lộ cần được điều tra như những hệ thống có khả năng đã bị xâm nhập hoàn toàn.