Shadow MCP: จุดบอดของ AI Agent ที่ SOC ขององค์กรไทยยังมองไม่เห็น

เมื่อตุลาคม 2025 เราเคยเขียนบทความเชิงบวกเรื่อง Agentic AI และ MCP Servers ว่าจะเป็นก้าวต่อไปของระบบอัตโนมัติ สถาปัตยกรรมนั้นยังใช้ได้จริง แต่ภาพด้านความปลอดภัยรอบ ๆ มันเปลี่ยนไปมากในรอบ 11 เดือนที่ผ่านมา และ SOC ส่วนใหญ่ยังตามไม่ทัน

MCP (Model Context Protocol) คือช่องทางที่ AI client อย่าง Cursor, Claude Desktop, VS Code และ agent framework ต่าง ๆ ใช้เชื่อมต่อกับเครื่องมือจริง เช่น ฐานข้อมูล, Git repository, ระบบ ticket หรือ shell โดยแต่ละการเชื่อมต่อคือ MCP server หนึ่งตัว ข้อมูลที่รวบรวมไว้ช่วงกลางปี 2026 ระบุว่า MCP server ถึง 86% รันอยู่บนเครื่องของนักพัฒนา และมีเพียง 5% ที่รันในสภาพแวดล้อม production ประโยคนี้สรุปปัญหาทั้งหมด: ชั้นการเชื่อมต่อที่โตเร็วที่สุดในองค์กร กำลังอยู่บน endpoint ที่ SOC มองว่าเป็นแค่โน้ตบุ๊กธรรมดา ถูกเรียกขึ้นมาเป็น child process ที่ไม่มีใครทำบัญชีไว้ และถือ credential ที่ไม่เคยมีใครหมุนเวียน

ปี 2026 มีอะไรเปลี่ยนไป: ตัวเลขที่ควรรู้

• มี CVE มากกว่า 30 รายการถูกยื่นต่อ MCP server ภายในช่วง 60 วันเมื่อต้นปี 2026 และราว 43% เป็นช่องโหว่ประเภท command injection
• โครงการ Vulnerable MCP Project ติดตาม ช่องโหว่ที่รู้จักแล้วกว่า 50 รายการ ในจำนวนนี้ 13 รายการอยู่ในระดับ critical
• การตรวจ MCP server กว่า 5,200 ตัวพบว่า 53% ใช้ API key หรือ personal access token แบบถาวร 79% ส่งคีย์ผ่าน environment variable และมีเพียง 8.5% ที่ใช้ OAuth
• GitGuardian พบ secret 24,008 รายการในไฟล์ config ที่เกี่ยวกับ MCP บน GitHub สาธารณะ โดย 2,117 รายการยังใช้งานได้จริง
• CVE-2025-6514 ใน mcp-remote (CVSS 9.6) ทำให้ผู้โจมตีรันโค้ดบนเครื่อง client ได้เมื่อเชื่อมต่อกับ server ที่ไม่น่าเชื่อถือ โดยแพ็กเกจนี้ถูกดาวน์โหลดไปแล้วกว่า 437,000 ครั้ง
• CVE-2025-54136 ("MCPoison") ใน Cursor แสดงรูปแบบที่แนบเนียนกว่านั้น คือไฟล์ MCP config ที่เคยได้รับความเชื่อถือแล้ว ถูกสลับเป็นเวอร์ชันอันตรายอย่างเงียบ ๆ ภายหลัง

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

ทำไม MCP ถึงเป็นจุดบอดของ SOC

บทความก่อนหน้าของเราเรื่อง Agentic AI SOC ปี 2026 พูดถึง AI agent ที่ทีม security รู้จักและควบคุมเอง แต่ Shadow MCP ต่างออกไป เพราะนี่คือ agent และการเชื่อมต่อเครื่องมือที่ พนักงานตั้งขึ้นเอง ส่วนใหญ่ด้วยเจตนาดี เพื่อให้ทำงานเร็วขึ้น

flowchart TD
    A["โน้ตบุ๊กของนักพัฒนา"] --> B["AI client เช่น Cursor หรือ Claude Desktop"]
    B --> C["ไฟล์ MCP config ระบุ server และคีย์"]
    C --> D["MCP server ถูกเปิดเป็น child process"]
    D --> E["Token ถาวรสำหรับ Git ฐานข้อมูล หรือ SaaS API"]
    E --> F["เข้าถึงระบบภายในด้วยบัญชีของนักพัฒนา"]

มองจากฝั่ง SOC ทุกขั้นในห่วงโซ่นี้ดูปกติไปหมด:

1. process ดูปกติ MCP server ที่รันผ่าน STDIO มักเป็นแค่ node, npx, python หรือ uvx ที่รันด้วยสิทธิ์ของผู้ใช้ ไม่มี service ใหม่ ไม่มีตัวติดตั้ง ไม่มี binary แปลกหน้าให้จับ
2. credential ดูถูกต้อง token เป็นของพนักงานตัวจริง เมื่อ agent ไป query ฐานข้อมูลลูกค้า log ฝั่งฐานข้อมูลจะเห็นเป็นชื่อพนักงานคนนั้น ไม่ใช่ "AI agent ที่ทำตามคำสั่งจาก tool description"
3. การเรียก tool ไม่ถูกบันทึกในที่ที่เราเก็บ log การสื่อสารของโปรโตคอล MCP เกิดขึ้นภายใน process ของ client ถ้าไม่มี gateway คั่นกลาง ก็ไม่มี audit trail เลยว่าเรียก tool อะไร ด้วย argument อะไร
4. ไม่มีใครเป็นเจ้าของบัญชีรายการ ฝ่าย IT ไม่ได้ติดตั้ง ฝ่าย security ไม่ได้อนุมัติ และนักพัฒนาอาจเพิ่มเข้าไปอีกสามตัวเมื่อสัปดาห์ที่แล้ว

ทีมวิจัยของ Obsidian จึงสรุปว่าความปลอดภัยของ MCP เป็น "ปัญหาการทำบัญชีรายการ" ก่อนจะเป็นอย่างอื่น เพราะเราไม่สามารถ patch, หมุน credential หรือเฝ้าระวัง server ที่เราไม่รู้ว่ามีอยู่ได้

4 ชั้นการตรวจจับบน Wazuh ที่เริ่มได้ภายในเดือนนี้

ทั้งหมดต่อไปนี้ไม่ต้องซื้อผลิตภัณฑ์ใหม่ เป็น รูปแบบอ้างอิง (reference pattern) สำหรับ Wazuh 4.x ทุกระบบ รวมถึง simpliSOC แต่ไม่ใช่โมดูล MCP สำเร็จรูปของ simpliSOC ซึ่งเราจะแยกให้ชัดในหัวข้อถัดไป

flowchart TD
    L1["ชั้นที่ 1 FIM บนไฟล์ MCP config"] --> W["Wazuh manager"]
    L2["ชั้นที่ 2 ข้อมูลการสร้าง process"] --> W
    L3["ชั้นที่ 3 พอร์ตที่เปิดรอรับใหม่"] --> W
    L4["ชั้นที่ 4 สแกน secret ก่อน commit"] --> W
    W --> R["เคสใน DFIR-IRIS ให้ analyst ตรวจสอบ"]

ชั้นที่ 1: File Integrity Monitoring บนไฟล์ MCP config

MCPoison พิสูจน์แล้วว่าไฟล์ config เป็นกลไกฝังตัว (persistence) ได้ จึงต้องเฝ้าดู ให้เพิ่มตำแหน่งไฟล์ config ของ client ที่รู้จักลงใน syscheck ของ Wazuh โดยจำกัดขอบเขตเฉพาะกลุ่ม agent "เครื่องนักพัฒนา" เพื่อไม่ต้องสแกนโปรไฟล์ผู้ใช้ทั้งองค์กร

<!-- agent.conf, group: dev-workstations (ตัวอย่าง Linux/macOS) -->
<syscheck>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/home</directories>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/Users</directories>
</syscheck>

จากนั้นยกระดับ alert เมื่อไฟล์เหล่านี้ถูกสร้างหรือแก้ไข:

<!-- local_rules.xml -->
<group name="mcp,syscheck,">
  <rule id="100910" level="10">
    <if_sid>550, 554</if_sid>
    <field name="file">mcp.json$|claude_desktop_config.json$</field>
    <description>MCP client configuration added or modified: $(file)</description>
    <mitre>
      <id>T1546</id>
    </mitre>
  </rule>
</group>

สิ่งที่เราตั้งใจไม่ทำ: อย่าเปิด report_changes กับ path เหล่านี้ เพราะไฟล์เหล่านี้มักมี API key อยู่ข้างใน และ report_changes จะคัดลอก diff รวมทั้ง secret ไปเก็บไว้ใน alert index เราต้องการรู้แค่ว่าไฟล์เปลี่ยน ไม่ใช่สร้างสำเนาของ secret ไว้อีกที่หนึ่งซึ่งต้องปกป้องเพิ่ม

ชั้นที่ 2: ข้อมูลการสร้าง process เมื่อ MCP server ถูกเปิด

สำหรับเครื่อง Windows ที่ส่ง Sysmon Event ID 1 เข้า Wazuh อยู่แล้ว rule ระดับต่ำตัวนี้จะเปลี่ยนการเปิด MCP server ให้เป็นบันทึกที่ค้นหาได้:

<group name="mcp,sysmon,">
  <rule id="100911" level="5">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(mcp-remote|@modelcontextprotocol|mcp-server|mcp_server)</field>
    <description>MCP server process launched: $(win.eventdata.commandLine)</description>
  </rule>
</group>

ระดับ 5 เป็นความตั้งใจ บนเครื่องนักพัฒนา rule นี้จะดังบ่อย และนั่นคือเป้าหมาย หลังสองสัปดาห์คุณจะมีบัญชีรายการว่า MCP server ตัวไหนรันจริง บนเครื่องใด เรียกโดย process อะไร เมื่อรู้ว่าอะไรคือ "ปกติ" แล้ว จึงเขียน rule ระดับสูงสำหรับข้อยกเว้น เช่น mcp-remote เวอร์ชันต่ำกว่า 0.1.16 หรือ MCP server ที่รันบนเครื่องนอกกลุ่มนักพัฒนา สำหรับ Linux ใช้แนวทางเดียวกันผ่าน auditd execve หรือ osquery

ชั้นที่ 3: พอร์ตที่เปิดรอรับใหม่บนเครื่องนักพัฒนา

MCP server ที่ใช้ HTTP transport บางตัว bind กับ 0.0.0.0 เป็นค่าเริ่มต้น ทำให้เครื่องมือบนโน้ตบุ๊กกลายเป็นบริการเครือข่ายที่ใครในวง LAN เดียวกันก็เรียกได้ config เริ่มต้นของ Wazuh มีคำสั่ง netstat สำหรับพอร์ตที่เปิดรอรับ และ rule 533 ที่จะดังเมื่อชุดพอร์ตเปลี่ยนอยู่แล้ว ให้ตรวจว่าเปิดใช้กับกลุ่มเครื่องนักพัฒนา และส่ง alert ของ rule 533 จากกลุ่มนี้เข้าคิวตรวจสอบ แทนที่จะปล่อยให้จมหายไปกับ noise พอร์ตใหม่ที่เจ้าของเป็น node หรือ python บนโน้ตบุ๊กควรค่าแก่การดู

ชั้นที่ 4: สแกน secret ก่อนไฟล์ config จะหลุดเข้า Git

secret 24,008 รายการไม่ได้รั่วจาก production แต่รั่วจากไฟล์ config ที่ถูก commit ขึ้น repository ชั้นนี้ Wazuh ไม่ใช่เครื่องมือที่เหมาะ ให้ใช้ secret scanner ใน pre-commit และ CI เช่น gitleaks หรือ TruffleHog โดยเพิ่มชื่อไฟล์ MCP config เข้าไปในขอบเขต แล้วส่งผลการสแกนเข้า Wazuh เป็น log source เพื่อให้เหตุการณ์คีย์รั่วเข้าสู่ workflow เคสเดียวกับเรื่องอื่น

แก้ที่โมเดลการยืนยันตัวตน ไม่ใช่แค่การตรวจจับ

การตรวจจับบอกเราได้ว่า MCP server ของนักพัฒนาถือ GitHub token อายุยาวอยู่ แต่ไม่ได้แก้ปัญหาที่ token นั้นมีอยู่ สเปก MCP ฉบับปรับปรุงเดือนมิถุนายน 2025 แนะนำให้ server ที่ใช้ HTTP ใช้ OAuth 2.1 ร่วมกับ PKCE และแยก resource server ออกจาก authorization server แต่ในทางปฏิบัติ MCP server ภายในองค์กรส่วนใหญ่ยังรับคีย์แบบถาวร เพราะสร้างได้เร็วที่สุด

สำหรับ MCP server ที่ทีมภายในสร้างขึ้นเอง แนวทางที่ดีกว่าคือวางไว้หลัง identity provider เดิมขององค์กร ให้ทุกการเรียก tool มี token อายุสั้นผูกกับผู้ใช้จริง จำกัดสิทธิ์เฉพาะ tool ที่ผู้ใช้คนนั้นต้องใช้ และเพิกถอนได้จากศูนย์กลาง simpliSSO ซึ่งสร้างบน Authentik คือส่วนที่เราใช้ในงานลูกค้า โดยขอระบุให้ชัดว่า การใช้ simpliSSO เป็น authorization server ให้ MCP server เป็น รูปแบบการเชื่อมต่อที่เรากำหนดขอบเขตเป็นรายโครงการ ไม่ใช่ฟีเจอร์ MCP สำเร็จรูปของ simpliSSO

ทำไมเรื่องนี้สำคัญเป็นพิเศษในบริบทไทย

PDPA: ถ้า MCP server บนเครื่องนักพัฒนาถือ token ที่เข้าถึงฐานข้อมูลลูกค้า และ token นั้นรั่ว เหตุการณ์นี้อาจเข้าข่ายการละเมิดข้อมูลส่วนบุคคลที่ผู้ควบคุมข้อมูลต้องแจ้งสำนักงานคณะกรรมการคุ้มครองข้อมูลส่วนบุคคลภายใน 72 ชั่วโมงนับแต่ทราบเหตุ คำถามแรกที่จะถูกถามคือ "token นี้ถูกใช้ทำอะไรไปบ้าง" ซึ่งถ้าไม่มีบัญชีรายการ MCP และไม่มี log การเรียก tool ก็แทบตอบไม่ได้

พ.ร.บ.การรักษาความมั่นคงปลอดภัยไซเบอร์ มาตรา 59: หน่วยงานโครงสร้างพื้นฐานสำคัญทางสารสนเทศต้องรายงานและรับมือเหตุภัยคุกคามตามกรอบเวลาที่กำหนด การที่ SOC มองไม่เห็นช่องทางที่ agent ใช้เข้าถึงระบบภายใน ทำให้การสืบสวนและรายงานยากขึ้นมาก

ร่าง พ.ร.บ. ปัญญาประดิษฐ์: สพธอ. (ETDA) เผยแพร่ร่างฉบับใหม่เมื่อ 2 กรกฎาคม 2026 เพื่อรับฟังความคิดเห็น ร่างนี้ยังไม่ใช่กฎหมายที่มีผลบังคับ แต่ถ้าผ่านในรูปแบบปัจจุบัน ผู้นำระบบ AI ความเสี่ยงสูงไปใช้งานจะต้องมีระบบบริหารความเสี่ยง มีผู้ดูแลที่มีความสามารถ และเก็บ log การทำงานไว้ไม่น้อยกว่าระยะเวลาขั้นต่ำ (ตามร่างภาษาไทยคือหกเดือน) องค์กรที่เริ่มเก็บบัญชีรายการ MCP และ log ตั้งแต่ตอนนี้ จะเตรียมตัวได้ง่ายกว่ามาก

ส่วนที่ใช้งานได้จริงวันนี้ กับส่วนที่เป็นรูปแบบอ้างอิง

สิ่งที่ simpliSOC มีให้ใช้งานวันนี้ และบทความนี้อาศัยอยู่:

• File integrity monitoring, การรับ log จาก Sysmon และ command monitoring ของ Wazuh ที่ติดตั้งและปรับจูนรายลูกค้า
• การจัดการเคสด้วย DFIR-IRIS สำหรับให้ analyst ตรวจสอบ alert ข้างต้น
• ผู้ช่วย triage ด้วย local LLM แบบอ่านอย่างเดียว ตามที่อธิบายในบทความ Agentic AI SOC ซึ่งอธิบาย alert เหล่านี้เป็นภาษาที่เข้าใจง่ายได้

สิ่งที่เป็นรูปแบบอ้างอิงในบทความนี้ ไม่ใช่ฟีเจอร์ที่ส่งมอบแล้ว:

• rule MCP ข้างต้น (rule ID 100910 และ 100911) ที่เราติดตั้งและปรับจูนในงานลูกค้า ไม่ได้อยู่ใน ruleset สำเร็จรูปของ simpliSOC
• การบันทึกการเรียก tool รายครั้งผ่าน MCP gateway หรือ proxy
• รายงานบัญชีรายการ MCP server แบบอัตโนมัติทั้งองค์กร
• simpliSSO ในบทบาท authorization server แบบ OAuth 2.1 สำหรับ MCP ซึ่งกำหนดขอบเขตเป็นรายโครงการ

แผนเริ่มต้น 30 วัน

1. สัปดาห์ที่ 1: สร้างกลุ่ม agent สำหรับเครื่องนักพัฒนา แล้วเปิดชั้นที่ 2 ที่ระดับ 5 ยังไม่ต้องแจ้งเตือน แค่เก็บข้อมูล
2. สัปดาห์ที่ 2: ตรวจบัญชีรายการที่ได้ จัดกลุ่ม MCP server แต่ละตัวเป็น อนุมัติ, ยอมรับได้ชั่วคราว หรือต้องถอดออก
3. สัปดาห์ที่ 3: เปิดชั้นที่ 1 (FIM บน config) และชั้นที่ 3 (พอร์ต) ให้กลุ่มนี้ และเพิ่มชื่อไฟล์ MCP config เข้า secret scanner
4. สัปดาห์ที่ 4: หมุนเวียน token ถาวรทุกตัวที่พบในสัปดาห์ที่ 2 และย้าย MCP server ภายในที่ใช้บ่อยที่สุดไปอยู่หลัง identity provider

คำถามที่พบบ่อย

MCP ปลอดภัยโดยการออกแบบไม่ใช่หรือ บทความปี 2025 ของคุณเองก็บอกว่า MCP ให้ความปลอดภัย
MCP ให้ "ตำแหน่งมาตรฐาน" สำหรับวางการควบคุม แต่ไม่ได้วางการควบคุมให้เรา การยืนยันสิทธิ์ในสเปกเป็นทางเลือก server แบบ STDIO ไม่มีการยืนยันตัวตนทางเครือข่ายเลย และ server ส่วนใหญ่ที่ใช้งานจริงใช้คีย์แบบถาวร บทความปี 2025 อธิบายสิ่งที่ MCP ทำให้เป็นไปได้ ส่วนบทความนี้อธิบายว่าการใช้งานจริงส่วนใหญ่ในปี 2026 เป็นอย่างไร

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

rule ชั้นที่ 2 จะทำให้ SIEM ท่วมไหม
บนเครื่องนักพัฒนาจะดังถี่ในช่วงแรก จึงเริ่มที่ระดับ 5 และเฉพาะกลุ่มนักพัฒนา หน้าที่ของมันคือสร้างบัญชีรายการ ไม่ใช่ปลุกใครกลางดึก

AI ของ simpliSOC ตรวจจับ tool poisoning ได้อัตโนมัติไหม
ไม่ได้ ผู้ช่วย local LLM ของเราอธิบาย alert ที่ Wazuh สร้างขึ้นแล้ว แต่ไม่ได้ตรวจ tool description ของ MCP ขณะทำงาน การจับ tool poisoning ต้องมองเห็นการสื่อสารของโปรโตคอลโดยตรง ซึ่งคือรูปแบบ gateway ที่เราระบุไว้ว่ายังไม่ได้ส่งมอบ

---

ถ้าคุณใช้ Wazuh อยู่และต้องการให้ช่วยแปลงรูปแบบเหล่านี้เป็น rule ที่ปรับจูนสำหรับ endpoint ของคุณเอง หรือต้องการวาง MCP server ภายในไว้หลังระบบยืนยันตัวตนที่ถูกต้อง นั่นคืองานที่เราทำ ดูรายละเอียดที่ simpliSOC และ simpliSSO หรือส่งอีเมลเล่าสภาพแวดล้อมของคุณสั้น ๆ มาที่ hello@simplico.net

---

แหล่งที่มา:

• MCP Security Statistics 2026: CVEs, Vulnerabilities & Breach Data — Practical DevSecOps
• MCP Security Vulnerabilities: Complete Threat Inventory — Obsidian Security
• Thailand Releases New Draft Artificial Intelligence Act — Tilleke & Gibbins
• Agentic AI และ MCP Servers — Simplico