Aviation Runway Cyber Range Security Case Study

[ MITM Attack on PLC–HMI IEC 60870-5-104 OT Control Channel ]

สนามบินสมัยใหม่พึ่งพาระบบ OT, IT และ IoT ที่บูรณาการอย่างมากเพื่อให้มั่นใจถึงการปฏิบัติงานของรันเวย์ที่ปลอดภัยและมีประสิทธิภาพของการควบคุมการจราจรทางอากาศ (ATC) ระบบเหล่านี้ยังกลายเป็นเป้าหมายที่เป็นไปได้สำหรับการโจมตีทางไซเบอร์ ในกรณีศึกษาครั้งนี้ ฉันจะใช้Mini OT Aviation CAT-II Airport Runway Lights Management Simulation System (v_0.2.1) เพื่อแสดงให้เห็นว่าผู้กระทำที่เป็นอันตรายในทีมสีแดงสามารถใช้ประโยชน์จากการกำหนดค่าที่ไม่ถูกต้องและจุดอ่อนในช่องทางการควบคุม PLC-HMI IEC 60870-5-104 ของช่วงไซเบอร์ผ่านการโจมตีทางไซเบอร์แบบ Man-in-the-Middle (MITM) ได้อย่างไร

กรณีศึกษาถูกออกแบบมาให้เป็นส่วนหนึ่งของการประชุมเชิงปฏิบัติการด้านความปลอดภัยทางไซเบอร์ IT/OT/IoT ของเรา เพื่อแสดงให้เห็นถึงเวกเตอร์การโจมตีที่แตกต่างกันหกแบบที่อาจเกิดขึ้นในระบบโลกแห่งความเป็นจริง สถานการณ์สมมติว่าผู้โจมตีบุกรุกกล้องวงจรปิด IoT ของบุคคลที่สามที่ไม่ได้รับอนุญาตภายในห้องควบคุม Tower ATC และจากนั้นสกัดกั้นและจัดการการรับส่งข้อมูล OT ระหว่าง Human Machine Interface (HMI) และ Programmable Logic Controller (PLC) ผลลัพธ์ของการโจมตีจำลองส่งผลให้เกิดการปฏิเสธการควบคุมไฟรันเวย์ชั่วคราว ซึ่งลุกลามไปสู่การหยุดชะงักของบริการควบคุมการจราจรทางอากาศ และท้ายที่สุดก็สร้างสถานการณ์เตือนภัยเชื้อเพลิงเครื่องบินเหลือน้อย

เนื้อหาของกรณีศึกษาประกอบด้วย 5 ส่วนต่อไปนี้:

• ความเป็นมาของสถานการณ์การโจมตีและสมมติฐานด้านความปลอดภัยทางไซเบอร์ที่ใช้ในกรณีศึกษา

• ระบบเตือนภัย การแจ้งเตือน และการป้องกันความปลอดภัยของ Runway Lights Management Simulation System

• การกำหนดค่าที่ไม่ถูกต้องในเครือข่ายหอควบคุมไฟรันเวย์สร้างจุดอ่อนที่สามารถใช้ประโยชน์ได้อย่างไร

• เส้นทางการโจมตีทีละขั้นตอนพร้อมรายละเอียดทางเทคนิคของการจัดการช่องทางการควบคุม MITM

• การสาธิตผลกระทบของการโจมตีและการใช้งานในการฝึกอบรมทีมตอบสนองต่อเหตุการณ์

หมายเหตุสำคัญ: กรณีศึกษาเกิดขึ้นในสภาพแวดล้อมช่วงไซเบอร์ที่มีการควบคุม ซึ่งมีการแทรกช่องโหว่และการกำหนดค่าที่ไม่ถูกต้องโดยเจตนาเพื่อวัตถุประสงค์ในการฝึกอบรม ในระบบการบินในโลกแห่งความเป็นจริง การป้องกันความปลอดภัยมีความแข็งแกร่งกว่า และจุดอ่อนส่วนใหญ่ที่อธิบายไว้ในที่นี้จะได้รับการแก้ไข การโจมตีที่แสดงให้เห็นไม่สามารถทำซ้ำได้โดยตรงบนระบบสนามบินที่ใช้งานอยู่

คำขอบคุณพิเศษ: ฉันขอแสดงความขอบคุณอย่างยิ่งต่อผู้เชี่ยวชาญด้านความปลอดภัยการบินมืออาชีพ Olivier Roubault  สำหรับคำแนะนำ ความคิดเห็น และคำแนะนำที่เป็นประโยชน์ ซึ่งช่วยเราปรับปรุงการออกแบบและความสมจริงของช่วงไซเบอร์และกรณีศึกษาของระบบการจัดการไฟรันเวย์ของเราได้อย่างมาก

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

บทนำ

กรณีศึกษาการโจมตีทางไซเบอร์นี้แสดงให้เห็นว่าเทคนิคการโจมตีหลายอย่างสามารถรวมกันเพื่อจัดการช่องทางการไหลของข้อมูลควบคุมระหว่าง Runway Light และ Indicator Control HMI ในหอควบคุมสนามบินและ PLC ที่รับผิดชอบในการควบคุมไฟสัญญาณรอการขึ้นบินได้อย่างไร การใช้ประโยชน์จากจุดอ่อนเหล่านี้ ผู้โจมตีสามารถทำให้เกิด การปฏิเสธหรือความล่าช้าในการปฏิบัติการลงจอดของเครื่องบิน ซึ่งส่งผลกระทบโดยตรงต่อบริการควบคุมการจราจรทางอากาศ กรณีศึกษาจะครอบคลุมเวกเตอร์การโจมตีทางไซเบอร์หกประเภท ได้แก่:

• การประนีประนอมห่วงโซ่อุปทานสำหรับอุปกรณ์ IOT

• การอัปเดตเฟิร์มแวร์ที่เป็นอันตรายและการกำหนดค่าที่ไม่ถูกต้อง

• ข้อบกพร่องของโปรโตคอล IEC61850-5-104

• การดักฟังและการดัดแปลงแพ็กเก็ต

• การจี้ควบคุม Man-in-the-Middle

• การปฏิเสธการให้บริการระดับส่วนประกอบ

กรณีศึกษาและการสาธิตทั้งหมดดำเนินการบน Mini OT Aviation CAT-II Airport Runway Lights Management Simulation System เวอร์ชันล่าสุด ซึ่งออกแบบมาโดยเฉพาะสำหรับการวิจัย การฝึกอบรม และการฝึกปฏิบัติในช่วงไซเบอร์ สถานการณ์การโจมตีและเทคนิคทั้งหมดที่นำเสนอในที่นี้มีวัตถุประสงค์เพื่อการศึกษาเท่านั้น สนับสนุนการฝึกอบรมด้านความปลอดภัยทางไซเบอร์ IT/OT/IoT และหลักสูตรที่เน้น ICS ในระดับต่างๆ

บทนำเกี่ยวกับ Aviation Cyber Range

Mini OT Aviation CAT-II Airport Runway Lights Management Simulation System เป็นแพลตฟอร์มช่วงไซเบอร์ขนาดกะทัดรัดที่พัฒนาขึ้นเพื่อจำลองสภาพแวดล้อม OT สี่ระดับที่แตกต่างกันของระบบควบคุมไฟรันเวย์เครื่องมือที่มีความแม่นยำของสนามบินประเภท II ดังแสดงในแผนภาพโครงสร้างระบบด้านล่าง:

Figure-01: Aviation Cyber Range Architecture Diagram version v0.2.1 (2025)

มีโมดูลการจำลองตั้งแต่กระบวนการทางกายภาพ OT-Level 0 (อุปกรณ์รันเวย์บริสุทธิ์) เช่น ไฟ ALS และ ILS, ระบบ Airport Surveillance Radar (ASR), VHF Comm และกล้อง ไปจนถึง OT-Level 3 Operations Management Zone เช่น ระบบ HMI ควบคุมและตรวจสอบหอควบคุม การออกแบบระบบทั้งหมดเป็นไปตาม Federal Aviation Administration (FAA) ATC "General Standard" แพลตฟอร์มจำลองระบบ Four SCADA ที่ใช้สำหรับ ATC ของสนามบิน:

• CAT-II Runway Light System: ระบบหลักจำลองไฟรันเวย์และตัวบ่งชี้ภาพ 11 ประเภท

• Airport Surveillance Radar System: ระบบผู้ช่วยรองจำลองเรดาร์ 3 ประเภท

• Radio Communication System: ระบบผู้ช่วยรองจำลองการสื่อสาร VHF/UHF ระหว่างนักบิน-หอควบคุม และโทรศัพท์หอควบคุม-ภาคพื้นดิน

• Surveillance Camera System: ระบบกล้อง IP ตรวจสอบเครื่องบินขึ้นลงรันเวย์

ปัจจุบันช่วงไซเบอร์ได้รับการอัปเดตเป็นเวอร์ชัน v_0.2.1 สำหรับข้อมูลเบื้องต้นเพิ่มเติม โปรดดูเอกสารแนะนำ v_0.0.1: https://www.linkedin.com/pulse/aviation-runway-lights-management-simulation-system-yuancheng-liu-5rzhc

การกำหนดค่าสภาพแวดล้อมระบบสาธิต

ในโลกแห่งความเป็นจริงของสนามบิน โครงสร้างพื้นฐาน IT และ OT มีความแข็งแกร่ง แยกจากกัน และออกแบบมาเพื่อต้านทานการโจมตีทางไซเบอร์ที่รู้จักกันในปัจจุบันส่วนใหญ่ เพื่อสร้างสภาพแวดล้อมการฝึกอบรมที่ใช้งานได้จริงสำหรับกรณีศึกษา เราได้จงใจแนะนำจุดอ่อนและข้อผิดพลาดในการกำหนดค่าที่เป็นสมมติฐานลงในแพลตฟอร์มช่วงไซเบอร์ของเรา ข้อสันนิษฐานเหล่านี้ช่วยให้เราสำรวจว่าผู้โจมตีอาจใช้ประโยชน์จากช่องโหว่ในระบบที่ได้รับการป้องกันน้อยกว่าได้อย่างไร โดยไม่ได้บอกเป็นนัยว่าข้อบกพร่องดังกล่าวมีอยู่ในเครือข่ายสนามบินที่ใช้งานอยู่

การกำหนดค่าเครือข่ายสาธิต (ดูรูปด้านบน) ประกอบด้วยเครือข่ายย่อยที่แตกต่างกันสี่เครือข่ายและเครื่องเสมือน (VM) ทั้งหมด 17 เครื่องดังแสดงด้านล่าง:

Figure-02: Case Study OT network topology diagram, version v0.2.1 (2025)

• Green Team Subnet – แสดงถึงการเชื่อมต่อทางกายภาพระหว่างอุปกรณ์และ PLC เครือข่ายย่อยนี้ ไม่สามารถเข้าถึงได้โดยตรง สำหรับผู้โจมตีทีมสีแดง

• Blue Team Subnet 1 – จำลองเครือข่ายการสื่อสารระหว่างห้องควบคุมหอควบคุมรันเวย์และ PLC ได้รับการป้องกันโดยการควบคุมการกำหนดเส้นทาง IP และ ไม่สามารถเข้าถึงได้โดยตรง สำหรับผู้โจมตีเช่นกัน

• Blue Team Subnet 2 – แสดงถึง เครือข่ายที่แยกจากกันของหอควบคุมรันเวย์ รวมถึง SCADA HMI และระบบตรวจสอบ แม้ว่าผู้โจมตีจะไม่สามารถเชื่อมต่อได้โดยตรง แต่เครือข่ายย่อยนี้อาจ ถูกเปิดเผยโดยอ้อม ผ่านกิจกรรมการบำรุงรักษาหรืออุปกรณ์ที่กำหนดค่าไม่ถูกต้อง

• Red Team Subnet/Internet – จำลองสภาพแวดล้อมของผู้โจมตี รวมถึงโครงสร้างพื้นฐาน C2 และอุปกรณ์ IoT ของบุคคลที่สามที่ถูกบุกรุก ผู้โจมตีไม่สามารถเชื่อมต่อโดยตรงกับ Blue Team Subnet2 ได้หากไม่มีเส้นทางตัวกลาง

กฎการออกแบบการเข้าถึงเครือข่ายที่สำคัญในการจำลองนี้คือ ไม่มีบุคคลใดสามารถเข้าถึงสภาพแวดล้อมของผู้โจมตีและเครือข่าย OT ที่แยกจากกันได้พร้อมกัน

สมมติฐานการกำหนดค่าที่ไม่ถูกต้องของสถานการณ์กรณีศึกษา

จากบทนำสภาพแวดล้อมก่อนหน้านี้ เราเข้าใจดีว่าไม่มีทางที่ผู้โจมตีทีมสีแดงจะสามารถเข้าถึงส่วนใดส่วนหนึ่งของเครือข่าย OT ได้แบบเรียลไทม์ แต่ผู้โจมตีต้องพึ่งพา วิศวกรบำรุงรักษาที่ประมาท และแล็ปท็อปที่ถูกบุกรุกของเขาเพื่อเชื่อมช่องว่าง สิ่งนี้สร้างเวกเตอร์ภัยคุกคามจากภายในที่สมจริง ซึ่งเน้นถึงความเสี่ยงของสุขอนามัยปลายทางที่ไม่ดี

เรากำหนด สมมติฐานหลักห้าประการ เกี่ยวกับจุดอ่อนและการกำหนดค่าที่ไม่ถูกต้องในระบบช่วงไซเบอร์นี้:

• สมมติฐานที่ 1: วิศวกรบำรุงรักษาที่ประมาทเชื่อมต่อแล็ปท็อปของเขากับอินเทอร์เน็ต ทำให้ผู้โจมตีมีโอกาสติดตั้งโทรจันสอดแนมและรับข้อมูลสำคัญเกี่ยวกับสนามบิน

• สมมติฐานที่ 2: แล็ปท็อปเครื่องเดียวกันนี้จะเชื่อมต่อทางกายภาพกับเครือข่าย OT รันเวย์ Level-3 ที่แยกจากกันในภายหลังเพื่อทำการทดสอบ ทำให้โทรจันที่ติดตั้งไว้ล่วงหน้าสามารถทำงานภายในสภาพแวดล้อมการควบคุมได้

• สมมติฐานที่ 3: หลังจากออกจากหอควบคุม วิศวกรบำรุงรักษาจะเชื่อมต่อแล็ปท็อปของเขากับอินเทอร์เน็ตอีกครั้ง ทำให้ผู้โจมตีสามารถดึงข้อมูลเครือข่ายที่ละเอียดอ่อนและตัวอย่างการสื่อสารที่โทรจันรวบรวมได้

• สมมติฐานที่ 4: ผู้โจมตีดำเนินการประนีประนอมห่วงโซ่อุปทาน โดยฝังโค้ดที่เป็นอันตรายลงในเฟิร์มแวร์ของกล้อง IoT ซึ่งจากนั้นทำหน้าที่เป็นจุดเข้าใช้งานแบบซ่อนตัวภายในสภาพแวดล้อม OT

• สมมติฐานที่ 5: การกำหนดค่าที่ไม่ถูกต้องทำให้กล้องวงจรปิด IoT ของบุคคลที่สามอยู่ในเครือข่ายย่อยเดียวกับ HMI ควบคุมไฟรันเวย์ วิศวกรบำรุงรักษาอัปเดตกล้องด้วยเฟิร์มแวร์ที่เป็นอันตราย สร้างจุดเปิดรับที่ไม่คาดคิด

สมมติฐานเหล่านี้ แม้ว่าจะไม่สมจริงสำหรับระบบการบินในโลกแห่งความเป็นจริง แต่ก็เป็น พื้นที่ฝึกอบรมที่ควบคุมได้และยืดหยุ่น ซึ่งเราสามารถจำลองการประนีประนอมห่วงโซ่อุปทาน การละเมิดการกำหนดค่าที่ไม่ถูกต้อง ความเสี่ยงจากภายใน และเส้นทางการโจมตีเฉพาะ OT เช่น การจัดการ MITM ของช่องทางการควบคุม IEC104

สถานการณ์และเส้นทางการโจมตีของกรณีศึกษา

แผนภาพด้านล่างแสดงเส้นทางการโจมตีจำลองที่ใช้ในกรณีศึกษา แสดงให้เห็นว่าผู้โจมตี — เริ่มต้นจากแล็ปท็อปบำรุงรักษาที่ถูกบุกรุกและกล้อง IoT ที่ถูกดัดแปลง — สร้าง Man-in-the-Middle (MITM) บน ช่องทางการควบคุม PLC ↔ HMI IEC-104 เพื่อแก้ไขส่วน ASDU ข้อมูลคำสั่งไฟสัญญาณรอการขึ้นบิน ทำให้เกิดความล่าช้าในการขึ้นบินและบังคับให้เครื่องบินขาเข้าอีกลำต้องบินวนในรูปแบบการรอจนกว่าจะมีการแจ้งเตือนเชื้อเพลิงเหลือน้อย

Figure-03: Case Study Attack Scenario and Path diagram, version v0.2.1 (2025)

การโจมตีแบบ end-to-end คลี่คลายไปตามไทม์ไลน์แบบแบ่งระยะต่อไปนี้ (T1 → T13) ตามที่ระบุไว้ในแผนภาพ แต่ละขั้นตอนอธิบายการกระทำของผู้โจมตี บทบาทของวิศวกรบำรุงรักษาที่ถูกบุกรุกในฐานะคนวงในที่ไม่รู้เรื่อง และวิธีการทางเทคนิคที่ใช้ในการสกัดกั้นการรับส่งข้อมูล OT

• ขั้นตอนที่ T1 — การประนีประนอมเริ่มต้นและการส่งสัญญาณ: ผู้โจมตีติดไวรัสโทรจันสอดแนมในแล็ปท็อปของวิศวกรบำรุงรักษา (ผ่านการฟิชชิ่ง การโฆษณาที่เป็นอันตราย หรือการประนีประนอมล่วงหน้า) โทรจันติดตั้งการสแกนเครือข่าย เพย์โหลดการจับแพ็กเก็ต และรอคำสั่งจากโครงสร้างพื้นฐาน C2 ของผู้โจมตี เมื่อแล็ปท็อปออนไลน์ ข้อมูล telemetry และแพ็กเก็ตที่จับได้จะถูกส่งไปยัง C2

• ขั้นตอนที่ T2 — การเข้าถึงทางกายภาพไปยัง OT: วิศวกรบำรุงรักษาที่ไม่ทราบถึงการติดไวรัส จะตัดการเชื่อมต่อจากอินเทอร์เน็ตและนำแล็ปท็อปเข้าไปในห้องหอควบคุมรันเวย์เพื่อทำงานบำรุงรักษา เขาเสียบแล็ปท็อปเข้ากับพอร์ตทดสอบ RJ45 ของหอควบคุมที่เชื่อมต่อกับสภาพแวดล้อม OT ที่แยกจากกัน

• ขั้นตอนที่ T3 — การลาดตระเวนในพื้นที่ภายใน OT: ในขณะที่เชื่อมต่อ โทรจันจะบันทึกการรับส่งข้อมูลเครือข่ายระหว่างแล็ปท็อปของเหยื่อและ PLC รันเวย์ Level-1 (PLC01) อย่างเงียบๆ โดยจับแพ็กเก็ต IEC-104 การระบุที่อยู่ และรูปแบบลำดับที่ใช้สำหรับการควบคุมไฟสัญญาณรอ

• ขั้นตอนที่ T4 — การส่งคืนและการวิเคราะห์ข้อมูล: หลังจากออกจากหอควบคุมและเชื่อมต่อกับอินเทอร์เน็ตอีกครั้ง แล็ปท็อปจะอัปโหลดการจับแพ็กเก็ตที่รวบรวมไว้ไปยัง C2 ของผู้โจมตี ผู้โจมตีดาวน์โหลดการจับเหล่านี้เพื่อทำการวิเคราะห์แบบออฟไลน์

• ขั้นตอนที่ T5 — การพัฒนาการโจมตี: การใช้การรับส่งข้อมูลที่จับได้และเอกสารที่รั่วไหล ผู้โจมตีจะวิศวกรรมย้อนกลับการส่งข้อความ IEC-104, IP HMI/PLC และบิตควบคุม พวกเขาพัฒนากิจวัตร MITM ที่สามารถแยกวิเคราะห์และแก้ไขคำสั่งและการตอบสนอง IEC-104 เฉพาะได้ ผู้โจมตีฝังเพย์โหลด MITM นี้ลงในอิมเมจเฟิร์มแวร์ "ที่กำหนดเอง" สำหรับกล้องวงจรปิด IoT ของบุคคลที่สาม

• ขั้นตอนที่ T6 — การส่งมอบห่วงโซ่อุปทาน: ผู้โจมตีดำเนินการหลอกลวงห่วงโซ่อุปทานหรือโลจิสติกส์เพื่อให้กล้องตัวหนึ่งถูกแฟลชด้วยเฟิร์มแวร์ที่เป็นอันตรายและส่งมอบให้กับการไหลของการบำรุงรักษา

• ขั้นตอนที่ T7 — การเปลี่ยนอุปกรณ์: วิศวกรบำรุงรักษา (หรือผู้รับเหมาในสถานที่) เปลี่ยนกล้องที่เสียในหอควบคุมด้วยยูนิตที่ถูกดัดแปลงโดยไม่ได้ตรวจสอบเฟิร์มแวร์หรือตำแหน่งเครือข่าย

• ขั้นตอนที่ T8 — การปลอมแปลง ARP และการเปลี่ยนเส้นทางการรับส่งข้อมูล: เมื่อใช้งานแล้ว กล้องที่เป็นอันตรายจะเปิดใช้งานและดำเนินการปลอมแปลง ARP / การจัดการการกำหนดเส้นทางในพื้นที่เพื่อวางตำแหน่งตัวเองเป็น MITM ที่โปร่งใสระหว่าง PLC01 และ HMI ทำให้การรับส่งข้อมูลไหล PLC01 → กล้อง → HMI

• ขั้นตอนที่ T9 — การแยกวิเคราะห์แพ็กเก็ตและตรรกะทริกเกอร์: กิจวัตร MITM ของกล้องจะแยกวิเคราะห์เฟรม IEC-104 สดและรอคำสั่ง/ลำดับเฉพาะ (the “trigger”) ที่บ่งชี้ว่าผู้ปฏิบัติงานกำลังออกการเปลี่ยนแปลงไฟสัญญาณรอการขึ้นบิน

• ขั้นตอนที่ T10 — การดัดแปลงคำสั่ง (การขึ้นบินถูกบล็อก): เมื่อผู้ปฏิบัติงานหอควบคุมกดปุ่ม HMI เพื่อปิดไฟสัญญาณรอการขึ้นบิน OFF (อนุญาตให้เครื่องบินเริ่มขึ้นบิน) MITM จะสกัดกั้นและพลิกบิตควบคุมที่เกี่ยวข้องเพื่อให้คำสั่งที่ส่งไปยัง PLC01 ระบุ ON (รอ) นักบินเห็นไฟจริง ทำให้เครื่องบินอยู่ในพื้นที่รอการขึ้นบิน

• ขั้นตอนที่ T11 — การระงับการตอบสนองสถานะ: พร้อมกัน MITM จะแก้ไขรายงานสถานะ PLC → HMI เพื่อให้ HMI แสดงสถานะ PLC ปกติ/ที่คาดไว้ สิ่งนี้ปกปิดการจัดการจากผู้ปฏิบัติงานหอควบคุมและป้องกันการดำเนินการแก้ไขของผู้ปฏิบัติงาน

• ขั้นตอนที่ T12 — ผลกระทบต่อการดำเนินงานแบบเรียงซ้อน: เครื่องบินขาเข้า (Plane-2) ในขั้นตอนสุดท้ายของการเข้าใกล้สังเกตรันเวย์ว่าถูกใช้งาน (หรือได้รับการสั่งการ ATC ที่สอดคล้องกับรันเวย์ที่ถูกใช้งาน) และต้องยกเลิก/ดำเนินการเข้าใกล้ที่พลาดไป โดยปีนกลับเข้าไปในรูปแบบการรอ

• ขั้นตอนที่ T13 — การยกระดับความปลอดภัย: หลังจากบินวนในรูปแบบการรอนาน นักบินขาเข้าประกาศสถานะ เชื้อเพลิงเหลือน้อย ต่อ ATC ซึ่งกระตุ้นให้มีการจัดการตามลำดับความสำคัญและเหตุการณ์ด้านความปลอดภัย

เส้นทางการโจมตีแสดงให้เห็นว่าการโจมตีแบบผสมผสาน — การรวมการประนีประนอมปลายทาง การดัดแปลงห่วงโซ่อุปทาน และ MITM ที่ตระหนักถึง OT — สามารถสร้างผลลัพธ์การดำเนินงานที่เป็นอันตรายได้ แม้ว่าเครือข่าย OT หลักจะได้รับการออกแบบมาให้แยกจากกันก็ตาม ขั้นตอนทั้งหมดข้างต้นดำเนินการในขอบเขตไซเบอร์ของเราภายใต้สภาวะที่ควบคุมได้ มีวัตถุประสงค์เพียงเพื่อเน้นกลไกการโจมตี โอกาสในการตรวจจับ และกลยุทธ์การลดความเสี่ยงสำหรับการฝึกอบรมและการวิจัย

ระบบเตือนภัยและการแจ้งเตือน Cyber Range

ก่อนที่ฉันจะเดินผ่านการสาธิตการโจมตี สิ่งสำคัญคือต้องเข้าใจ กลไกการป้องกันความปลอดภัย ที่สร้างขึ้นในขอบเขตไซเบอร์ กลไกเหล่านี้จำลองการป้องกัน ATC ของหอควบคุมในโลกแห่งความเป็นจริง เพื่อให้คุณเห็นว่าทำไมผู้โจมตีต้องทำการลาดตระเวนเฉพาะและการดำเนินการบายพาสเพื่อให้ยังคงแอบแฝงอยู่

วัตถุประสงค์และพฤติกรรมระดับสูง: PLC และ HMI ในเครื่องจำลองของเราใช้ การตรวจสอบสถานะอัตโนมัติ และระบบ การสร้างคำเตือน/การแจ้งเตือน แบบแบ่งชั้น เมื่อใดก็ตามที่ผู้ปฏิบัติงานออกการดำเนินการควบคุม (เช่น การเปิดไฟรันเวย์หรือไฟแท่งเข้าใกล้เพื่อปล่อยสถานะ) PLC จะเปรียบเทียบสถานะที่สั่งการกับการตอบสนองของเซ็นเซอร์สถานะไฟ ความไม่ตรงกันหรือสภาวะที่ผิดปกติใดๆ จะถูกตั้งค่าสถานะและส่งไปยัง HMI ของหอควบคุมและไปยังจอแสดงผลเครื่องจำลองโลกทางกายภาพ เพื่อให้ผู้ปฏิบัติงานสามารถตรวจจับและตอบสนองต่อข้อผิดพลาดได้อย่างรวดเร็ว เซ็นเซอร์ไฟ PLC และตรรกะการควบคุมเป็นไปตามตรรกะเดียวกันในบทความควบคุม PLC นี้: https://www.linkedin.com/pulse/use-plc-remote-control-circuit-breaker-power-system-yuancheng-liu-7ljxc เวอร์ชันปัจจุบันมีคำเตือนรันเวย์ 11 ประเภท การแจ้งเตือนรันเวย์ 18 ประเภท และการแจ้งเตือนเครื่องบิน 4 ประเภท

วิธีการแสดงภาพคำเตือนและการแจ้งเตือน

• Physical World Simulator จะซ้อนทับไอคอนคำเตือน/การแจ้งเตือนที่กะพริบบนอุปกรณ์จำลองโดยตรง (เช่น ไฟรันเวย์หรือสัญญาณไฟ) เพื่อให้ผู้ใช้ขอบเขตไซเบอร์เห็นส่วนประกอบที่ได้รับผลกระทบได้ทันที

• HMI จะสะท้อนการแจ้งเตือนเหล่านั้นใน แผงตัวบ่งชี้คำเตือนและการแจ้งเตือน โดยเฉพาะ โดยที่สัญญาณเตือนจะกะพริบและให้ข้อมูลตามบริบท (ประเภท อุปกรณ์ที่ได้รับผลกระทบ การประทับเวลา)

แผนผังจาก Physical World Simulator (คำเตือนและแจ้งเตือนจริง) ไปยัง HMI (คำเตือนและแจ้งเตือนที่ตรวจพบ) แสดงอยู่ด้านล่าง:

Figure-04: Cyber Range Warning & Alert System diagram, version v0.2.1 (2025)

ตัวอย่างตรรกะการตรวจจับ:

• ผู้ปฏิบัติงานกดปุ่มควบคุม → HMI ส่งคำสั่งควบคุม IEC-104 → PLC สั่งงานอุปกรณ์และอ่านเซ็นเซอร์ในพื้นที่ → PLC รายงานสถานะจริงกลับไปยัง HMI

• หากสถานะเซ็นเซอร์ PLC ≠ สถานะที่สั่งการภายในระยะหมดเวลาหรือค่าความคลาดเคลื่อนที่กำหนดค่าไว้ PLC จะส่ง การแจ้งเตือน หากการกระทำของผู้ปฏิบัติงานต้องการความสนใจแต่ไม่สำคัญ คำเตือน อาจแสดงแทน PLC/HMI ทำตามตรรกะเซ็นเซอร์/การควบคุมเดียวกันกับที่ใช้ในตัวอย่างการควบคุมระยะไกล PLC ของเรา

แค็ตตาล็อกการแจ้งเตือนและคำเตือน

• คำเตือนรันเวย์ (11) — เช่น เปิดใช้งานไฟพักเครื่องขึ้น; คำเตือนเกี่ยวกับพลังงานของ Beacon Tower; ไฟขอบรันเวย์ดับ; เปิดใช้งานไฟอำพันในเขตเตือน ...

• การแจ้งเตือนรันเวย์ (18) — การแจ้งเตือนโดยละเอียดเกี่ยวกับความไม่ตรงกันของพลังงาน/สถานะและความล้มเหลวของเซ็นเซอร์ทั่วทั้งแถบแนวทาง แถบขีดเริ่ม PAPI ตัวบ่งชี้ทางขับเคลื่อน เสาอากาศเรดาร์ และเสาอากาศ VHF ...

• การแจ้งเตือนเครื่องบิน (4) — เช่น เชื้อเพลิงเครื่องบินเหลือน้อย การไต่ระดับฉุกเฉินของเครื่องบิน ความใกล้เคียงของเรดาร์ ความขัดแย้งของไฟรันเวย์ ...

หมวดหมู่เหล่านี้ให้การรับรู้สถานการณ์หลายระดับ: คำเตือนสำหรับความสนใจของผู้ปฏิบัติงาน การแจ้งเตือนที่โดยทั่วไปต้องมีขั้นตอนการตอบสนองต่อเหตุการณ์ทันที

การตอบสนองในการปฏิบัติงาน

เมื่อ คำเตือน ปรากฏขึ้น ผู้ปฏิบัติงานจะต้องตรวจสอบสถานะทางกายภาพอีกครั้งและดำเนินการแก้ไข เมื่อ การแจ้งเตือน เกิดขึ้น ผู้ปฏิบัติงานต้อง เรียกใช้ขั้นตอนการตอบสนองต่อเหตุการณ์ (แยก ตรวจสอบเซ็นเซอร์ ย้อนกลับคำสั่ง เรียกการบำรุงรักษา ฯลฯ) ในระหว่างการโจมตีทางไซเบอร์ ผู้โจมตีต้องทำให้เป็นกลางหรือหลีกเลี่ยงการป้องกันเหล่านี้ ระงับหรือปลอมแปลง PLC → ข้อเสนอแนะ HMI เพื่อให้ HMI แสดง "ปกติ" ต่อไปแม้ว่าสถานะอุปกรณ์จริงจะเปลี่ยนแปลงไป

การสาธิตสถานการณ์การโจมตี

ในส่วนนี้ เราจะอธิบายขั้นตอนการเล่นของผู้โจมตีทีละขั้นตอน: เครื่องมือและ Payload ที่ใช้ (ระดับสูง) การวิเคราะห์ระดับ Packet ที่แจ้งตรรกะการโจมตี และการกระทำที่สำคัญที่ศัตรูดำเนินการตั้งแต่การประนีประนอมเริ่มต้นไปจนถึงการจัดการ MITM สดที่ขัดขวางการปฏิบัติงานของรันเวย์

แต่ละขั้นตอนที่สำคัญจะจับคู่ความตั้งใจของผู้โจมตีกับสิ่งประดิษฐ์ทางเทคนิคที่สังเกตได้ (PCAPs, ฟิลด์ IEC-104 ASDU, พฤติกรรมของอุปกรณ์) เพื่อให้ผู้ป้องกันสามารถเข้าใจได้ว่าการโจมตีทำงานอย่างไรและมีโอกาสในการตรวจจับอยู่ที่ใด

ขั้นตอน-T1 → T2 — การประนีประนอมเริ่มต้นและการส่งสัญญาณ

ส่วนการสาธิตนี้ครอบคลุมสองขั้นตอนแรกของผู้โจมตี:

• (1) การฝังตัวดักฟังน้ำหนักเบาบนแล็ปท็อปของวิศวกรซ่อมบำรุงอย่างเงียบๆ

• (2) การรอให้วิศวกรนำ Endpoint ที่ติดไวรัสนั้นเข้าไปในสภาพแวดล้อม OT ที่แยกจากกัน เพื่อให้ Implant สามารถจับภาพการรับส่งข้อมูลจาก PLC ไปยังแล็ปท็อปของเหยื่อได้

ชุดเครื่องมือที่ใช้ : ผู้โจมตีใช้ชุดเครื่องมือ Red-Team ที่ฉันพัฒนาขึ้น — Project Ninja RT Framework (RTC2 & Trojan-Malware Cyber-Attack Simulation System) Project Ninja ให้คอนโซล C2 พร้อม Payload แบบโมดูลาร์ที่สามารถส่งไปยังเป้าหมายได้ รวมถึง "Light Agent" ขนาดเล็กที่ออกแบบมาสำหรับการจับภาพ Packet และการ Exfiltration ในระยะยาว เวิร์กโฟลว์ของชุดเครื่องมือแสดงอยู่ในแผนภาพด้านล่าง

Figure-05: Project Ninja RT Framework Workflow diagram, version v0.2.1 (2025)

สำหรับข้อมูลเบื้องต้นโดยละเอียดเกี่ยวกับระบบการโจมตีนี้ คุณสามารถตรวจสอบเอกสารนี้ได้: https://www.linkedin.com/pulse/project-ninja-framework-rtc2-trojan-malware-cyber-attack-liu-loihc

การติดไวรัสและการปรับใช้ Payload จากแดชบอร์ดควบคุมโทรจันบนเว็บ C2 ผู้โจมตีจะแจกแจงแล็ปท็อปของเหยื่อและเลือก Payload ของ Light Agent (ฟังก์ชัน #9 ในคอนโซล) ผู้โจมตีใช้ GUI เพื่อกำหนดค่าพารามิเตอร์การจับภาพ:

• Target NIC: ethernet-5 (อินเทอร์เฟซ RJ45 ในพื้นที่ของแล็ปท็อปที่วิศวกรจะเชื่อมต่อเข้ากับพอร์ต RJ45 ทดสอบของ Tower ในภายหลัง)

• ระยะเวลา/ช่วงเวลาการจับภาพ: 43,200 วินาที → 12 ชั่วโมง (Agent แบ่งส่วนการจับภาพออกเป็นไฟล์ pcap หลายไฟล์)

• พฤติกรรมหลังการจับภาพ: ลบโมดูล Payload โดยอัตโนมัติหลังจากที่การบันทึกตามกำหนดการเสร็จสิ้น

Figure-06: Attacker Active EavesDrop Victim's traffic function, version v0.2.1 (2025)

หลังจากติดตั้ง Payload แล้ว (ขั้นตอน-T1) ผู้โจมตีจะรอช่วงเวลาการบำรุงรักษาตามกำหนดการ ในวันทำการถัดไป วิศวกรซ่อมบำรุงจะตัดการเชื่อมต่อจากอินเทอร์เน็ต เข้าสู่ Runway Tower และเสียบแล็ปท็อปเข้ากับพอร์ตทดสอบ RJ45 ของ Blue Team Subnet-2 ที่แยกจากกัน (ขั้นตอน-T2) ในระหว่างเซสชันนั้น Implant จะจับภาพการรับส่งข้อมูลจากแล็ปท็อปของเหยื่อ ↔ PLC (การทดสอบไฟขึ้น/พักเครื่องและการรายงานสถานะ) ตามแผนทุกประการ

เมื่อปรับใช้แล้ว โทรจันจะทำงานในโหมดที่มองเห็นได้น้อยและพยายามส่งสัญญาณไปยัง C2 ของผู้โจมตีเป็นระยะๆ เพื่อรับคำสั่งและ Exfiltrate pcaps ที่รวบรวมไว้เมื่อแล็ปท็อปกลับมาเชื่อมต่ออินเทอร์เน็ตอีกครั้ง

ขั้นตอน-T3 → T4 — การคืนข้อมูล การวิเคราะห์ และการตัดสินใจโจมตี

หลังจากเซสชันการบำรุงรักษาเสร็จสิ้นและวิศวกรเชื่อมต่ออินเทอร์เน็ตอีกครั้งหลังจากกลับบ้าน โทรจันที่ฝังไว้จะส่งสัญญาณ C2 และ Exfiltrate การจับภาพเมื่อผู้โจมตีใช้ฟังก์ชัน "02 — Steal File from Victim to C2-DB" ในตัว (ดังแสดงด้านล่าง)

Figure-07: Attacker Steal file from the victim laptop to C2, version v0.2.1 (2025)

หลังจากงานเสร็จสิ้น PCAPs ที่อัปโหลดจะปรากฏในที่เก็บไฟล์ C2 (ดังแสดงด้านล่าง) และผู้โจมตีจะดาวน์โหลดจาก C2 ไปยังคอมพิวเตอร์ในพื้นที่ของเขาเพื่อทำการวิเคราะห์แบบออฟไลน์

Figure-08: Attacker download the pcap file C2, version v0.2.1 (2025)

หลังจากได้บันทึก Packet การรับส่งข้อมูล "eavesdrop_record-07_13_09_2024.pcapng" ผู้โจมตีเริ่มวิเคราะห์ข้อมูล Packet และพบว่า PCAPs มีการรับส่งข้อมูล Layer-2/3 และเฟรม IEC-104 ที่จับภาพได้ในขณะที่แล็ปท็อปเชื่อมต่อกับ Subnet Blue-Team ที่แยกจากกัน สิ่งประดิษฐ์สำคัญที่กู้คืนได้ระหว่างการวิเคราะห์ ได้แก่:

• เฟรมควบคุม IEC-104 ASDU (คำขอคำสั่งจากแล็ปท็อปไปยัง PLC ซึ่ง HMI ใช้กับ PLC ด้วย)

• PLC → รายงานสถานะแล็ปท็อป (จุดวัด/คุณภาพที่ PLC อาจฟ้องร้องกับ HMI ด้วย)

• การกำหนด IP และการ Mapping สำหรับ HMI และ PLC (เช่น PLC01 = 10.10.20.11)

• รูปแบบลำดับ/เวลาและตัวนับ APCI ที่ใช้โดยเซสชัน IEC-104

ข้อจำกัดของ Protocol และสภาพแวดล้อมที่ค้นพบ

จากการตรวจสอบ Packet อย่างละเอียดถี่ถ้วนของเอกสารและการวิเคราะห์ พบว่ามีปัจจัยป้องกันที่สำคัญหลายประการที่จำกัดตัวเลือกการโจมตีอย่างง่าย:

• PLC write whitelist PLC บังคับใช้นโยบาย Allowed-Write White List เพื่อให้แน่ใจว่าเฉพาะเครื่อง HMI เท่านั้นที่สามารถส่งคำสั่งเปลี่ยนสถานะ PLC ไปยัง PLC เพื่อป้องกันการโจมตีด้วยการฉีดคำสั่งปลอม เว้นแต่ผู้โจมตีจะสามารถ Bypass การควบคุมการเข้าถึง PLC ได้

• Measurement-point persistence: สถานะแสงได้รับการดูแลรักษาใน IOA การวัดแบบ Discrete ที่คาดว่าจะได้รับการอัปเดตโดยตรรกะ PLC การฉีดคำขอข้อมูลปลอมโดยตรงจะถูก PLC ปฏิเสธโดยตรง

• APCI sequence/acknowledgement counters: IEC-104 ใช้หมายเลขลำดับ Tx/Rx ในส่วนหัว APCI (ดัชนีการส่ง/รับ) การ Replay เฟรมที่จับภาพไว้ก่อนหน้านี้อย่างง่ายๆ จะล้มเหลว เว้นแต่ตัวนับลำดับเหล่านี้จะซิงโครไนซ์อย่างถูกต้องกับเซสชัน HMI↔PLC สด ซึ่งแทบจะเป็นไปไม่ได้เลยที่การโจมตีด้วย Packet Replay จะตรงกับลำดับกับ Packet ที่บันทึกไว้เก่าอย่างแม่นยำ

Figure-09: IEC 60870-5-104 APCI message sequence, version v0.2.1 (2025)

เอกสารกฎการเปลี่ยนแปลงจุดหน่วยความจำ IEC 104: https://infosys.beckhoff.com/english.php?content=../content/1033/tf6500_tc3_iec60870_5_10x/984444939.html&id=

เนื่องจากข้อจำกัดเหล่านี้ ผู้โจมตีจึงสรุปได้ว่าทั้งการฉีดปลอมแบบ Blind และการ Replay อย่างง่ายจะไม่สามารถควบคุมได้อย่างลับๆ อย่างน่าเชื่อถือ วิธีเดียวสำหรับเขาคือการโจมตี Man In The Middle เพื่อแก้ไขข้อมูลที่ถูกต้องที่ส่งจาก HMI ไปยัง PLC

จาก Traffic ที่จับภาพได้ ผู้โจมตีจะระบุองค์ประกอบ ASDU และ IOA ที่เกี่ยวข้องกับการควบคุมไฟพักเครื่องได้อย่างแม่นยำดังแสดงด้านล่าง:

Figure-10: HMI to PLC IEC 60870-5-104 ASDU requset data, version v0.2.1 (2025)

• การอ้างอิง ASDU ควบคุมดัชนีควบคุม PLC 11

• IOA ที่เปลี่ยนแปลงได้สำหรับการควบคุมแสงคือ 13

• การควบคุม "Step Up" ของผู้ปฏิบัติงานแสดงเป็นค่าควบคุมเฉพาะ (val=02) ภายใน ASDU

ผู้โจมตียังสังเกตเห็นรูปแบบ Readback จาก PLC ไปยัง HMI ดังแสดงด้านล่าง:

Figure-11: PLC to HMI IEC 60870-5-104 ASDU response data, version v0.2.1 (2025)

เมื่อมีการออกคำสั่ง UP เพื่อเปลี่ยนสถานะแสง PLC จะได้รับค่าเซ็นเซอร์ด้วย จากนั้นบันทึกลงใน IOA การวัด 1 การเปลี่ยน (OFF → ON) และต่อมา HMI จะอ่านกลับผ่านลำดับการอ่าน/รายงาน IEC-104 แยกต่างหาก

เมื่อนำชิ้นส่วนต่างๆ มารวมกัน ผู้โจมตีจะสร้างแบบจำลองกลยุทธ์การโจมตีที่เป็นไปได้: เพื่อให้ยังคงแอบแฝงอยู่ พวกเขาต้อง สกัดกั้นและเปลี่ยนแปลงทั้งสองทิศทาง ของการแลกเปลี่ยน IEC-104 — HMI → การควบคุม PLC ASDU (เพื่อพลิกคำสั่ง) และ PLC → การวัด/รายงาน HMI ASDU (เพื่อให้การแสดงผล HMI สอดคล้องกัน) ผู้โจมตีร่างตรรกะ MITM และเป้าหมายที่ต้องการ (ฟิลด์ควบคุม ASDU RCO และฟิลด์รายงาน ASDU SPI/สถานะ) ในแผนภาพสมมติฐานการโจมตีดังแสดงด้านล่าง:

Figure-11: MITM attack assumption diagram, version v0.2.1 (2025)

ขั้นตอน-T5 → T7 — การพัฒนาและการปรับใช้การโจมตี

หลังจากวิเคราะห์ Traffic IEC-104 ที่จับภาพได้และระบุฟิลด์ ASDU และ IOA ที่เกี่ยวข้องกับการควบคุมไฟพักเครื่องอย่างแม่นยำ ผู้โจมตีเลือกที่จะใช้กลยุทธ์ การแก้ไขในเส้นทาง : วิธีปฏิบัติเดียวที่จะยังคงแอบแฝงอยู่ได้คือการนั่งระหว่าง HMI และ PLC และเปลี่ยนแปลงข้อความในทั้งสองทิศทาง

• HMI → PLC: แก้ไขคำขอควบคุมเพื่อให้ "Step Up / อนุญาต" ของผู้ปฏิบัติงานกลายเป็น "Step Down / Hold" (หรือในทางกลับกัน)

• PLC → HMI: ย้อนกลับรายงาน Readback/สถานะเพื่อให้ HMI แสดงสถานะปกติและไม่ส่งคำเตือน/การแจ้งเตือนต่อไป

เนื่องจาก Blue Team Subnet 2 ถูกแยกออกจากอินเทอร์เน็ต แทนที่จะพยายามโจมตีโดยตรงจากเครือข่าย Red-Team ภายนอก ศัตรูจึงใช้ กล้อง IoT ของบุคคลที่สามที่ถูกบุกรุก เป็นสื่อทางกายภาพเพื่อให้ได้ตำแหน่งในเส้นทางนั้น เมื่อเชื่อมต่อกับ Subnet เดียวกับ HMI ควบคุมแสงแล้ว กล้องที่ถูกดัดแปลงจะวางตำแหน่งตัวเองเพื่อสังเกตและมีอิทธิพลต่อการไหลของ HMI↔PLC โดยการโฆษณาข้อมูล Routing เครือข่ายท้องถิ่นที่ทำให้เข้าใจผิด (เช่น การ Mapping ARP ที่ปลอมแปลง) เพื่อให้ Traffic ถูก Routing เปลี่ยนเส้นทางผ่านอุปกรณ์ แผนภาพการไหลของการโจมตีแสดงอยู่ด้านล่าง:

Figure-12: MITM attack flow diagram, version v0.2.1 (2025)

ในการสร้าง Payload MITM ในการสาธิตการโจมตีนี้ เราใช้ Ettercap ซึ่งเป็นชุดเครื่องมือที่ครอบคลุมที่ใช้ Linux สำหรับการโจมตี Man In The Middle เพื่อใช้ ARP Spoofing และใช้ Ettercap Filter เพื่อวิเคราะห์ Traffic พอร์ต 2042 และทำการแทนที่ Bit สำหรับลำดับข้อมูล IEC104 ASDU โดยละเอียด คุณสามารถอ้างอิงคำอธิบายนี้ได้: https://www.linkedin.com/pulse/python-virtual-plc-simulator-iec-60870-5-104-protocol-yuancheng-liu-bov7c

ผู้โจมตีต้องการแก้ไขข้อมูล Step ควบคุม C_CT_TA_1 หาก HMI ส่ง Step Up [\x02] เปลี่ยนเป็น Step Down [\x01] (หรือในทางกลับกัน) เพื่อใช้งานสิ่งนี้ ฉันได้สร้าง Ettercap Bit Modification Filter ดังแสดงด้านล่าง:

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();
    }
 }

เมื่อเซ็นเซอร์ไฟพักเครื่องส่งสถานะแสงกลับไปยัง HMI ผู้โจมตีต้องเปลี่ยนสถานะเปิดไฟตอบสนองของ PLC เป็น OFF (หรือในทางกลับกัน) เพื่อใช้งานสิ่งนี้ ฉันได้สร้าง Ettercap Bit Reverse Filter ดังแสดงด้านล่าง:

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();
    }
}

หลังจากเสร็จสิ้น Filter ให้คอมไพล์ไฟล์ Filter เป็นไฟล์ Payload *.ef ที่ Ettercap สามารถโหลดได้โดยตรง:

etterfilter arp_mitm.filter -o mitm.ef

จากนั้นผู้โจมตีทำตามตัวอย่างนี้เพื่อบรรจุ Payload ที่เป็นอันตรายนี้ลงในคอมโพเนนต์อัปเดตเฟิร์มแวร์ขั้นต่ำและรวมเข้ากับอิมเมจกล้อง: https://www.linkedin.com/pulse/ot-cyber-attack-workshop-case-study-06-replay-safety-surveillance-gcgxc และเพิ่มคำสั่ง Run อัตโนมัติสำหรับการควบคุม ARP Spoofing ด้วยที่อยู่ IP Router ของ Subnet Blue Team 2 ในสคริปต์เริ่มต้นเฟิร์มแวร์พื้นฐานของกล้อง:

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

หลังจากเสร็จสิ้นทั้งหมด กล้อง IoT ที่กำหนดเองจะถูกส่งไปยังเวิร์กโฟลว์การบำรุงรักษาและติดตั้งทางกายภาพใน Tower โดยวิศวกรซ่อมบำรุงที่ไม่ตรวจสอบความถูกต้องของเฟิร์มแวร์หรือการกำหนดค่าเครือข่าย เมื่อเปิดใช้งานบน OT LAN แล้ว กล้องจะเริ่มการจัดการ Routing ในพื้นที่และการแทนที่ ASDU แบบเลือก โดยดำเนินการเฉพาะกับรูปแบบทริกเกอร์ที่กำหนดไว้อย่างแคบ (เพื่อลดสัญญาณรบกวนและลดโอกาสในการตรวจจับ)

ขั้นตอน-T8 → T11 — การโจมตี MITM เพื่อชะลอการขึ้นเครื่องบิน

ขั้นตอนนี้อธิบายสิ่งที่เกิดขึ้น หลังจาก ติดตั้งกล้อง IoT ที่ถูกดัดแปลงใน Tower และตรรกะในเส้นทางของผู้โจมตีเริ่มทำงาน เรื่องราวต่อไปนี้เปรียบเทียบพฤติกรรมปกติของผู้ปฏิบัติงาน/PLC/HMI กับสิ่งที่ผู้ปฏิบัติงานสังเกตเห็นในขณะที่ MITM กำลังจัดการ Traffic ทั้งคำสั่งและสถานะอย่างแข็งขัน

การทำงานของ Tower ปกติ — "อนุญาตให้ขึ้นเครื่อง" (Baseline)

เมื่อการดำเนินงานเป็นปกติและรันเวย์ว่างเปล่า การควบคุมการขึ้นเครื่องบินของผู้ปฏิบัติงาน Tower จะแสดงอยู่ด้านล่าง:

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

• ผู้ปฏิบัติงาน Tower ออกคำสั่ง ปิดไฟพักเครื่องขึ้น บน HMI เพื่ออนุญาตให้เครื่องบินเริ่มขึ้น

• HMI ส่งการควบคุม IEC-104 ไปยัง PLC; PLC จะปิดไฟพักเครื่องขึ้นของรันเวย์ที่อุปกรณ์และรายงานสถานะเซ็นเซอร์กลับไปยัง HMI

• Simulator ทางกายภาพ (หรืออุปกรณ์จริง) แสดงไฟ OFF; แผงสถานะรันเวย์ HMI และตัวบ่งชี้การควบคุมพลังงานสะท้อนสถานะ OFF ทั้งคู่ ไม่มีการแสดงคำเตือนการขึ้นเครื่อง

การทำงานของ Tower ปกติ — "พักเครื่องขึ้น" (Baseline)

เมื่อมีเหตุผลที่ต้องระงับการขึ้นบิน (เช่น เครื่องบินที่ลงจอดอีกลำยังไม่เคลื่อนที่ในทางขับเคลื่อน) การควบคุมการระงับการขึ้นบินของเครื่องบินโดยเจ้าหน้าที่ควบคุมหอบังคับการบินจะแสดงดังต่อไปนี้:

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

• เจ้าหน้าที่เปิด ไฟระงับการขึ้นบิน ON ผ่าน HMI ไปยัง PLC

• PLC เปลี่ยนไฟระงับการขึ้นบินของเครื่องจำลองโลกเสมือนจริง และเครื่องบินที่รอขึ้นบินจะรออยู่ที่บริเวณเตรียมพร้อม

• HMI รับข้อมูลเซ็นเซอร์จาก PLC และอัปเดตบนแผงควบคุมรันเวย์ด้วยเส้นสีแดง 2 เส้น

• พื้นที่แสดงสัญญาณเตือนของ HMI จะแสดง คำเตือน การระงับการขึ้นบิน เพื่อระบุว่ามีเครื่องบินกำลังรอขึ้นบิน

MITM Active — วิธีที่การโจมตีเปลี่ยนแปลงพฤติกรรม

เมื่อกล้องที่เป็นอันตรายกลายเป็นอุปกรณ์ในเส้นทาง มันจะสกัดกั้นการแลกเปลี่ยน HMI ↔ PLC อย่างเลือกสรร และดำเนินการสองอย่างที่ประสานกันทุกครั้งที่เจ้าหน้าที่เปลี่ยนไฟขึ้นบิน

• แก้ไขคำสั่งควบคุมขาออก (HMI → PLC) : MITM พลิกหรือแทนที่การกระทำควบคุมที่เจ้าหน้าที่ตั้งใจไว้ เพื่อให้ PLC ได้รับคำสั่งที่แตกต่างจากที่เจ้าหน้าที่สั่ง (เช่น เจ้าหน้าที่กด OFF แต่ PLC ได้รับ ON หรือในทางกลับกัน)

• ปลอมแปลง/เปลี่ยนแปลง PLC readback (PLC → HMI) : ทันทีหลังจากสถานะเซ็นเซอร์จริงของ PLC เปลี่ยนแปลง (หรือไม่เปลี่ยนแปลง) MITM จะแก้ไขรายงาน PLC → HMI เพื่อให้ HMI แสดงค่าที่ คาดหวัง (ค่าที่เจ้าหน้าที่คาดว่าจะเห็น) ป้องกันการแจ้งเตือนหรือความไม่ตรงกันของสถานะที่ชัดเจนบนคอนโซล

การสังเกตจะแสดงดังต่อไปนี้:

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

• เจ้าหน้าที่ควบคุมหอบังคับการบินกดปุ่มปิดไฟระงับบน HMI เพื่ออนุญาตให้เครื่องบิน 1 ขึ้นบิน

• ไฟจริงยังคงอยู่ในสถานะตรงกันข้ามกับสิ่งที่เจ้าหน้าที่เชื่อ (เช่น เจ้าหน้าที่ปิดไฟแล้ว แต่ไฟยังคงเปิดอยู่ในโลกแห่งความเป็นจริง) ดังนั้นเครื่องบินที่จุดรอจึงไม่เริ่มขึ้นบิน

• HMI แสดงสถานะปกติ/ที่คาดหวัง (ปิดเครื่อง) เนื่องจาก MITM ได้ปรับเปลี่ยนรายงาน PLC → HMI เพื่อซ่อนความไม่ตรงกัน เจ้าหน้าที่ไม่เห็นสิ่งผิดปกติและคิดว่าคำสั่งสำเร็จ

• แผงควบคุมพลังงานอาจระบุสถานะคำสั่งที่คาดหวัง (เนื่องจากตัวบ่งชี้นั้นสะท้อนถึงผลตอบรับที่ถูกปรับเปลี่ยน) ซึ่งยิ่งทำให้เจ้าหน้าที่มั่นใจว่ารันเวย์ว่าง

• ข้อความเตือนก็ไม่ถูกกระตุ้นเช่นกัน เพื่อยืนยันว่าไม่มีเครื่องบินอยู่ที่สถานะระงับการขึ้นบิน

ตอนนี้การโจมตีแบบ Man in the mid ของกล้อง IoT ได้ชะลอขั้นตอนการขึ้นบินของเครื่องบินแล้ว

ขั้นตอน-T12 → T13 — ผลกระทบต่อการดำเนินงานแบบต่อเนื่องและการยกระดับความปลอดภัย

เมื่อการโจมตี MITM ได้ชะลอขั้นตอนการขึ้นบินของเครื่องบิน 1 สำเร็จ เพื่อปกปิดสถานะรันเวย์ที่แท้จริงจาก HMI ของหอบังคับการบิน ผลกระทบต่อการดำเนินงานจะลุกลามอย่างรวดเร็วจากความผิดพลาดของอุปกรณ์เฉพาะที่ ไปสู่เหตุการณ์ความปลอดภัยด้านการบิน ดังที่แสดงด้านล่าง:

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

• เครื่องบินขาเข้า (Plane-02) เข้าสู่รูปแบบการเข้าใกล้สุดท้าย ในขณะที่เครื่องบินขาออก (Plane-01) ยังคงอยู่ที่จุดรอออกเดินทาง เนื่องจากไฟขึ้นบินจริงไม่เคยถูกปิด นักบินของเครื่องบิน 02 ตรวจพบสถานการณ์รันเวย์ถูกใช้งานจากเรดาร์และวิสัยทัศน์

• นักบินขาเข้าดำเนินการพลาดการเข้าใกล้ฉุกเฉิน / เชิดหัวขึ้นใหม่ (ยกเลิกการลงจอดและไต่กลับไปยังรูปแบบการรอที่เผยแพร่) เพื่อหลีกเลี่ยงการชนที่อาจเกิดขึ้น

• Plane-02 กลับเข้าสู่รูปแบบการรอ และอาจถูกนำทางหรือจัดลำดับตามหลังการจราจรอื่น ๆ การเผาผลาญเชื้อเพลิงเพิ่มขึ้นเนื่องจากการบินยังคงอยู่ในอากาศนานกว่าที่วางแผนไว้

หลังจากรอคอยเป็นเวลานาน นักบินขาเข้าประกาศสถานะ เชื้อเพลิงเหลือน้อย ต่อ ATC สิ่งนี้จะยกระดับความสำคัญของการบินทันที และกระตุ้นการจัดการ/จัดลำดับการลงจอดฉุกเฉิน เครื่องจำลองจะแสดงสัญญาณเตือนเชื้อเพลิงเหลือน้อยและการยกระดับการดำเนินงานที่เกิดขึ้น (ดังที่แสดงในเครื่องจำลองโลกเสมือนจริงด้านล่าง)

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

ในที่สุดการโจมตี MITM ก็ส่งผลกระทบต่อการดำเนินงานแบบต่อเนื่องและก่อให้เกิดเหตุการณ์ยกระดับความปลอดภัย

การตอบสนองต่อเหตุการณ์ : เมื่อเครื่องบิน-02 รายงานว่าเชื้อเพลิงเหลือน้อยต่อหอบังคับการบิน เจ้าหน้าที่เริ่มขั้นตอนการตอบสนองต่อเหตุการณ์ เพื่อยืนยันสถานะปัจจุบันของรันเวย์ นำเครื่องบิน 01 หรือรถลากเครื่องบินไปยังพื้นที่แท็กซี่ จากนั้นนำเครื่องบิน-02 ลงจอด

การป้องกันและบทสรุป

หลังจากสาธิตวิธีการโจมตีแบบ Man-in-the-Middle (MITM) หลายขั้นตอน ที่สามารถดำเนินการกับระบบควบคุมไฟรันเวย์การบิน โดยการใช้ประโยชน์จากการกำหนดค่าที่ไม่ถูกต้องและอุปกรณ์ IoT ที่ถูกบุกรุกภายในสภาพแวดล้อม Cyber Range เราสามารถให้รายการตรวจสอบสั้น ๆ สำหรับผู้ป้องกัน เพื่อลดความเสี่ยงในการยกระดับและตัดขาดห่วงโซ่การโจมตีทางไซเบอร์ที่เป็นไปได้:

• รักษาความซ้ำซ้อนที่เป็นอิสระสำหรับการตรวจสอบสถานะรันเวย์ (เส้นทางเซ็นเซอร์สำรอง ฟีดกล้องที่แยกจากกัน)

• บังคับใช้การเริ่มต้นใช้งานอุปกรณ์และการตรวจสอบเฟิร์มแวร์อย่างเข้มงวด สำหรับอุปกรณ์ใด ๆ ที่จะเชื่อมต่อกับ OT VLAN

• ใช้ความสามารถในการแยกอย่างรวดเร็ว (การควบคุมการเข้าถึงเครือข่าย การปิดใช้งานพอร์ตสวิตช์) เพื่อลบปลายทางที่น่าสงสัยออกอย่างรวดเร็ว

• สร้างและฝึกซ้อมขั้นตอนการควบคุมรันเวย์ด้วยตนเองเป็นประจำ เพื่อให้เจ้าหน้าที่สามารถดำเนินการต่อไปได้อย่างปลอดภัย ในขณะที่กำลังตรวจสอบสาเหตุหลักทางเทคนิค

การจำลองแสดงให้เห็นถึงศักยภาพของการโจมตีดังกล่าว ในการสกัดกั้นและจัดการการรับส่งข้อมูลโปรโตคอล IEC 60870-5-104 OT ซึ่งนำไปสู่การปฏิเสธการควบคุมไฟรันเวย์ ความล่าช้าในการขึ้นบินของเครื่องบิน และท้ายที่สุด สถานการณ์เชื้อเพลิงเหลือน้อยที่สำคัญต่อความปลอดภัยสำหรับเครื่องบินขาเข้า แม้ว่าสถานการณ์จะอาศัยช่องโหว่ที่จงใจฉีดเข้าไปเพื่อวัตถุประสงค์ในการฝึกอบรม แต่ก็เน้นย้ำถึงความสำคัญอย่างยิ่งของการแบ่งส่วนเครือข่ายที่แข็งแกร่ง ความปลอดภัยของห่วงโซ่อุปทานที่เข้มงวด และการตรวจสอบช่องทางการควบคุม OT ที่ครอบคลุม ท้ายที่สุด การฝึกนี้ทำหน้าที่เป็นเครื่องมือที่มีค่าสำหรับการฝึกอบรมทีมตอบสนองต่อเหตุการณ์ และเน้นย้ำถึงความจำเป็นในการป้องกันแบบหลายชั้น เพื่อปกป้องโครงสร้างพื้นฐานด้านการบินที่สำคัญ จากภัยคุกคามทางไซเบอร์แบบผสมผสาน IT/OT/IoT ที่เกิดขึ้นใหม่

ขอบคุณที่สละเวลาตรวจสอบรายละเอียดบทความ หากคุณมีคำถามและข้อเสนอแนะ หรือพบข้อผิดพลาดของโปรแกรม โปรดส่งข้อความถึงฉันได้เลย ขอบคุณมากหากคุณสามารถให้ความคิดเห็นและแบ่งปันคำแนะนำในการปรับปรุง เพื่อให้เราสามารถปรับปรุงงานของเราให้ดีขึ้นได้ ~

แก้ไขล่าสุดโดย LiuYuancheng ([email protected]) เมื่อวันที่ 13/09/2025 หากคุณมีปัญหาใด ๆ โปรดส่งข้อความถึงฉัน