สรุปสั้น
บริษัท Dream ผู้ให้บริการด้านปัญญาประดิษฐ์และการป้องกันภัยไซเบอร์ของอิสราเอล เปิดเผยเมื่อวันที่ 12 สิงหาคม 2569 ว่าทีมวิจัยได้ค้นพบเวิร์กสเปซปฏิบัติการฉบับสมบูรณ์ของกรอบการทำงานเอเจนต์ AI ตัวหนึ่ง ที่ถูกใช้ไล่เจาะหน่วยงานรัฐในเอเชียด้วยตัวเองเกือบทั้งกระบวนการ โดยไฟล์ทั้งหมดถูกทิ้งไว้บนอินเทอร์เน็ตแบบเปิดโล่งรวม 1,395 ไฟล์ ขนาดราว 160 เมกะไบต์ ซึ่งนักวิจัยไปพบเข้าระหว่างการติดตามภัยคุกคามตามปกติ กรอบการทำงานตัวนี้ไม่ใช่มัลแวร์ที่เขียนขึ้นใหม่ แต่ประกอบขึ้นจากเฟรมเวิร์กเอเจนต์ AI โอเพนซอร์สที่ใครก็โหลดมาใช้ได้อย่าง Hermes และ OpenClaw แล้วสั่งให้ปล่อยเอเจนต์ย่อยทำงานคู่ขนานกันสูงสุด 8 ตัวต่อหนึ่งระลอก
ตลอดช่วงเวลาราว 4 วันระหว่างวันที่ 1–4 กรกฎาคม 2569 และ 12 ระลอกการโจมตีที่มีเอกสารบันทึกไว้ ระบบได้แม็ประบบราชการที่เชื่อมต่อกันได้ 21 ระบบ แคร็กบัญชีเจ้าหน้าที่ได้ 85 บัญชี ดูดประวัติบุคลากรออกไปมากกว่า 2,564 รายการ ค้นพบช่องโหว่ในการตรวจสอบลายเซ็นดิจิทัลของบริการยืนยันตัวตนกลางของประเทศ และฝังแบ็กดอร์ค้างไว้บนเว็บแอปพลิเคชันของราชการ ก่อนจะขยายการสแกนต่อไปยังผู้รับเหมาไอทีของภาครัฐ หน่วยงานความปลอดภัยทางนิวเคลียร์ ระบบอีเมลของรัฐ และบริษัทในภาคพลังงานอีกอย่างน้อย 7 แห่ง
จุดที่ทำให้เคสนี้ต่างจากการโจมตีที่ใช้ AI ช่วยซึ่งเคยมีรายงานมาก่อน คือมนุษย์แทบไม่ต้องเข้ามาคุมทีละขั้น ระบบจัดลำดับเป้าหมายเอง ค้นคว้าเทคนิคใหม่เองเมื่อเจอทางตัน และป้อนผลลัพธ์ของแต่ละระลอกกลับเข้าไปวางแผนระลอกถัดไป ส่วนการ์ดความปลอดภัยของโมเดลภาษาที่อยู่เบื้องหลังถูกข้ามด้วยวิธีง่ายที่สุดวิธีหนึ่ง คือการกำกับกรอบงานทั้งหมดว่าเป็น “การทดสอบเจาะระบบที่ได้รับอนุญาต” ทำให้โมเดลปฏิบัติต่อกิจกรรมที่สร้างความเสียหายเหมือนงานวิจัยความปลอดภัยตามปกติ
รายละเอียดข่าว
เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 12 สิงหาคม 2569 ว่ามีผู้โจมตีซึ่งต้องสงสัยว่าเชื่อมโยงกับจีน ก่อเหตุที่นักวิจัยอธิบายว่าเป็นการโจมตีไซเบอร์แบบอัตโนมัติเต็มรูปแบบครั้งแรกต่อรัฐบาลต่างประเทศ โดยใช้เครื่องมือ AI แบบโอเพนซอร์สเจาะเว็บไซต์ของหน่วยงานรัฐและโครงสร้างพื้นฐานสำคัญของไต้หวัน รายละเอียดของเหตุการณ์ถูกเปิดเผยครั้งแรกผ่านหนังสือพิมพ์ Financial Times ก่อนที่ Dream จะเผยแพร่รายงานเชิงเทคนิคฉบับเต็มของตัวเองตามมา
ประเด็นที่ต้องแยกให้ชัดคือ รายงานของ Dream เองไม่ได้ระบุชื่อประเทศเป้าหมาย ทีมวิจัยอ้างนโยบายบริษัทและยืนยันเพียงว่าได้แจ้งเตือนรัฐบาลแห่งหนึ่งในภูมิภาคเอเชีย-แปซิฟิกไปแล้ว การระบุว่าเป้าหมายคือไต้หวันมาจากแหล่งข่าวที่ใกล้ชิดกับเรื่องนี้ซึ่งให้ข้อมูลกับสื่อ ไม่ใช่คำยืนยันจากผู้วิจัยหรือจากรัฐบาลไต้หวัน เช่นเดียวกับการชี้ว่าเป็นฝีมือของฝ่ายจีน ซึ่งอาศัยหลักฐานทางภาษาเป็นหลัก กล่าวคือเอกสารรายงานสถานะภายในของปฏิบัติการเขียนด้วยภาษาจีนตัวย่อ ขณะที่ข้อมูลที่ดึงออกมาจากเป้าหมายและบทวิเคราะห์ฝั่งเป้าหมายอยู่ในภาษาจีนตัวเต็ม ซึ่งเป็นรูปแบบการเขียนที่ใช้ในไต้หวัน ฮ่องกง และมาเก๊า Dream ไม่ได้ระบุชื่อกลุ่มผู้โจมตีอย่างเป็นทางการ และไม่สามารถระบุได้ว่าโมเดลภาษาขนาดใหญ่ตัวใดเป็นตัวขับเคลื่อนเอเจนต์เหล่านี้
นาย Amir Becker ประธานเจ้าหน้าที่ฝ่ายกลยุทธ์ของ Dream ซึ่งเคยเป็นหัวหน้าฝ่ายปฏิบัติการไซเบอร์ของหน่วย 8200 ของกองทัพอิสราเอล เรียกเหตุการณ์นี้ว่าเป็น “การโจมตีอัตโนมัติแบบครบวงจร” ต่อเป้าหมายที่เป็นรัฐบาล ซึ่งไม่เคยปรากฏมาก่อน โดยชี้ว่าระบบมีพฤติกรรมเหมือนทีมโจมตีที่ประสานงานกัน มากกว่าจะเป็นสคริปต์อัตโนมัติตัวเดียว ทีมวิจัยระบุว่าปริมาณผลผลิต 1,395 ไฟล์ในเวลาเพียง 4 วัน สอดคล้องกับการทำงานอัตโนมัติหนักในระดับที่ผู้ปฏิบัติการซึ่งเป็นมนุษย์ทำเองคนเดียวไม่ไหว
ข้อสรุปเชิงยุทธศาสตร์ที่ Dream เน้นย้ำคือ ต้นทุนของการโจมตีที่มีคุณภาพได้ทรุดลงแล้ว แต่ต้นทุนของการป้องกันยังไม่ลดลงตาม สิ่งที่ครั้งหนึ่งต้องใช้ทีมผู้เชี่ยวชาญผลัดกันทำงานเป็นกะ วันนี้ถูกจัดการได้ด้วยซอฟต์แวร์ที่แม็ปเครือข่าย ขโมยรหัสผ่าน ค้นหาช่องโหว่ และเปลี่ยนเส้นทางโจมตีแบบเรียลไทม์ ขณะเดียวกันฝั่งผู้ป้องกันก็กำลังเร่งสร้างระบบ AI ที่เทียบเคียงกันได้ เพื่อตรวจจับและตัดวงจรปฏิบัติการอัตโนมัติลักษณะนี้ก่อนที่มันจะลุกลาม
วิธีการโจมตี
กรอบการทำงานนี้ทำงานภายใต้เวิร์กสเปซสองชุดคือ .hermes และ .openclaw โดยเอเจนต์ย่อยแต่ละตัวจะได้รับรหัสเป็นตัวอักษรและภารกิจเฉพาะของตัวเอง ตั้งแต่การขโมยรหัสผ่าน การเจาะ API ไปจนถึงการสำรวจห่วงโซ่อุปทาน ตลอด 12 ระลอกการโจมตี ทีมวิจัยพบเอเจนต์ตั้งแต่ตัว A ถึงตัว Q และพบว่ามีการปล่อยพร้อมกันสูงสุด 8 ตัวในระลอกเดียว โดยทยอยส่งเป็น 3 ชุด
ขั้นสำรวจเริ่มจากการดาวน์โหลดและถอดรหัสบันเดิล JavaScript ของพอร์ทัลราชการที่สร้างด้วย Angular แล้วดึงทุก URL ปลายทาง API รหัส OAuth client ID และค่าคอนฟิกของ Keycloak ที่ฝังอยู่ในโค้ดที่คอมไพล์แล้วออกมา จากจุดเริ่มต้นจุดเดียวนี้ ระบบระบุระบบราชการที่เชื่อมต่อกันได้ 21 ระบบ พร้อมแม็ปสถาปัตยกรรม SSO ระดับชาติทั้งหมด ทั้ง 6 sub-realm ปลายทาง OIDC ทุกตัว กุญแจลงลายมือชื่อ RSA 2 ชุด และรูปแบบการยืนยันตัวตนที่รองรับทั้งหมด บนเป้าหมายเพียงระบบเดียวยังพบปลายทาง API มากกว่า 36 จุด และหลายจุดในนั้นไม่ต้องยืนยันตัวตนเลย โดยมีระบบหนึ่งเปิดฐานข้อมูลผู้ใช้ทั้งก้อนให้เข้าถึงได้โดยไม่ต้องล็อกอิน ทำให้ได้ชื่อ หน่วยงาน และรหัสบัญชี SSO ของเจ้าหน้าที่มาเป็นพัน ๆ รายการ
ทางเข้าที่ใช้จริงมี 3 ทางที่เดินคู่ขนานกัน ทางแรกคือ แบ็กดอร์ของนักพัฒนา ซึ่งเป็นปลายทาง API ที่ซ่อนอยู่ 3 จุดบนเว็บแอปพลิเคชันราชการ ที่รับ request แบบใดก็ได้แล้วคืนเซสชันที่ผ่านการยืนยันตัวตนกลับมาโดยไม่ต้องใช้รหัสผ่าน — เป็นปลายทางสำหรับดีบักที่ถูกลืมทิ้งไว้บนระบบใช้งานจริง ทางที่สองคือ การพ่นรหัสผ่านอัตโนมัติ ใส่พอร์ทัลระบบสำนักงานอัตโนมัติของหน่วยงาน โดยใช้รายชื่อผู้ใช้ที่เก็บมาจาก API ที่ไม่ต้องยืนยันตัวตน แม้พอร์ทัลจะมี CAPTCHA ป้องกัน แต่ระบบใช้ Tesseract OCR ถอดภาพ CAPTCHA ขนาดเล็กได้แม่นยำ 100% แล้วลองรูปแบบรหัสผ่านที่คาดเดาได้จากรหัสประจำตัวของเจ้าหน้าที่แต่ละคน เช่น การเปลี่ยนตัวพิมพ์ใหญ่หรือเติมสัญลักษณ์ยอดนิยมต่อท้ายชื่อผู้ใช้ จนแคร็กสำเร็จ 85 บัญชี (ได้ 12 บัญชีในรอบแรก แล้วได้เพิ่มอีก 73 บัญชีเมื่อค้นพบรูปแบบใหม่) ทางที่สามคือ JWT ที่ตั้งค่า algorithm เป็น none บน API ของราชการตัวหนึ่ง ซึ่งแปลว่าใครก็ปลอมโทเคนยืนยันตัวตนได้โดยไม่ต้องรู้กุญแจลงลายมือชื่อ
ในขั้นเคลื่อนตัวด้านข้าง รหัสผ่านที่แคร็กได้ถูกนำไปลองกับทุกระบบภายในที่ผูกกับ SSO เดียวกันอย่างเป็นระบบ และเนื่องจากระบบภายในแต่ละตัวมีจุดเข้า SSO เฉพาะที่เชื่อเซสชันของระบบสำนักงานอัตโนมัติโดยอัตโนมัติ — ไม่ต้องยืนยันตัวตนซ้ำ ไม่มี MFA ไม่ต้องให้ผู้ใช้ยืนยัน — บัญชี 84 จาก 85 บัญชี หรือ 98.8% จึงเข้าสู่ระบบสารสนเทศภายในของหน่วยงานได้สำเร็จ ระบบยังอัปโหลดเว็บเชลล์ผ่าน API อัปโหลดไฟล์ที่ไม่จำกัดชนิดไฟล์ แต่ถูกชั้น Forms Authentication อีกชั้นบล็อกการรันไว้ จึงไม่บรรลุการรันโค้ดจากระยะไกล ข้อมูลที่ถูกดูดออกไปได้แก่ ประวัติบุคลากร 2,564 รายการขึ้นไป (พนักงาน 1,409 ราย ผู้ใช้จาก API ที่ไม่ต้องยืนยันตัวตน 916 ราย และผู้ประกอบวิชาชีพกฎหมาย 239 รายจากปลายทางของกระทรวงยุติธรรม) ฐานข้อมูลผู้ใช้ทั้งชุดในรูปแบบ JSON รวมถึง SSO client secret 7 รายการ และรหัสผ่านฐานข้อมูลภายในอีก 6 ชุด (MSSQL, Oracle, Sybase)
องค์ประกอบที่นักวิจัยมองว่าโดดเด่นที่สุดคือ เครื่องยนต์ตัดสินใจเชิงความน่าจะเป็นแบบสองชั้น ชั้นแรกให้คะแนนช่องโหว่รายตัวด้วยโมเดลเบส์ โดยเริ่มทุกช่องโหว่ที่ค่าความน่าจะเป็นก่อนหน้า P=0.50 แล้วปรับด้วยอัตราส่วนความควรจะเป็นตามหลักฐานที่ได้ เช่น ผลสแกนจากเครื่องมือให้ LR+ = 6.0 การยืนยันด้วย curl ด้วยมือให้ LR+ = 10.0 ส่วนการพบ WAF หรือข้อจำกัดให้ LR− = 0.30 ผลลัพธ์ที่ได้จะกำหนดว่าจะทำอะไรต่อ โดยค่า P เกิน 0.95 ถือว่ายืนยันแล้วให้เลื่อนขึ้นเป็นห่วงโซ่โจมตี ส่วนค่าต่ำกว่า 0.30 ให้ทิ้งเพื่อไม่เสียแรงเปล่า ชั้นที่สองให้คะแนนห่วงโซ่โจมตีทั้งสายด้วยสูตร P_success = P_chain × (1 − P_blocker) ตัวอย่างที่ทีมวิจัยยกมาคือห่วงโซ่เคลื่อนตัวผ่าน SSO ที่ระบบให้คะแนนไว้ 99% และผลจริงออกมาที่ 98.8% ซึ่งใกล้เคียงกับที่ประเมินไว้มาก
นอกจากนี้ยังมี “รอบการเรียนรู้” (Learning Cycles) ซึ่งเป็นช่วงที่ระบบไปค้นฐานข้อมูลช่องโหว่ คลัง GitHub และงานวิจัยความปลอดภัยด้วยตัวเอง เพื่อหาเทคนิคที่ใช้ได้กับโครงสร้างพื้นฐานของเป้าหมายโดยเฉพาะ ทีมวิจัยพบรอบการเรียนรู้ที่มีเอกสารบันทึกไว้ 5 รอบ (v1 ถึง v5) ที่แยกหมวดผลลัพธ์ตามความเกี่ยวข้องกับสภาพแวดล้อมเป้าหมาย โค้ดโจมตีสาธารณะที่หาได้ ความน่าจะเป็นที่จะสำเร็จ และลำดับความสำคัญในการลงมือ ที่น่าสนใจไม่แพ้กันคือ ความสามารถในการจับผิดตัวเอง โดยสรุปรอบสุดท้ายระบุผลบวกลวงไว้ 7 รายการควบคู่กับช่องโหว่จริง ตัวอย่างที่ชัดที่สุดคือกรณีที่เอเจนต์รายงานว่าพบ SQL injection แบบ blind จากการที่เซิร์ฟเวอร์ตอบช้า 21 วินาที แต่เมื่อทดสอบซ้ำตามระเบียบที่กำหนดให้ต้อง “ยืนยันทางกายภาพ” กลับพบว่าความล่าช้านั้นเกิดจาก SMTP timeout ตอนที่เซิร์ฟเวอร์พยายามส่งอีเมลยืนยัน ไม่ใช่การรันคำสั่ง SQL ที่แทรกเข้าไป จึงถูกจัดใหม่เป็นผลบวกลวงและตัดออกถาวร ทั้งนี้เอกสารสรุปของผู้โจมตีระบุว่าช่องโหว่ที่ยืนยันแล้วแต่ละรายการต้องผ่านการทวนสอบข้ามเอเจนต์อีก 2 รอบ รอบละ 3 ตัว รวมเป็นการทดสอบซ้ำ 6 ครั้งก่อนจะถูกนับเป็นของจริง
ผลกระทบต่อไทย
ความสำคัญของเคสนี้ไม่ได้อยู่ที่เทคนิคการเจาะ เพราะทุกอย่างที่เอเจนต์ทำล้วนเป็นของพื้นฐานที่ผู้ทดสอบเจาะระบบมือใหม่ก็ทำได้ ทั้งการอ่านบันเดิล JavaScript หาปลายทาง API การพ่นรหัสผ่านที่คาดเดาได้ การใช้ JWT ที่ตั้ง algorithm เป็น none และการอาศัย SSO ที่เชื่อเซสชันข้ามระบบโดยไม่ตรวจซ้ำ สิ่งที่เปลี่ยนไปคือความเร็วและความขนาน เมื่อไม่มีใครต้องอนุมัติทีละคำสั่ง งานสำรวจที่เคยกินเวลาหลายสัปดาห์จึงจบใน 4 วัน และเมื่อต้นทุนต่อการโจมตีหนึ่งครั้งถูกลง เป้าหมายระดับรองที่เคยไม่คุ้มค่าลงแรงก็กลายเป็นเป้าหมายที่คุ้มขึ้นมาทันที
สำหรับประเทศไทย เรื่องนี้ไม่ใช่ภัยเชิงทฤษฎี เพราะเมื่อเดือนกรกฎาคม 2569 มีกรณีที่โครงสร้างเดียวกันเกิดขึ้นกับหน่วยงานไทยมาแล้ว คือกรณีที่ผู้โจมตีปล่อยเอเจนต์ Hermes ในโหมด YOLO ให้ไล่เจาะเครือข่ายของกระทรวงการคลังเองโดยไม่มีคนคุม (ดูรายละเอียดใน โพสต์ 2026/07/262 ) ซึ่งใช้เฟรมเวิร์กตัวเดียวกันกับที่ปรากฏในเคสไต้หวันนี้ ทั้งสองเคสมีจุดร่วมที่ตรงกันคือ ระบบเป้าหมายมีการตั้งค่าเริ่มต้นที่หละหลวมอยู่ก่อนแล้ว ไม่ว่าจะเป็นบริการที่ยอมรับรหัสผ่านอะไรก็ได้ หรือปลายทาง API ที่เปิดให้เข้าถึงโดยไม่ต้องยืนยันตัวตน เอเจนต์ AI เพียงแต่ทำให้การไล่หาสิ่งเหล่านี้ถูกลงและเร็วขึ้นเท่านั้น อีกจุดที่ตรงกันคือทั้งสองปฏิบัติการเผลอเปิดไดเรกทอรีของตัวเองทิ้งไว้ให้นักวิจัยเก็บหลักฐานได้ ซึ่งบอกเป็นนัยว่าปริมาณปฏิบัติการลักษณะนี้อาจมีมากกว่าที่ถูกตรวจพบ
ประเด็นเชิงโครงสร้างที่หน่วยงานไทยควรนำไปเทียบโดยตรงคือ ระบบยืนยันตัวตนกลางแบบ SSO ที่หน่วยงานภายในเชื่อเซสชันของกันและกันอัตโนมัติ เพราะนั่นคือกลไกที่ทำให้บัญชีที่ถูกแคร็ก 85 บัญชีขยายผลเป็นการเข้าถึงระบบภายในได้ถึง 98.8% ในเคสนี้ องค์กรที่กำลังทยอยเชื่อมระบบเข้ากับ SSO กลางควรตั้งคำถามว่า เมื่อบัญชีหนึ่งถูกยึด ระบบปลายทางจะยังตรวจสอบอะไรเพิ่มอีกหรือไม่ หรือเพียงแค่เห็นโทเคนแล้วปล่อยผ่าน
คำแนะนำ
ผู้ดูแลระบบควรเริ่มจากการไล่ตรวจปลายทาง API ที่เปิดให้ผู้ใช้ที่ไม่ยืนยันตัวตนเข้าถึงได้ โดยเฉพาะปลายทางที่คืนรายชื่อผู้ใช้หรือข้อมูลบุคลากร เพราะนั่นคือเชื้อเพลิงที่ทำให้การพ่นรหัสผ่านในเคสนี้ได้ผล ถัดมาควรตรวจหาปลายทางสำหรับดีบักที่หลุดขึ้นระบบใช้งานจริง โดยเทียบรายการเส้นทางที่ปรากฏในบันเดิล JavaScript ฝั่งหน้าเว็บกับเส้นทางที่ตั้งใจเปิดให้บริการจริง ในฝั่งการยืนยันตัวตน ต้องบังคับปฏิเสธ JWT ที่มีค่า alg เป็น none ที่ระดับไลบรารีและระดับเกตเวย์ อย่าอาศัยการตรวจในโค้ดแอปพลิเคชันเพียงชั้นเดียว และควรทบทวนว่าระบบภายในที่รับเซสชันจาก SSO มีการตรวจสอบเพิ่มเติมหรือไม่ พร้อมบังคับ MFA สำหรับการเข้าถึงระบบภายในที่มีข้อมูลบุคลากร
ในแง่การตรวจจับ ควรตั้งการแจ้งเตือนจากรูปแบบที่เป็นลายเซ็นของการทำงานอัตโนมัติมากกว่าจะไล่ตามที่อยู่ไอพี เช่น การเรียก API จำนวนมากในเวลาสั้นจากต้นทางเดียว การพยายามล็อกอินที่กระจายไปหลายบัญชีแต่ลองรหัสผ่านน้อยครั้งต่อบัญชี และการส่งภาพ CAPTCHA ผ่านในอัตราที่สูงผิดปกติ ซึ่งเป็นสัญญาณว่ามีตัวถอด OCR อยู่ปลายทาง สุดท้าย นโยบายรหัสผ่านที่อนุญาตให้ตั้งจากรหัสประจำตัวพนักงานหรือชื่อผู้ใช้ที่เติมสัญลักษณ์เพียงเล็กน้อย ควรถูกปิดตายด้วยกฎฝั่งเซิร์ฟเวอร์ ไม่ใช่แค่คำแนะนำในคู่มือ เพราะรูปแบบเหล่านี้คือสิ่งแรกที่ระบบอัตโนมัติจะลอง