Một cuộc trò chuyện hỗ trợ tưởng như bình thường đã chạm tới một lớp tin cậy rất nhạy cảm: chứng chỉ ký mã. Theo mô tả sự cố được ghi nhận tại Bugzilla của Mozilla, ngày 2/4/2026, kẻ tấn công liên hệ đội hỗ trợ DigiCert qua kênh chat khách hàng và gửi một tệp ZIP giả làm ảnh chụp màn hình; bên trong là tệp thực thi .scr có mã độc ^[12]. Sau đó, qua các hệ thống hỗ trợ bị xâm nhập, kẻ tấn công lấy được mã khởi tạo cho một số lượng hạn chế chứng chỉ ký mã, và một vài chứng chỉ đã bị dùng để ký malware ^[1].

Điểm cần nhấn mạnh: đây không được mô tả như một vụ chiếm toàn bộ hạ tầng CA của DigiCert. Rủi ro nằm ở chỗ kẻ tấn công đã lợi dụng được một đoạn trong quy trình hỗ trợ và phát hành chứng chỉ, đủ để biến chữ ký số thành vỏ bọc khiến phần mềm độc hại trông đáng tin hơn ^{[1][5][10][15]}.

Sự cố bắt đầu như thế nào

Help Net Security mô tả đây là một vụ social engineering nhắm vào kênh hỗ trợ của DigiCert: file ZIP được ngụy trang như ảnh chụp màn hình của khách hàng, nhưng thực tế chứa file .scr, định dạng Windows dùng cho screensaver và cũng có thể chạy mã độc ^[2].

SecurityWeek cho biết malware đã lây nhiễm hai endpoint; một máy được phát hiện ngày 3/4/2026, máy còn lại ngày 14/4/2026 ^[10]. Từ một hệ thống bị xâm nhập, kẻ tấn công được cho là đã di chuyển sang cổng hỗ trợ nội bộ của DigiCert ^[10]. Ở đó, các chuyên viên hỗ trợ đã xác thực có một chức năng hạn chế cho phép truy cập vào tài khoản khách hàng theo ngữ cảnh hỗ trợ; chức năng này có thể mở ra một số thao tác, bao gồm truy cập mã khởi tạo cho các chứng chỉ đang chờ hoàn tất ^[10].

BleepingComputer cũng mô tả phạm vi là có giới hạn, nhưng nêu rõ phần bị lộ là mã khởi tạo của các chứng chỉ EV Code Signing đã được phê duyệt nhưng chưa được bàn giao ^[5].

Vì sao chứng chỉ ký mã EV là mục tiêu hấp dẫn

DigiCert là một tổ chức chứng thực số lớn, được trình duyệt và hệ điều hành trên toàn cầu tin cậy; các chứng chỉ ký mã của hãng được nhiều nhà phát triển phần mềm sử dụng trong chuỗi phân phối phần mềm ^[11]. Nói đơn giản, chữ ký số giúp hệ thống và người dùng đánh giá nguồn gốc, tính toàn vẹn của một tệp thực thi.

Chính vì vậy, khi chứng chỉ ký mã bị lạm dụng, vấn đề không chỉ là một tài khoản hỗ trợ bị xâm nhập. ThreatNoir cho biết một số chứng chỉ ký mã lấy được trong vụ việc đã được dùng để ký malware ^[1]. CyberInsider cũng mô tả việc hệ thống hỗ trợ nội bộ và dữ liệu phát hành chứng chỉ bị lạm dụng để lấy chứng chỉ EV Code Signing hợp lệ, rồi một số chứng chỉ sau đó được dùng để ký malware ^[11].

EV là viết tắt của Extended Validation, thường được hiểu là mức xác thực mở rộng. Với kẻ tấn công, giá trị của EV nằm ở tín hiệu tin cậy cao hơn mà nó tạo ra. Vectra mô tả mô hình này ở bình diện rộng hơn: các tác nhân đe dọa có thể dùng chứng chỉ EV để ký file độc hại, khai thác mức độ tin cậy thường gắn với ứng dụng đã ký EV; các tổ chức chỉ dựa vào niềm tin từ chữ ký số sẽ dễ bị tổn thương ^[15].

Điều gì chưa được chứng minh

Trong các nguồn hiện có, vụ việc được mô tả xoay quanh endpoint của bộ phận hỗ trợ, cổng hỗ trợ nội bộ, chức năng truy cập hạn chế và mã khởi tạo chứng chỉ ^{[1][5][10][12]}. Các nguồn này không cho thấy khóa root hoặc khóa CA của DigiCert bị xâm phạm.

Điều đó không làm sự cố trở nên nhẹ nhàng. Nó chỉ giúp xác định đúng bản chất: đây là vụ lạm dụng quy trình hỗ trợ và phát hành chứng chỉ ký mã, không phải một cuộc tiếp quản hoàn toàn tổ chức chứng thực số ^[1][5][10].

Quy mô thiệt hại: con số khác nhau vì đang nói về các nhóm khác nhau

Các báo cáo công khai không hoàn toàn dùng cùng một cách đếm:

• ThreatNoir nói kẻ tấn công lấy được mã khởi tạo cho một số lượng hạn chế chứng chỉ ký mã, trong đó một vài chứng chỉ bị dùng để ký malware ^[1].
• Risky Business báo cáo 27 chứng chỉ ký mã bị đánh cắp và sau đó được dùng để ký malware ^[8].
• ThreatLocker nêu con số 60 chứng chỉ ký mã bị thu hồi tổng cộng ^[3].

Vì vậy, khi đọc các con số, cần phân biệt giữa chứng chỉ bị lấy được, chứng chỉ bị lạm dụng thực tế và chứng chỉ bị thu hồi để phòng ngừa hoặc khống chế rủi ro. Dù phạm vi được mô tả là giới hạn, chỉ một vài chứng chỉ trông hợp lệ cũng có thể đủ để giúp malware lợi dụng niềm tin của hệ thống phòng thủ ^[1][15].

DigiCert đã chặn thiệt hại ra sao

Theo BleepingComputer, các chứng chỉ đã xác định bị ảnh hưởng được DigiCert thu hồi trong vòng 24 giờ sau khi phát hiện, đồng thời ngày thu hồi được đặt về ngày phát hành của chứng chỉ ^[5]. Các đơn hàng đang chờ trong khung thời gian liên quan cũng bị hủy như một biện pháp phòng ngừa ^[5]. ThreatNoir cũng ghi nhận rằng chứng chỉ bị ảnh hưởng được thu hồi trong vòng 24 giờ và các đơn đang chờ trong khoảng thời gian bị ảnh hưởng bị hủy ^[1].

Thu hồi chứng chỉ giúp hạn chế việc tiếp tục lạm dụng, nhưng không đồng nghĩa đội phòng thủ có thể khép lại sự cố. Với malware đã được ký, cần đánh giá cả dữ liệu chứng chỉ, mã băm, hành vi tiến trình, kết nối mạng, cơ chế bám trụ và bối cảnh tình báo mối đe dọa, vì chữ ký EV có thể được dùng như một lớp ngụy trang tin cậy ^[15].

Rắc rối song song: Microsoft Defender báo nhầm

Sự cố còn kéo theo một lớp nhiễu đáng kể cho đội vận hành bảo mật. BleepingComputer cho biết Microsoft Defender đã nhận diện nhầm các chứng chỉ DigiCert là Trojan:Win32/Cerdigent.A!dha ^[5]. Daily.dev tóm tắt rằng sau bản cập nhật chữ ký ngày 30/4, Defender đã đánh dấu nhầm các chứng chỉ root DigiCert hợp lệ; Microsoft sau đó phát hành bản cập nhật Security Intelligence 1.449.430.0 để sửa lỗi và khôi phục các chứng chỉ bị gỡ ^[7].

Với doanh nghiệp, đây là bài toán phản ứng sự cố rất thực tế: cùng lúc phải phân biệt chứng chỉ bị lạm dụng thật, cảnh báo đối với malware đã được ký, và cảnh báo sai nhắm vào chứng chỉ hợp lệ ^[5][7].

Bài học cho đội bảo mật

• Đừng coi chữ ký số là vé thông hành. Một file có chữ ký hợp lệ, kể cả EV, không nên tự động được xem là an toàn; kẻ tấn công có thể dùng chứng chỉ EV để ký file độc hại và khai thác niềm tin vào ứng dụng đã ký ^[15].
• Kiểm tra chi tiết chứng chỉ. Nhà phát hành, số sê-ri, chuỗi chứng chỉ, dấu thời gian và trạng thái thu hồi đều quan trọng khi một binary đã ký có dấu hiệu bất thường; trong vụ DigiCert, thu hồi chứng chỉ và đặt ngày thu hồi về ngày phát hành là biện pháp khống chế then chốt ^[5].
• Ưu tiên hành vi của file. Hash, cây tiến trình, lệnh được gọi, kết nối mạng, cơ chế persistence và kết quả sandbox nên được xem cùng chữ ký số, thay vì để chữ ký số quyết định thay toàn bộ phân tích ^[15].
• Xem cổng hỗ trợ và cổng quản trị là vùng rủi ro cao. Vụ việc cho thấy ngay cả chức năng hỗ trợ có giới hạn cũng có thể trở thành điểm yếu nghiêm trọng nếu nó cho phép truy cập tài khoản khách hàng hoặc mã khởi tạo chứng chỉ ^[10].
• Xử lý false positive có kiểm soát. Các cảnh báo liên quan đến chứng chỉ không phải lúc nào cũng là nhiễm malware; trong sự cố Defender, chứng chỉ root DigiCert hợp lệ đã bị đánh dấu nhầm và sau đó được Microsoft khôi phục bằng bản cập nhật ^[7].

Kết luận

Vụ DigiCert đáng chú ý không phải vì một file screensaver quá mới lạ, mà vì nó nhắm vào niềm tin nằm sau hoạt động phân phối phần mềm. Các nguồn hiện có cho thấy đây là sự cố có phạm vi giới hạn quanh hệ thống hỗ trợ, mã khởi tạo và chứng chỉ ký mã bị lạm dụng, không phải bằng chứng về việc khóa root hoặc khóa CA bị lộ ^{[1][5][10][12]}. Tuy vậy, thông điệp dành cho phòng thủ malware rất rõ: chữ ký số là một tín hiệu quan trọng, nhưng không thể là lời phán quyết cuối cùng.