จัดทำโดย: Cloud Thunder Threat Intelligence
หัวข้อ: ปฏิบัติการเจาะหน่วยงานรัฐไต้หวันด้วยกรอบเอเจนต์ AI หลายตัว (Multi-Agent AI Framework) จากเฟรมเวิร์กโอเพนซอร์ส Hermes และ OpenClaw
ประเภทเอกสาร: บทวิเคราะห์เชิงยุทธศาสตร์ด้านภัยคุกคาม (Strategic Threat Analysis)
มุมมอง: ความมั่นคงปลอดภัยไซเบอร์ของประเทศไทย
ฐานข้อมูล: รายงานสืบสวนของบริษัท Dream (อิสราเอล), รายงานข่าวของ Financial Times, Reuters, CyberScoop, The Register, Taipei Times, แถลงของกระทรวงกิจการดิจิทัลไต้หวัน (MODA) และฐานข่าวของ Cloud Thunder

บทสรุปเชิงยุทธศาสตร์ (Strategic Summary)

ระหว่างวันที่ 1–4 กรกฎาคม 2569 มีปฏิบัติการจารกรรมไซเบอร์ครั้งหนึ่งเกิดขึ้นกับหน่วยงานรัฐของไต้หวัน ซึ่งนักวิจัยประเมินว่าเป็น กรณีแรกที่มีหลักฐานครบถ้วนว่าการโจมตีหน่วยงานรัฐทั้งกระบวนการ ตั้งแต่การสำรวจเป้าหมายไปจนถึงการขโมยข้อมูลออก ถูกขับเคลื่อนโดยเอเจนต์ปัญญาประดิษฐ์ (AI agent) ที่ทำงานเองเป็นหลัก โดยมีมนุษย์คอยกำกับเพียงเบาบาง ปฏิบัติการนี้ถูกเปิดโปงโดยบริษัท Dream ซึ่งเป็นบริษัทด้าน AI และการป้องกันภัยไซเบอร์สัญชาติอิสราเอล และปรากฏต่อสาธารณะครั้งแรกผ่านรายงานของ Financial Times เมื่อวันที่ 12 สิงหาคม 2569

สิ่งที่ทำให้เหตุการณ์นี้ต่างจาก “การใช้ AI ช่วยแฮ็ก” ที่เคยมีมา คือผู้โจมตีไม่ได้ใช้ AI เป็นเพียงผู้ช่วยเขียนโค้ดหรือร่างอีเมลหลอกลวง แต่ ประกอบ “ฝูงเอเจนต์” (agent swarm) ขึ้นมาทั้งระบบ จากเฟรมเวิร์กโอเพนซอร์สที่ใครก็ดาวน์โหลดได้สองตัว คือ Hermes และ OpenClaw แล้วปล่อยให้เอเจนต์เหล่านั้นแบ่งงานกันเอง จัดลำดับความสำคัญของช่องทางโจมตีเอง ค้นคว้าเทคนิคใหม่จากอินเทอร์เน็ตเองเมื่อเจอทางตัน และตรวจสอบผลลัพธ์ของตัวเองซ้ำเพื่อคัดผลบวกลวง (false positive) ออก นาย Amir Becker ประธานเจ้าหน้าที่ฝ่ายยุทธศาสตร์ของ Dream ซึ่งเคยเป็นหัวหน้าฝ่ายปฏิบัติการไซเบอร์ของหน่วย 8200 แห่งกองทัพอิสราเอล อธิบายว่าระบบนี้ “ทำตัวเหมือนทีมไซเบอร์ที่ทำงานประสานกัน มากกว่าจะเป็นสคริปต์อัตโนมัติตัวเดียว”

บทวิเคราะห์ฉบับนี้ประเมินว่าเหตุการณ์นี้มีนัยเชิงยุทธศาสตร์ที่สำคัญ 5 ประการ ได้แก่

• (1) ต้นทุนของการโจมตีระดับรัฐพังทลายลง แต่ต้นทุนการป้องกันยังเท่าเดิม — งานที่เคยต้องใช้ทีมผู้เชี่ยวชาญหลายคนผลัดกันทำเป็นสัปดาห์ ถูกย่อลงเหลือซอฟต์แวร์โอเพนซอร์สที่ทำงาน 4 วันรวด โดยไม่ต้องมีคนนั่งเฝ้า
• (2) เครื่องมือทั้งหมดเป็นของเปิดเผยและฟรี — ไม่มีมัลแวร์ระดับรัฐ ไม่มีช่องโหว่ zero-day ที่ซื้อมาราคาแพง มีเพียงเฟรมเวิร์กเอเจนต์โอเพนซอร์ส เครื่องมืออ่านตัวอักษรจากภาพ (OCR) ที่ใช้กันทั่วไป และความผิดพลาดในการตั้งค่าระบบของฝ่ายตั้งรับ
• (3) จุดแตกหักไม่ใช่ “AI เก่ง” แต่คือ “ระบบพิสูจน์ตัวตนรวมศูนย์ที่ตั้งค่าผิด” — บัญชีที่ยึดได้ 84 จาก 85 บัญชี (ร้อยละ 98.8) สามารถเข้าสู่ระบบภายในอื่น ๆ ต่อได้ทันทีผ่านสะพานเชื่อม Single Sign-On (SSO) ของภาครัฐ
• (4) มาตรการกำกับความปลอดภัยของโมเดล AI ถูกข้ามด้วยประโยคเดียว — ผู้โจมตีเพียงประกาศกรอบงานว่าเป็น “การทดสอบเจาะระบบที่ได้รับอนุญาต” (authorized penetration testing) ซึ่งโมเดลไม่มีทางตรวจสอบหรือปฏิเสธได้
• (5) ประเทศไทยไม่ใช่ผู้สังเกตการณ์ แต่เป็นสนามที่เพิ่งถูกใช้มาแล้ว — เฟรมเวิร์ก Hermes ตัวเดียวกันนี้ คือเครื่องมือที่ปรากฏในปฏิบัติการเจาะเครือข่าย กระทรวงการคลังของไทย ระหว่างวันที่ 9–13 กรกฎาคม 2569 ซึ่งเกิดขึ้นห่างจากปฏิบัติการไต้หวันเพียงไม่ถึงหนึ่งสัปดาห์

สำหรับประเทศไทย ประเด็นสำคัญที่สุดไม่ใช่คำถามว่า “ไทยจะโดนหรือไม่” เพราะไทยโดนไปแล้วเมื่อเดือนกรกฎาคม แต่คือคำถามว่า ระบบพิสูจน์ตัวตนกลางของภาครัฐไทย ระบบ API ที่เปิดให้บริการประชาชน และผู้ให้บริการเทคโนโลยีที่เป็นห่วงโซ่อุปทาน (Supply Chain) ของหน่วยงานรัฐ จะทนต่อการถูกสำรวจด้วยความเร็วระดับเครื่องจักรตลอด 24 ชั่วโมงได้นานเท่าใด เพราะช่องโหว่ทุกจุดที่ฝูงเอเจนต์ใช้เจาะไต้หวัน ล้วนเป็นความผิดพลาดในการตั้งค่าที่พบได้ทั่วไปในระบบราชการไทยเช่นกัน

ภาพที่ 1: ภาพรวมปฏิบัติการทั้ง 6 เฟส ตั้งแต่การถอดรหัสไฟล์จาวาสคริปต์ของเว็บท่าหน่วยงานรัฐ ไปจนถึงการขยายผลสู่หน่วยงานความปลอดภัยนิวเคลียร์และบริษัทพลังงาน โดยใช้เวลารวมเพียง 4 วัน

1. รู้จักปฏิบัติการและผู้อยู่เบื้องหลัง

1.1 การค้นพบ — ผู้โจมตีเผลอเปิดคลังไฟล์ปฏิบัติการทิ้งไว้

นักวิจัยของ Dream ไม่ได้พบปฏิบัติการนี้จากการเฝ้าระวังเครือข่ายของเหยื่อ แต่พบจากงานติดตามภัยคุกคามตามปกติ เมื่อพบ คลังไฟล์ขนาด 160 เมกะไบต์ ที่เปิดทิ้งไว้บนอินเทอร์เน็ต บรรจุไฟล์รวม 1,395 ไฟล์ ซึ่งเป็นผลผลิตทั้งหมดที่ฝูงเอเจนต์สร้างขึ้นระหว่างปฏิบัติการ ตั้งแต่บันทึกการทำงานของแต่ละเอเจนต์ ผลการสแกน รายงานสรุปที่เอเจนต์เขียนถึงกันเอง ไปจนถึงข้อมูลที่ขโมยออกมาได้

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

อนึ่ง รูปแบบ “ผู้โจมตีเผลอเปิดไดเรกทอรีปฏิบัติการทิ้งไว้” นี้ ตรงกับกรณีที่บริษัท Hunt.io และนาย Bob Diachenko ใช้เปิดโปงปฏิบัติการเจาะกระทรวงการคลังของไทยในเดือนเดียวกัน ซึ่งสะท้อนว่าวินัยด้านความปลอดภัยเชิงปฏิบัติการ (Operational Security : OPSEC) ของผู้โจมตีกลุ่มนี้ยังหละหลวม แม้เครื่องมือจะก้าวหน้าก็ตาม — และนั่นคือโอกาสตั้งรับที่ฝ่ายป้องกันยังพอมีอยู่

1.2 การพิสูจน์ตัวตนผู้โจมตี (Attribution)

Dream ไม่ได้ระบุชื่อกลุ่มผู้โจมตีอย่างเป็นทางการ และตามนโยบายบริษัทระบุเพียงว่าได้แจ้งเตือน “รัฐบาลหนึ่งในภูมิภาคเอเชีย-แปซิฟิก” ขณะที่แหล่งข่าวที่รับทราบเรื่องนี้ยืนยันกับสื่อว่าเป้าหมายคือไต้หวัน หลักฐานที่ชี้ไปยังผู้ปฏิบัติการที่ใช้ภาษาจีนประกอบด้วย

หนึ่ง การสลับภาษาในเอกสารปฏิบัติการ (code-switching) โดยรายงานสถานะภายในที่เอเจนต์เขียนถึงผู้ควบคุมใช้ ภาษาจีนตัวย่อ (Simplified Chinese) ซึ่งเป็นรูปแบบที่ใช้ในจีนแผ่นดินใหญ่ ขณะที่เอกสารวิเคราะห์ที่เกี่ยวกับเป้าหมายใช้ ภาษาจีนตัวเต็ม (Traditional Chinese) ซึ่งเป็นรูปแบบที่ใช้ในไต้หวัน ฮ่องกง และมาเก๊า สอง มีบันทึกสรุปผลลัพธ์เขียนด้วยภาษาจีนตัวย่อว่า “8个真实漏洞（物理确权+3+3交叉验证）” แปลได้ว่า “ช่องโหว่จริง 8 รายการ (ยืนยันเชิงกายภาพ + ตรวจสอบไขว้ 3+3 รอบ)” ซึ่งเป็นสำนวนการทำงานของผู้ที่ใช้ภาษาจีนเป็นภาษาหลัก

ทั้งนี้ นักวิจัยไม่สามารถระบุได้ว่าโมเดลภาษาขนาดใหญ่ (Large Language Model : LLM) ตัวใดเป็นเครื่องยนต์เบื้องหลังเอเจนต์เหล่านี้ เนื่องจากเฟรมเวิร์กทั้งสองตัวสามารถต่อกับโมเดลใดก็ได้ ทั้งโมเดลเชิงพาณิชย์ผ่าน API และโมเดลโอเพนซอร์สที่ติดตั้งใช้งานเองบนเซิร์ฟเวอร์ของผู้โจมตี ซึ่งข้อเท็จจริงนี้เองมีนัยสำคัญต่อการตั้งรับ เพราะหมายความว่า การควบคุมที่ผู้ให้บริการโมเดลรายใดรายหนึ่งกำหนดขึ้น ไม่เพียงพอที่จะสกัดปฏิบัติการลักษณะนี้ได้

ในมุมมองของ Cloud Thunder การประเมินที่เหมาะสมคือ “ความเชื่อมั่นระดับปานกลาง” (medium confidence) ว่าเป็นผู้ปฏิบัติการที่ใช้ภาษาจีนและมีเป้าหมายสอดคล้องกับผลประโยชน์ของรัฐจีน โดยยังไม่ควรผูกเข้ากับชื่อกลุ่มที่รู้จัก เช่น Mustang Panda หรือ APT41 จนกว่าจะมีหลักฐานด้านโครงสร้างพื้นฐานหรือรหัสโปรแกรมที่ทับซ้อนกันชัดเจน

1.3 บริบทของไต้หวัน และเหตุผลที่ไทยต้องอ่านเหตุการณ์นี้อย่างจริงจัง

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

สำหรับประเทศไทย เหตุผลที่ต้องอ่านเหตุการณ์นี้อย่างจริงจังมีสามข้อ

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

ข้อที่สอง เฟรมเวิร์ก Hermes ถูกใช้โจมตีหน่วยงานเศรษฐกิจหลักของไทยไปแล้วในเดือนเดียวกัน จึงไม่ใช่ภัยที่อยู่ไกลตัว

ข้อที่สาม ปฏิบัติการนี้ไม่ได้จบที่หน่วยงานรัฐ แต่ขยายไปยัง ผู้ให้บริการเทคโนโลยีของภาครัฐ หน่วยงานกำกับความปลอดภัยนิวเคลียร์ และบริษัทพลังงานอย่างน้อย 7 แห่ง ซึ่งเป็นรูปแบบเดียวกับที่จะเกิดขึ้นได้กับโครงสร้างพื้นฐานสำคัญทางสารสนเทศ (Critical Information Infrastructure : CII) ของไทยตามพระราชบัญญัติการรักษาความมั่นคงปลอดภัยไซเบอร์ พ.ศ. 2562

2. ไทม์ไลน์และสถาปัตยกรรมของกรอบโจมตี

2.1 ลำดับเหตุการณ์

จุดที่ควรสังเกตในไทม์ไลน์นี้คือ ช่องว่างระหว่างวันที่ถูกโจมตี (1 กรกฎาคม) กับวันที่เริ่มแจ้งเตือน (20 กรกฎาคม) ซึ่งห่างกันเกือบสามสัปดาห์ ขณะที่ฝ่ายโจมตีใช้เวลาเพียง 4 วันในการทำงานทั้งหมดจนจบ ความไม่สมมาตรของเวลานี้ คือแก่นของปัญหาที่ผู้กำหนดนโยบายต้องแก้ เพราะต่อให้กระบวนการตอบสนองของฝ่ายตั้งรับทำงานได้ถูกต้องตามขั้นตอน มันก็ยังช้ากว่าฝ่ายโจมตีหลายเท่าตัว

2.2 สถาปัตยกรรมฝูงเอเจนต์ — จากพื้นที่ทำงานสองชุด สู่เอเจนต์ A ถึง Q

หลักฐานในคลังไฟล์แสดงว่าผู้โจมตีจัดระเบียบงานไว้ใน พื้นที่ทำงาน (workspace) สองชุด คือ .hermes และ .openclaw ซึ่งตรงกับชื่อเฟรมเวิร์กเอเจนต์โอเพนซอร์สทั้งสองตัวที่นำมาประกอบกัน โดยแต่ละระลอกการโจมตีจะ ปล่อยเอเจนต์ย่อยที่ตั้งชื่อด้วยตัวอักษร (lettered sub-agents) สูงสุด 8 ตัวทำงานขนานกัน แบ่งส่งเป็น 3 ชุดต่อระลอก และตลอดทั้งปฏิบัติการพบเอเจนต์ตั้งแต่ Agent A ถึง Agent Q โดยเอเจนต์แต่ละตัวได้รับมอบหมาย เป้าหมายและเทคนิคที่แตกต่างกัน ไม่ใช่การทำซ้ำงานเดียวกันหลายรอบ

โครงสร้างเช่นนี้เทียบได้กับ ทีมทดสอบเจาะระบบ (red team) ที่แบ่งสายงานกันตามความถนัด โดยมีเอเจนต์ที่รับผิดชอบการสำรวจ เอเจนต์ที่ไล่นับ API เอเจนต์ที่โจมตีรหัสผ่าน เอเจนต์ที่ยืนยันช่องโหว่ เอเจนต์ที่เคลื่อนย้ายในแนวขวาง และเอเจนต์ที่มองหาช่องทางผ่านห่วงโซ่อุปทาน ความแตกต่างสำคัญจากทีมมนุษย์คือ ฝูงเอเจนต์ไม่ต้องนอน ไม่ต้องประชุม และขยายจำนวนได้ตามงบประมาณค่าประมวลผล

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

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

2.3 กลไกตัดสินใจ — เมื่อการโจมตีถูกจัดลำดับด้วยความน่าจะเป็นแบบเบย์

หัวใจที่ทำให้ปฏิบัติการนี้ต่างจากเครื่องมืออัตโนมัติทั่วไป อยู่ที่ ระบบให้คะแนนความน่าจะเป็นแบบเบย์ (Bayesian) สองชั้น ซึ่งฝูงเอเจนต์ใช้ตัดสินใจว่าจะทุ่มทรัพยากรไปทางไหน

ชั้นที่หนึ่ง — ให้คะแนนช่องโหว่รายจุด ทุกสิ่งที่ค้นพบจะเริ่มต้นด้วยความน่าจะเป็นตั้งต้น (prior) ที่ P = 0.50 แล้วปรับขึ้นลงตามน้ำหนักหลักฐานที่เรียกว่าอัตราส่วนภาวะน่าจะเป็น (Likelihood Ratio : LR) ดังนี้ ผลบวกจากการสแกนด้วยเครื่องมือมีน้ำหนัก 6.0 การยืนยันด้วยมือผ่านคำสั่ง curl มีน้ำหนักสูงสุดที่ 10.0 การประเมินผลกระทบที่เป็นบวกมีน้ำหนัก 3.0 ส่วนการพบว่ามีไฟร์วอลล์ระดับแอปพลิเคชัน (WAF) หรือข้อจำกัดอื่นขวางอยู่ จะลดน้ำหนักลงเหลือ 0.30

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

ชั้นที่สอง — ให้คะแนนห่วงโซ่การโจมตีทั้งสาย ด้วยสูตร P_success = P_chain × (1 − P_blocker) ตัวอย่างที่ชัดที่สุดคือห่วงโซ่การเคลื่อนย้ายผ่าน SSO ซึ่งระบบให้คะแนนไว้ที่ 0.99 (จากขั้นตอนที่ยืนยันแล้วครบ 3 จาก 3 ขั้น และประเมินโอกาสถูกสกัดไว้เพียง 0.01) และเมื่อลงมือจริง ผลลัพธ์ออกมาที่ร้อยละ 98.8 ซึ่งใกล้เคียงกับที่ประเมินไว้อย่างน่าตกใจ

นอกจากนี้ ฝูงเอเจนต์ยังมี “วงจรการเรียนรู้” (Learning Cycles) ที่ทำงานเอง 5 รอบ (v1 ถึง v5) โดยเมื่อเจอทางตัน ระบบจะสั่งให้เอเจนต์อีกตัวออกไปค้นฐานข้อมูลช่องโหว่ คลังโค้ดบน GitHub และบทความด้านความปลอดภัยบนอินเทอร์เน็ต เพื่อหาเทคนิคที่ใช้ได้กับเป้าหมายเฉพาะราย แล้วเขียนรายงานกลับมาโดยจัดหมวดตามความเกี่ยวข้อง ความพร้อมของโค้ดโจมตี โอกาสสำเร็จ และลำดับความสำคัญในการลงมือ

ที่สำคัญไม่แพ้กันคือ ความสามารถในการแก้ไขตัวเอง (self-correction) โดยระบบคัดผลบวกลวงทิ้งไปถึง 7 รายการ ตัวอย่างที่ชัดเจนคือกรณีที่ระบบสงสัยว่าพบช่องโหว่ SQL injection เพราะเซิร์ฟเวอร์ตอบช้าผิดปกติ 21 วินาที แต่เมื่อทดสอบซ้ำกลับพบว่าความล่าช้านั้นเกิดจากการหมดเวลาเชื่อมต่อของระบบส่งอีเมล (SMTP timeout) ไม่ใช่ช่องโหว่จริง และมีข้อค้นพบบางรายการที่ต้องผ่านการทดสอบซ้ำถึง 6 รอบ ก่อนที่ระบบจะยอมบันทึกว่าเป็นช่องโหว่ที่ยืนยันแล้ว

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

ภาพที่ 3: น้ำหนักหลักฐาน (Likelihood Ratio) ที่ฝูงเอเจนต์ใช้ปรับความน่าจะเป็นของช่องโหว่แต่ละจุด และเกณฑ์การตัดสินใจ 4 ระดับ ตั้งแต่ตัดทิ้งจนถึงยืนยันว่าโจมตีได้จริง

3. ยุทธวิธี เทคนิค และเครื่องมือ (TTPs)

ปฏิบัติการนี้แบ่งได้เป็น 6 เฟส โดยจุดที่ควรเน้นคือ แทบทุกเทคนิคที่ใช้ไม่ใช่เทคนิคใหม่ ทั้งหมดเป็นความผิดพลาดในการตั้งค่าที่วงการความมั่นคงปลอดภัยเตือนมาหลายปี สิ่งใหม่คือ ความเร็วและความต่อเนื่องในการร้อยเรียงความผิดพลาดเหล่านั้นเข้าด้วยกัน

3.1 เฟสที่ 1 — การสำรวจเชิงรับ: ถอดรื้อไฟล์จาวาสคริปต์เพื่ออ่านแผนผังระบบราชการ

จุดเริ่มต้นคือเว็บท่าของหน่วยงานรัฐที่พัฒนาด้วยเฟรมเวิร์ก Angular ซึ่งเป็นเทคโนโลยีที่ส่งโค้ดฝั่งผู้ใช้ (client-side) ไปประมวลผลบนเบราว์เซอร์ของผู้เข้าชม เอเจนต์จึงเพียง ดาวน์โหลดไฟล์จาวาสคริปต์ที่รวมไว้ (JavaScript bundle) แล้วถอดรื้อออกมาอ่าน ซึ่งไม่ถือเป็นการบุกรุกในทางเทคนิค เพราะเป็นไฟล์ที่เว็บส่งให้ผู้เข้าชมทุกคนอยู่แล้ว

สิ่งที่ได้จากขั้นตอนที่ไม่ผิดกฎหมายนี้กลับมหาศาล ได้แก่ รายชื่อ URL ปลายทาง จุดเชื่อมต่อ API รหัสลูกค้า OAuth (OAuth client ID) และค่าตั้งของระบบ Keycloak ซึ่งเป็นซอฟต์แวร์บริหารตัวตนและการเข้าถึงแบบโอเพนซอร์สที่หน่วยงานรัฐทั่วโลกนิยมใช้ ผลลัพธ์คือเอเจนต์สามารถวาด แผนผังของระบบราชการที่เชื่อมโยงกัน 21 ระบบ ได้ตั้งแต่ยังไม่ได้แตะระบบใดเลย

ที่ร้ายแรงกว่านั้นคือ เอเจนต์ได้ภาพ สถาปัตยกรรม SSO ระดับชาติทั้งชุด ประกอบด้วยขอบเขตย่อย (sub-realm) 6 ขอบเขต จุดเชื่อมต่อ OIDC ทั้งหมด และกุญแจลงลายมือชื่อ RSA 2 ดอก พร้อมกันนั้นยังพบ จุดเชื่อมต่อ API ที่ไม่ต้องพิสูจน์ตัวตนอย่างน้อย 36 จุด ซึ่งเปิดเผยข้อมูลบุคลากรนับพันรายการ โดยไม่ต้องล็อกอินแม้แต่น้อย

3.2 เฟสที่ 2 — เก็บเกี่ยวเอกสารนักพัฒนา และวิเคราะห์โค้ดด้วย LLM

เมื่อรู้ว่าระบบใช้เทคโนโลยีอะไร เอเจนต์จึงไปเก็บ เอกสารสำหรับนักพัฒนา (SDK documentation) ที่หน่วยงานเผยแพร่บนแพลตฟอร์ม GitBook โดยใช้ช่องทางที่ออกแบบมาเพื่อ AI โดยเฉพาะ คือไฟล์ดัชนี llms.txt และการดึงเนื้อหาดิบในรูปแบบ .md ซึ่งทำให้อ่านเอกสารทั้งชุดได้เร็วกว่าการไล่คลิกทีละหน้าอย่างมาก ผลคือได้ ตัวอย่างโค้ดสำหรับ Java Spring Boot และ ASP.NET Core 8.0 ที่หน่วยงานแจกให้ผู้พัฒนาระบบเชื่อมต่อ

จากนั้นเอเจนต์นำโค้ดตัวอย่างเหล่านั้นเข้าเครื่องมือวิเคราะห์โค้ดแบบสถิตที่ขับเคลื่อนด้วยโมเดลภาษาซึ่งผู้โจมตีตั้งชื่อว่า Local-LLM-SAST-0day และพบจุดอ่อนเชิงออกแบบสามประการ ได้แก่ การเปลี่ยนเส้นทางแบบเปิด (open redirect) ที่เปิดช่องให้ส่งผู้ใช้ไปเว็บปลอมได้ การปิดการป้องกัน CSRF ซึ่งเปิดช่องให้หลอกให้เบราว์เซอร์ผู้ใช้ส่งคำสั่งโดยไม่รู้ตัว และ การแลกเปลี่ยนโทเคนที่ไม่ต้องพิสูจน์ตัวตน (unauthenticated token exchange) ซึ่งเป็นจุดอ่อนที่นำไปสู่การปลอมตัวตนในเฟสถัดไป

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

3.3 เฟสที่ 3 — เข้าถึงครั้งแรก: ประตูหลังของนักพัฒนา รหัสผ่านที่เดาได้ และ CAPTCHA ที่ไม่ได้ป้องกันอะไร

เฟสนี้คือจุดที่ปฏิบัติการเปลี่ยนจากการสำรวจไปสู่การบุกรุกจริง ผ่านสามช่องทางที่ทำงานเสริมกัน

ช่องทางที่หนึ่ง — จุดเชื่อมต่อประตูหลังของนักพัฒนา เอเจนต์พบ จุดเชื่อมต่อ API ที่ซ่อนไว้ 3 จุด ซึ่งรับคำขอใด ๆ ก็ได้ แล้วคืนเซสชันที่ผ่านการพิสูจน์ตัวตนแล้วกลับมา จุดเชื่อมต่อลักษณะนี้มักถูกสร้างขึ้นระหว่างการพัฒนาเพื่อความสะดวกในการทดสอบ แล้วลืมถอดออกก่อนขึ้นระบบจริง

ช่องทางที่สอง — การพ่นรหัสผ่านที่เดาจากรหัสพนักงาน เอเจนต์ทดสอบรูปแบบรหัสผ่านที่คาดเดาได้ซึ่งสร้างจากรหัสประจำตัวพนักงานแต่ละคน และ ยึดบัญชีได้สำเร็จ 85 บัญชี โดยด่านที่ควรจะขวางการทดสอบรหัสผ่านจำนวนมากคือ CAPTCHA กลับถูกข้ามได้ด้วยเครื่องมืออ่านตัวอักษรจากภาพแบบโอเพนซอร์สชื่อ Tesseract OCR ซึ่งอ่านภาพ CAPTCHA ขนาดเล็กเหล่านั้นได้ถูกต้องร้อยเปอร์เซ็นต์

ช่องทางที่สาม — การปลอมโทเคนด้วยช่องโหว่ alg: none ระบบเป้าหมายยอมรับโทเคน JWT ที่ระบุอัลกอริทึมการลงลายมือชื่อเป็น “none” ซึ่งหมายความว่าเซิร์ฟเวอร์ยอมรับโทเคนโดยไม่ตรวจลายเซ็น ผู้โจมตีจึงสร้างโทเคนปลอมเป็นใครก็ได้โดยไม่ต้องรู้กุญแจลับ ช่องโหว่นี้เป็นข้อผิดพลาดที่ถูกเตือนในเอกสารมาตรฐานมาตั้งแต่ปี 2558 แต่ยังพบได้ในระบบภาครัฐทั่วโลกจนถึงปัจจุบัน

3.4 เฟสที่ 4 — การเคลื่อนย้ายในแนวขวาง: SSO ที่กลายเป็นทางด่วนของผู้บุกรุก

เมื่อได้รหัสผ่าน 85 ชุด เอเจนต์นำไปทดสอบกับระบบอื่น ๆ ที่เชื่อมกันผ่าน SSO และผลลัพธ์คือจุดที่น่าตกใจที่สุดของทั้งปฏิบัติการ คือ 84 จาก 85 บัญชี (ร้อยละ 98.8) สามารถเข้าสู่ระบบภายในอื่นได้ทันทีผ่านจุดเชื่อมต่อสะพาน SSO (SSO bridge endpoint)

ตัวเลขนี้เปิดเผยปัญหาเชิงออกแบบที่ลึกกว่าเรื่องรหัสผ่านอ่อน กล่าวคือ ระบบพิสูจน์ตัวตนรวมศูนย์ถูกออกแบบมาเพื่อความสะดวกของผู้ใช้ แต่ไม่ได้ออกแบบขอบเขตความเชื่อถือ (trust boundary) ระหว่างหน่วยงานไว้เลย ผลคือบัญชีของเจ้าหน้าที่ระดับปฏิบัติการในหน่วยงานหนึ่ง กลายเป็นกุญแจที่เปิดเข้าไปได้อีกหลายระบบข้ามหน่วยงาน ซึ่งขัดกับหลักการให้สิทธิ์เท่าที่จำเป็น (least privilege) โดยสิ้นเชิง

เอเจนต์ยังพยายามอัปโหลด เว็บเชลล์ (web shell) ซึ่งเป็นสคริปต์ที่ให้ผู้โจมตีสั่งงานเซิร์ฟเวอร์ผ่านหน้าเว็บ ผ่าน API รับไฟล์ที่ไม่จำกัดชนิดไฟล์ และอัปโหลดสำเร็จ แต่ การสั่งรันถูกสกัดไว้ได้ด้วยกลไก Forms Authentication ของเซิร์ฟเวอร์ ซึ่งเป็นหนึ่งในไม่กี่จุดของปฏิบัติการนี้ที่ฝ่ายตั้งรับ “รอด” และควรถูกบันทึกไว้ว่า การป้องกันเป็นชั้น (defense in depth) ยังทำงานได้จริง แม้ในสถานการณ์ที่ฝ่ายโจมตีมีความได้เปรียบเกือบทุกด้าน

3.5 เฟสที่ 5 — การนำข้อมูลออก

ข้อมูลที่ถูกนำออกจากระบบมีดังนี้ ประวัติบุคลากรมากกว่า 2,564 รายการ ซึ่งแยกที่มาได้เป็น 1,409 รายการจากการเข้าถึงแบบผ่านการพิสูจน์ตัวตน 916 รายการจาก API ที่ไม่ต้องพิสูจน์ตัวตน และอีก 239 รายการจากจุดเชื่อมต่อของกระทรวงยุติธรรม นอกจากนี้ยังได้ ฐานข้อมูลผู้ใช้ทั้งชุด กุญแจลับของแอปพลิเคชันที่เชื่อมกับ SSO 7 ชุด ข้อมูลรับรองการเข้าถึงฐานข้อมูลภายใน 6 ชุด (ครอบคลุมทั้ง MSSQL, Oracle และ Sybase) รวมถึง ผังช่วงหมายเลขไอพีภายในองค์กร

ในเชิงข่าวกรอง ข้อมูลชุดนี้มีค่ามากกว่าตัวเลขจำนวนระเบียนที่ปรากฏ เพราะ ประวัติบุคลากรของหน่วยงานรัฐคือวัตถุดิบชั้นดีสำหรับปฏิบัติการรอบถัดไป ทั้งการทำฟิชชิงแบบเจาะจงตัวบุคคล การสวมตัวตนเจ้าหน้าที่ และการคัดเลือกเป้าหมายที่มีสิทธิ์เข้าถึงระบบสำคัญ ส่วนกุญแจลับของ SSO และข้อมูลรับรองฐานข้อมูล คือ ใบเบิกทางสำหรับกลับเข้ามาใหม่แม้จะเปลี่ยนรหัสผ่านผู้ใช้ทั้งหมดแล้วก็ตาม

3.6 เฟสที่ 6 — ขยายผลผ่านห่วงโซ่อุปทานสู่โครงสร้างพื้นฐานสำคัญ

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

ทิศทางการขยายผลนี้บอกเจตนาได้ชัดเจน เพราะหากเป้าหมายเป็นเพียงข้อมูลส่วนบุคคลเพื่อขายต่อ ผู้โจมตีย่อมหยุดที่ฐานข้อมูลบุคลากร การเดินหน้าต่อไปยัง หน่วยงานกำกับนิวเคลียร์และบริษัทพลังงาน สะท้อนความสนใจในโครงสร้างพื้นฐานสำคัญ ซึ่งเป็นรูปแบบพฤติกรรมของ ปฏิบัติการเตรียมสนามรบ (operational preparation of the environment) มากกว่าอาชญากรรมไซเบอร์เพื่อผลกำไร

3.7 การหลบเลี่ยงมาตรการกำกับของโมเดล AI

จุดที่ควรถูกอ่านซ้ำโดยผู้กำหนดนโยบายคือวิธีที่ผู้โจมตีข้ามมาตรการความปลอดภัยของโมเดล ตามที่ Dream ระบุไว้ว่า “มาตรการกำกับความปลอดภัยของเฟรมเวิร์กเอง ซึ่งก็คือการที่โมเดลปฏิเสธคำสั่ง ถูกข้ามด้วยการกำหนดกรอบให้กิจกรรมทั้งหมดเป็น ‘การทดสอบเจาะระบบที่ได้รับอนุญาต’”

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

4. ผลกระทบและความเสี่ยงต่อประเทศไทยโดยตรง

4.1 เส้นเชื่อมที่ปฏิเสธไม่ได้ — Hermes ตัวเดียวกันเคยเข้ามาที่กระทรวงการคลังไทยแล้ว

ประเด็นที่ทำให้รายงานฉบับนี้ไม่ใช่ “ข่าวต่างประเทศ” คือ เฟรมเวิร์กเอเจนต์ Hermes ซึ่งเป็นครึ่งหนึ่งของระบบที่ใช้เจาะไต้หวัน คือเครื่องมือตัวเดียวกับที่ปรากฏในปฏิบัติการเจาะเครือข่าย กระทรวงการคลังของประเทศไทย ซึ่งบริษัท Hunt.io และนาย Bob Diachenko เปิดโปงจาก open directory บนเซิร์ฟเวอร์เตรียมการในฮ่องกง ระหว่างวันที่ 9–13 กรกฎาคม 2569 — ห่างจากปฏิบัติการไต้หวัน (1–4 กรกฎาคม) เพียงห้าวัน

เมื่อวางสองเหตุการณ์เรียงกัน จะเห็นพัฒนาการที่ชัดเจนของวิธีใช้เอเจนต์ AI ในงานจารกรรม

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

4.2 พื้นผิวความเสี่ยงของภาครัฐไทย — ช่องโหว่ทั้ง 6 ชนิดที่ถูกใช้ ล้วนพบได้ในระบบราชการไทย

หากนำรายการจุดอ่อนที่ฝูงเอเจนต์ใช้เจาะไต้หวันมาเทียบกับสภาพระบบราชการไทย จะพบว่าแทบทุกข้อเป็นรูปแบบที่พบซ้ำ ๆ ในการตรวจประเมินระบบภาครัฐไทย

หนึ่ง โค้ดฝั่งผู้ใช้ที่เปิดเผยแผนผังระบบภายใน ระบบราชการไทยจำนวนมากพัฒนาด้วยเฟรมเวิร์กสมัยใหม่ (Angular, React, Vue) และมักฝังรายการ API ปลายทาง ชื่อโฮสต์ภายใน และค่าตั้งของระบบพิสูจน์ตัวตนไว้ในไฟล์ที่ส่งถึงเบราว์เซอร์ผู้ใช้ทุกคน

สอง API ที่ไม่ต้องพิสูจน์ตัวตน การเปิด API ให้บริการโดยไม่ตรวจสิทธิ์ เพราะคิดว่า “ไม่มีใครรู้ URL” เป็นรูปแบบที่พบบ่อยในระบบบริการประชาชนของไทย และเป็นสาเหตุของเหตุข้อมูลรั่วไหลหลายกรณีในช่วงสามปีที่ผ่านมา

สาม จุดเชื่อมต่อสำหรับทดสอบที่ลืมถอด ระบบที่พัฒนาโดยผู้รับจ้างภายนอกและส่งมอบตามกำหนดเวลาที่กระชั้น มักหลงเหลือ endpoint สำหรับทดสอบไว้ในระบบจริง

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

ห้า CAPTCHA เป็นด่านเดียวที่กันการทดสอบรหัสผ่านจำนวนมาก ระบบไทยหลายระบบใช้ CAPTCHA แบบภาพตัวอักษรที่สร้างเองแทนการจำกัดอัตราการเรียก (rate limiting) หรือการล็อกบัญชี ซึ่งกรณีนี้พิสูจน์แล้วว่า Tesseract OCR อ่านได้ถูกต้องร้อยเปอร์เซ็นต์

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

ภาพที่ 4: การประเมินของ Cloud Thunder ว่าจุดอ่อนแต่ละชนิดที่ฝูงเอเจนต์ใช้เจาะระบบไต้หวัน มีโอกาสพบและมีผลกระทบเพียงใดในบริบทของหน่วยงานภาครัฐไทย (คะแนน 1–5 เป็นการประเมินเชิงคุณภาพจากรูปแบบที่พบซ้ำในเหตุการณ์และการตรวจประเมินที่ผ่านมา ไม่ใช่ผลสำรวจเชิงสถิติ)

4.3 ภาคส่วนของไทยที่มีความเสี่ยงสูงและเหตุผลเชิงยุทธศาสตร์

จากทิศทางการขยายผลของปฏิบัติการไต้หวัน ภาคส่วนของไทยที่ควรถูกจัดลำดับความสำคัญสูงสุดมีดังนี้

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

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

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

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

ระบบไปรษณีย์อิเล็กทรอนิกส์ของภาครัฐ เป็นทั้งเป้าหมายและเครื่องมือ เพราะบัญชีเมลราชการที่ถูกยึดสามารถใช้ส่งฟิชชิงที่น่าเชื่อถืออย่างยิ่งไปยังหน่วยงานอื่นและไปยังภาคเอกชนคู่สัญญาได้ต่อ

5. การประเมินเชิงยุทธศาสตร์ต่อความมั่นคงของชาติ

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

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

ประการที่สาม จุดแตกหักอยู่ที่การตั้งค่า ไม่ใช่ที่เทคโนโลยีล้ำสมัย ไม่มี zero-day ไม่มีมัลแวร์ที่พัฒนาขึ้นเฉพาะ สิ่งที่ทำให้ปฏิบัติการสำเร็จคือ endpoint ทดสอบที่ลืมถอด API ที่ไม่ตรวจสิทธิ์ รหัสผ่านที่เดาได้ โทเคนที่ไม่ตรวจลายเซ็น และ SSO ที่ไม่มีขอบเขตความเชื่อถือ ข่าวดีคือทั้งหมดนี้แก้ได้ด้วยงานพื้นฐานที่ไม่ต้องใช้เทคโนโลยีราคาแพง ข่าวร้ายคือมันเป็นงานที่ถูกเลื่อนออกไปเสมอเพราะไม่มีใครเห็นผลลัพธ์

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

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

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

6. ข้อเสนอเชิงยุทธศาสตร์และแนวทางรับมือ

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

6.1 การดำเนินการเร่งด่วน (0–30 วัน)

ตรวจสอบจุดเชื่อมต่อ API ทั้งหมดที่เปิดสู่อินเทอร์เน็ต โดยเฉพาะการค้นหา endpoint ที่ไม่ต้องพิสูจน์ตัวตนและ endpoint ที่หลงเหลือจากการพัฒนา วิธีที่ตรงที่สุดคือทำแบบเดียวกับที่ผู้โจมตีทำ คือดาวน์โหลดไฟล์จาวาสคริปต์ของเว็บท่าของตนเอง ถอดรื้อออกมาอ่าน แล้วไล่ทดสอบทุก endpoint ที่พบว่าต้องใช้สิทธิ์จริงหรือไม่

ตรวจการตั้งค่า JWT และระบบพิสูจน์ตัวตนทันที ต้องยืนยันว่าเซิร์ฟเวอร์ปฏิเสธโทเคนที่ระบุอัลกอริทึมเป็น none และปฏิเสธโทเคนที่ลายเซ็นไม่ถูกต้องในทุกกรณี รวมถึงตรวจสอบว่าไม่มีการยอมรับโทเคนที่ออกโดยขอบเขต (realm) อื่นข้ามหน่วยงานโดยไม่ตั้งใจ

บังคับเปลี่ยนรหัสผ่านที่สร้างจากรหัสประจำตัว และตรวจหาบัญชีที่ยังใช้รหัสผ่านตามรูปแบบมาตรฐานขององค์กร พร้อมบังคับใช้การพิสูจน์ตัวตนหลายปัจจัย (MFA) กับบัญชีที่เข้าถึงระบบผ่าน SSO ได้หลายระบบเป็นลำดับแรก

เพิ่มการจำกัดอัตราการเรียกและการล็อกบัญชี โดยไม่พึ่ง CAPTCHA เป็นด่านเดียว เนื่องจากกรณีนี้ยืนยันแล้วว่า CAPTCHA แบบภาพตัวอักษรถูกอ่านด้วย OCR ได้ครบถ้วน

ตั้งกฎเฝ้าระวังสำหรับพฤติกรรมความเร็วระดับเครื่องจักร ได้แก่ การเรียก API จำนวนมากจากต้นทางเดียวในเวลาสั้น การทดสอบเข้าสู่ระบบด้วยบัญชีจำนวนมากในช่วงเวลาแคบ การเรียกซ้ำแบบมีระบบต่อ endpoint เดิมหลายรอบ (พฤติกรรมการตรวจสอบซ้ำของเอเจนต์) และการดาวน์โหลดเอกสารนักพัฒนาทั้งชุดผ่าน llms.txt หรือ .md ดิบ

6.2 การปรับปรุงเชิงกระบวนการ (1–3 เดือน)

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

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

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

ทบทวนสิ่งที่หน่วยงานเผยแพร่ต่อสาธารณะในฐานะ “พื้นผิวข่าวกรอง” โดยเฉพาะเอกสารนักพัฒนา ตัวอย่างโค้ด และไฟล์ดัชนีที่ออกแบบมาให้ AI อ่าน ซึ่งควรประเมินว่าข้อมูลระดับใดจำเป็นต้องเปิดสาธารณะ และข้อมูลระดับใดควรอยู่หลังการลงทะเบียน

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

6.3 การเตรียมการเชิงยุทธศาสตร์ (3–12 เดือน)

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

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

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

พัฒนากลไกแบ่งปันข่าวกรองภัยคุกคามที่เร็วพอ ระหว่างหน่วยงานกำกับด้านไซเบอร์ หน่วยรับมือเหตุฉุกเฉิน องค์กรโครงสร้างพื้นฐานสำคัญ และภาคเอกชน โดยเน้นการส่งต่อตัวบ่งชี้เชิงพฤติกรรมได้ภายในหลักชั่วโมง ไม่ใช่หลักสัปดาห์

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

7. บทสรุปและมุมมองไปข้างหน้า (Outlook)

เหตุการณ์ที่ไต้หวันระหว่างวันที่ 1–4 กรกฎาคม 2569 ไม่ใช่การสาธิตว่า AI เก่งขึ้นเพียงใด แต่เป็นการสาธิตว่า ความผิดพลาดพื้นฐานในการตั้งค่าระบบ ซึ่งวงการเตือนกันมาสิบปี จะมีราคาแพงเพียงใดเมื่อมีเครื่องมือที่ค้นหาและร้อยเรียงมันเข้าด้วยกันได้ตลอดเวลาโดยไม่เหนื่อย ผู้โจมตีไม่ได้ใช้ zero-day ไม่ได้ใช้มัลแวร์ที่พัฒนาขึ้นเฉพาะ และไม่ได้ใช้งบประมาณระดับรัฐไปกับเครื่องมือ สิ่งที่ใช้คือซอฟต์แวร์ฟรี ความอดทนระดับเครื่องจักร และความบกพร่องที่ฝ่ายตั้งรับทิ้งไว้

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

มุมมองไปข้างหน้า Cloud Thunder ประเมินว่าในช่วง 6–12 เดือนข้างหน้า จะเห็นพัฒนาการสามทิศทาง ทิศทางแรก จำนวนปฏิบัติการที่ใช้เอเจนต์ AI เป็นแกนกลางจะเพิ่มขึ้นอย่างมีนัยสำคัญในภูมิภาคเอเชียตะวันออกเฉียงใต้ เนื่องจากเครื่องมือเป็นโอเพนซอร์สและวิธีการถูกเปิดเผยต่อสาธารณะแล้ว ทิศทางที่สอง เป้าหมายจะเลื่อนจากหน่วยงานรัฐโดยตรงไปสู่ผู้ให้บริการเทคโนโลยีและผู้รับจ้างของภาครัฐมากขึ้น เพราะให้ผลตอบแทนสูงกว่าต่อความพยายามหนึ่งครั้ง ทิศทางที่สาม ฝ่ายตั้งรับที่ยังพึ่งการวิเคราะห์ด้วยมนุษย์ล้วนจะเสียเปรียบมากขึ้นเรื่อย ๆ และการลงทุนในการตรวจจับที่ทำงานอัตโนมัติในระดับที่ปลอดภัยจะเปลี่ยนจากทางเลือกเป็นความจำเป็น

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

ภาคผนวก ก: การจับคู่กับกรอบ MITRE ATT&CK

ภาคผนวก ข: ตัวบ่งชี้และแนวทางการไล่ล่าภัยคุกคาม (Hunting Guidance)

รายงานต้นทางของ Dream ไม่ได้เผยแพร่รายการตัวบ่งชี้การถูกโจมตี (IoC) ในรูปแบบไอพี โดเมน หรือค่าแฮชไฟล์ เนื่องจากลักษณะของปฏิบัติการนี้ไม่ได้อาศัยมัลแวร์เฉพาะทาง ดังนั้นการตรวจจับจึงต้องอาศัย ตัวบ่งชี้เชิงพฤติกรรม เป็นหลัก ดังนี้

ข.1 ตัวบ่งชี้เชิงพฤติกรรมบนระบบเว็บและ API

• การเรียกไฟล์จาวาสคริปต์ที่รวมไว้ (bundle) ทั้งชุดจากต้นทางเดียวในเวลาสั้น ตามด้วยการเรียก API endpoint จำนวนมากที่ไม่เคยถูกเรียกจากผู้ใช้ทั่วไป
• การไล่เรียก endpoint แบบเป็นระบบตามลำดับตัวอักษรหรือตามโครงสร้างที่ปรากฏในเอกสาร SDK
• การเรียกไฟล์ llms.txt หรือการดึงเนื้อหา .md ดิบจากพื้นที่เอกสารนักพัฒนาเป็นจำนวนมาก
• คำขอที่ส่งโทเคน JWT ซึ่งระบุอัลกอริทึมเป็น none หรือมีลายเซ็นว่าง (ควรตั้งเป็นการแจ้งเตือนระดับสูงเสมอ เพราะไม่มีการใช้งานปกติใดที่ชอบธรรม)
• การเรียกซ้ำต่อ endpoint เดิมหลายรอบในลักษณะการตรวจสอบยืนยัน (พฤติกรรม self-correction ของเอเจนต์) ซึ่งมักถูกระบบเฝ้าระวังลดระดับความสำคัญโดยอัตโนมัติเพราะดูเหมือนการทดสอบที่ล้มเหลว

ข.2 ตัวบ่งชี้บนระบบพิสูจน์ตัวตน

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

ข.3 ตัวบ่งชี้ด้านการนำข้อมูลออกและการคงอยู่

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

ข.4 คำแนะนำเชิงเทคนิคสำหรับทีมเฝ้าระวัง

ควรทบทวนกฎการลดระดับความสำคัญของเหตุการณ์ (alert suppression) ที่ใช้อยู่ เพราะพฤติกรรมของฝูงเอเจนต์ — การทดสอบซ้ำหลายรอบ การล้มเหลวจำนวนมากก่อนสำเร็จ และการกระจายคำขอไปหลาย endpoint — ตรงกับรูปแบบที่ระบบเฝ้าระวังจำนวนมากถูกตั้งค่าให้ “กรองทิ้ง” ในฐานะสัญญาณรบกวน การปรับกฎให้มองความสัมพันธ์ระหว่างเหตุการณ์ที่ต้นทางเดียวกันข้ามช่วงเวลา จะให้ผลดีกว่าการดูเหตุการณ์รายครั้ง

แหล่งอ้างอิง

1. Dream — “Inside a Multi-Agent AI Framework Used to Compromise Government Entities in Asia” (รายงานต้นทาง) · https://www.dreamgroup.com/blog/inside-a-multi-agent-ai-framework-used-to-compromise-government-entities-in-asia
2. Financial Times — รายงานเปิดเผยปฏิบัติการครั้งแรก, 12 สิงหาคม 2569
3. CyberScoop — “Researchers observe first ’near-autonomous’ AI attack on government target in Taiwan” · https://cyberscoop.com/near-autonomous-ai-attack-government-target-taiwan/
4. Cyber Security News — “China-linked Hackers Using AI Agents to Attack Taiwan Government Websites” · https://cybersecuritynews.com/chinese-hackers-target-taiwan-using-ai/
5. GBHackers — “China-Linked Hackers Use Autonomous AI Agents to Breach Taiwan Government Systems” · https://gbhackers.com/china-linked-hackers-breach-taiwan-government-systems/
6. Security Affairs — “China-Linked Hackers Use AI Agents in Autonomous Attack on Taiwan” · https://securityaffairs.com/197079/apt/china-linked-hackers-use-ai-agents-in-autonomous-attack-on-taiwan.html
7. Taipei Times — “AI-driven hacking campaign targets Taiwan government agencies”, 13 สิงหาคม 2569 · https://www.taipeitimes.com/News/front/archives/2026/08/13/2003862438
8. Taipei Times — “Taiwan targeted in AI-driven hacking campaign” (แถลงของ MODA), 14 สิงหาคม 2569 · https://www.taipeitimes.com/News/front/archives/2026/08/14/2003862463
9. TechRadar Pro — “World-first autonomous ’end-to-end’ AI attack against Taiwan tied to Chinese hackers” · https://www.techradar.com/pro/security/world-first-autonomous-end-to-end-ai-attack-against-taiwan-tied-to-chinese-hackers-and-the-scariest-part-is-that-it-was-fully-open-source
10. Cloud Thunder — “บทวิเคราะห์เชิงลึก: เอเจนต์ AI Hermes โหมด YOLO เจาะกระทรวงการคลังไทย และ implant Hades”, 27 กรกฎาคม 2569 · /reports/analysis/2026/07/hermes-ai-agent-mof-thailand/
11. Cloud Thunder — “บทวิเคราะห์เชิงลึก: Mustang Panda กับภัยจารกรรมไซเบอร์ต่อความมั่นคงของประเทศไทย”, 17 กรกฎาคม 2569 · /reports/analysis/2026/07/mustang-panda-thailand/