-
08/10/2013
-
401
-
1.009 bài viết
Mã độc TRITON tấn công vào hệ thống an toàn công nghiệp SIS
Cuối năm 2017, giới an ninh mạng công nghiệp chấn động bởi sự xuất hiện của TRITON (còn gọi là TRISIS/HatMan), một mã độc ICS/OT nguy hiểm được thiết kế nhằm vô hiệu hóa hệ thống an toàn công nghiệp (Safety Instrumented Systems - SIS) tại một nhà máy hóa dầu ở Ả Rập Xê Út. Đây là trường hợp đầu tiên mã độc nhắm thẳng vào hệ thống an toàn – tuyến phòng thủ cuối cùng bảo vệ người và thiết bị – khiến TRITON được mệnh danh là một trong những malware công nghiệp nguy hiểm nhất từng được phát hiện. Vụ tấn công TRITON được cho là do nhóm hacker có tên mã TEMP.Veles (còn gọi là Xenotime theo cách đặt của Dragos) thực hiện, với động cơ phá hoại công nghiệp và dấu hiệu hỗ trợ bởi một quốc gia nào đó.
Bài viết này sẽ trình bày chuyên sâu về cơ chế hoạt động của malware TRITON, cách kẻ tấn công khai thác các lỗ hổng để xâm nhập và chiếm quyền SIS, phân tích tác động thực tế của TRITON trong sự cố năm 2017, tìm hiểu về nhóm hacker TEMP.Veles và các kỹ thuật tấn công của họ, đồng thời đề xuất các biện pháp phòng ngừa và phát hiện nhằm giảm thiểu rủi ro từ các cuộc tấn công tương tự.
Bài viết này sẽ trình bày chuyên sâu về cơ chế hoạt động của malware TRITON, cách kẻ tấn công khai thác các lỗ hổng để xâm nhập và chiếm quyền SIS, phân tích tác động thực tế của TRITON trong sự cố năm 2017, tìm hiểu về nhóm hacker TEMP.Veles và các kỹ thuật tấn công của họ, đồng thời đề xuất các biện pháp phòng ngừa và phát hiện nhằm giảm thiểu rủi ro từ các cuộc tấn công tương tự.
Mã độc TRITON và cơ chế hoạt động
TRITON là một bộ khung tấn công malware được thiết kế đặc biệt để tương tác với bộ điều khiển SIS Triconex của Schneider Electric. Khác với các malware CNTT thông thường, TRITON hoạt động trên máy trạm kỹ sư SIS (Engineering Workstation) chạy Windows – nơi dùng để cấu hình và lập trình cho SIS. Mã độc này đã được ngụy trang thành chương trình hợp pháp tên “Trilog” (một tiện ích xem log thuộc bộ phần mềm TriStation của Triconex) nhằm qua mặt kỹ sư vận hành. Thực chất, TRITON là một mã Python được biên dịch sang dạng thực thi (bằng Py2EXE), kèm theo một tệp thư viện library dạng file zip chứa các thư viện và mô-đun tùy chỉnh do kẻ tấn công phát triển để giao tiếp với bộ điều khiển Triconex. Khi chạy, TRITON cho phép tin tặc giao tiếp với các PLC an toàn Triconex thông qua giao thức TriStation (giao thức độc quyền của Schneider) – điều đáng chú ý vì giao thức này không được công bố công khai, cho thấy kẻ tấn công đã nghiên cứu và tự xây dựng lại giao thức để xây dựng công cụ.
Về cơ chế kiểm soát và chức năng, TRITON có khả năng đọc/ghi chương trình trên SIS, đọc/ghi các hàm và truy vấn trạng thái của bộ điều khiển SIS. Nó có thể gửi các lệnh điều khiển chuyên biệt (ví dụ: lệnh dừng/halt thiết bị, đọc bộ nhớ) và tải mã độc tùy ý vào bộ nhớ của bộ điều khiển SIS từ xa. Cụ thể, mẫu TRITON được phân tích cho thấy kẻ tấn công đã thêm một chương trình do chúng cung cấp vào bảng thực thi của bộ điều khiển Triconex, trong khi vẫn để nguyên các chương trình an toàn hợp lệ nhằm hy vọng hệ thống tiếp tục vận hành bình thường không báo lỗi. TRITON có nhiều tính năng do thám như liệt kê thiết bị SIS qua mạng, nhưng trong vụ tấn công, chỉ một số chức năng đã được sử dụng. Mã độc không tự lây lan một cách ngẫu nhiên; thay vào đó, tin tặc phải chỉ định địa chỉ IP của từng bộ điều khiển mục tiêu và triển khai chạy file “trilog.exe” riêng cho mỗi thiết bị. Khi kích hoạt, TRITON kiểm tra trạng thái hiện tại của bộ điều khiển, đọc thông tin cấu hình qua giao thức TriStation, rồi mã hóa hai tệp payload (gồm “inject.bin” – chứa mã độc thực thi chức năng, và “imain.bin” – chứa logic điều khiển độc hại) và nạp chúng vào bộ nhớ chương trình của SIS.
Để duy trì tính ổn định của hệ thống, TRITON được lập trình với các cơ chế kiểm soát lỗi và che giấu dấu vết khá tinh vi. Sau khi chèn payload vào bộ nhớ SIS, mã độc bắt đầu đếm ngược và theo dõi trạng thái của bộ điều khiển. Nếu phát hiện lỗi hoặc thiết bị chuyển sang trạng thái lỗi, TRITON sẽ cố gắng khôi phục bộ điều khiển về trạng thái chạy bình thường bằng cách sử dụng lệnh đặc biệt của giao thức TriStation (phương thức “SafeAppendProgramMod”). Trong trường hợp nỗ lực khôi phục thất bại trong khoảng thời gian cho phép, TRITON sẽ ghi đè lên chương trình độc hại bằng dữ liệu vô nghĩa (một chương trình “rỗng”) nhằm xóa dấu vết của mã độc trong bộ nhớ thiết bị. Chính nhờ cơ chế “tự sửa lỗi” này, kẻ tấn công hy vọng SIS có thể tiếp tục vận hành trơn tru với mã độc nằm ẩn bên trong, tránh bị phát hiện bởi bất kỳ sự cố bất thường nào. Thực tế, mẫu TRITON qua phân tích, chứa một điều kiện kiểm tra khiến payload độc hại không được lưu vĩnh viễn trên thiết bị nếu chưa thỏa mãn tiêu chí nhất định, có lẽ để tránh gây lỗi rõ ràng. (Các nhà nghiên cứu Mandiant khi phân tích đã phát hiện và loại bỏ cơ chế kiểm tra này; khi đó payload độc hại có thể tồn tại lâu dài trong bộ nhớ SIS và bộ điều khiển vẫn tiếp tục chạy).
Tóm lại, TRITON hoạt động như một bộ công cụ tấn công ICS chuyên biệt, cho phép kẻ tấn công từ xa lập trình lại logic an toàn của SIS. Mục tiêu cuối cùng của mã độc là vô hiệu hóa chức năng an toàn: hoặc bằng cách gây ra sự kiện dừng đột ngột do giả tạo, khiến hệ thống ngừng hoạt động khi không có nguy hiểm thực sự, hoặc tệ hơn là lặng lẽ làm tê liệt hệ thống an toàn để các điều kiện nguy hiểm không bị phát hiện, mở đường cho sự cố vật lý nghiêm trọng. Phương thức tấn công này khác biệt hẳn so với các mã độc mạng IT thông thường vốn chỉ đánh cắp dữ liệu hay phá hoại logic điều khiển; TRITON nhắm đến việc qua mặt cả cơ chế an toàn nhằm cho phép các tình huống mất an toàn diễn ra mà không bị ngăn chặn.
Về cơ chế kiểm soát và chức năng, TRITON có khả năng đọc/ghi chương trình trên SIS, đọc/ghi các hàm và truy vấn trạng thái của bộ điều khiển SIS. Nó có thể gửi các lệnh điều khiển chuyên biệt (ví dụ: lệnh dừng/halt thiết bị, đọc bộ nhớ) và tải mã độc tùy ý vào bộ nhớ của bộ điều khiển SIS từ xa. Cụ thể, mẫu TRITON được phân tích cho thấy kẻ tấn công đã thêm một chương trình do chúng cung cấp vào bảng thực thi của bộ điều khiển Triconex, trong khi vẫn để nguyên các chương trình an toàn hợp lệ nhằm hy vọng hệ thống tiếp tục vận hành bình thường không báo lỗi. TRITON có nhiều tính năng do thám như liệt kê thiết bị SIS qua mạng, nhưng trong vụ tấn công, chỉ một số chức năng đã được sử dụng. Mã độc không tự lây lan một cách ngẫu nhiên; thay vào đó, tin tặc phải chỉ định địa chỉ IP của từng bộ điều khiển mục tiêu và triển khai chạy file “trilog.exe” riêng cho mỗi thiết bị. Khi kích hoạt, TRITON kiểm tra trạng thái hiện tại của bộ điều khiển, đọc thông tin cấu hình qua giao thức TriStation, rồi mã hóa hai tệp payload (gồm “inject.bin” – chứa mã độc thực thi chức năng, và “imain.bin” – chứa logic điều khiển độc hại) và nạp chúng vào bộ nhớ chương trình của SIS.
Để duy trì tính ổn định của hệ thống, TRITON được lập trình với các cơ chế kiểm soát lỗi và che giấu dấu vết khá tinh vi. Sau khi chèn payload vào bộ nhớ SIS, mã độc bắt đầu đếm ngược và theo dõi trạng thái của bộ điều khiển. Nếu phát hiện lỗi hoặc thiết bị chuyển sang trạng thái lỗi, TRITON sẽ cố gắng khôi phục bộ điều khiển về trạng thái chạy bình thường bằng cách sử dụng lệnh đặc biệt của giao thức TriStation (phương thức “SafeAppendProgramMod”). Trong trường hợp nỗ lực khôi phục thất bại trong khoảng thời gian cho phép, TRITON sẽ ghi đè lên chương trình độc hại bằng dữ liệu vô nghĩa (một chương trình “rỗng”) nhằm xóa dấu vết của mã độc trong bộ nhớ thiết bị. Chính nhờ cơ chế “tự sửa lỗi” này, kẻ tấn công hy vọng SIS có thể tiếp tục vận hành trơn tru với mã độc nằm ẩn bên trong, tránh bị phát hiện bởi bất kỳ sự cố bất thường nào. Thực tế, mẫu TRITON qua phân tích, chứa một điều kiện kiểm tra khiến payload độc hại không được lưu vĩnh viễn trên thiết bị nếu chưa thỏa mãn tiêu chí nhất định, có lẽ để tránh gây lỗi rõ ràng. (Các nhà nghiên cứu Mandiant khi phân tích đã phát hiện và loại bỏ cơ chế kiểm tra này; khi đó payload độc hại có thể tồn tại lâu dài trong bộ nhớ SIS và bộ điều khiển vẫn tiếp tục chạy).
Tóm lại, TRITON hoạt động như một bộ công cụ tấn công ICS chuyên biệt, cho phép kẻ tấn công từ xa lập trình lại logic an toàn của SIS. Mục tiêu cuối cùng của mã độc là vô hiệu hóa chức năng an toàn: hoặc bằng cách gây ra sự kiện dừng đột ngột do giả tạo, khiến hệ thống ngừng hoạt động khi không có nguy hiểm thực sự, hoặc tệ hơn là lặng lẽ làm tê liệt hệ thống an toàn để các điều kiện nguy hiểm không bị phát hiện, mở đường cho sự cố vật lý nghiêm trọng. Phương thức tấn công này khác biệt hẳn so với các mã độc mạng IT thông thường vốn chỉ đánh cắp dữ liệu hay phá hoại logic điều khiển; TRITON nhắm đến việc qua mặt cả cơ chế an toàn nhằm cho phép các tình huống mất an toàn diễn ra mà không bị ngăn chặn.
Khai thác lỗ hổng để chiếm quyền SIS
Để có thể triển khai được TRITON như trên, kẻ tấn công TEMP.Veles đã phải xâm nhập sâu vào mạng OT của nạn nhân qua nhiều giai đoạn. Thông thường, mạng SIS được cô lập hoặc tách lớp khỏi mạng IT, nhưng trong vụ này, kiến trúc nhà máy có mức độ tích hợp giữa hệ thống điều khiển (DCS) và SIS nhất định, tạo điều kiện cho kẻ tấn công đi chuyển ngang từ mạng IT/DCS sang mạng SIS. Các báo cáo điều tra cho thấy trước khi chạm đến được máy trạm SIS, nhóm hacker đã hiện diện âm thầm trong mạng nạn nhân nhiều tháng liền (gần một năm), chiếm quyền trên nhiều máy chủ và máy trạm khác nhau. Chúng sử dụng những kỹ thuật xâm nhập truyền thống như spear-phishing hoặc khai thác lỗ hổng để có chỗ đứng ban đầu trên mạng IT, sau đó leo thang đặc quyền và đánh cắp thông tin xác thực từ hệ thống Windows (ví dụ: công cụ tùy chỉnh “SecHack” tương tự Mimikatz để trích xuất mật khẩu từ bộ nhớ). Với thông tin đăng nhập thu được, chúng di chuyển qua lại giữa các máy trong mạng bằng cách thi hành lệnh từ xa (công cụ “NetExec” tương tự PSExec), đồng thời cài đặt nhiều cửa hậu (backdoor) khác nhau để duy trì quyền truy cập (bao gồm backdoor dựa trên Cryptcat, Plink, Bitvise, OpenSSH, cũng như web shell cài vào máy chủ Outlook Web Access). Tất cả các công cụ này đều được tùy biến riêng (thay vì dùng bản có sẵn công khai) nhằm né tránh chống virus và hệ thống phát hiện xâm nhập, giúp nhóm hacker ẩn mình lâu hơn trong mạng nạn nhân.
Sau khi đã kiểm soát các nút trong mạng IT và DCS, nhóm TEMP.Veles tiến hành bước quyết định là xâm nhập vào mạng SIS. Thông qua một máy chủ trung gian có kết nối hai chiều giữa mạng DCS và SIS (có thể là máy trạm kỹ sư hoặc máy chủ giao tiếp DMZ), kẻ tấn công truy cập được máy trạm kỹ sư SIS – nơi cài phần mềm TriStation để lập trình hệ thống an toàn. Từ đây, chúng nhanh chóng triển khai mã độc TRITON đã chuẩn bị sẵn lên máy trạm SIS và bắt đầu tương tác với các bộ điều khiển an toàn Triconex trong nhà máy. Theo FireEye, kẻ tấn công đã đột nhập và kích hoạt TRITON ngay sau khi đạt được quyền truy cập máy trạm SIS, cho thấy chúng đã có sự chuẩn bị kỹ lưỡng từ trước, bao gồm thử nghiệm mã độc trên cùng loại thiết bị và phần mềm trong phòng thí nghiệm trước khi tấn công thực tế. Điều này cũng hàm ý chúng sở hữu hoặc tiếp cận được phần cứng SIS hiếm gặp để phát triển và thử nghiệm – một khả năng chỉ các tổ chức lớn hoặc quốc gia mới có thể hỗ trợ.
Sau khi đã kiểm soát các nút trong mạng IT và DCS, nhóm TEMP.Veles tiến hành bước quyết định là xâm nhập vào mạng SIS. Thông qua một máy chủ trung gian có kết nối hai chiều giữa mạng DCS và SIS (có thể là máy trạm kỹ sư hoặc máy chủ giao tiếp DMZ), kẻ tấn công truy cập được máy trạm kỹ sư SIS – nơi cài phần mềm TriStation để lập trình hệ thống an toàn. Từ đây, chúng nhanh chóng triển khai mã độc TRITON đã chuẩn bị sẵn lên máy trạm SIS và bắt đầu tương tác với các bộ điều khiển an toàn Triconex trong nhà máy. Theo FireEye, kẻ tấn công đã đột nhập và kích hoạt TRITON ngay sau khi đạt được quyền truy cập máy trạm SIS, cho thấy chúng đã có sự chuẩn bị kỹ lưỡng từ trước, bao gồm thử nghiệm mã độc trên cùng loại thiết bị và phần mềm trong phòng thí nghiệm trước khi tấn công thực tế. Điều này cũng hàm ý chúng sở hữu hoặc tiếp cận được phần cứng SIS hiếm gặp để phát triển và thử nghiệm – một khả năng chỉ các tổ chức lớn hoặc quốc gia mới có thể hỗ trợ.
Hình 2: Ảnh chụp khóa chuyển chế độ trên bộ điều khiển SIS Triconex. Khóa có các vị tríRemote(điều khiển từ xa) với các chế độ Run/Program/Stop, vàLocal. Để lập trình từ xa, khóa phải ở vị tríRemote Program. Nếu khóa này bị cố ý để ở chế độ Program từ xa, kẻ tấn công có thể tải mã độc xuống SIS một cách dễ dàng qua mạng.
Bên cạnh việc lợi dụng cấu hình mạng tích hợp, nhóm TEMP.Veles còn khai thác các điểm yếu về quy trình và thiết kế an toàn của hệ thống SIS. Một yếu tố quan trọng là trạng thái khóa vật lý trên bộ điều khiển SIS (Hình 2): trên các máy Triconex, có khóa chuyển cho phép lựa chọn chế độ Run/Program. Theo nguyên tắc, khóa chỉ nên chuyển sang chế độ “Program” (lập trình) khi có bảo trì và phải để “Run” (chạy) trong vận hành bình thường[26]. Tuy nhiên, khả năng cao trong vụ này, các bộ điều khiển đã ở chế độ cho phép lập trình từ xa, tạo cơ hội để tin tặc tải logic độc hại vào mà không cần khai thác lỗ hổng phần mềm nào sâu hơn. Thực vậy, giao thức TriStation mà TRITON sử dụng không có cơ chế xác thực mạnh – bất kỳ máy trạm nào trong mạng có thể gửi lệnh hợp lệ tới SIS nếu hệ thống không có lớp bảo vệ bổ sung. Kết hợp việc không phân tách mạng SIS triệt để và khóa lập trình SIS không được kiểm soát chặt, kẻ tấn công đã “mở khóa” thành công cánh cửa vào lõi an toàn của nhà máy.
Các báo cáo cũng đề cập việc nhóm hacker đã tận dụng một lỗ hổng hoặc thiếu sót trong cơ chế bảo vệ của Triconex SIS để thực sự chiếm quyền điều khiển nó. Cụ thể, TRITON đã khai thác giao thức và chức năng nội tại của thiết bị để vô hiệu hóa hệ thống an toàn (bằng cách nạp mã độc tùy chỉnh). Kết quả là các bộ điều khiển SIS bị chuyển sang trạng thái lỗi, không còn thực thi chức năng an toàn, tức là “bị hạ gục” khỏi vai trò bảo vệ. Nói cách khác, kẻ tấn công đã khiến SIS không hoạt động khi cần thiết, trong khi từ góc nhìn hệ thống vận hành thì mọi thứ có vẻ vẫn bình thường – một tình huống cực kỳ nguy hiểm. Rất may, như phân tích ở phần sau, việc khai thác của TRITON tại nhà máy Ả Rập Xê Út đã dẫn đến hiện tượng lỗi an toàn được phát hiện (fault) khiến hệ thống dừng khẩn, chứ không lặng lẽ bỏ qua cảnh báo. Nhưng rõ ràng, khoảng trống bảo mật ở đây là có thực: thiếu các rào cản ngăn chặn lập trình trái phép SIS và thiếu giám sát xâm nhập sâu trong mạng OT.
Các báo cáo cũng đề cập việc nhóm hacker đã tận dụng một lỗ hổng hoặc thiếu sót trong cơ chế bảo vệ của Triconex SIS để thực sự chiếm quyền điều khiển nó. Cụ thể, TRITON đã khai thác giao thức và chức năng nội tại của thiết bị để vô hiệu hóa hệ thống an toàn (bằng cách nạp mã độc tùy chỉnh). Kết quả là các bộ điều khiển SIS bị chuyển sang trạng thái lỗi, không còn thực thi chức năng an toàn, tức là “bị hạ gục” khỏi vai trò bảo vệ. Nói cách khác, kẻ tấn công đã khiến SIS không hoạt động khi cần thiết, trong khi từ góc nhìn hệ thống vận hành thì mọi thứ có vẻ vẫn bình thường – một tình huống cực kỳ nguy hiểm. Rất may, như phân tích ở phần sau, việc khai thác của TRITON tại nhà máy Ả Rập Xê Út đã dẫn đến hiện tượng lỗi an toàn được phát hiện (fault) khiến hệ thống dừng khẩn, chứ không lặng lẽ bỏ qua cảnh báo. Nhưng rõ ràng, khoảng trống bảo mật ở đây là có thực: thiếu các rào cản ngăn chặn lập trình trái phép SIS và thiếu giám sát xâm nhập sâu trong mạng OT.
Tác động thực tế của TRITON đối với hệ thống ICS/OT
Vụ tấn công TRITON vào năm 2017 để lại hệ quả nghiêm trọng cho một nhà máy hóa dầu, đồng thời gióng lên hồi chuông cảnh tỉnh về nguy cơ đối với các hệ thống ICS/OT trên toàn cầu. Theo điều tra, vào tối ngày 4/8/2017, hai hệ thống SIS tại cơ sở ở Ả Rập Xê Út bất ngờ kích hoạt chế độ dừng khẩn cấp gần như đồng thời, khiến một phần tổ hợp nhà máy phải ngừng hoạt động tức thì. Hệ thống an toàn đã phản ứng đúng như thiết kế khi nhận thấy tín hiệu bất thường: nó chủ động ngắt quy trình để ngăn chặn khả năng xảy ra sự cố nguy hiểm như rò rỉ khí độc hoặc nổ lớn trong nhà máy. Thời điểm đó, các kỹ sư vận hành trong phòng điều khiển không phát hiện bất kỳ dấu hiệu bất thường nào về quá trình công nghệ – mọi cảm biến và thông số quy trình dường như vẫn trong giới hạn an toàn. Việc hệ thống SIS “đột ngột” kích hoạt mà DCS không thấy sự cố quy trình đã gây hoang mang và thúc giục nhà máy tiến hành điều tra khẩn cấp.
Kết quả điều tra (có sự tham gia của chuyên gia bên thứ ba như FireEye Mandiant) đã sớm phát hiện mã độc TRITON ẩn trong các thiết bị SIS. Các bộ điều khiển an toàn Triconex bị nạp mã lạ dẫn đến lỗi trầm trọng giữa các bộ xử lý dự phòng, buộc SIS phải chuyển sang trạng thái an toàn (fail-safe) và dừng quy trình. Nói cách khác, mã độc đã trực tiếp gây ra hai lần dừng khẩn cấp tại nhà máy – đây là hậu quả hữu hình đầu tiên của một cuộc tấn công mạng vào hệ thống an toàn công nghiệp. May mắn thay, việc SIS kịp thời dừng quy trình đã ngăn chặn sự cố vượt khỏi tầm kiểm soát. Không có thiệt hại vật chất hay thương vong nào được báo cáo, ngoài thiệt hại về thời gian ngừng sản xuất và chi phí khởi động lại hệ thống. Giới chuyên gia đánh giá rằng nếu kẻ tấn công thành công vô hiệu hóa hoàn toàn SIS một cách âm thầm (thay vì gây ra lỗi phát hiện được), chúng có thể đã tiến hành các thao tác nguy hiểm trên hệ thống điều khiển (DCS) để tạo ra thảm họa vật lý – ví dụ như gây quá áp suất, quá nhiệt dẫn đến nổ lớn – mà hệ thống an toàn không can thiệp kịp. Thực tế, ý đồ này đã không thành công do trục trặc trong giai đoạn phát triển tấn công: FireEye cho rằng kẻ tấn công vô tình gây shutdown sớm khi đang thử nghiệm khả năng gây hại, tức là chúng chưa đạt mục đích cuối. Dù vậy, sự cố năm 2017 vẫn được xem là “cuộc tấn công liều lĩnh nhất” nhắm vào ICS tính đến thời điểm đó, vì nó trực tiếp can thiệp vào hệ thống bảo vệ sự an toàn của một tổ hợp công nghiệp quy mô lớn.
Hậu quả tức thời của vụ TRITON là nhà máy phải tạm dừng hoạt động để kiểm tra và khôi phục hệ thống. Quan trọng hơn, sự kiện này đã thúc đẩy hàng loạt cảnh báo từ các cơ quan an ninh mạng trên thế giới. Các thông báo kỹ thuật (ICS Alert) được phát đi để cảnh báo các ngành công nghiệp khác về một loại malware tấn công ICS mới, khuyến nghị kiểm tra hệ thống Triconex và áp dụng các biện pháp bảo mật khẩn cấp. Về phía Schneider Electric – nhà cung cấp thiết bị, hãng cũng phối hợp điều tra và phát hành hướng dẫn kỹ thuật nhằm hỗ trợ khách hàng phát hiện dấu hiệu TRITON và tăng cường an ninh cho sản phẩm Triconex.
Từ góc độ an ninh ICS, vụ TRITON đã minh chứng một kịch bản tồi tệ: tin tặc có thể chiếm quyền cả hệ thống điều khiển lẫn hệ thống an toàn của một nhà máy, đặt cơ sở vào tình thế mất kiểm soát. Đây không còn là nguy cơ giả định mà đã thành hiện thực. Nếu như vụ Stuxnet (2010) cho thấy mã độc có thể phá hủy thiết bị công nghiệp (máy ly tâm hạt nhân) và Industroyer (2016) cho thấy tin tặc có thể làm sập lưới điện, thì TRITON (2017) bổ sung một lời cảnh báo mới: ngay cả hệ thống an toàn “cứu mạng” cũng có thể bị tấn công. Điều này đặt ra yêu cầu cấp bách về việc tái đánh giá các giả định an toàn trong thiết kế ICS/OT – rằng an toàn và an ninh mạng không còn tách rời, một lỗ hổng an ninh có thể dẫn đến rủi ro an toàn nghiêm trọng.
Kết quả điều tra (có sự tham gia của chuyên gia bên thứ ba như FireEye Mandiant) đã sớm phát hiện mã độc TRITON ẩn trong các thiết bị SIS. Các bộ điều khiển an toàn Triconex bị nạp mã lạ dẫn đến lỗi trầm trọng giữa các bộ xử lý dự phòng, buộc SIS phải chuyển sang trạng thái an toàn (fail-safe) và dừng quy trình. Nói cách khác, mã độc đã trực tiếp gây ra hai lần dừng khẩn cấp tại nhà máy – đây là hậu quả hữu hình đầu tiên của một cuộc tấn công mạng vào hệ thống an toàn công nghiệp. May mắn thay, việc SIS kịp thời dừng quy trình đã ngăn chặn sự cố vượt khỏi tầm kiểm soát. Không có thiệt hại vật chất hay thương vong nào được báo cáo, ngoài thiệt hại về thời gian ngừng sản xuất và chi phí khởi động lại hệ thống. Giới chuyên gia đánh giá rằng nếu kẻ tấn công thành công vô hiệu hóa hoàn toàn SIS một cách âm thầm (thay vì gây ra lỗi phát hiện được), chúng có thể đã tiến hành các thao tác nguy hiểm trên hệ thống điều khiển (DCS) để tạo ra thảm họa vật lý – ví dụ như gây quá áp suất, quá nhiệt dẫn đến nổ lớn – mà hệ thống an toàn không can thiệp kịp. Thực tế, ý đồ này đã không thành công do trục trặc trong giai đoạn phát triển tấn công: FireEye cho rằng kẻ tấn công vô tình gây shutdown sớm khi đang thử nghiệm khả năng gây hại, tức là chúng chưa đạt mục đích cuối. Dù vậy, sự cố năm 2017 vẫn được xem là “cuộc tấn công liều lĩnh nhất” nhắm vào ICS tính đến thời điểm đó, vì nó trực tiếp can thiệp vào hệ thống bảo vệ sự an toàn của một tổ hợp công nghiệp quy mô lớn.
Hậu quả tức thời của vụ TRITON là nhà máy phải tạm dừng hoạt động để kiểm tra và khôi phục hệ thống. Quan trọng hơn, sự kiện này đã thúc đẩy hàng loạt cảnh báo từ các cơ quan an ninh mạng trên thế giới. Các thông báo kỹ thuật (ICS Alert) được phát đi để cảnh báo các ngành công nghiệp khác về một loại malware tấn công ICS mới, khuyến nghị kiểm tra hệ thống Triconex và áp dụng các biện pháp bảo mật khẩn cấp. Về phía Schneider Electric – nhà cung cấp thiết bị, hãng cũng phối hợp điều tra và phát hành hướng dẫn kỹ thuật nhằm hỗ trợ khách hàng phát hiện dấu hiệu TRITON và tăng cường an ninh cho sản phẩm Triconex.
Từ góc độ an ninh ICS, vụ TRITON đã minh chứng một kịch bản tồi tệ: tin tặc có thể chiếm quyền cả hệ thống điều khiển lẫn hệ thống an toàn của một nhà máy, đặt cơ sở vào tình thế mất kiểm soát. Đây không còn là nguy cơ giả định mà đã thành hiện thực. Nếu như vụ Stuxnet (2010) cho thấy mã độc có thể phá hủy thiết bị công nghiệp (máy ly tâm hạt nhân) và Industroyer (2016) cho thấy tin tặc có thể làm sập lưới điện, thì TRITON (2017) bổ sung một lời cảnh báo mới: ngay cả hệ thống an toàn “cứu mạng” cũng có thể bị tấn công. Điều này đặt ra yêu cầu cấp bách về việc tái đánh giá các giả định an toàn trong thiết kế ICS/OT – rằng an toàn và an ninh mạng không còn tách rời, một lỗ hổng an ninh có thể dẫn đến rủi ro an toàn nghiêm trọng.
Nhóm hacker TEMP.Veles (Xenotime) và kỹ thuật tấn công
Các dấu vết kỹ thuật số và tình báo mạng đã dẫn giới chuyên môn tới nhận định nhóm đứng sau TRITON chính là TEMP.Veles – một nhóm APT, được chống lưng bởi nguồn lực lớn (nhiều khả năng từ chính phủ). FireEye/Mandiant theo dõi nhóm này dưới mã TEMP.Veles, trong khi công ty an ninh ICS Dragos định danh nhóm tương tự là Xenotime. Hồ sơ của TEMP.Veles/Xenotime cho thấy nhóm bắt đầu hoạt động từ năm 2014, nhắm vào các mục tiêu hạ tầng trọng yếu (dầu khí, năng lượng) và kiên trì xâm nhập trong thời gian dài. Điểm nổi bật là nhóm có kiến thức chuyên sâu về hệ thống công nghiệp: xây dựng từ đầu bộ công cụ TRITON để tấn công SIS – việc đòi hỏi kỹ năng hiểu rất rõ giao thức độc quyền và thử nghiệm trên thiết bị thật. FireEye đánh giá những dấu hiệu này cho thấy một quốc gia bảo trợ: mục tiêu tấn công vào hạ tầng trọng yếu, không nhằm vào thu lợi tiền bạc, sẵn sàng đầu tư nghiên cứu nhiều năm và mua sắm phần cứng chuyên dụng.
Về kỹ thuật tấn công, TEMP.Veles thể hiện sự bài bản và tinh vi xuyên suốt chu trình xâm nhập. Như đã đề cập, nhóm sử dụng nhiều công cụ tùy chỉnh cho giai đoạn thâm nhập mạng IT: từ thu thập thông tin xác thực (SecHack tương tự Mimikatz) đến di chuyển ngang (NetExec tương tự PsExec), cài backdoor đa dạng (dựa trên các công cụ mã nguồn mở nhưng đã chỉnh sửa) giúp tránh bị phát hiện. Kẻ gian cũng rất kiên nhẫn: trong cả hai sự cố FireEye điều tra (nhà máy Saudi 2017 và một cơ sở khác năm 2019), hacker đã hiện diện hàng tháng trời trong mạng nạn nhân, hoàn thiện việc kiểm soát hệ thống Windows và thu thập thông tin ICS trước khi tung đòn tấn công TRITON. Thậm chí, FireEye lưu ý rằng việc phát hiện các công cụ tùy chỉnh như SecHack/NetExec trong mạng nội bộ là dấu hiệu chỉ báo quan trọng – vì nhóm này ít xuất hiện, nên nếu thấy các mã độc dạng đó, rất có thể mạng đang bị TEMP.Veles nhắm tới.
Một khía cạnh đáng chú ý khác là phạm vi hoạt động của TEMP.Veles không dừng lại ở Trung Đông. Sau vụ 2017, nhóm này bị phát hiện mở rộng mục tiêu sang các công ty dầu khí ở Bắc Mỹ và thậm chí dò quét vào hệ thống điện của Mỹ. Đầu năm 2019, Dragos báo cáo rằng nhóm này đã tiến hành quét rộng rãi hàng chục công ty điện lực Hoa Kỳ, tìm kiếm các cổng dịch vụ và lỗ hổng tương tự cách thức chúng từng làm với dầu khí. Mặc dù việc dò quét này chưa gây hậu quả, nhưng sự hiện diện của một nhóm hacker hung hãn có tiền sử tấn công an toàn nhà máy trong mạng lưới điện là cực kỳ đáng lo ngại. Dragos thậm chí gọi Xenotime là “mối đe dọa nguy hiểm nhất đối với ICS từng được biết”. Ngoài ra, các báo cáo tình báo còn cho thấy TEMP.Veles có thể đang nhắm vào chuỗi cung ứng công nghệ công nghiệp – ví dụ như thâm nhập các công ty cung cấp thiết bị/phần mềm ICS – nhằm tìm kiếm lỗ hổng mới hoặc tạo cửa hậu cho các cuộc tấn công tương lai. Tất cả cho thấy nhóm này vẫn rất tích cực và dài hơi, đặt ra mối đe dọa thường trực cho các hệ thống ICS/OT trên thế giới. Các chuyên gia nhận định TEMP.Veles/Xenotime sẽ còn hoạt động trong tương lai gần và có thể thay đổi chiến thuật sau khi bị lộ thông tin, đòi hỏi các nhà phòng thủ phải liên tục cập nhật và cảnh giác.
Về kỹ thuật tấn công, TEMP.Veles thể hiện sự bài bản và tinh vi xuyên suốt chu trình xâm nhập. Như đã đề cập, nhóm sử dụng nhiều công cụ tùy chỉnh cho giai đoạn thâm nhập mạng IT: từ thu thập thông tin xác thực (SecHack tương tự Mimikatz) đến di chuyển ngang (NetExec tương tự PsExec), cài backdoor đa dạng (dựa trên các công cụ mã nguồn mở nhưng đã chỉnh sửa) giúp tránh bị phát hiện. Kẻ gian cũng rất kiên nhẫn: trong cả hai sự cố FireEye điều tra (nhà máy Saudi 2017 và một cơ sở khác năm 2019), hacker đã hiện diện hàng tháng trời trong mạng nạn nhân, hoàn thiện việc kiểm soát hệ thống Windows và thu thập thông tin ICS trước khi tung đòn tấn công TRITON. Thậm chí, FireEye lưu ý rằng việc phát hiện các công cụ tùy chỉnh như SecHack/NetExec trong mạng nội bộ là dấu hiệu chỉ báo quan trọng – vì nhóm này ít xuất hiện, nên nếu thấy các mã độc dạng đó, rất có thể mạng đang bị TEMP.Veles nhắm tới.
Một khía cạnh đáng chú ý khác là phạm vi hoạt động của TEMP.Veles không dừng lại ở Trung Đông. Sau vụ 2017, nhóm này bị phát hiện mở rộng mục tiêu sang các công ty dầu khí ở Bắc Mỹ và thậm chí dò quét vào hệ thống điện của Mỹ. Đầu năm 2019, Dragos báo cáo rằng nhóm này đã tiến hành quét rộng rãi hàng chục công ty điện lực Hoa Kỳ, tìm kiếm các cổng dịch vụ và lỗ hổng tương tự cách thức chúng từng làm với dầu khí. Mặc dù việc dò quét này chưa gây hậu quả, nhưng sự hiện diện của một nhóm hacker hung hãn có tiền sử tấn công an toàn nhà máy trong mạng lưới điện là cực kỳ đáng lo ngại. Dragos thậm chí gọi Xenotime là “mối đe dọa nguy hiểm nhất đối với ICS từng được biết”. Ngoài ra, các báo cáo tình báo còn cho thấy TEMP.Veles có thể đang nhắm vào chuỗi cung ứng công nghệ công nghiệp – ví dụ như thâm nhập các công ty cung cấp thiết bị/phần mềm ICS – nhằm tìm kiếm lỗ hổng mới hoặc tạo cửa hậu cho các cuộc tấn công tương lai. Tất cả cho thấy nhóm này vẫn rất tích cực và dài hơi, đặt ra mối đe dọa thường trực cho các hệ thống ICS/OT trên thế giới. Các chuyên gia nhận định TEMP.Veles/Xenotime sẽ còn hoạt động trong tương lai gần và có thể thay đổi chiến thuật sau khi bị lộ thông tin, đòi hỏi các nhà phòng thủ phải liên tục cập nhật và cảnh giác.
Biện pháp phòng ngừa và phát hiện tấn công tương tự
Sự kiện TRITON đã chỉ ra rằng việc bảo vệ hệ thống ICS/OT, đặc biệt là hệ thống an toàn SIS, cần được ưu tiên hàng đầu. Dựa trên bài học từ vụ tấn công và khuyến cáo của các chuyên gia, dưới đây là một số biện pháp phòng ngừa và phát hiện nhằm giảm thiểu rủi ro từ các cuộc tấn công tương tự:
- Phân tách mạng ICS và SIS: Thiết kế kiến trúc mạng phân vùng chặt chẽ giữa mạng an toàn (SIS) và mạng điều khiển/quản trị (DCS/IT). Tránh tích hợp hai hệ thống nếu không thực sự cần thiết. Đặc biệt, máy trạm kỹ sư SIS không được kết nối đồng thời vào mạng DCS hoặc mạng văn phòng. Nếu cần trao đổi dữ liệu giữa SIS và hệ thống khác, nên sử dụng các giải pháp một chiều (data diode) thay vì kết nối mạng hai chiều.
- Bảo vệ vật lý thiết bị an toàn: Sử dụng các cơ chế khóa vật lý trên bộ điều khiển SIS để ngăn lập trình trái phép. Ví dụ, luôn giữ khóa chế độ của Triconex ở vị trí “Run” (không cho phép Program từ xa) trừ khi bảo trì có kế hoạch. Thực hiện quy trình quản lý thay đổi cho bất kỳ lần chuyển khóa nào và kiểm tra định kỳ trạng thái khóa trên các bộ điều khiển an toàn.
- Kiểm soát truy cập và cấu hình hệ thống: Thực hiện kiểm soát truy cập nghiêm ngặt đến mọi máy chủ, máy trạm có thể tiếp cận SIS qua giao thức mạng (TCP/IP). Áp dụng giải pháp danh sách trắng trên các ứng dụng trên các máy trạm kỹ sư – chỉ cho phép chạy các phần mềm đã được phê duyệt để ngăn mã độc lạ thực thi. Đảm bảo tài khoản người dùng có quyền cấu hình SIS được quản lý chặt (mật khẩu mạnh, hạn chế người dùng, áp dụng xác thực đa yếu tố nếu có thể).
- Giám sát mạng ICS và phát hiện bất thường: Triển khai hệ thống IDS/IPS chuyên biệt cho ICS để giám sát lưu lượng mạng giữa các thành phần OT. Cấu hình hệ thống giám sát để cảnh báo khi có lưu lượng hoặc lệnh bất thường trên giao thức ICS (ví dụ: lệnh TriStation bất ngờ xuất hiện trên mạng, hoặc một máy trạm lạ giao tiếp với bộ điều khiển SIS). Việc giám sát ngang trong mạng OT cũng quan trọng không kém gì bảo vệ chu vi, vì kẻ tấn công thường đã ở bên trong và di chuyển trong mạng một thời gian trước khi ra tay.
- Phát hiện hành vi xâm nhập sớm: Kết hợp theo dõi hệ thống IT và OT để phát hiện các dấu hiệu tấn công giai đoạn sớm. Thực hiện săn tìm các mối đe dọa định kỳ, tìm kiếm các chỉ dấu như việc sử dụng các công cụ đáng ngờ (vd: công cụ dump mật khẩu, PSExec/WinRM bất thường) trong mạng IT – đây có thể là dấu hiệu của nhóm APT đang chuẩn bị xâm nhập OT. Các kỹ thuật, công cụ mà TEMP.Veles sử dụng đã được công bố rộng rãi trong các báo cáo tình báo mối đe dọa, doanh nghiệp nên đưa những chỉ báo này vào quy trình giám sát và săn tìm mối đe dọa của mình.
- Cập nhật và kiểm định hệ thống SIS: Làm việc với nhà cung cấp (như Schneider Electric) để cập nhật firmware/bản vá mới nhất cho thiết bị SIS, nếu có các bản vá bảo mật. Sau sự cố TRITON, Schneider đã hợp tác hỗ trợ người dùng đánh giá hệ thống – do đó doanh nghiệp sở hữu Triconex nên liên hệ để được tư vấn cấu hình an toàn. Đồng thời, tiến hành kiểm định bảo mật độc lập cho hệ thống SIS (pentest/đánh giá) để kịp thời phát hiện cấu hình chưa an toàn hoặc điểm yếu logic.
- Đào tạo và quy trình ứng phó sự cố: Nâng cao nhận thức an ninh mạng cho đội ngũ vận hành ICS/OT – giúp họ nhận biết các dấu hiệu bất thường có thể là do tấn công (vd: thiết bị an toàn báo lỗi không rõ nguyên nhân). Xây dựng kế hoạch ứng phó sự cố ICS chi tiết, bao gồm kịch bản khi nghi ngờ malware tấn công SIS: phải làm gì để khôi phục an toàn, ai liên lạc hỗ trợ (nhà cung cấp, chuyên gia IR), cách cô lập hệ thống tránh lây lan, v.v. Việc diễn tập định kỳ các kịch bản này sẽ giúp tổ chức phản ứng nhanh và chính xác, giảm thiểu thiệt hại nếu xảy ra sự cố thật.
Tổng kết
Sự kiện TEMP.Veles và malware TRITON năm 2017 là lời nhắc nhở đắt giá rằng an ninh mạng và an toàn vận hành công nghiệp có mối liên hệ mật thiết. Một lỗ hổng bảo mật bị khai thác không chỉ dừng lại ở mất dữ liệu hay gián đoạn sản xuất, mà có thể dẫn đến nguy cơ khủng hoảng an toàn, đe dọa tính mạng con người và môi trường. TRITON đánh dấu bước leo thang nguy hiểm trong “cuộc chạy đua vũ trang” về chiến tranh mạng công nghiệp, khi kẻ tấn công dám nhắm vào hệ thống bảo hộ cuối cùng của nhà máy.
Đối với cộng đồng bảo mật ICS/OT, bài học rút ra là không thể chủ quan với bất kỳ lớp nào của hệ thống. Cần rà soát lại kiến trúc mạng, củng cố các biện pháp bảo vệ phòng thủ nhiều tầng và đầu tư vào khả năng phát hiện sớm. Việc chia sẻ thông tin tình báo mối đe dọa (như IoCs, TTP của TEMP.Veles) giữa các tổ chức cũng rất quan trọng để đón đầu nhóm tấn công trước khi chúng kịp gây hậu quả.
Nhìn về tương lai, các nhóm hacker như TEMP.Veles nhiều khả năng vẫn âm thầm hoạt động, thậm chí thay đổi chiến thuật để né tránh sự chú ý. Do đó, các nhà vận hành hạ tầng thiết yếu cần duy trì trạng thái cảnh giác cao, liên tục cập nhật thông tin và công nghệ phòng thủ. Sự cố TRITON 2017, tuy nguy hiểm, đã may mắn không gây thảm họa. Nhưng nó cho chúng ta cơ hội để học hỏi và củng cố hệ thống, đảm bảo rằng những toan tính tấn công vào an toàn công nghiệp như vậy sẽ bị phát hiện và ngăn chặn kịp thời, trước khi có thể gây ra hậu quả khôn lường.
Tham khảo
A Peek Into the Toolkit of the Dangerous 'Triton' Hackers - WIRED
The Highly Dangerous 'Triton' Hackers Have Probed the US Grid - WIRED
TEMP.Veles, XENOTIME, Group G0088 - MITRE ATT&CK
TRITON Malware: Attackers Deploy New ICS Attack Framework - Google Cloud Blog
The inside story of the world's most dangerous malware - E&E News by POLITICO
Đối với cộng đồng bảo mật ICS/OT, bài học rút ra là không thể chủ quan với bất kỳ lớp nào của hệ thống. Cần rà soát lại kiến trúc mạng, củng cố các biện pháp bảo vệ phòng thủ nhiều tầng và đầu tư vào khả năng phát hiện sớm. Việc chia sẻ thông tin tình báo mối đe dọa (như IoCs, TTP của TEMP.Veles) giữa các tổ chức cũng rất quan trọng để đón đầu nhóm tấn công trước khi chúng kịp gây hậu quả.
Nhìn về tương lai, các nhóm hacker như TEMP.Veles nhiều khả năng vẫn âm thầm hoạt động, thậm chí thay đổi chiến thuật để né tránh sự chú ý. Do đó, các nhà vận hành hạ tầng thiết yếu cần duy trì trạng thái cảnh giác cao, liên tục cập nhật thông tin và công nghệ phòng thủ. Sự cố TRITON 2017, tuy nguy hiểm, đã may mắn không gây thảm họa. Nhưng nó cho chúng ta cơ hội để học hỏi và củng cố hệ thống, đảm bảo rằng những toan tính tấn công vào an toàn công nghiệp như vậy sẽ bị phát hiện và ngăn chặn kịp thời, trước khi có thể gây ra hậu quả khôn lường.
Tham khảo
A Peek Into the Toolkit of the Dangerous 'Triton' Hackers - WIRED
The Highly Dangerous 'Triton' Hackers Have Probed the US Grid - WIRED
TEMP.Veles, XENOTIME, Group G0088 - MITRE ATT&CK
TRITON Malware: Attackers Deploy New ICS Attack Framework - Google Cloud Blog
The inside story of the world's most dangerous malware - E&E News by POLITICO