สรุปสั้น

นักวิจัยจากบริษัท Cracken เผยแพร่งานวิเคราะห์ความปลอดภัยเชิงลึกครั้งแรกของเครื่องมือ AI สาย offensive security แบบ agentic จำนวน 12 ตัวที่ถูกนำไปใช้งานอย่างแพร่หลาย และพบช่องโหว่ทางสถาปัตยกรรมร้ายแรงที่เปิดทางให้ผู้โจมตีขโมยกุญแจ API ของโมเดลภาษา (LLM API key) ฝังตัวอยู่ในระบบอย่างถาวร และยึดครองเครื่องของผู้ปฏิบัติงานได้อย่างสมบูรณ์ แม้ตัว agent จะถูกรันอยู่ภายใน Docker container ที่ถูกแยกออกมา (sandbox) แล้วก็ตาม เครื่องมือเหล่านี้เป็นแพลตฟอร์มขับเคลื่อนด้วย LLM ที่ทำงานอัตโนมัติเต็มรูปแบบ ออกแบบมาเพื่อจำลองการทดสอบเจาะระบบและปฏิบัติการเชิงรุก โดยจับคู่ตัว orchestrator ที่เป็น LLM เข้ากับ worker container ที่เป็น Kali Linux ซึ่งสามารถรันคำสั่ง shell ใด ๆ ก็ได้กับเป้าหมาย จุดที่น่ากังวลที่สุดคือเทคนิคใหม่ที่ชื่อ “agent-phishing” ซึ่งเป็นการหลอก agent โดยไม่ต้องใช้ prompt injection เลย แต่กลับมีอัตราความสำเร็จสูงถึง 97.8% กับทุก agent และทุกโมเดลที่ทดสอบ นอกจากนี้ยังพบว่า 11 ใน 12 เครื่องมือสามารถถูกขโมย secret ได้อย่างง่ายดายเมื่อผู้โจมตีมีจุดยืนในระบบแล้ว และมาตรการ guardrail ที่หลายเครื่องมือใช้ป้องกันกลับไม่มีตัวใดได้ผลจริง สะท้อนว่าเครื่องมือ AI ที่สร้างมาเพื่อความปลอดภัยกลับกลายเป็นพื้นที่โจมตีใหม่ที่อันตราย

รายละเอียดข่าว

เว็บไซต์ Cyber Security News รายงานเมื่อวันที่ 24 มิถุนายน พ.ศ. 2569 ว่าบริษัท Cracken ได้เผยแพร่งานวิเคราะห์ความปลอดภัยเชิงลึกชิ้นแรกของระบบ AI red-team แบบ agentic ซึ่งเป็นเครื่องมือที่ขับเคลื่อนด้วย AI และออกแบบมาให้ดำเนินการทดสอบเจาะระบบและปฏิบัติการเชิงรุกได้ด้วยตนเองโดยอัตโนมัติ

งานวิจัยนี้เปิดเผยชุดของข้อบกพร่องด้านการออกแบบที่ใช้ร่วมกันในวงกว้าง ซึ่งเปิดทางให้ผู้โจมตีที่ตื่นตัว (active adversary) สามารถดูดข้อมูลรับรองที่อ่อนไหวออกไป เปลี่ยนโครงสร้างพื้นฐานของเหยื่อให้กลายเป็นอาวุธ และยึดครองเครื่องของผู้ปฏิบัติงานได้อย่างสมบูรณ์ แม้ agent จะรันอยู่ใน Docker container ที่ถูก sandbox ไว้

นักวิจัยได้วิเคราะห์เครื่องมือโอเพนซอร์สยอดนิยม 12 ตัว ซึ่งรวมถึง PentestGPT, RedAmon, DarkMoon, AIRecon, CAI, PentAGI, STRIX, Artemis, METATRON และอื่น ๆ โดยทั้งหมดจับคู่ตัว orchestrator ที่เป็นโมเดลภาษาขนาดใหญ่เข้ากับ worker container ที่เป็น Kali Linux ซึ่งสามารถรันคำสั่ง shell ตามอำเภอใจกับเป้าหมายได้ เครื่องมือเหล่านี้กำลังเข้าสู่กระบวนการทำงานด้านความปลอดภัยในระดับ production อย่างรวดเร็ว มีการนำไปใช้เพิ่มขึ้นในทีมความปลอดภัยขององค์กรและได้รับความสนใจมากขึ้นจากหน่วยงานไซเบอร์ทางทหาร ทำให้พื้นที่โจมตีของมันกลายเป็นเรื่องที่ต้องเร่งให้ความสำคัญ

agentic red-team AI tools security vulnerabilities exfiltrate API keys
agentic red-team AI tools security vulnerabilities exfiltrate API keys

รายละเอียดช่องโหว่

นักวิจัยได้นำเสนอ cyber kill chain ที่ออกแบบเฉพาะสำหรับระบบ AI red-team แบบ agentic ซึ่งแบ่งเป็น 5 ขั้นตอน ขั้นแรกคือ Worker RCE ผ่านการชักจูง agent โดยผู้โจมตีวาง honeypot ที่บรรจุ payload ที่ถูกจัดเตรียมไว้แบบมุ่งร้าย agent จะดาวน์โหลดและรันมันโดยไม่ต้องมี prompt injection ที่ชัดเจน ทำให้ได้ reverse shell บน worker container ขั้นที่สองคือการยกระดับสิทธิ์ (privilege escalation) ที่อาศัยการแยก file-system หรือเครือข่ายระหว่าง worker กับ orchestrator ที่อ่อนแอ เช่นใน PentestGPT ที่มี Docker volume เขียนได้เปิดเผยไฟล์ settings.json ของ orchestrator ทำให้สามารถฉีด hook เพื่อกระตุ้น RCE บน orchestrator ทุกครั้งที่เริ่ม session ใหม่ ขั้นที่สามคือการฝังตัวถาวร (persistence) ด้วยการวางยาในส่วนที่ไม่ลบหายไป เช่นไฟล์ซอร์สโค้ด ไดเรกทอรี MCP server หรือหน่วยความจำแบบ episodic ขั้นที่สี่คือการหลุดออกจาก sandbox ผ่านการ mount Docker socket ที่ตั้งค่าผิดและการเข้าถึง host-network และขั้นสุดท้ายคือการยึดเครื่องของผู้ปฏิบัติงานได้อย่างสมบูรณ์ พร้อมติดตั้ง C2 และทำกิจกรรมหลังการเจาะระบบ

จุดที่น่าตื่นตระหนกที่สุดคือเทคนิคการโจมตีใหม่ที่ชื่อ “agent-phishing” ซึ่งเป็นการชักจูงที่ไม่ต้องใช้ prompt injection แต่กลับสำเร็จถึง 97.8% กับทุก agent และทุก LLM ที่ทดสอบ โดยผู้โจมตีจะวางไบนารีที่ทำงานได้จริง (เช่นโปรแกรมถอดรหัสกุญแจรหัสผ่านชื่อ pwcrypt) ไว้บน honeypot ที่ควบคุมเอง พร้อม README ที่น่าเชื่อถือและ log ของ CI pipeline ปลอม agent จะดาวน์โหลดและรันไบนารีนั้นด้วยความเชื่อว่ามันเป็นไฟล์สำคัญ โดยตัวไบนารีบรรจุช่องโหว่ memory corruption ที่ถูกฝังไว้เอง (ไม่ใช่โค้ดมุ่งร้าย) ซึ่งถูกกระตุ้นเมื่อรันและจี้ control flow เพื่อรันโค้ดตามอำเภอใจ วิธีนี้เอาชนะการตรวจสอบด้วยโมเดลได้อย่างสิ้นเชิงเพราะไม่มี shellcode ไม่มี payload ที่เข้ารหัส และไม่มีรูปแบบ syscall ที่น่าสงสัย โดยมีผลกับ Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro, DeepSeek V4 Pro, GLM-5.1 และ Kimi K2.6

เมื่อมีจุดยืนในระบบแล้ว การดูดข้อมูลลับออกไปทำได้ง่ายใน 11 จาก 12 เครื่องมือ เพราะส่วนใหญ่วาง worker และ orchestrator ไว้ใน container เดียวกัน ทำให้ LLM API key และหน่วยความจำข้าม session ถูกเปิดเผยโดยตรง เช่นใน RedAmon ที่ใช้ API key ภายในร่วมกันและเครือข่าย Docker bridge ที่ไม่ต้องยืนยันตัวตน ทำให้ผู้โจมตีดูดประวัติการสนทนา รวมถึงโฮสต์เป้าหมายและข้อมูลรับรองของผู้ใช้ทุกคนทุก session ออกไปได้ ขณะที่ 7 ใน 12 เครื่องมือมี guardrail, regex filter หรือ LLM-as-judge เพื่อบล็อกเป้าหมายอ่อนไหว แต่นักวิจัยพบว่าไม่มีตัวใดได้ผล เพราะ guardrail ถูกบังคับใช้แค่ที่ชั้น orchestration ไม่เคยตรวจสอบกิจกรรมเครือข่ายจริงของ worker ผู้โจมตีที่มี shell บน worker จึงเลี่ยง guardrail ได้แบบมองไม่เห็น ซึ่งสอดคล้องกับที่ Microsoft เพิ่งเปิดเผย CVE-2026-25592 และ CVE-2026-26030 ใน Semantic Kernel ที่ยืนยันว่า LLM ไม่ใช่ขอบเขตความปลอดภัย (security boundary)

ผลกระทบต่อไทย

ทีมความปลอดภัยและบริษัท penetration testing ในประเทศไทยเริ่มนำเครื่องมือ AI สาย offensive มาช่วยงานทดสอบเจาะระบบมากขึ้นตามกระแสทั่วโลก งานวิจัยนี้เป็นคำเตือนสำคัญว่าเครื่องมือเหล่านี้เองอาจกลายเป็นช่องทางให้ถูกโจมตีกลับ โดยเฉพาะการรั่วไหลของ LLM API key ที่มีค่าใช้จ่ายสูง และที่ร้ายแรงกว่าคือการที่ข้อมูลรับรองของลูกค้าและรายละเอียดเป้าหมายที่ทีมเก็บไว้ในระบบ agent อาจถูกขโมยออกไปทั้งหมด องค์กรไทยที่ใช้หรือกำลังพิจารณาใช้เครื่องมือ AI red-team แบบ agentic ควรตระหนักว่า worker container ที่รันคำสั่งกับเป้าหมายต้องถูกมองว่าเป็นสภาพแวดล้อมที่ไว้ใจไม่ได้

คำแนะนำ

ทีมความปลอดภัยควรนำหลักการสถาปัตยกรรมที่นักวิจัยเสนอไปปรับใช้ โดยยึดหลักว่า “ต้องมองตัว LLM worker เป็นสภาพแวดล้อมที่ไว้ใจไม่ได้” ซึ่งรวมถึงการแยก worker กับ orchestrator อย่างเด็ดขาดโดยไม่มี shared mount ที่เขียนได้ ใช้การแบ่งเครือข่ายที่ต้องยืนยันตัวตน แยก secret ออกมาให้ API key ไม่มีทางไปถึง worker ได้ บังคับใช้ guardrail ที่ชั้น worker ผ่านการกรอง network egress และใช้ filesystem ของ worker แบบ immutable ที่ถูกสร้างใหม่ทุกครั้งระหว่างปฏิบัติการ นอกจากนี้ควรหลีกเลี่ยงการ mount Docker socket หรือเปิด host-network ให้ container และทบทวนสิทธิ์การเข้าถึงของเครื่องมือที่ใช้อยู่อย่างสม่ำเสมอ

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