Lỗ hổng zero-day N-central bị khai thác sau vài giờ

Lỗ hổng zero-day N-central bị khai thác chỉ vài giờ sau khi công bố PoC

Một lỗ hổng zero-day mới trong phần mềm quản lý N-central của N-able đã bị kẻ tấn công khai thác chỉ vài giờ sau khi nhà nghiên cứu bảo mật Sean Bales công bố mã khai thác thử nghiệm (PoC) trên GitHub. Lỗ hổng có tên 4EverAble2Shell cho phép kẻ tấn công chưa xác thực thực thi mã từ xa (RCE) với quyền root trên các máy chủ N-central.

Sự việc đáng lo ngại ở chỗ lỗ hổng vẫn khai thác được trên các máy chủ đã cài bản vá mới nhất, biến đây thành mối đe dọa cấp thiết với các doanh nghiệp đang dùng nền tảng quản lý đầu cuối này.

Minh họa lỗ hổng phần mềm

Chuỗi khai thác nhắm vào lỗ hổng Apache Axis

Theo Bales, 4EverAble2Shell là sự kết hợp giữa một khai thác cho lỗ hổng Apache Axis gần đây (CVE-2026-90436, điểm CVSS 9.8) và một khai thác cho lỗ hổng chưa được xác định cụ thể trong các bản triển khai N-central có bật Legacy API.

Chuỗi khai thác lợi dụng lỗi Apache Axis để đạt RCE, sau đó nâng quyền lên root và chạy một shell script (tập lệnh dòng lệnh). Theo Bales, chuỗi này vẫn hoạt động trên các máy chủ N-central đã được cập nhật lên bản 2026.4 HF2 (số build 2026.4.1.26) trong tuần — bản vá chứa các sửa lỗi cho những zero-day Able2Shell được công bố trước đó.

Đây là đợt công bố thứ hai của Bales chỉ trong vài ngày: trước đó vào cuối tuần, ông đã công khai một loạt lỗ hổng chưa được vá và N-able đã phát hành bản sửa lỗi, nhưng lỗ hổng mới lại xuất hiện hai ngày sau đó.

N-able phản ứng và hạn chế tính năng

N-able đã phản ứng ngay lập tức, hạn chế một số tính năng và tích hợp của N-central, bao gồm Legacy API và tích hợp Intune. Ngày 13/11, công ty cho biết đang tiếp tục điều tra và đã xác định thêm các dấu hiệu xâm nhập (IoC), đồng thời phối hợp chặt chẽ với các khách hàng bị ảnh hưởng để đánh giá và giảm thiểu rủi ro.

Ngày 12/11, Bales công bố mã PoC cho 4EverAble2Shell và Agent2Shell — một nhóm khoảng một tá lỗ hổng zero-day cho phép kẻ tấn công thực thi lệnh trên các agent Windows được quản lý với quyền System.

Bị khai thác trong vòng vài giờ

Nền tảng tình báo mối đe dọa Previdian (trước đây là KEVIntel) cho biết kẻ tấn công bắt đầu sử dụng PoC 4EverAble2Shell chỉ vài giờ sau khi nó được công bố. Công ty quản lý bề mặt tấn công WatchTowr cũng cảnh báo đã ghi nhận các hoạt động dò quét nhắm vào lỗ hổng này trên các build có bật Legacy API.

Minh họa an ninh mạng

Lupovis và Huntback quan sát thấy kẻ tấn công chiếm được máy chủ N-central thành công khoảng 5 giờ sau khi PoC được công bố. Chúng triển khai trình đào tiền mã hóa XMRig, kèm cơ chế duy trì hoạt động (persistence) qua systemd hoặc cron.

Theo Lupovis, mỗi trình đào của nạn nhân được đặt tên theo địa chỉ IP của máy đó. Ví của kẻ tấn công ghi nhận 21 máy liên kết với các máy chủ N-central bị xâm nhập tại Mỹ (9), Nam Phi (4), Canada (4), Anh, Đức, Pháp và Thụy Điển. Lupovis khẳng định các máy mồi (decoy) của họ không bao giờ thực thi mã, nên toàn bộ các máy trong danh sách đều là máy chủ thật đã bị chiếm quyền root.

Trong bài phân tích kỹ thuật, Huntback cho biết 19 trong số các nạn nhân đã cài bản vá mới nhất từ N-able. Họ nhấn mạnh trình đào tiền mã hóa là payload duy nhất được quan sát tới nay, nhưng việc nâng quyền trao cho kẻ tấn công quyền root trên một máy chủ quản lý toàn bộ thiết bị đầu cuối của khách hàng — vì vậy một vụ xâm nhập cần được coi là thỏa hiệp toàn diện, chứ không chỉ là việc dọn dẹp. Việc chỉ cài Hotfix 2 là chưa đủ.

Góc nhìn

Sự việc cho thấy khoảng cách giữa công bố lỗ hổng và khai thác thực tế đã gần như bằng không. Chỉ trong khoảng 5 giờ, kẻ tấn công đã có thể chiếm quyền root trên máy chủ N-central — một hệ thống thường được dùng để quản lý hàng loạt thiết bị đầu cuối của khách hàng. Với các đội kỹ thuật và doanh nghiệp, bài học là việc đã cài bản vá mới nhất không đồng nghĩa đã an toàn: cần bổ sung giám sát bất thường, kiểm tra các dấu hiệu xâm nhập đã được công bố và rà soát xem tính năng Legacy API có thực sự cần thiết hay không. Với các nhà cung cấp dịch vụ quản lý (MSP) dùng N-central, một máy chủ bị nhiễm có thể ảnh hưởng tới toàn bộ khách hàng, nên quy trình ứng phó cần coi đây là sự cố nghiêm trọng thay vì chỉ xử lý phần mềm độc hại đơn lẻ.