ทำความเข้าใจเครื่องมือโจมตีด้วย AI ยุคหลัง ARTEX: กลไกการทำงานและความเสี่ยงที่องค์กรต้องตรวจสอบ

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

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

บทความนี้มีเนื้อหาสำหรับผู้รับผิดชอบฝ่ายไอทีและฝ่ายพัฒนาที่ดูแลระบบคลาวด์และบริการเว็บ โดยจะอธิบายภาพรวมของโครงสร้างพื้นฐานการโจมตี ขอบเขตที่การสำรวจแบบเปิดเผยต่อสาธารณะได้แสดงให้เห็น และสิ่งที่บริษัทควรตรวจสอบ ส่วน ScopeWeaver, Strix, Shannon และ PentAGI จะถูกนำมาใช้เป็นตัวอย่างที่เป็นรูปธรรมเพื่อทำความเข้าใจความแตกต่างระหว่างกัน วันที่ตรวจสอบข้อมูลคือวันที่ 12 พฤศจิกายน 2026 ความปลอดภัยของสภาพแวดล้อมแต่ละแห่งและความครอบคลุมของการตรวจสอบนั้น จำเป็นต้องมีการตรวจสอบให้สอดคล้องกับเป้าหมายแต่ละกรณี

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

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

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

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

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

การสำรวจของ GitGuardian ได้หยิบยกเฟรมเวิร์กที่เกี่ยวข้องมานำเสนอประมาณ 45 รายการ นอกเหนือจาก ARTEX โดยทางบริษัทได้จัดหมวดหมู่ตามวัตถุประสงค์การใช้งาน ได้แก่ การสำรวจและบุกรุกเครือข่าย, เว็บแอปและ API, การเชื่อมต่อกับ C2, การใช้เอเจนต์ทั่วไปเป็นเครื่องมือในการโจมตี (Harness) และกลไกสำหรับการวิจัย ทั้งนี้ ไม่ใช่การเปรียบเทียบประสิทธิภาพโดยการรันผลิตภัณฑ์ทั้งหมดภายใต้เงื่อนไขเดียวกัน การสำรวจของ GitGuardian

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

ตารางนี้ไม่ได้มีไว้เพื่อแบ่งผลิตภัณฑ์ออกเป็นกล่องตายตัว เนื่องจากเครื่องมือเดียวกันอาจมีพฤติกรรมที่เปลี่ยนไปตามเวอร์ชัน, โหมดการทำงาน, ข้อมูลที่ป้อนให้ หรือโมเดลที่เชื่อมต่อ การตัดสินใจที่ว่า "เป็นผลิตภัณฑ์ที่อ่านซอร์สโค้ดจึงไม่มีการดำเนินการภายนอก" หรือ "เป็นแบบ Self-host ข้อมูลจึงไม่รั่วไหลออกไป" จำเป็นต้องมีการตรวจสอบเส้นทางข้อมูลจริงและการตั้งค่าการทำงานประกอบด้วย

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

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

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

GitGuardian ได้ทำการทดสอบ ARTEX 1 บิลด์ที่ไม่มีสแกนเนอร์ข้อมูลลับเฉพาะในสภาพแวดล้อมแบบแยกส่วนโดยใช้ที่เก็บข้อมูลสมมติ โดยรายงานว่าจากการทดลอง 9 ครั้ง ซึ่งเป็นการรันคำสั่งค้นหา 3 ประเภท ประเภทละ 3 ครั้ง โมเดลสามารถค้นพบข้อมูลรับรองสมมติ 8 จาก 9 รายการได้ทุกครั้ง โดยใช้เพียงเครื่องมือทั่วไปอย่าง git และ grep การทดลองแบบแยกส่วนของ GitGuardian

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

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

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

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

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

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

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

Microsoft ได้ตรวจพบการโจมตีที่ใช้เครื่องมือแบบ Agentic เพื่อค้นหาข้อมูลลับที่เปิดเผยอยู่บน GitHub สาธารณะ และนำไปใช้ในกิจกรรมที่ตามมา โดยมีรายงานอย่างน้อยหนึ่งกรณีที่ระบุว่าใช้เวลาเพียง 5 นาที ตั้งแต่การค้นหาข้อมูลลับไปจนถึงการรั่วไหลของข้อมูลใน Azure Key Vault ซึ่งนี่เป็นเพียงระยะเวลาของกรณีศึกษาเฉพาะเท่านั้น ไม่ใช่ระยะเวลาที่ใช้ในการโจมตีทุกรูปแบบ รายงานจาก Microsoft

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

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

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

งานลบค่าที่รั่วไหลออกจากไฟล์และงานทำให้ค่าดังกล่าวไม่สามารถใช้ยืนยันตัวตนได้นั้นเป็นคนละส่วนกัน คำแนะนำอย่างเป็นทางการของ GitHub ระบุว่าหากรหัสผ่านหรือโทเค็นรั่วไหล สิ่งแรกที่ต้องทำคือการเพิกถอนหรือหมุนเวียน (Rotate) ค่าเหล่านั้น การแก้ไขประวัติ (History) ไม่ได้หมายความว่าจะสามารถลบค่าดังกล่าวออกจาก Clone หรือ Fork ที่มีอยู่เดิมได้ทั้งหมด คำแนะนำในการรับมือของ GitHub

การรับมือสามารถจัดระเบียบได้โดยแบ่งออกเป็นงานที่มีวัตถุประสงค์ต่างกัน ดังนี้:

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

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

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

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

GitGuardian ได้เผยแพร่ตัวเลขสรุปบริการที่ระบุได้ผ่าน Shodan จำนวน 1,428 รายการที่เกี่ยวข้องกับ ARTEX ณ วันที่ 7 พฤศจิกายน 2026 ในขณะที่ Censys รายงานว่าตรวจพบโฮสต์ที่มีคอนโซล ARTEX เปิดเผยต่อสาธารณะจำนวน 1,465 โฮสต์ ณ วันที่ 4 พฤศจิกายน การรวบรวมข้อมูลของ GitGuardian และ การตรวจพบของ Censys

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

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

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

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

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

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

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

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

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

ที่มา: ScopeWeaver, Strix, Shannon, PentAGI

ตัวอย่างเช่น เอกสารของ ScopeWeaver อธิบายว่า "scope" เป็นตัวกรองสำหรับคำสั่งบนพรอมต์และบันทึกสินทรัพย์ โดยระบุชัดเจนว่าขอบเขตเครือข่ายจริงจำเป็นต้องมีการควบคุมการสื่อสารจากภายนอก เอกสารของ PentAGI ก็อธิบายถึงผลกระทบที่เกิดขึ้นเมื่อส่ง Docker socket ของโฮสต์ให้เอเจนต์ ซึ่งจะทำให้เอเจนต์สามารถจัดการ Docker API ของโฮสต์ได้ คำอธิบาย scope ของ ScopeWeaver, คำอธิบายสิทธิ์ Docker ของ PentAGI

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

เมื่อพิจารณาว่าจะสามารถนำไปใช้ในการตรวจสอบอย่างเป็นทางการได้หรือไม่ นอกจากคำอธิบายฟังก์ชันการทำงานแล้ว ให้ตรวจสอบเงื่อนไขการใช้งานของผลิตภัณฑ์แต่ละรายการด้วย README ของ ScopeWeaver ได้ระบุเงื่อนไขเพิ่มเติมที่จำกัดการใช้งานไว้เฉพาะการวิจัยและการตรวจสอบทางเทคนิคในสภาพแวดล้อมแบบแยกส่วน (Isolated Environment) ในเครื่องเท่านั้น และห้ามนำไปใช้กับระบบออนไลน์หรือการทดสอบจริงในสภาพแวดล้อมการใช้งานจริง (Production) จำเป็นต้องแยกอ่านคำอธิบายของ AGPL และเงื่อนไขการใช้งานของผู้เขียนรายนี้ออกจากกัน เงื่อนไขการใช้งานของ ScopeWeaver

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

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

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

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

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

ตัวอย่างเช่น แม้ผู้รับผิดชอบแอปพลิเคชันบนเว็บจะทราบขอบเขตการเปิดเผยซอร์สโค้ด แต่อาจมีกรณีที่สิทธิ์ของ Cloud ID ที่รวมอยู่ในการตั้งค่านั้นถูกจัดการโดยทีมอื่น ในกรณีนี้ การยืนยันเพียงว่า "ไม่มีข้อมูลลับ" จะไม่สามารถสื่อสารขอบเขตของ Repository ที่ตรวจสอบ ระยะเวลาที่ตรวจสอบ หรือขอบเขตของ ID ที่เป็นเป้าหมายได้ การใช้ตารางเพื่อจับคู่หน่วยของการตรวจสอบจึงมีประโยชน์

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

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

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

OWASP ระบุว่าควรให้เครื่องมือและสิทธิ์ที่จำเป็นแก่ Agent เท่านั้น และให้ตรวจสอบการอนุญาต (Authorization) ที่ฝั่งการทำงานซึ่งอยู่นอกบริบทของโมเดล สำหรับการดำเนินการที่มีผลกระทบสูง แนวคิดคือการเชื่อมโยงการอนุมัติเข้ากับเป้าหมายและการดำเนินการจริง พร้อมทั้งผสมผสานการออกแบบบันทึกการตรวจสอบ (Audit Log) และการหยุดการทำงานเข้าด้วยกัน OWASP AI Agent Security Cheat Sheet

ในเอกสารการปฏิบัติงาน (Operation Sheet) ควรมีช่องสำหรับกรอกผลการตรวจสอบนอกเหนือจากรายการการตั้งค่า ตัวอย่างเช่น รายการต่อไปนี้เป็นข้อเสนอแนะในการตรวจสอบเพื่อยืนยันสถานะการรองรับของผลิตภัณฑ์แต่ละตัว:

• เส้นทางการเข้าถึง (Public Path): ได้ตรวจสอบขอบเขตการเข้าถึงและการยืนยันตัวตนของหน้าจอ, API, ไฟล์ผลลัพธ์ และการสำรองข้อมูลแล้วหรือไม่
• ขอบเขตการทำงาน (Execution Scope): จะจำกัดการเข้าถึงปลายทางการสื่อสาร, ไฟล์, ข้อมูลยืนยันตัวตน และโฮสต์ไว้ที่จุดใด
• สิทธิ์การดำเนินการ (Operation Privilege): อนุญาตให้ใครสามารถดู, ดาวน์โหลด, สั่งการ, หรือเริ่ม/หยุดการทำงานได้บ้าง
• การจัดเก็บหลักฐาน (Evidence Retention): จะจัดการข้อมูลที่รวมอยู่ในบันทึกการสื่อสารและรายงาน รวมถึงการดู, การเก็บรักษา, และการลบข้อมูลอย่างไร
• การหยุดชะงักและการกู้คืน (Interruption and Recovery): จะตรวจสอบการประมวลผลหลังจากปิดหน้าจอ, การเชื่อมต่อที่ยังค้างอยู่, และการกู้คืนข้อมูลเป้าหมายอย่างไร

ผลลัพธ์ควรแบ่งออกเป็น "ตรวจสอบแล้ว (Confirmed)", "มีเงื่อนไข (Conditional)", "ยังไม่ได้ตรวจสอบ (Unconfirmed)", และ "ไม่เกี่ยวข้อง (Not Applicable)" โดยต้องไม่ใส่รายการที่ยังไม่ได้ทดสอบลงในช่องผ่านการตรวจสอบ ในกรณีที่ต้องทดสอบการดำเนินการที่ควรถูกปฏิเสธ ให้ใช้เป้าหมายที่แยกส่วน (Isolated) และข้อมูลจำลองที่ได้รับอนุญาตเท่านั้น โดยต้องกำหนดเป้าหมายและเงื่อนไขการหยุดทำงานไว้ล่วงหน้า การนำการควบคุมสิทธิ์ไปใช้งานจริงสามารถดูรายละเอียดได้ที่ คู่มือการออกแบบสิทธิ์ขั้นต่ำ (Least Privilege Design Guide) และสำหรับการหยุดการทำงานหรือการจำกัดค่าใช้จ่าย สามารถดูได้ที่ รายการตรวจสอบการดำเนินงานการ์ดเรล (Guardrail Operations Checklist)

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

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

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

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

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

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

ความท้าทายของฝั่งองค์กรคือการทำความเข้าใจเส้นทางจากข้อมูลลับที่เปิดเผยสู่สินทรัพย์สำคัญ รวมถึงสิทธิ์และข้อมูลที่จัดเก็บไว้ในตัวโครงสร้างพื้นฐานสำหรับการวินิจฉัยเอง แม้ไม่ได้ใช้เครื่องมือวินิจฉัย AI ปัญหาประการแรกก็ยังคงอยู่ และหากมีการติดตั้งสภาพแวดล้อมสำหรับการทดลองใช้ ก็จะเพิ่มภาระในการจัดการประการหลังเข้ามาด้วย ตัวอย่างของ ScopeWeaver, Strix, Shannon และ PentAGI เป็นข้อมูลที่ช่วยให้เข้าใจขอบเขตดังกล่าวได้อย่างเป็นรูปธรรม

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