Bạn có bao giờ tự hỏi điều gì sẽ xảy ra nếu kẻ tấn công không cần mất hàng tuần để dò tìm lỗ hổng, mà chỉ cần vài giờ để chiếm toàn bộ hệ thống của một cơ quan chính phủ? Không phải bằng một cuộc tấn công ồn ào, mà bằng một chuỗi hành động lặng lẽ, được điều khiển bởi một "đồng phạm" không phải con người.
Đó không còn là kịch bản giả tưởng. Đó là những gì đang diễn ra ngay lúc này với PHP2Shell bị khai thác trên phạm vi toàn cầu. Và điều khiến tôi, với 20 năm theo dõi những cuộc chiến an ninh mạng, phải lạnh gáy không phải là tốc độ của cuộc tấn công. Mà là cách nó được thực hiện: agentic AI đang trở thành cánh tay phải của tin tặc, và ranh giới giữa con người với máy móc trong các vụ xâm nhập đang mờ đi nhanh chóng.
PHP2Shell là gì và tại sao nó là cơn ác mộng của mọi quản trị viên?
Để hiểu vì sao câu chuyện này quan trọng, trước tiên cần hiểu PHP2Shell là gì. Đây không phải là một lỗ hổng đơn lẻ. Đó là tên gọi chung cho một nhóm lỗ hổng nghiêm trọng trong nhân PHP – ngôn ngữ lập trình đang vận hành phần lớn internet hiện đại, từ các hệ thống quản lý nội dung, cửa hàng trực tuyến, cho đến những công cụ nội bộ của doanh nghiệp và cơ quan nhà nước.
Hai lỗ hổng được theo dõi với mã CVE-2026-109618 và CVE-2026-109619 đều là lỗi nghiêm trọng cho phép thực thi mã từ xa (RCE) ngay trong cấu hình PHP mặc định. Nói cách khác, kẻ tấn công không cần cài đặt bất kỳ thư viện đặc biệt nào, không cần chờ quản trị viên mắc sai lầm. Chỉ cần một yêu cầu HTTP được thiết kế khéo léo, chúng có thể chạy mã độc trên máy chủ – và từ đó, nắm quyền kiểm soát toàn bộ hệ thống.
Điều đáng sợ nằm ở con số: có gần 37 triệu hệ thống đang chạy PHP hoặc phần mềm liên quan PHP trên toàn thế giới, theo quét diện rộng của các tổ chức an ninh mạng. Phần lớn trong số đó tập trung tại Mỹ, Đức, Pháp, Hà Lan và Nhật Bản. Nhưng Việt Nam cũng không nằm ngoài vòng nguy hiểm, bởi hàng nghìn website, ứng dụng và hệ thống nội bộ tại nước ta đang sử dụng PHP mỗi ngày.
Vụ tấn công chính phủ châu Âu: Hai giờ để đánh mất mọi thứ
Hãy tạm gác lại những con số khô khan và đi vào một vụ việc cụ thể. Trong một cuộc tấn công nhắm vào một cơ quan chính phủ tại châu Âu, kẻ tấn công đã lợi dụng PHP2Shell bị khai thác để xâm nhập. Và đây là phần khiến tôi phải dừng lại, đọc đi đọc lại nhiều lần: chỉ trong vòng hai giờ kể từ khi khai thác thành công, chúng đã truy cập được hash mật khẩu và các bí mật xác thực đa yếu tố (MFA).
Hai giờ. Bạn có thể đang uống một tách cà phê, dự một cuộc họp ngắn, hoặc kiểm tra email buổi sáng. Và trong khoảng thời gian đó, một cơ quan chính phủ đã bị lộ những thông tin mà lẽ ra phải được bảo vệ bằng nhiều lớp phòng thủ.
Nhưng cuộc tấn công không dừng lại ở đó. Kẻ tấn công còn thiết lập một đường hầm NTLM relay vào Active Directory – hệ thống xương sống quản lý danh tính và quyền truy cập của hầu hết tổ chức lớn. Từ đó, chúng cố gắng leo thang đặc quyền lên Domain Admin, cấp quyền cao nhất trong toàn bộ miền mạng. Nếu thành công, chúng có thể tạo tài khoản mới, thay đổi chính sách bảo mật, và duy trì quyền truy cập gần như vô hạn.
Điều đáng chú ý là các nhà điều tra sau đó đã phải rút lại kết luận ban đầu rằng vụ việc này liên quan trực tiếp đến hai lỗ hổng PHP2Shell. Họ xác định rằng những gì được quan sát là một cuộc tấn công nhắm vào một ứng dụng PHP có lỗ hổng, nhưng chưa thể xác nhận việc xâm nhập ban đầu có gắn với đúng hai mã CVE cụ thể hay không. Đây là một chi tiết quan trọng, bởi nó cho thấy bức tranh kỹ thuật vẫn đang thay đổi, và các nhà phòng thủ cần theo dõi sát sao thay vì vội vàng kết luận.
Agentic AI: Khi tin tặc có một "đồng phạm" biết tự suy nghĩ
Nhưng có một chi tiết còn đáng lo ngại hơn cả tốc độ. Trong quá trình điều tra, các chuyên gia phát hiện ra những dấu hiệu hành vi đặc trưng của một tác nhân AI tự trị (agentic attacker).
Cụ thể, các lệnh được thực thi trên hệ thống bị xâm phạm được nhóm lại thành từng lô và bao quanh bởi các dấu phân cách như ==SHELLUSER== và ==PASSWD==. Những dấu phân cách này không phải ngẫu nhiên. Chúng tạo ra đầu ra có thể được một mô hình AI phân tích tự động – nghĩa là kẻ tấn công đang dùng AI để đọc kết quả trinh sát, ra quyết định bước tiếp theo, và thực thi hành động mà không cần con người can thiệp thủ công ở từng bước.
Hãy hình dung sự khác biệt. Trước đây, một cuộc xâm nhập điển hình cần một kỹ thuật viên ngồi trước màn hình, gõ từng lệnh, đọc từng kết quả, cân nhắc từng bước. Giờ đây, AI có thể đảm nhận vai trò đó: nó trinh sát cơ sở dữ liệu xác thực, tìm hash mật khẩu và bí mật 2FA, truy vấn LDAP ẩn danh vào domain controller để tìm tài khoản quản trị, và rà soát máy chủ để phát hiện tích hợp DNS/AD, máy chủ nội bộ, nhóm đặc quyền và người dùng đang tương tác.
Tất cả những hành động này diễn ra với tốc độ mà con người khó có thể theo kịp. Và quan trọng hơn, chúng diễn ra mà không cần một con người ngồi sau bàn phím. Đó chính là điều khiến agentic AI trở thành một bước ngoặt trong cách các cuộc tấn công mạng được thực hiện.
Nghi vấn Triều Tiên: Chiến dịch quét toàn cầu với 21 nút bị xâm phạm
Song song với các vụ khai thác đơn lẻ, một chiến dịch có tổ chức hơn đang được các nhà nghiên cứu theo dõi với mức độ nghi ngờ cao. Chiến dịch này sử dụng PHP2Shell bị khai thác để thăm dò cơ sở hạ tầng PHP trên toàn cầu, xuất phát từ 21 nút bị xâm phạm.
Điều khiến chiến dịch này khó bị phát hiện nằm ở cách nó vận hành. Theo mô tả của những người theo dõi, hoạt động quét được thực hiện với khối lượng thấp và nhịp độ có chủ đích. Các nút bị xâm phạm được luân chuyển và bị bỏ rơi ngay khi có dấu hiệu bị chặn hoặc bị giới hạn tốc độ. Điều này có nghĩa là các hệ thống cảnh báo dựa trên ngưỡng – vốn được thiết kế để phát hiện những đợt quét ồ ạt – gần như không thể bắt được.
Danh sách mục tiêu mà chiến dịch nhắm tới gồm 216 máy chủ chưa được vá hoặc vá chưa đầy đủ, trải rộng khắp Mỹ, Nhật Bản, Hàn Quốc, Thái Lan, Indonesia, Australia, Đài Loan, Ấn Độ, Singapore, UAE, Saudi Arabia và Liên minh châu Âu. Các lĩnh vực bị nhắm tới không hề ngẫu nhiên: cơ quan chính phủ, tổ chức tài chính, logistics, sân bay và hàng không, sản xuất, và các nền tảng giao dịch trực tuyến.
Đây là những mục tiêu có giá trị cao. Và theo đánh giá của giới nghiên cứu, các tổ chức trong những lĩnh vực và khu vực này nên mặc định rằng mình đang nằm trong tầm ngắm, thay vì chờ đợi bằng chứng cụ thể.
Dấu vết Lazarus: Ngôn ngữ, hạ tầng và mục tiêu quen thuộc
Chiến dịch quét này được đánh giá với mức độ tin cậy trung bình là do một nhóm vận hành nói tiếng Triều Tiên thực hiện, có liên hệ với hệ sinh thái Lazarus Group – nhóm tấn công có chủ đích được biết đến với các vụ xâm nhập tài chính và đánh cắp tiền mã hóa.
Có nhiều dấu hiệu củng cố nhận định này. Hoạt động được điều phối qua một kênh I2P khép kín – một mạng ẩn danh tương tự Tor nhưng ít phổ biến hơn, thường được các nhóm tấn công có động cơ chính trị sử dụng. Hai tài khoản vận hành trong kênh này từng được ghi nhận thực hiện các chiến dịch bí mật cho những nhóm tấn công tương tự. Và đặc biệt, các cuộc trò chuyện bị thu thập sử dụng từ vựng và chính tả đặc trưng của tiếng Triều Tiên (Munhwaŏ), khác với chuẩn tiếng Hàn của miền Nam.
Hạ tầng chỉ huy và điều khiển (C2) cũng trùng khớp với những gì Lazarus từng sử dụng để khai thác các tài sản web. Nhóm này có lịch sử xâm nhập máy chủ PHP và WordPress để làm C2 và cài web shell, ưu tiên cơ quan chính phủ và ngân hàng – đặc biệt là các nền tảng giao dịch trực tuyến. Tất cả những mảnh ghép này tạo nên một bức tranh đáng lo ngại: PHP2Shell bị khai thác không chỉ là vấn đề của những kẻ tấn công đơn lẻ, mà có thể là một phần trong chiến lược có tổ chức của một nhóm tấn công cấp quốc gia.
Không chỉ có một nhóm: Honeypot và những đợt thăm dò liên tục
Trong khi chiến dịch quét lớn đang diễn ra, các đợt thăm dò nhỏ hơn vẫn tiếp tục xuất hiện ở nhiều nơi. Các honeypot – hệ thống giả được dựng lên để dụ kẻ tấn công – đã ghi nhận những yêu cầu đáng ngờ nhắm vào thiết bị bảo mật của các tổ chức lớn.
Những yêu cầu này mang theo dấu hiệu PHP_SESSION_UPLOAD_PROGRESS với chuỗi "p2s-rider" và một tệp tải lên giả không có nội dung độc hại. Đây là dấu hiệu của ai đó đang kiểm tra xem hệ thống có dính lỗi xử lý tiến trình tải lên hay không – một bước đi trinh sát trước khi tung ra khai thác thực sự. Nguồn gốc của các yêu cầu này đến từ một địa chỉ IP được biết đến với các hoạt động khai thác hàng loạt.
Điều này cho thấy một thực tế: PHP2Shell bị khai thác không phải là một sự kiện đơn lẻ. Đó là một quá trình liên tục, với nhiều nhóm khác nhau tham gia ở nhiều giai đoạn khác nhau – từ trinh sát, thăm dò, cho đến khai thác và chiếm quyền.
Tại sao lỗ hổng này khó vá và khó phát hiện?
Có một lý do kỹ thuật khiến CVE-2026-109618 và CVE-2026-109619 trở nên đặc biệt nguy hiểm: chúng không phụ thuộc vào lỗi trong mã ứng dụng. Chúng nằm trong nhân PHP – phần lõi mà mọi ứng dụng đều dùng chung.
Cơ chế khai thác khá tinh vi. Kẻ tấn công phải tính toán kích thước yêu cầu để làm hỏng cấp phát bộ nhớ vào đúng thời điểm, đồng thời phải vượt qua ASLR – cơ chế ngẫu nhiên hóa địa chỉ bộ nhớ – để tìm được địa chỉ hợp lệ. Cụ thể, chúng dùng một tên trường trong biểu mẫu đủ nhỏ để nằm trong phần thân yêu cầu được chấp nhận, nhưng đủ lớn để khi PHP sao chép khóa đó vào bảng băm, nó vượt quá giới hạn bộ nhớ. Khi PHP phân tích tên trường, nó tạo ra nhiều bản sao; kẻ tấn công lợi dụng bộ nhớ dư thừa đó để ép xảy ra lỗi cấp phát.
Hệ quả là gì? Một lỗ hổng trong nhân PHP không thể sửa bằng cách thay đổi mã ứng dụng. Cập nhật plugin, đổi giao diện, hay thêm tường lửa ứng dụng web (WAF) cũng không loại bỏ được gốc rễ vấn đề. Cách duy nhất để vá là cập nhật chính PHP trên máy chủ.
Và đó chính là điểm yếu chết người. Nhiều tổ chức, đặc biệt là các cơ quan nhà nước và doanh nghiệp vừa và nhỏ, thường trì hoãn việc nâng cấp PHP vì lo ảnh hưởng đến ứng dụng cũ. Họ chọn cách sống chung với rủi ro. Nhưng khi lỗ hổng cho phép thực thi mã từ xa trong cấu hình mặc định, sống chung với rủi ro đồng nghĩa với việc để ngỏ cánh cửa cho bất kỳ ai muốn bước vào.
Cách phát hiện và phòng chống: Những bước đi cụ thể
Trước một lỗ hổng nguy hiểm như vậy, cảm giác lo lắng là điều dễ hiểu. Nhưng thay vì hoảng sợ, hãy biến nó thành hành động. Dưới đây là những việc cần làm ngay.
1. Kiểm tra phiên bản PHP và cập nhật ngay lập tức
Đây là bước quan trọng nhất. Hãy xác định phiên bản PHP đang chạy trên mọi máy chủ của bạn và cập nhật lên bản vá mới nhất. Đừng chờ đợi. Đừng giả định rằng hệ thống của bạn “không ai biết đến”. Kẻ tấn công đang quét toàn cầu, và sự ẩn danh không phải là một lớp bảo vệ.
2. Theo dõi chuỗi lỗi đặc trưng
Các thử nghiệm trong phòng lab đã xác định được một chuỗi dấu hiệu có thể giúp phát hiện khai thác: một yêu cầu POST trả về lỗi 500, sau đó PHP báo cạn kiệt bộ nhớ và hỏng heap, và tiến trình Apache xử lý yêu cầu đó bị crash. Nếu bạn thấy chuỗi này trong log, hãy coi đó là tín hiệu khẩn cấp.
3. Rà soát log và tìm dấu hiệu trinh sát
Hãy tìm các yêu cầu bất thường trong log truy cập, đặc biệt là những yêu cầu có tham số liên quan đến PHP_SESSION_UPLOAD_PROGRESS hoặc các chuỗi đáng ngờ như "p2s-rider". Đồng thời, kiểm tra xem có truy vấn LDAP ẩn danh bất thường nào từ máy chủ web đến domain controller hay không.
4. Đừng tin vào WAF như một giải pháp duy nhất
Tường lửa ứng dụng web có thể giúp giảm thiểu rủi ro, nhưng không thể vá lỗ hổng trong nhân PHP. Nếu bạn chỉ dựa vào WAF mà không cập nhật PHP, bạn đang cầm một chiếc ô giấy trước một cơn bão thật sự.
5. Chuẩn bị cho một lỗ hổng thứ ba
Bên cạnh hai lỗ hổng đã biết, một lỗ hổng thực thi mã từ xa thứ ba – CVE-2026-115560 – cũng đã được cảnh báo. Lỗ hổng này chỉ xảy ra trong một tổ hợp cấu hình và mã ứng dụng đặc biệt, nhưng nó cho thấy rằng các lỗ hổng trong PHP vẫn đang tiếp tục được phát hiện. Đừng bao giờ chủ quan với suy nghĩ “đã vá xong là an toàn mãi mãi”.
Bài học cho doanh nghiệp và cơ quan Việt Nam
Việt Nam không nằm ngoài bản đồ tấn công. Với hàng nghìn hệ thống chạy PHP – từ website doanh nghiệp, cổng thông tin, cho đến các ứng dụng nội bộ – rủi ro là hiện hữu và có thể xảy ra bất cứ lúc nào.
Bài học đầu tiên là không được trì hoãn việc cập nhật. Nếu tổ chức của bạn đang chạy một phiên bản PHP cũ vì “ứng dụng chưa tương thích”, hãy coi đó là một khoản nợ kỹ thuật cần được xử lý ngay, không phải một vấn đề có thể gác lại.
Bài học thứ hai là phải có khả năng phát hiện. Nếu bạn không có hệ thống giám sát log, không có cảnh báo khi có chuỗi lỗi bất thường, thì ngay cả khi bị xâm nhập, bạn cũng không biết. Và trong an ninh mạng, không biết chính là thất bại.
Bài học thứ ba là đừng đối phó với agentic AI bằng công cụ của thế hệ trước. Khi kẻ tấn công dùng AI để trinh sát và ra quyết định với tốc độ cao, các quy trình phòng thủ thủ công, chậm chạp sẽ không thể theo kịp. Cần tự động hóa việc phát hiện và ứng phó, và cần hiểu rằng đối thủ không còn là con người đơn thuần.
Khi tốc độ của kẻ tấn công vượt qua tốc độ của người phòng thủ
Tôi đã chứng kiến ngành an ninh mạng thay đổi rất nhiều trong hai thập kỷ qua. Từ những con sâu máy tính lây lan qua email, đến những chiến dịch tấn công có chủ đích với kỹ thuật tinh vi. Nhưng chưa bao giờ tôi thấy khoảng cách giữa tốc độ tấn công và tốc độ phòng thủ lại bị thu hẹp một cách đáng sợ như lúc này.
PHP2Shell bị khai thác không chỉ là một lỗ hổng cần vá. Đó là một lời nhắc nhở rằng cuộc chơi đã thay đổi. Kẻ tấn công không còn cần hàng tuần để dò tìm. Chúng có AI để trinh sát, có hạ tầng để luân chuyển, và có những danh sách mục tiêu được chuẩn bị sẵn. Trong khi đó, nhiều tổ chức vẫn đang loay hoay với những bản vá bị trì hoãn và những quy trình phòng thủ được thiết kế cho một thời đại đã qua.
Nhưng tôi vẫn tin rằng hiểu biết là bước đầu tiên của phòng thủ. Và nếu bạn đang đọc đến những dòng này, bạn đã bắt đầu hiểu. Câu hỏi là: bạn sẽ làm gì với hiểu biết đó?
Khi kẻ tấn công có thể dùng AI để chiếm quyền truy cập vào hệ thống của một cơ quan chính phủ chỉ trong hai giờ, bạn nghĩ đâu là lỗ hổng lớn nhất trong cách các tổ chức tại Việt Nam đang bảo vệ dữ liệu của mình – là công nghệ lạc hậu, là thiếu nhân lực, hay là tư duy “chưa đến lượt mình”? Và nếu hôm nay bạn phải kiểm tra một hệ thống PHP đang vận hành, bạn sẽ bắt đầu từ đâu để biết mình có đang nằm trong tầm ngắm hay không?
0 Comment
Add your comment to this article