ทดสอบเจาะระบบ AI

การทดสอบแอปพลิเคชันที่ใช้ AI หรือ LLM ไม่เหมือนกับการทดสอบเว็บแอปพลิเคชันทั่วไป ในแอปพลิเคชันปกติ โค้ดกับข้อมูลเดินอยู่คนละเลน ตัวโปรแกรมคือคำสั่ง ส่วนผู้ใช้ป้อนได้แค่ข้อมูล แต่ language model ลบเส้นแบ่งนั้นทิ้ง เพราะมันอ่านทั้งคำสั่งและข้อมูลผ่านช่องทางเดียวกัน ข้อความที่ไม่น่าเชื่อถือชิ้นไหนที่ model เอาไปประมวลผล ก็กลายเป็นคำสั่งที่มันทำตามได้ พอเพิ่ม retrieval-augmented generation (RAG) เข้าไป model ก็เริ่มดึงเนื้อหาจากภายนอกเข้ามา ทั้งเอกสาร หน้าเว็บ หรือ ticket ที่คุณไม่ได้เขียนเองและตรวจทั้งหมดไม่ได้ และถ้าให้มันเป็น agent ที่ลงมือทำได้ มันก็ไม่ได้แค่ตอบ แต่เรียก tool ยิง API และลงมือทำอะไรบางอย่างกับระบบของคุณ ทุกจุดที่ขยับออกไปแบบนี้ เปิดช่องโหว่คนละกลุ่มกับที่ pentest ทั่วไปมองหา บริการทดสอบเจาะระบบ AI ของเราจับที่พื้นผิวตรงนั้นโดยตรง อิงตาม OWASP Top 10 for LLM Applications (2025)

ถ้าอยากเข้าใจหลักการโจมตีหลักก่อนอ่านต่อ ทีมของเราเขียนไว้แล้วที่ อธิบาย prompt injection

สิ่งที่เราทดสอบ

ทุกงานเราแมปเข้ากับ OWASP Top 10 for LLM Applications (2025) เพื่อให้ finding เรียงตรงกับ framework ที่ทีมพัฒนาและ auditor ของคุณคุ้นเคยอยู่แล้ว

• LLM01 — Prompt Injection — input ที่ออกแบบมาลบล้างคำสั่งเดิมของ model เราทดสอบทั้งแบบ direct ที่ผู้โจมตีพิมพ์ payload เข้าไปตรง ๆ และแบบ indirect ที่ payload ซ่อนอยู่ในเนื้อหาที่ model อ่านทีหลัง เช่น เอกสารหรือหน้าเว็บ
• LLM02 — Sensitive Information Disclosure — model หลุดข้อมูลที่ไม่ควรเปิดเผย ทั้งข้อมูลของผู้ใช้คนอื่น ความลับ การตั้งค่าภายใน หรือเศษข้อมูลจากชุด training
• LLM03 — Supply Chain — ความเสี่ยงที่ติดมากับ model, plugin, dataset และ library ของบุคคลที่สาม เช่น component ต้นน้ำที่ถูกแทรกแซงหรือดัดแปลงก่อนถึงแอปของคุณ
• LLM04 — Data & Model Poisoning — ข้อมูลที่เป็นอันตรายหรือถูกปนเปื้อน แทรกเข้ามาตอน train หรือ fine-tune เพื่อบิดพฤติกรรมของ model ไปทางที่ผู้โจมตีต้องการ
• LLM05 — Improper Output Handling — เอา output ของ model ไปเชื่อว่าปลอดภัยแล้วส่งตรงเข้า browser, shell, database หรือ API ปลายทาง จนกลายเป็น XSS, SQL injection หรือ command injection
• LLM06 — Excessive Agency — agent ที่ได้สิทธิ์ การเข้าถึง tool หรืออิสระในการตัดสินใจมากเกินกว่างานที่ทำจริง คำสั่งที่ถูกดัดแปลงเพียงชิ้นเดียวก็สั่งให้มันลงมือทำจริงได้
• LLM07 — System Prompt Leakage — system prompt รั่ว เปิดเผยคำสั่งที่ซ่อนไว้ กติกาทางธุรกิจ หรือความลับที่คนออกแบบคิดว่าจะไม่มีใครได้เห็น
• LLM08 — Vector & Embedding Weaknesses — จุดอ่อนในชั้น RAG ทั้ง access control ที่หละหลวมบน vector store, การทำ embedding inversion หรือเอกสารที่ถูก poison เพื่อดึง retrieval ไปหาเนื้อหาที่ผู้โจมตีเลือกไว้
• LLM09 — Misinformation — output ที่มั่นใจ ฟังดูมีเหตุผล แต่ผิด ทั้ง hallucination และการพึ่ง model มากเกินไป จนเกิดความเสียหายเมื่อผู้ใช้หรือระบบปลายทางลงมือทำตาม
• LLM10 — Unbounded Consumption — ไม่มีขีดจำกัดว่าผู้เรียกจะสั่งให้ model ทำงานได้มากแค่ไหน เปิดทางให้เกิด denial of service ค่าใช้จ่ายบานปลาย หรือการดูด model ออกไปด้วยการ query จำนวนมหาศาล

ขั้นตอนการทดสอบ

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

1. Scoping — เราวางแผนที่ของเป้าหมายร่วมกับคุณ ทั้ง model และเวอร์ชันไหน แหล่ง RAG มีอะไรบ้าง agent เข้าถึง tool และ API ตัวใดได้ และมี role หรือระดับสิทธิ์อะไรเข้ามาเกี่ยว พื้นผิวที่จะไม่ทดสอบ ตกลงกันตรงนี้ ไม่ใช่มาเจอตอนจบ
2. Static review — ตรวจ system prompt การตั้งค่า model และ guardrail หรือ content filter ที่มี เพื่อให้การทดสอบแบบ dynamic มีข้อมูลตั้งต้น ไม่ใช่งมเข้าไปเปล่า ๆ
3. Prompt injection & jailbreak testing — พยายามลบล้างพฤติกรรมที่ตั้งใจไว้ ทั้งผ่าน input ตรง ๆ และ payload แบบ indirect ที่ฝังไว้ในเนื้อหาที่ model รับเข้าไป แล้ววัดว่า guardrail ยังกันอยู่ไหมเมื่อโดนกดดัน
4. RAG & embedding testing — ทดสอบชั้น retrieval ทั้ง access control บน vector store ว่าเอกสารที่ถูก poison หรือปั้นขึ้นมาจะดึงคำตอบให้เพี้ยนได้ไหม และ embedding รั่วข้อความต้นทางที่อยู่เบื้องหลังหรือเปล่า
5. Agent & tool-abuse testing — สำหรับระบบที่เป็น agent เราทดสอบ excessive agency ตรง ๆ คำสั่งที่ถูกดัดแปลงสั่งให้ agent เรียก tool ยิง API หรือลงมือทำเกินอำนาจที่ควรมีได้ไหม
6. Output-handling & downstream-impact testing — เราตาม output ของ model ไปจนถึงสิ่งที่เอาไปใช้ต่อ แล้วดูว่า output ที่ไม่ได้ sanitize กลายเป็น XSS, injection หรือการกระทำที่ไม่ตั้งใจในระบบที่เชื่อมกันอยู่ได้ไหม
7. Reporting & retest — finding ทุกข้อเขียนพร้อมผลกระทบและแนวทางแก้ พอทีมคุณแก้เสร็จ เรา retest เพื่อยืนยันว่าแต่ละประเด็นปิดได้จริง

สิ่งที่คุณได้รับ

ทุกรายงานมีอย่างน้อยเท่านี้

• Executive summary — สรุปภาพความเสี่ยงในภาษาธุรกิจ ให้ผู้บริหารและ auditor อ่านแล้วตัดสินใจต่อได้
• Finding จัดตาม Risk Level — ทุกประเด็นให้ระดับ Critical, High, Medium หรือ Low เรียงลำดับได้เลยว่าต้องแก้อะไรก่อน
• POC ประกอบทุก finding — prompt, payload และขั้นตอนที่ทำซ้ำประเด็นนั้นได้ครบ วิศวกรของคุณไม่ต้องเดาว่าเราทำได้ยังไง
• คำแนะนำการแก้ไข — วิธีแก้ที่ผูกกับสถาปัตยกรรมของคุณจริง ไม่ใช่ boilerplate จาก scanner
• Retest ยืนยันผล — หลังคุณแก้เสร็จ เราตรวจซ้ำแล้วอัปเดตรายงานให้สะท้อนรายการที่ปิดไปแล้ว

ตลอดประวัติของบริษัท เราไม่เคยส่งรายงานเปล่าแม้แต่ฉบับเดียว ทุกงานที่ผ่านมาเจอ finding จริงที่ผ่านการยืนยันแล้วทั้งนั้น

ทีมและใบรับรอง

ทีมภายในของเราลงมือทดสอบเองทุกงาน ถือใบรับรองในวงการอย่าง OSCP, OSCE, CREST CRT, CREST CPSA และ GIAC GREM ที่ต้องผ่านการสอบภาคปฏิบัติอย่างเข้มข้นกว่าจะได้มา ทีมเดียวกันนี้เอาพื้นฐานสาย offensive security มาจับพื้นผิวการโจมตี AI ที่เพิ่งเกิดใหม่ ดูใบรับรองทั้งหมดที่ทีมถือ

มาตรฐานที่ใช้

การทดสอบ AI ของเราอิงกับ framework ที่วงการมาลงตัวร่วมกัน

• OWASP Top 10 for LLM Applications (2025) — แกนหลักของสิ่งที่เราทดสอบ ตามที่ไล่ไว้ด้านบน
• OWASP Machine Learning Security Top 10 — สำหรับความเสี่ยงในชั้น ML ที่อยู่ใต้แอป generative
• MITRE ATLAS — ฐานความรู้ภัยคุกคามเชิงปฏิปักษ์สำหรับระบบ AI ใช้ไล่เหตุผลว่าผู้โจมตีใช้เทคนิคอะไรได้บ้าง
• NIST AI RMF — กรอบการบริหารความเสี่ยงที่เราเทียบ finding เข้าไป เมื่อคุณต้องคุยกับฝั่ง governance

pentest บอกคุณว่าระบบ AI พังตรงไหนได้ในวันนี้ แต่การรักษาให้ปลอดภัยต่อเนื่องขณะที่มันพัฒนาไปเป็นโจทย์ฝั่ง governance คือการวาง AI Management System รอบมาตรฐาน ISO/IEC 42001 ซึ่งทีม consulting ของเราดูแลส่วนนี้ การทดสอบกับการวาง governance เสริมกัน อย่างหนึ่งพิสูจน์สถานะปัจจุบัน อีกอย่างรักษาให้ยืนหยัดได้ในระยะยาว