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

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

Agent Data Injection คืออะไร

Agent Data Injection เป็นแนวทางการโจมตี AI Agent ที่มุ่งเปลี่ยนแปลงข้อมูลซึ่งระบบใช้ประกอบการตัดสินใจ โดยไม่จำเป็นต้องเปลี่ยนคำสั่งหลักของผู้ใช้

โดยทั่วไป AI Agent ต้องประมวลผลข้อมูลสองประเภท ได้แก่

• คำสั่ง เช่น สิ่งที่ผู้ใช้ต้องการให้ Agent ทำ
• ข้อมูล เช่น อีเมล หน้าเว็บไซต์ ความคิดเห็นใน GitHub ผลลัพธ์จากเครื่องมือ หรือข้อมูลจากฐานข้อมูล

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

ตัวอย่างเช่น ผู้ใช้สั่งให้ AI สรุปรีวิวสินค้า แต่รีวิวที่ถูกแทรกไว้มีข้อมูลปลอมเกี่ยวกับหมายเลขปุ่ม เมื่อ Agent ต้องการคลิกปุ่ม “อ่านเพิ่มเติม” ระบบอาจคลิกปุ่ม “ซื้อทันที” แทน

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

ช่องโหว่เกิดจากวิธีที่ AI Agent อ่านข้อมูล

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

โปรแกรมแบบดั้งเดิมจะอ่านโครงสร้างเหล่านี้ตามกฎที่แน่นอน หากเครื่องหมายไม่ตรงตามรูปแบบ โปรแกรมมักมองว่าเป็นข้อความธรรมดา แต่โมเดลภาษาขนาดใหญ่ไม่ได้อ่านด้วยกฎตายตัวเสมอไป ระบบจะตีความโครงสร้างจากความน่าจะเป็นและบริบทของข้อความ

นักวิจัยเรียกเทคนิคที่ใช้ประโยชน์จากพฤติกรรมนี้ว่า Probabilistic Delimiter Injection

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

• เครื่องหมายคำพูดที่มีการ Escape
• เครื่องหมายคำพูดแบบโค้ง
• วงเล็บหรือแท็กที่ดูคล้ายโครงสร้างจริง
• เครื่องหมายดอลลาร์
• การขึ้นบรรทัดใหม่ในตำแหน่งที่ทำให้เกิดความสับสน

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

ตัวอย่างการโจมตี Agent Data Injection

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

ปลอมหมายเลขปุ่มบนหน้าเว็บไซต์

ในระบบ Web Agent ผู้โจมตีสามารถแทรกรีวิวสินค้าที่มีข้อมูลอ้างอิงถึงหมายเลขปุ่มซึ่งตรงกับปุ่มจริงบนหน้าเว็บไซต์

เมื่อ Agent ต้องการคลิกปุ่ม “Read More” เพื่ออ่านรายละเอียดเพิ่มเติม ระบบอาจเลือกหมายเลของค์ประกอบที่ถูกปลอมไว้ และคลิกปุ่ม “Buy Now” แทน ทำให้เกิดการสั่งซื้อโดยที่ผู้ใช้ไม่ได้ตั้งใจ

เครื่องมือที่ถูกนำมาทดสอบประกอบด้วย Claude in Chrome, Google Antigravity และ Nanobrowser

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

ปลอมชื่อผู้เขียนความคิดเห็นใน GitHub

ในเครื่องมือช่วยเขียนโค้ด ผู้โจมตีสามารถสร้างความคิดเห็นที่ดูเหมือนมาจากผู้ดูแลโครงการ โดยปลอมส่วนที่แสดงชื่อผู้เขียนหรือโครงสร้างของข้อมูลความคิดเห็น

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

เครื่องมือที่ถูกนำมาทดสอบ ได้แก่

• Claude Code
• OpenAI Codex
• Google Gemini CLI

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

ปลอมผลลัพธ์ของการตรวจสอบโค้ด

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

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

หากผู้ใช้อนุมัติ Pull Request โค้ดอันตรายจริงอาจถูกนำเข้าสู่ระบบ แม้ขั้นตอนการตรวจสอบที่ Agent อ้างถึงจะไม่เคยเกิดขึ้น

ระบบขออนุมัติก่อนทำงานอาจยังไม่เพียงพอ

AI Agent หลายระบบมีขั้นตอนขออนุมัติจากผู้ใช้ก่อนดำเนินการที่มีความเสี่ยง เช่น คลิกปุ่มสั่งซื้อ รันคำสั่ง หรือรวมโค้ดเข้าสู่โครงการ

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

ในกรณีของ Web Agent หน้าต่างยืนยันอาจแจ้งเพียงว่า Agent ต้องการคลิกองค์ประกอบหนึ่งบนหน้าเว็บ แต่ไม่ได้อธิบายอย่างชัดเจนว่าปุ่มดังกล่าวคืออะไร มีข้อความว่าอย่างไร และเหตุใด Agent จึงต้องคลิก

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

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

โมเดล AI หลายค่ายพบความเสี่ยงจาก ADI

งานวิจัยระบุว่าโมเดลจากหลายผู้พัฒนาแสดงพฤติกรรมที่สามารถถูกโจมตีด้วยวิธีดังกล่าวได้ โดยมีการทดสอบกับโมเดลจาก OpenAI, Anthropic และ Google

โมเดลที่ถูกระบุในงานวิจัยประกอบด้วย

• OpenAI GPT-5.2
• OpenAI GPT-5-mini
• Anthropic Claude Opus 4.5
• Anthropic Claude Sonnet 4.5
• Google Gemini 3 Pro
• Google Gemini 3 Flash

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

เมื่อนำไปทดสอบกับระบบป้องกัน Prompt Injection ที่ออกแบบมาโดยเฉพาะ การโจมตีแบบซ่อนคำสั่งทั่วไปถูกป้องกันได้เกือบทั้งหมด แต่ ADI ยังสามารถทำงานสำเร็จได้สูงสุดประมาณ 50%

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

วิธีป้องกัน Agent Data Injection

งานวิจัยได้ทดลองแนวทางป้องกันหลายรูปแบบ โดยแต่ละวิธีมีข้อดีและข้อจำกัดแตกต่างกัน

ใช้รหัสองค์ประกอบแบบสุ่ม

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

เมื่อรหัสไม่สามารถคาดเดาได้ ผู้โจมตีจะปลอมหมายเลขให้ตรงกับปุ่มเป้าหมายได้ยากขึ้น

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

ติดตามแหล่งที่มาของข้อมูล

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

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

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

ลบเครื่องหมายที่ใช้แบ่งข้อมูล

การลบหรือกรองเครื่องหมายวรรคตอนบางประเภทสามารถลดโอกาสที่ AI จะตีความข้อมูลปลอมเป็นโครงสร้างจริง

อย่างไรก็ตาม วิธีนี้อาจทำลายข้อมูลที่จำเป็น เช่น

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

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

แสดงรายละเอียดก่อนขออนุมัติ

ระบบควรแสดงข้อมูลที่ผู้ใช้สามารถตรวจสอบได้ก่อนอนุมัติ เช่น

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

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

เงื่อนไขที่ทำให้การโจมตีเกิดขึ้นได้

Agent Data Injection ต้องอาศัยองค์ประกอบหลายอย่างร่วมกัน

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

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

ผู้โจมตีรู้รูปแบบข้อมูลของ Agent ได้อย่างไร

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

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

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

ความเชื่อมโยงกับ EchoLeak และการโจมตีผ่าน GitHub

ปัญหาความน่าเชื่อถือของข้อมูลใน AI Agent เคยปรากฏให้เห็นผ่านช่องโหว่อื่นมาก่อน

ในเดือนมิถุนายน 2025 มีการเปิดเผย EchoLeak หรือ CVE-2025-32711 ซึ่งเกี่ยวข้องกับ Microsoft 365 Copilot ผู้โจมตีสามารถสร้างอีเมลที่ทำให้ระบบเปิดเผยข้อมูลภายในได้โดยไม่ต้องให้ผู้ใช้คลิกลิงก์

EchoLeak ใช้วิธีซ่อนคำสั่งไว้ในข้อมูล ขณะที่ Agent Data Injection เปลี่ยนไปปลอมข้อเท็จจริงที่ระบบเชื่อถือ เช่น ใครเป็นผู้ส่ง ข้อมูลมาจากแหล่งใด หรือเครื่องมือเคยทำอะไรไปแล้ว

นอกจากนี้ ยังเคยมีการสาธิตว่าข้อความใน GitHub Issue และ Pull Request สามารถชักนำ Coding Agent ให้เข้าถึงข้อมูลจาก Repository ส่วนตัว หรือเปิดเผยข้อมูลสำคัญได้

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

นักพัฒนา AI Agent ควรเตรียมรับมืออย่างไร

การป้องกัน ADI ไม่ควรพึ่งการกรอง Prompt Injection เพียงอย่างเดียว แต่ต้องออกแบบระบบให้แยกข้อมูลตามระดับความน่าเชื่อถืออย่างชัดเจน

แนวทางที่ควรนำไปพิจารณา ได้แก่

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

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

สรุป Agent Data Injection สะท้อนปัญหาความน่าเชื่อถือของข้อมูลใน AI Agent

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

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

ระบบป้องกัน Prompt Injection แบบเดิมจึงอาจไม่เพียงพอสำหรับ Agent ที่สามารถดำเนินการจริง นักพัฒนาต้องแยกข้อมูลที่ระบบรับรองออกจากข้อมูลภายนอก ติดตามแหล่งที่มา ใช้รหัสที่คาดเดาไม่ได้ และแสดงรายละเอียดที่ตรวจสอบได้ก่อนขออนุมัติ

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

ที่มา thehackernews

SiamGeek

The post Agent Data Injection ภัยโจมตี AI Agent รูปแบบใหม่ที่ปลอมข้อมูลให้ระบบตัดสินใจผิด appeared first on SiamByte.

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

พฤติกรรมที่ถูกตรวจจับมีตั้งแต่การถอดรหัสข้อมูลรับรองในเบราว์เซอร์ การตรวจสอบข้อมูลใน Windows Credential Manager การดาวน์โหลดไฟล์ผ่านเครื่องมือของระบบ ไปจนถึงการสร้างสคริปต์ในโฟลเดอร์ Startup เพื่อให้ทำงานอัตโนมัติเมื่อเปิดเครื่อง

AI Coding Agent ทำอะไรจนถูกมองว่าเป็นการโจมตี

Sophos วิเคราะห์ข้อมูลจากระบบตรวจจับพฤติกรรมบน Windows เป็นระยะเวลา 7 วันในเดือนมิถุนายน 2026 โดยนับจากจำนวนเครื่องที่พบพฤติกรรม ไม่ได้นับจากจำนวนเหตุการณ์ทั้งหมด

ผลการวิเคราะห์พบว่ากิจกรรมที่ถูกบล็อกแบ่งออกเป็นกลุ่มสำคัญ ได้แก่

• การเข้าถึงข้อมูลรับรองคิดเป็น 56.2 เปอร์เซ็นต์
• การสั่งรันคำสั่งหรือโปรแกรมคิดเป็น 28.8 เปอร์เซ็นต์
• การดาวน์โหลดไฟล์ผ่านเครื่องมือของ Windows
• การสร้างกลไกให้โปรแกรมทำงานอัตโนมัติหลังเปิดเครื่อง
• การลองใช้วิธีอื่นทันทีเมื่อวิธีแรกถูกระบบรักษาความปลอดภัยบล็อก

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

การเข้าถึงข้อมูลในเบราว์เซอร์ทำให้ระบบแจ้งเตือน

หนึ่งในกฎตรวจจับที่ทำงานบ่อยที่สุดเกี่ยวข้องกับการใช้ Windows Data Protection API หรือ DPAPI เพื่อถอดรหัสข้อมูลที่ถูกจัดเก็บไว้ในเบราว์เซอร์

กฎนี้คิดเป็น 42.6 เปอร์เซ็นต์ของกลุ่มพฤติกรรมเข้าถึงข้อมูลรับรอง โดยปกติแล้ว DPAPI ถูกใช้เพื่อปกป้องข้อมูลสำคัญ เช่น รหัสผ่าน คุกกี้ และข้อมูลการเข้าสู่ระบบ

Sophos พบว่า Claude Code ซึ่งใช้งานชุดความสามารถ GStack สามารถเรียกฟังก์ชันสำหรับควบคุมเบราว์เซอร์ โดยมีการใช้ PowerShell ติดต่อกับ DPAPI เพื่อปลดล็อกข้อมูลที่เบราว์เซอร์จัดเก็บไว้

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

Claude Code ตรวจสอบ Credential Manager ของ Windows

Sophos ยังพบเหตุการณ์ที่ Claude Code ปิดเบราว์เซอร์ซึ่งกำลังทำงานอยู่ ก่อนเรียกใช้สคริปต์ Python เพื่ออ่านข้อมูลจากพื้นที่จัดเก็บข้อมูลรับรองของเบราว์เซอร์

ในอีกเหตุการณ์หนึ่ง Claude Code ใช้คำสั่งต่อไปนี้เพื่อตรวจสอบข้อมูลที่ Windows Credential Manager จัดเก็บไว้

cmdkey /list

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

Sophos ระบุว่า Claude Code ในเหตุการณ์นี้ทำงานร่วมกับตัวเลือก --dangerously-skip-permissions ซึ่งเป็นโหมดที่ลดขั้นตอนการขออนุญาตก่อนดำเนินการบางอย่าง

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

OpenAI Codex เปลี่ยนวิธีดาวน์โหลดไฟล์เมื่อถูกบล็อก

OpenAI Codex ถูกตรวจพบว่าพยายามดาวน์โหลดตัวติดตั้ง Python จากเว็บไซต์ python.org โดยเริ่มจากการใช้คำสั่ง certutil

เมื่อระบบรักษาความปลอดภัยบล็อกคำสั่งดังกล่าว Codex จึงเปลี่ยนไปใช้ bitsadmin เพื่อดาวน์โหลดไฟล์แทน

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

พฤติกรรมลักษณะนี้มักถูกเรียกว่า Living off the Land หรือการใช้เครื่องมือที่มีอยู่ในระบบปฏิบัติการเพื่อดำเนินกิจกรรมบางอย่าง

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

Cursor สร้างสคริปต์ในโฟลเดอร์ Startup

Cursor ถูกตรวจพบว่าใช้ PowerShell เพื่อเขียนไฟล์สคริปต์ลงในโฟลเดอร์ Startup ของ Windows

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

Sophos ไม่สามารถยืนยันได้ว่าสคริปต์ดังกล่าวมีหน้าที่อะไร แต่การเขียนไฟล์ลงใน Startup โดยกระบวนการที่ไม่ใช่โปรแกรมติดตั้งที่เชื่อถือได้ ถือเป็นพฤติกรรมที่ฝ่ายรักษาความปลอดภัยต้องตรวจสอบ

AI Agent อาจเป็นทั้งเครื่องมือพัฒนาและเครื่องมือโจมตี

ปัญหานี้ไม่ได้อยู่ที่ AI Coding Agent ฝั่งนักพัฒนาเพียงอย่างเดียว เพราะผู้โจมตีก็สามารถใช้ AI Agent เพื่อช่วยสร้าง ทดสอบ และปรับปรุงมัลแวร์ได้เช่นกัน

Sophos เคยพบผู้โจมตีใช้ AI Agent เพื่อพัฒนาเครื่องมือและทดสอบการหลบเลี่ยงระบบ Endpoint Detection and Response หรือ EDR โดยมีการใช้ Claude Opus 4.5 ช่วยประสานขั้นตอนการทำงาน

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

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

พฤติกรรมเดียวกันอาจมาจากหลายสถานการณ์

การเรียกใช้ DPAPI การดาวน์โหลดไฟล์ผ่านเครื่องมือของ Windows หรือการเขียนไฟล์ลงใน Startup ไม่ได้บ่งชี้เจตนาได้ชัดเจนเหมือนในอดีต

พฤติกรรมเดียวกันอาจเกิดจากหลายกรณี ได้แก่

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

ข้อมูลจาก CrowdStrike Global Threat Report 2026 ระบุว่า 82 เปอร์เซ็นต์ของเหตุการณ์ที่ตรวจพบในปี 2025 เป็นการโจมตีที่ไม่ใช้มัลแวร์โดยตรง

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

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

แนวทางลดการแจ้งเตือนจาก AI Coding Agent

Sophos แนะนำให้องค์กรแยกนโยบายตรวจจับตามระดับความเสี่ยงของแต่ละพฤติกรรม ไม่ควรปิดระบบตรวจจับทั้งหมดเพียงเพราะต้นทางเป็น AI Coding Agent ที่รู้จัก

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

• ชื่อโปรเซสหลัก เช่น claude.exe หรือ cursor.exe
• โปรเซสลูกที่ถูกสร้างจาก AI Agent
• โฟลเดอร์โครงการหรือ Workspace ที่ได้รับอนุญาต
• โฟลเดอร์ชั่วคราวที่ใช้ระหว่างการพัฒนา
• ชื่อเสียงและความน่าเชื่อถือของโดเมนปลายทาง
• Hash หรือลายเซ็นดิจิทัลของไฟล์ที่ดาวน์โหลด
• บัญชีผู้ใช้และระดับสิทธิ์ของกระบวนการ
• คำสั่งที่ AI เรียกใช้และบริบทก่อนหน้า

การกำหนดเงื่อนไขเหล่านี้ช่วยลดการแจ้งเตือนที่ไม่จำเป็น โดยไม่ต้องยกเว้นการตรวจสอบ AI Agent ทั้งหมด

การเข้าถึงข้อมูลรับรองไม่ควรถูกอนุญาตแบบครอบคลุม

Sophos เน้นว่าพฤติกรรมเกี่ยวกับข้อมูลรับรองควรถูกจัดการอย่างเข้มงวดกว่ากิจกรรมประเภทอื่น

การถอดรหัสข้อมูลจากเบราว์เซอร์ การตรวจสอบ Windows Credential Manager หรือการอ่านโทเคนของผู้ใช้ ไม่ควรถูกมองว่าปลอดภัยโดยอัตโนมัติเพียงเพราะคำสั่งดังกล่าวมาจาก AI Agent

แนวทางที่องค์กรควรนำไปใช้ ได้แก่

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

องค์กรต้องกำหนดขอบเขตการทำงานของ AI Agent

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

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

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

สรุป

AI Coding Agent อย่าง Claude Code, Cursor และ OpenAI Codex ไม่ได้เป็นมัลแวร์ แต่รูปแบบการทำงานของเครื่องมือเหล่านี้เริ่มคล้ายกับเทคนิคที่ผู้โจมตีใช้มากขึ้น

การถอดรหัสข้อมูลในเบราว์เซอร์ การตรวจสอบ Credential Manager การดาวน์โหลดไฟล์ผ่าน certutil หรือ bitsadmin และการสร้างไฟล์ใน Startup ล้วนเป็นพฤติกรรมที่ระบบรักษาความปลอดภัยมีเหตุผลเพียงพอที่จะตรวจจับ

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

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

ที่มา thehackernews

SiamGeek

The post AI Coding Agent ทำระบบรักษาความปลอดภัยแจ้งเตือน หลังพฤติกรรมคล้ายแฮกเกอร์ appeared first on SiamByte.