I. Tóm tắt chung

Chương trình diễn tập quốc tế ACID 2022 chủ đề “Dealing with Disruptive Cyber-Attacks Arising from Exploitation of Vulnerabilities - Ứng phó tấn công gián đoạn mạng từ việc khai thác lỗ hổng bảo mật”. Diễn tập ACID 2022 tiếp tục sử dụng các xu hướng an toàn thông tin mạng mới nhất làm tình huống diễn tập nhằm tăng cường sự chuẩn bị sẵn sàng và xử lý các sự cố đang xảy ra tại các quốc gia ASEAN.

Nhận được Công văn mời tham gia diễn tập và nhận thấy chủ đề có nội dung thiết thực, có thể nâng cao trình độ và khả năng phản ứng của Đội, Đội Ứng cứu sự cố Ngành Bảo hiểm xã hội Việt Nam đã tập hợp các thành viên đăng ký tham gia.

2. Chia sẻ nội dung thực hiện các pha diễn tập

Chương trình diễn tập lấy một tình huống xảy ra khi nhận được một cảnh báo từ SingCERT (Đội ứng cứu sự cố của Singapore) về một nguy cơ tấn công mã hóa dữ liệu để đòi tiền chuộc, nếu nạn nhân không đồng ý trả tiền thì kẻ tấn công sẽ tiếp tục tấn công vào các hệ thống khác của nạn nhân.

Nội dung chương trình diễn tập bao gồm 6 phase với mỗi phase sẽ yêu cầu các đội chơi phân tích các thông tin để tìm ra cách thức tấn công, lỗ hổng tồn tại trong hệ thống cũng như khuyến nghị cho tổ chức bị tấn công cách giải quyết, giảm thiểu thiệt hại.

1. Phase 1

Nhận được thư điện tử từ SingCERT cảnh báo về cuộc tấn công có thể xảy ra do khai thác lỗ hổng để tấn công hệ thống thông tin của tổ chức.

Inject 01: Cảnh báo từ SingCERT

Đối với Đội Ứng cứu sự cố của BHXH Việt Nam (sau đây gọi tắt là Đội), khi nhận được cảnh báo như vậy, Đội sẽ khuyến nghị CERT các nước tăng cường thu thập thông tin, săn tìm lỗ hổng (Threat Hunting) để nhanh chóng có thể phát hiện được những nguy cơ tiềm tàng. Đồng thời, cần thiết lập các kênh trao đổi để CERT các nước có thể chia sẻ thông tin cần thiết để có thể thực hiện ứng cứu nhanh nhất có thể.

2.  Phase 2

[Tóm tắt nội dung]

Phase 2 bắt đầu với việc nhận được thư từ Hersey Consulting thông báo về việc hệ thống của họ bị tấn công và trang cổng thông tin của họ hiện không thể cung cấp để người dùng truy cập được. Ngoài ra, họ có gửi file log của ứng dụng web, trong đó có chứa các request của những người dùng trong hệ thống

Application logs (Nhật ký của ứng dụng) là các tệp có chứa thông tin về các sự kiện đã xảy ra trong một ứng dụng phần mềm. Những sự kiện này được đăng nhập bởi ứng dụng và được ghi vào tệp. Chúng có thể bao gồm các lỗi và cảnh báo cũng như các sự kiện thông tin.

[Các câu hỏi phase 2]

Các câu hỏi được đưa ra ở phase 2 này là :

• Có một HTTP Status code lạ mà Webserver đã trả về, vui lòng cho biết địa chỉ IP của Người gửi Request này!
• Vui lòng trả lời câu lệnh mà kẻ tấn công đã thực hiện để làm gián đoạn hệ thống.
• Loại mã hóa (encrypt) mà webserver sử dụng là gì?

[Các bước xử lý của Đội ƯCSC BHXH Việt Nam]

Trong file log, phát hiện nhiều request từ địa chỉ 41.73.98.168 mà webserver trả về với Http status 418, đây là 1 mã lạ trả về lỗi cho người dùng mà không thường một server trả về vì đây là mã được tạo ra từ một trò đùa Cá tháng 4.

Ngoài ra, sau khi tìm các dấu hiệu bất thường trong file log trên, Đội đã tìm ra dòng log có nội dung lạ được mã hóa như sau:

Sau khi giải mã thông điệp được mã hóa base64 thu được: “catch me if you can”.

Ngoài ra, địa chỉ 212.162.48.47 của tài khoản elusive938 cũng có thêm 1 request nữa mà khi giải mã ra thông điệp sẽ là “Fernet is good”, từ đây ta có thể đoán được loại mã hóa webserver sử dụng là fernet với key là fxrL4M30gxE_hadUE6tJT7kM1SZTIH0izX8I0JhDWxk=

Sử dụng loại mã hóa Fernet với key có được, Đội đã tiến hành mã hóa một số lệnh mà kẻ tấn công sử dụng:

Trong đó lệnh mà kẻ tấn công đã dùng để làm hệ thống của đơn vị không thể hoạt động được đó là DROP DATABASE root@localhost;

Câu lệnh này được sử dụng với mục đích xóa database của hệ thống.

Dựa vào những phân tích trên chúng tôi nghi ngờ hệ thống của đơn vị đã bị xâm nhập và chiếm đoạt thông tin. Đề nghị cung cấp thêm các thông tin trên các máy chủ của hệ thống cổng thông tin của đơn vị để có thể đưa ra những hành động cụ thể hơn. Đồng thời Đội đề nghị Hersey Consulting triệu tập đội ứng cứu, sự trợ giúp từ những đội ứng cứu các nước để thực hiện rà soát hệ thống, thu hồi tài khoản đã bị chiếm đoạt đồng thời hardening (tăng cường tính chặt chẽ) các chính sách truy cập đến các hệ thống từ người quản trị để tránh kẻ tấn công leo thang đặc quyền sang các hệ thống khác.

3. Phase 3

[Tóm tắt nội dung]

Sau khi thu thập được các thông tin qua nhật ký ứng dụng về cuộc tấn công vào cơ sở dữ liệu của Hersey Consulting, đơn vị đã gửi thêm nhật ký của tường lửa để có thể tìm ra được kẻ tấn công.

[Các câu hỏi phase 3]

• Địa chỉ Webserver là gì?
• Địa chỉ IP và port của kẻ tấn công đã lấy dữ liệu là gì?

[Các bước xử lý của Đội ƯCSC BHXH Việt Nam]

Sau khi xem xét file log trên thiết bị tường lửa nhận được từ Hersey Consulting, Đội tiến hành lọc các traffic với application là “ftp” để tìm ra địa chỉ đã thực hiện đẩy dữ liệu từ máy chủ nạn nhân ra bên ngoài.

Sau khi lọc các traffic, nhận thấy rằng địa chỉ thực hiện gửi dữ liệu ra ngoài là 159.63.53.251 (web server) và địa chỉ nhận là 91.209.238.58 (kẻ tấn công).

4. Phase 4

[Tóm tắt nội dung]

Sau khi xác định được rằng dữ liệu của đơn vị đã bị gửi ra bên ngoài đồng thời bị xóa trên hệ thống cổng thông tin, những kẻ tấn công đã gửi thư tống tiền đến nạn nhân đồng thời thay đổi giao diện của trang cổng thông tin.

Đính kèm với thư điện tử là hình ảnh mà nhóm tấn công đăng tải lên trang cổng thông tin của đơn vị:

 [Các câu hỏi phase 4]

• Nhóm tin tặc nào đã thực hiện cuộc tấn công này?

[Các bước xử lý của Đội ƯCSC BHXH Việt Nam]

Dựa vào thông tin của ví điện tử để lại trên hình ảnh mà nhóm tấn công đã để lại trên cổng thông tin của đơn vị, Đội đã tìm ra được tổ chức nắm giữ tài khoản ví này là của nhóm hacker STARDUST CHOLLIMA.

Đồng thời, Đội cũng khuyến nghị Hersey Consulting thực hiện các hành động sau để giảm thiểu thiệt hại từ cuộc tấn công cũng như nhanh chóng xử lý sự cố:

1. Kiểm tra lại các bản backup dữ liệu, source code hệ thống, máy chủ...
2. Xác định sự cố:

• Xác định phạm vi, danh sách các máy chủ có liên quan sự cố mã độc. Danh sách tổng hợp từ quá trình phân tích các logs trên hệ thống SIEM, phân tích trực tiếp trên thiết bị, phân tích memory, phân tích network traffic (nếu có thể),...
• Xác định Tài khoản người dùng/Tài khoản ứng dụng có liên quan tới sự cố mã độc này (bao gồm toàn bộ tài khoản liên quan tới luồng Lateral Movement)
• Xác định khả năng lộ lọt các dữ liệu nhạy cảm, bí mật của tổ chức, cá nhân.
• Xác định các lỗ hổng bảo mật hay điểm yếu nào đã bị lợi dụng.
• Thu thập danh sách các công cụ tấn công, mã độc được sử dụng (các mã hash tương ứng).
• Kiểm tra khả năng phát hiện và ngăn chặn (cách ly, làm sạch) của giải pháp AV hiện tại của đơn vị với các mẫu mã độc.
• Xác định các hành vi, chức năng, địa chỉ C&C kết nối của các mẫu mã độc nếu tìm được thông qua phân tích mã độc chuyên sâu (kết hợp phân tích động và phân tích tĩnh). Tổng hợp danh sách các IoC liên quan tới các mã độc. Sử dụng các IoC này để kiểm tra (thủ công hoặc viết công cụ/script tự động quét) nhằm phát hiện thêm các thiết bị đã bị nhiễm.
• Xác định timestamp của các sự kiện liên quan tới sự cố

3. Xử lý ban đầu:

• Cô lập, Cách ly tạm thời các thiết bị có ảnh hưởng tới sự cố (PC/Laptop/Server,...)
• Tạm thời disable các tài khoản bị ảnh hưởng bao gồm tài khoản OS, tài khoản ứng dụng, các thông tin xác thực (credentials, authentication key) liên quan đến sự cố. Trường hợp không thể disable tạm thời, thực hiện đổi mật khẩu (đổi authentication key - nếu có)
• Cấu hình chặn các IP, địa chỉ C&C trên các giải pháp phòng thủ.
• Bổ sung các  IoC vào giải pháp AV/Endpoint
• Khắc phục tạm thời việc khai thác các lỗ hổng bảo mật/điểm yếu liên quan (nếu có thể - Ex: Thêm rule các giải pháp phòng thủ như waf, firewall, IDPS, DLP, ...)

5. Phase 5+6

[Tóm tắt nội dung]

Sau khi không nhận được tiền chuộc từ nạn nhân, có khả năng kẻ tấn công đã lợi dụng lỗ hổng trong hệ thống thông tin để thực hiện tấn công DDoS để làm tê liệt khả năng đáp ứng của máy chủ. Hersey Consulting gửi kèm file pcap (file nhật ký lưu lượng mạng) để giúp tìm ra cách tấn công, các địa chỉ thực hiện tấn công.

[Các câu hỏi phase 5+6]

• Kẻ tấn công đã dùng kỹ thuật DDoS gì để tấn công?
• Có bao nhiêu IP tham gia tấn công?
• Tại sao request lại bị timeout, kẻ tấn công đã gửi thiếu ký tự gì?
• Mục đích của kẻ tấn công khi gửi request tới URI /?[các con số khác nhau] để làm gì?
• Lỗ hổng mà kẻ tấn công khai thác là gì?
• Câu lệnh mà kẻ tấn công thực hiện để tấn công DDoS máy chủ mục tiêu là?
• Theo mã khai thác được viết bằng ngôn ngữ