Ivanti Connect Secure: Chuỗi zero-day lên quyền root không cần đăng nhập — Vá ngay trước hạn 2/11

Tobi•31/10/2026• … views

Ngày 30/10/2026, Cơ quan An ninh mạng và Hạ tầng Hoa Kỳ (CISA) đã đưa thêm hai lỗ hổng của Ivanti Connect Secure vào danh mục lỗ hổng đang bị khai thác thực tế (KEV): CVE-2026-111357 và CVE-2026-118527, với hạn khắc phục cho các cơ quan liên bang Mỹ lần lượt là 2/11 và 13/11/2026. Đây không phải hai lỗ hổng rời rạc mới xuất hiện từ hư không — chúng là hai mắt xích cuối cùng của một chuỗi tấn công zero-day mà nhóm tấn công UTA0576 đã dùng từ đầu tháng 10 để chiếm quyền root trên thiết bị VPN mà không cần đăng nhập.

Và đây là cái bẫy nguy hiểm nhất: nếu bạn đã vá Ivanti Connect Secure vào giữa tháng 10 rồi yên tâm đóng ticket, thì rất có thể bạn vẫn đang hở. Bản vá tháng 10 chỉ đóng cánh cửa đầu tiên, bước leo thang lên root phải tới 29/10 mới có vá — và CISA vừa đặt hạn chót là 2/11. Nếu công ty bạn dùng Ivanti Connect Secure (ICS) làm cổng VPN, bài này dành cho bạn.

1. Chuyện gì vừa xảy ra?

Hãy nhìn lại toàn bộ diễn biến theo trình tự thời gian, vì chỉ khi đặt các mốc cạnh nhau bạn mới thấy vì sao “đã vá rồi” lại chưa đủ:

Đầu tháng 10/2026: Volexity phát hiện nhóm tấn công mới UTA0576 đang khai thác chuỗi zero-day trên thiết bị Ivanti Connect Secure của một khách hàng — thiết bị đang chạy 22.8R2.4, bản mới nhất tại thời điểm đó. Đây là zero-day thật sự, không phải do nạn nhân lười cập nhật.
Đầu tháng 10/2026: Volexity ghi nhận khai thác từ 3/10, hãng Defused báo cáo dấu hiệu từ 1/10. Dù chênh nhau một hai ngày, điểm chung không đổi: chuỗi đã chạy trong thực tế trước khi có bản vá hay cảnh báo công khai nào.
13/10/2026: Ivanti vá mắt xích đầu tiên, CVE-2026-104935 (CVSS 8.6); cùng ngày CISA đưa CVE này vào KEV, Ivanti xác nhận “một số lượng hạn chế khách hàng” đã bị ảnh hưởng. Lúc này bản vá cho bước leo thang lên root vẫn chưa có — chuỗi chưa được đóng hoàn toàn.
29/10/2026: Ivanti phát hành bản vá cho hai mắt xích còn lại: CVE-2026-111357 (leo thang đặc quyền) và CVE-2026-118527 (tên file có thể đoán trước khi tải lên). Các bản vá cho hai nhánh chính là 22.8R2.6 và 25.1.1.3.
30/10/2026: CISA đưa cả hai CVE này vào KEV. CVE-2026-111357 có hạn khắc phục 2/11/2026 và yêu cầu rà soát pháp y (forensic triage); CVE-2026-118527 có hạn 13/11/2026.

Đáng chú ý, CISA ghi nhận danh mục KEV đã lên tới 1.766 mục ở phiên bản ngày 30/10 — KEV giờ là hàng đợi vá khẩn cấp, không còn là danh sách tham khảo khi rảnh.

2. Chuỗi 3 lỗ hổng hoạt động ra sao?

Đừng nhìn từng CVE riêng lẻ rồi đánh giá theo điểm số. Sức mạnh của vụ này nằm ở cách ba lỗ hổng nối với nhau thành một đường đi trọn vẹn: từ người lạ ngoài internet tới quyền root trên thiết bị VPN — tức là quyền cao nhất, làm gì cũng được trên chính cánh cổng kết nối nhân viên vào mạng nội bộ.

CVE	Vai trò trong chuỗi	Điểm CVSS (theo Ivanti)
CVE-2026-104935	Vượt qua xác thực và thực thi mã từ xa	8.6
CVE-2026-118527	Tải file lên vị trí có thể đoán trước trên đĩa	4.3
CVE-2026-111357	Leo thang đặc quyền lên root (thiếu xác thực cho chức năng quan trọng)	8.8

Cách chuỗi vận hành, theo phân tích kỹ thuật của Volexity, có thể tóm gọn như sau:

Bước 1 — Lách cửa đăng nhập. Kẻ tấn công lợi dụng sự không khớp giữa URL và header X-DSCGI-PATH để chạm tới handler tải lên vốn được bảo vệ, không cần đăng nhập (CVE-2026-104935, qua script welcome.cgi).

Bước 2 — Đặt file vào chỗ đã biết trước. Handler wu.cgi ghi nội dung vào vị trí tạm có thể đoán trước, trước khi kiểm tra đó có phải file ZIP hợp lệ không (CVE-2026-118527). Nhìn riêng, CVSS 4.3 của nó trông rất “hiền” — nhưng trong chuỗi, nó là cầu nối đặt mã vào đúng chỗ cần thiết.

Bước 3 — Leo lên root. Kẻ tấn công lạm dụng dịch vụ đặc quyền dsinvoked: đổi mã thư viện trong bộ nhớ và sửa tác vụ bảo trì trong kho DSCache, khiến dịch vụ chạy mã của chúng với quyền root (CVE-2026-111357).

Có hai điểm kỹ thuật khiến chuỗi này khác hẳn một vụ RCE thông thường, và cả hai đều làm công tác phát hiện khó hơn rất nhiều:

Thứ nhất, kẻ tấn công không cài backdoor hay web shell. UTA0576 chạy lại toàn bộ chuỗi cho mỗi lệnh và nhận kết quả ngay trong phản hồi HTTPS của chính chuỗi đó. Không có kênh C2 riêng, không có file độc hại nằm chờ — công cụ quét file truyền thống gần như không có gì để bám vào.

Thứ hai, phần lớn dấu vết chỉ nằm trong bộ nhớ. Các thay đổi trong bộ nhớ và việc khôi phục cấu hình đã qua mặt được Integrity Checker của Ivanti; CISA cũng cảnh báo công cụ này có thể bỏ sót bằng chứng khai thác CVE-2026-104935. Hệ quả: kết quả quét “sạch” không chứng minh được thiết bị chưa từng bị chạm vào (xem thêm mục 7).

Về điểm số, cần nói rõ một chênh lệch: Ivanti chấm CVE-2026-111357 là 8.8, còn NVD ghi điểm phụ 7.0 (vector tấn công cục bộ, độ phức tạp cao). Nhưng khi mắt xích này đã nằm trong chuỗi khai thác từ xa được chứng minh, điểm riêng lẻ không còn là thước đo đúng nữa — việc CISA đưa nó vào KEV, tức đã có bằng chứng khai thác thực tế, mới là tín hiệu để hành động.!

3. Ai bị ảnh hưởng?

Ivanti Connect Secure — trước đây có tên Pulse Connect Secure — là thiết bị VPN SSL cho doanh nghiệp, đặt ở biên mạng để nhân viên, nhà thầu và đội ngũ làm việc kết hợp (hybrid) truy cập tài nguyên nội bộ và đám mây. Theo BleepingComputer, tổ chức Shadowserver từng ghi nhận hơn 5.500 thiết bị ICS lộ ra internet. Dù không phải tất cả đều chưa vá, con số này cho thấy bề mặt tấn công của sản phẩm này lớn tới mức nào: chỉ cần một phần nhỏ trong đó còn ở bản cũ, kẻ tấn công đã có đủ mục tiêu để quét.

Bảng dưới đây tổng hợp các nhánh bị ảnh hưởng và bản vá, theo advisory cập nhật ngày 29/10 của Ivanti (được The Stack và các hãng tin tổng hợp lại):

Lỗ hổng	Phiên bản bị ảnh hưởng	Bản vá
CVE-2026-104935	25.1.1.1 trở xuống; 25.1.2.2 trở xuống; 22.8R2.4 trở xuống	25.1.1.2; 25.1.3.0 / 25.1.3.1; 22.8R2.5
CVE-2026-111357 và CVE-2026-118527	25.1.1.2 trở xuống; 22.8R2.5 trở xuống	25.1.1.3; 22.8R2.6

Đọc bảng này theo chiều dọc bạn sẽ thấy ngay cái bẫy: 22.8R2.5 — bản vá của ngày 13/10 — lại chính là bản bị ảnh hưởng của đợt vá ngày 29/10. Tương tự, 25.1.1.2 cũng vậy. Nghĩa là lộ trình vá an toàn không phải “lên bản mới nhất của tháng 10 là xong”, mà là phải đi đủ hai chặng: chặng 13/10 rồi chặng 29/10. Nếu đội của bạn dừng ở chặng đầu, thiết bị vẫn hở bước leo thang lên root.

Lưu ý: Ivanti có nhiều nhánh song song, hãy đối chiếu advisory của hãng cho đúng nhánh của bạn, đừng suy luận từ nhánh khác. Các bản 22.7.x trở xuống không chứa các lỗ hổng này, nhưng đó không đồng nghĩa với an toàn — nhánh cũ có thể hết hỗ trợ hoặc dính lỗ khác. Nhánh 22.8 cũng sẽ hết vòng đời vào 31/1/2027 theo CISA, nên hãy đưa việc rời khỏi 22.8 vào kế hoạch ngay từ bây giờ.

Nhóm rủi ro cao nhất: thiết bị ICS lộ ra internet, thiết bị đang ở 22.8R2.5 hoặc 25.1.1.2 (tưởng đã vá xong), và các tổ chức mà ICS kết nối tới Active Directory — thứ UTA0576 nhắm tới sau khi chiếm thiết bị. Minh họa 3D isometric: thiết bị cổng VPN nối văn phòng với nhân viên làm việc từ xa, phía trên có khiên cảnh báo màu đỏ

4. Sau khi vào được, kẻ tấn công làm gì?

Đây là phần khiến vụ Ivanti lần này đáng sợ hơn một vụ DoS hay một vụ RCE “thông thường”: thiết bị VPN không phải là đích đến, mà là bàn đạp. Một khi đã có quyền root trên ICS, UTA0576 tập trung vào đúng thứ giá trị nhất mà một cổng VPN nắm trong tay: thông tin xác thực và bí mật của cả mạng nội bộ.

Theo Volexity, kẻ tấn công đã:

Trích xuất thông tin xác thực miền đã lưu trữ, dùng tài khoản dịch vụ Active Directory của chính thiết bị VPN để truy vấn hệ thống nội bộ.
Nhắm tới mật khẩu quản trị viên cục bộ qua LAPS, khóa khôi phục BitLocker và các thuộc tính chứa mật khẩu.
Moi thông tin xác thực plaintext từ lưu lượng mạng bằng script Python ghi xuống đĩa (/data/.icscap/h.py), phân tích file bắt gói tin để lấy LDAP, HTTP Basic và hash NTLM; kèm các script /tmp/mk.py, /tmp/rr.py.
Sửa log để xóa dấu vết — thêm một lý do khiến “không thấy gì bất thường trong log” không phải bằng chứng an toàn.

Volexity đánh giá với độ tin cậy thấp rằng UTA0576 có động cơ tội phạm (criminal) hơn là gián điệp, dựa trên mục tiêu là đánh cắp thông tin xác thực và dữ liệu. Dù động cơ cuối cùng là gì, thì với nạn nhân, hậu quả thực tế là như nhau: mọi bí mật mà thiết bị VPN từng chạm tới đều phải được coi là có khả năng đã lộ, và việc chỉ vá phần mềm mà không xoay lại các bí mật đó là chưa đủ. Mục 7 sẽ liệt kê cụ thể cần xoay những gì.

Ivanti mô tả số khách hàng bị ảnh hưởng là “một số lượng hạn chế” — đó là phát biểu tại thời điểm công bố, dựa trên những gì hãng biết lúc đó. Nó không có nghĩa các tổ chức khác tự động an toàn, nhất là khi chuỗi này được thiết kế để xóa dấu vết. Cách đọc đúng: hãng xác nhận có nạn nhân thật, và nếu bạn chạy bản bị ảnh hưởng từ đầu tháng 10 tới nay, bạn nằm trong nhóm cần điều tra.

5. Kiểm tra phiên bản của bạn trong 2 phút

Cách 1 — qua giao diện quản trị: đăng nhập trang quản trị ICS và xem số phiên bản (thường ở trang tổng quan hoặc mục System). Ghi chính xác cả nhánh lẫn số bản vá — 22.8R2.5 khác hẳn 22.8R2.6, chỉ ghi “22.8” là không đủ.

Cách 2 — đối chiếu bằng script trong môi trường giả lập. Vì mình không có thiết bị ICS thật để chạy thử, mình dựng một script đối chiếu phiên bản đơn giản trong sandbox trên máy này, nạp đúng quy tắc từ advisory 29/10 (nhánh 22.8 cần tối thiểu 22.8R2.6, nhánh 25.1.1 cần tối thiểu 25.1.1.3) rồi chạy với một loạt phiên bản mẫu. Kết quả chạy thật dưới đây cho thấy ranh giới “hở — đã vá” nằm chính xác ở đâu:

Ảnh chụp terminal trong môi trường giả lập: script đối chiếu phiên bản Ivanti, 22.8R2.4 và 22.8R2.5 vẫn hở, 22.8R2.6 và 25.1.1.3 đã vá

Kết quả chạy thật trong sandbox: 22.8R2.4 và 22.8R2.5 đều “ĐANG HỞ”, chỉ từ 22.8R2.6 trở lên mới “ĐÃ VÁ”; tương tự, 25.1.1.2 vẫn hở, 25.1.1.3 mới vá xong. Script này chỉ đối chiếu số phiên bản theo advisory — nó không kết nối tới thiết bị thật và không thay thế việc kiểm tra trực tiếp trên trang quản trị của bạn.

Nếu phiên bản thấp hơn mốc tối thiểu của đúng nhánh đó, bạn đang hở — chuyển ngay sang mục 6. Nếu đã ở 22.8R2.6 hoặc 25.1.1.3 (hoặc bản tương đương theo advisory), phần vá coi như xong, nhưng vẫn nên đọc mục 7 để quyết định có cần điều tra dấu vết từ đầu tháng 10 tới nay không.![

Minh họa 3D isometric: kỹ sư đang cập nhật và xoay lại khóa cho cụm máy chủ, xung quanh là khiên và dấu kiểm bảo mật

6. Vá từng bước — và đừng quên chặng thứ hai

Vá thiết bị biên như ICS cần cẩn thận hơn vá web server thông thường — sai một bước là cả công ty mất cổng truy cập từ xa:

Bước 0 — Chuẩn bị cửa sổ bảo trì và bản sao lưu. Đặt lịch bảo trì ngoài giờ cao điểm, thông báo trước cho người dùng VPN, và chụp snapshot/backup cấu hình thiết bị theo quy trình của Ivanti trước khi nâng cấp. Nếu thiết bị của bạn là cụm HA (high availability), hãy kiểm tra quy trình nâng cấp theo từng node của cụm, đừng nâng cả hai node cùng lúc.

Bước 1 — Lấy đúng bản vá từ Ivanti License Server (ILS). Tải bản vá của đúng nhánh bạn đang chạy: nhánh 22.8 lên 22.8R2.6, nhánh 25.1.1 lên 25.1.1.3. Nếu bạn đang ở nhánh khác (ví dụ 25.1.3), hãy đối chiếu advisory của Ivanti để lấy bản tương đương — đừng tự suy ra từ hai nhánh này.

Bước 2 — Nâng cấp và xác minh lại phiên bản. Sau khi nâng cấp xong, đăng nhập lại trang quản trị và xác nhận số phiên bản hiển thị đúng là bản đã vá (22.8R2.6 hoặc 25.1.1.3), rồi chạy lại phép đối chiếu ở mục 5. Nhiều sự cố “vá rồi mà vẫn hở” thực ra là nâng cấp chưa hoàn tất, hoặc thiết bị đã tự rollback về snapshot cũ mà không ai để ý.

Bước 3 — Chạy Integrity Checker, nhưng hiểu đúng giới hạn của nó. Hãy chạy công cụ kiểm tra toàn vẹn của Ivanti sau khi vá, nhưng nhớ rằng công cụ này có thể bỏ sót dấu vết của chuỗi tấn công này (lý do ở mục 2 và 4). Kết quả “sạch” là điều kiện cần, không phải bằng chứng kết luận.

Bước 4 — Lên lịch rời khỏi nhánh 22.8. Nhánh 22.8 sẽ hết vòng đời vào 31/1/2027 theo thông tin CISA nêu. Nếu bạn còn ở 22.8, hãy đưa việc lên nhánh được hỗ trợ dài hạn vào kế hoạch quý tới, thay vì chờ tới sát hạn mới cuống lên di dời.

7. Nếu nghi ngờ đã bị xâm nhập: đừng chỉ vá rồi thôi

Đây là mục quan trọng nhất nếu thiết bị của bạn từng chạy bản bị ảnh hưởng từ đầu tháng 10 tới nay và lộ ra internet. Vá phần mềm chỉ ngăn kẻ tấn công vào lại bằng đúng chuỗi này — nó không thu hồi các bí mật có thể đã bị lấy đi, cũng không xóa quyền truy cập mà kẻ tấn công có thể đã tạo ở nơi khác trong mạng.

Dấu hiệu và chỉ báo cần rà soát (theo phân tích của Volexity, dùng làm điểm bắt đầu chứ không phải danh sách đầy đủ):

Các file bất thường như /data/.icscap/h.py, /tmp/mk.py, /tmp/rr.py trên thiết bị.
Thay đổi bất thường trong cấu hình DSCache hoặc tác vụ bảo trì liên quan tới dịch vụ dsinvoked.
Lưu lượng hoặc phiên đi ra từ thiết bị ICS tới các hệ thống nội bộ mà bình thường ICS không truy cập — đặc biệt là truy vấn Active Directory ngoài giờ làm việc.
Địa chỉ hạ tầng được Volexity ghi nhận trong vụ việc: host 108.165.147[.]64 (một VPS Evoxt, từng chạy OpenVPN từ 30/9 tới 7/10/2026). Hãy rà log firewall/proxy xem có kết nối nào liên quan không, nhưng đừng kết luận “không thấy IP này là an toàn” — kẻ tấn công hoàn toàn có thể dùng hạ tầng khác ở các vụ khác.

Nếu tìm thấy dấu hiệu, hoặc nếu bạn không thể chứng minh là không có dấu hiệu:

Coi thiết bị như đã bị xâm nhập, làm theo hướng dẫn khôi phục ICS/IPS của Ivanti — dựng lại từ bản sạch thay vì chỉ vá đè lên.
Xoay lại toàn bộ bí mật thiết bị từng nắm giữ: mật khẩu tài khoản dịch vụ Active Directory của ICS, mật khẩu LAPS, khóa khôi phục BitLocker, mật khẩu người dùng VPN, khóa và chứng chỉ trên thiết bị. Đây là bước tốn công nhất nhưng không thể bỏ qua — vì đó chính là mục tiêu của UTA0576.
Rà soát tài khoản, phiên truy cập nội bộ phát sinh từ ICS trong giai đoạn bị ảnh hưởng và điều tra lan rộng sang các hệ thống khác; lưu giữ log, ảnh pháp y trước khi ghi đè.

Nếu không có đội ứng cứu nội bộ, đây là lúc nên gọi hãng ứng cứu chuyên nghiệp. CISA cũng gắn cờ “yêu cầu rà soát pháp y” cho CVE-2026-111357 — tức chính cơ quan này cũng không coi “vá xong là xong”.

8. Kết luận

Vụ Ivanti tháng 10/2026 là bài học về cách đọc tin bảo mật: đừng đọc tiêu đề rồi dừng. Tiêu đề ngày 13/10 nói “đã có bản vá”, nhưng đó mới là một nửa câu chuyện; nửa còn lại — bước leo thang lên root — phải chờ tới 29/10, và 30/10 CISA đặt hạn 2/11. Ai dừng ở bản vá đầu tiên thì tới hôm nay vẫn đang hở, trên chính thiết bị nắm chìa khóa vào mạng nội bộ.

Tóm lại, nếu bạn vận hành Ivanti Connect Secure, hãy làm ba việc ngay hôm nay: một, kiểm tra phiên bản thật của bạn và đối chiếu với bảng ở mục 3 — mốc an toàn là 22.8R2.6 hoặc 25.1.1.3 (tùy nhánh); hai, nếu còn ở bản cũ thì nâng cấp trong cửa sổ bảo trì gần nhất, trước hạn 2/11; ba, nếu thiết bị từng ở bản bị ảnh hưởng từ đầu tháng 10 tới nay, đừng chỉ vá — hãy rà soát dấu vết và xoay lại các bí mật liên quan tới Active Directory. VPN là cánh cổng vào nhà bạn; đừng để cánh cổng đó mở toang chỉ vì một bản vá còn dang dở.

FAQ

Tôi đã nâng cấp lên 22.8R2.5 vào giữa tháng 10, vậy đã an toàn chưa?

Chưa. 22.8R2.5 chỉ vá CVE-2026-104935. Bạn vẫn hở hai CVE còn lại cho tới khi lên 22.8R2.6 (tương tự, 25.1.1.2 vẫn hở tới khi lên 25.1.1.3).

Điểm CVSS của CVE-2026-118527 chỉ có 4.3, có cần gấp không?

Cần, vì nó là mắt xích của chuỗi đã bị khai thác thực tế. Điểm thấp khi đứng một mình không phản ánh rủi ro khi kết hợp với hai CVE còn lại — cả ba đều đã vào KEV.

Chạy Integrity Checker ra kết quả sạch thì có yên tâm được không?

Chưa đủ. Chuỗi này chạy phần lớn trong bộ nhớ, có thể qua mặt công cụ kiểm tra toàn vẹn, và kẻ tấn công còn sửa log. Kết quả sạch chỉ có nghĩa là “không tìm thấy dấu vết bằng công cụ này”.

Tôi không dùng Ivanti Connect Secure thì bài này có liên quan gì không?

Trực tiếp thì không, nhưng bài học thì có: với thiết bị biên (VPN, firewall, gateway), bản vá “một nửa” rất dễ tạo cảm giác an toàn giả. Hãy theo dõi tới khi advisory tuyên bố đã vá toàn bộ chuỗi rồi mới đóng ticket.

Hạn 2/11 của CISA có bắt buộc với công ty tôi ở Việt Nam không?

Hạn đó ràng buộc trực tiếp các cơ quan dân sự liên bang Mỹ theo BOD 26-04. Với doanh nghiệp khác, nó không phải nghĩa vụ pháp lý, nhưng là mốc tham chiếu thực tế — sau mốc đó, mức độ quét/khai thác diện rộng thường tăng vì thông tin đã quá công khai.

Nguồn tham khảo

Chuyên mục:Cybersecurity