AI Supply Chain Breach ครั้งใหญ่ 2,500 กว่าองค์กร และ 434,000 CI/CD Pipelines อาจได้รับผลกระทบ

CloudSEK เปิดเผยผลการวิเคราะห์เหตุการณ์ Supply Chain Attack ที่เกี่ยวข้องกับ LiteLLM โดยประเมินว่ามีองค์กรมากกว่า 2,500 แห่ง และ CI/CD Pipelines ประมาณ 434,000 รายการ อยู่ในชุดข้อมูลที่อาจได้รับการเปิดเผย จากเหตุการณ์โจมตีในเดือนมีนาคม 2026 ซึ่งแคมเปญดังกล่าวถูกเชื่อมโยงกับกลุ่มผู้โจมตี TeamPCP

อย่างไรก็ตาม สิ่งสำคัญที่ต้องทำความเข้าใจคือ ตัวเลขดังกล่าวเป็น Reconstructed Exposure Dataset ซึ่ง CloudSEK ได้ระบุว่าไม่ควรถูกตีความว่าทุกองค์กรในรายการถูกโจมตีสำเร็จ หรือ Credentials ของทุกองค์กรถูกขโมยไปแล้ว

การพบชื่อองค์กรในชุดข้อมูลจึงหมายถึง Potentially Exposed ต้องมีการตรวจสอบเพิ่มเติมก่อนสรุปว่าเกิด Compromise ขึ้นจริง

ตรวจสอบองค์กรของคุณ

CloudSEK ได้เปิดให้ใช้งาน AI Supply Chain Incident Exposure Checker เพื่อช่วยให้องค์กรตรวจสอบว่าชื่อองค์กรปรากฏอยู่ใน Exposure Dataset ของเหตุการณ์นี้หรือไม่ https://exposure.cloudsek.com/ai-supply-chain-incident

หากพบองค์กรอยู่ใน Dataset ควรใช้ผลลัพธ์เป็นจุดเริ่มต้นสำหรับการตรวจสอบภายใน เช่น ตรวจ Build และ Dependency History, ตรวจสอบ Credentials ที่อาจเข้าถึงได้, Review Logs และดำเนินการ Rotate Credentials ตามระดับความเสี่ยง

Supply Chain Attack ลุกลามไปยังระบบอื่นได้อย่างไร?

CloudSEK ระบุว่า Trivy ซึ่งเป็น Security Scanner ที่อยู่ Upstream ในกระบวนการพัฒนา ถูกผู้โจมตีเข้าควบคุม โดยเกี่ยวข้องกับ Automation Token ที่รั่วไหลและแม้จะมีการ Rotate แล้ว แต่ไม่ได้ถูก Revoke อย่างสมบูรณ์ เปิดช่องให้ผู้โจมตีสามารถแทนที่โค้ดภายใต้ Version Tags ที่ดูเหมือนถูกต้องได้

LiteLLM CI Pipeline มีการติดตั้ง Trivy โดยไม่ได้ Pin Dependency ไว้อย่างเข้มงวด ทำให้ Compromised Scanner ไหลเข้าสู่ Build Process โดยอัตโนมัติ และนำไปสู่การสร้างและเผยแพร่ LiteLLM เวอร์ชัน 1.82.7 และ 1.82.8 ที่ได้รับผลกระทบบน PyPI

Package ดังกล่าวอยู่บน PyPI ในช่วง Exposure ประมาณ 40 นาที แต่ด้วยลักษณะการทำงานแบบ Automation ของ CI/CD ทำให้ Scheduled Jobs, Dependency Resolvers, Build Runners, Developer Machines และ Cached Layers สามารถ Download และกระจาย Package ไปยัง Environment อื่นได้อย่างรวดเร็ว

ดังนั้น แม้ Malicious Package จะปรากฏอยู่บน Repository เพียงช่วงเวลาสั้น ๆ แต่ผลกระทบที่ตามมาอาจใช้เวลาในการตรวจสอบและจัดการนานกว่านั้นมาก

จุดที่น่ากังวลคือไม่ต้อง import LiteLLM ก็อาจทำงานได้

อีกหนึ่งรายละเอียดทางเทคนิคที่สำคัญคือ Malicious Payload ถูกนำมาใช้ผ่านไฟล์ .pth

CloudSEK ระบุว่าไฟล์ประเภทนี้สามารถทำงานเมื่อ Python Interpreter เริ่มต้นได้ โดย ไม่จำเป็นต้องมีการ import LiteLLMโดยตรง หมายความว่า Environment ที่มี Package ที่ได้รับผลกระทบติดตั้งอยู่ก็อาจมีโอกาสรัน Payload ดังกล่าวได้

เป้าหมายสำคัญคือ Credentials

ความเสี่ยงสำคัญของเหตุการณ์นี้คือข้อมูลและสิทธิ์ที่ CI/CD Runner หรือ Environment นั้นสามารถเข้าถึงได้

CloudSEK ระบุว่า Credential Stealer ซึ่ง Google ติดตามภายใต้ชื่อ SANDCLOCK สามารถค้นหาและเก็บข้อมูลสำคัญจาก CI Runner ที่ได้รับผลกระทบได้

ข้อมูลที่อาจตกอยู่ในความเสี่ยงประกอบด้วย

• Cloud Credentials ของ AWS, Google Cloud และ Microsoft Azure
• GitHub/GitLab Tokens, SSH Keys และ Deploy Keys
• Kubernetes Tokens และ Service Accounts
• Environment Variables, .env Files และ CI/CD Secrets
• Package Publishing และ Container Registry Credentials
• Database, SaaS และ Webhook Credentials
• LLM API Keys และ AI Gateway Credentials
• Private Source Code, Build Images และ Build Artifacts

CloudSEK ระบุเพิ่มเติมว่า Cloud Credentials บางประเภทสามารถถูกอ่านผ่าน Instance Metadata Service ขณะที่ Kubernetes Tokens สามารถอยู่ใน Mounted Service Account Paths ซึ่งหมายความว่าผู้โจมตีอาจไม่จำเป็นต้องใช้ช่องโหว่เพิ่มเติม หาก Process ที่ได้รับผลกระทบมีสิทธิ์เข้าถึงข้อมูลเหล่านี้อยู่แล้ว

หาก Credentials ถูกนำออกจาก Environment ได้สำเร็จ ผลกระทบจึงอาจไม่ได้หยุดอยู่ที่เครื่องหรือ Package ต้นทาง แต่สามารถขยายไปยัง Cloud Accounts, Source Code Repositories, Kubernetes Clusters, Package Registries, SaaS Platforms, Databases และ AI Services ขององค์กรได้

ที่สำคัญ การนำ Malicious Package ออกจาก Repository ไม่ได้หมายความว่า Incident สิ้นสุดลง เพราะ Credentials ที่ถูกคัดลอกออกไปสามารถถูกนำกลับมาใช้ในภายหลังได้ หากยังไม่ได้รับการ Rotate หรือ Revoke

ทำไม AI Infrastructure กลายเป็นเป้าหมายสำคัญ?

AI Infrastructure ขององค์กรยุคใหม่กำลังกลายเป็นจุดเชื่อมระหว่าง Data, Identity, Compute และ Automation

AI Gateway, Agent Runtime, Model Endpoint, Vector Database และ MCP Server อาจเชื่อมต่อกับ Model Providers, Cloud Services, Databases, Plugins และ Internal Business Applications หลายระบบพร้อมกัน

นอกจากนี้ Agentic AI Workflows ยังอาจมี Permission ให้สามารถอ่านและเขียนข้อมูล เรียกใช้ Tools หรือ Trigger Business Processes ได้โดยอัตโนมัติ ซึ่งทำให้ผลกระทบจาก Credential ที่ถูกขโมยมีโอกาสขยายวงกว้างขึ้น

อีกหนึ่งความท้าทายคือองค์กรอาจนำ AI Services มาใช้งานเร็วกว่าที่ทีม Security สามารถจัดทำ Inventory ได้ครบถ้วน ส่งผลให้เกิด Shadow AI, Unknown AI Assets และ Unmanaged Credentials ที่อยู่นอกการมองเห็นของทีมรักษาความปลอดภัย

เหตุการณ์ LiteLLM จึงเป็นอีกหนึ่งสัญญาณว่า Cybersecurity ในยุค AI ไม่ควรพิจารณาเฉพาะ Application, Endpoint หรือ Network เท่านั้น แต่จำเป็นต้องครอบคลุมไปถึง AI Dependencies, Software Supply Chain และ AI Attack Surface ด้วย

องค์กรควรทำอะไรต่อไป?

สำหรับองค์กรที่ใช้งาน LiteLLM หรือมี CI/CD Environment ที่อาจเกี่ยวข้องกับเหตุการณ์นี้ CloudSEK แนะนำให้เริ่มตรวจสอบว่า Environment เคยมีการใช้งาน LiteLLM เวอร์ชัน 1.82.7 หรือ 1.82.8 หรือไม่ รวมถึงตรวจสอบ Runner, Host, Container Image และ Cache ที่อยู่ในช่วงเวลาที่เกี่ยวข้อง

หากพบความเป็นไปได้ที่จะได้รับ Exposure ควรพิจารณาดำเนินการดังนี้

• Rotate Credentials ทุกประเภทที่ Process หรือ CI/CD Runner ที่ได้รับผลกระทบสามารถเข้าถึงได้ ไม่ใช่เฉพาะ LLM หรือ LiteLLM Credentials
• ตรวจสอบ Cloud, Source Control, Package Registry และ Kubernetes/Cluster Audit Logs
• Isolate Runner, Host, Image หรือ Cache ที่อาจได้รับผลกระทบ
• Rebuild Environment จาก Known-clean Source
• ตรวจสอบ Token Usage, Login, Service Account หรือ Network Egress ที่ผิดปกติ
• Pin Dependencies และ GitHub Actions ด้วย Verified Hashes
• ลดอายุและ Scope ของ Credentials และพิจารณาใช้ Workload Identity แทน Static Keys
• Monitor CI/CD Runtime Behavior และ Third-party AI Dependencies อย่างต่อเนื่อง
• จัดทำ Inventory ของ AI Assets, AI Services และผู้รับผิดชอบระบบ ให้ชัดเจน

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

การไม่พบกิจกรรมที่ผิดปกติไม่ได้หมายความว่า Credential ไม่เคยถูกคัดลอกออกไป และในหลายกรณีต้นทุนในการ Rotate Credential ต่ำกว่าความเสียหายจากการ Contain Incident ล่าช้า

ยกระดับการมองเห็นความเสี่ยงใน AI และ Software Supply Chain ด้วย CloudSEK

Cybersecurity ในยุค AI ไม่สามารถพิจารณาเฉพาะระบบที่องค์กรพัฒนาขึ้นเองได้ เพราะ Library, Package, SDK, Model Provider, Plugin และ Third-party Service ที่เชื่อมต่อเข้าสู่ Development และ AI Ecosystem สามารถกลายเป็นส่วนหนึ่งของ Attack Surface ได้ทั้งหมด

BMSP พร้อมช่วยให้องค์กรเพิ่ม Visibility ต่อความเสี่ยงใน Digital และ AI Supply Chain ด้วยโซลูชันจาก CloudSEKเพื่อให้องค์กรมองเห็น Exposure ที่กระจายอยู่ตั้งแต่ Third-party Dependencies ไปจนถึง AI Infrastructure และ External Attack Surface

มองเห็นความเสี่ยงก่อนถูกนำไปใช้เป็นช่องทางโจมตี และเสริมความมั่นคงปลอดภัยให้กับทุกส่วนของ Digital & AI Supply Chain ด้วย CloudSEK Managed by BMSP

อ้างอิง

• CloudSEK