Shai-Hulud บุก npm: หนอนขโมยข้อมูลลามกว่า 1,280 แพ็กเกจในไม่กี่ชั่วโมง

จุดเริ่มต้น: บัญชีผู้ดูแลถูกยึด

เวลาประมาณ 09:00 น. UTC ของวันที่ 4 สิงหาคม ผู้โจมตีเข้าควบคุมบัญชี GitHub ของ Jared Wray (jaredwray) และใช้สิทธิ์ดังกล่าวผลักโค้ดอันตรายเข้า main ของรีโพซิทอรี keyv พร้อมสร้างรีลีสใหม่ในตระกูลแพ็กเกจ keyv และ cacheable

ระยะแรกมีแพ็กเกจที่เป็นต้นทางของการแพร่เชื้อ 11 รายการ ครอบคลุมสอง namespace เช่น keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache และ file-entry-cache นักวิจัยจาก Aikido Security, StepSecurity, Socket และ Chainguard ต่างยืนยันเหตุการณ์ดังกล่าวในช่วงแรกของการโจมตี

โค้ดอันตรายทำงานอย่างไร

แพ็กเกจที่ถูกวางยาทุกรายการมีรูปแบบการติดเชื้อคล้ายกัน ได้แก่ ไฟล์ใหม่สองไฟล์คือ setup.mjs และ Math_Symbol.js รวมถึงการแก้ไข package.json ให้มีคำสั่งต่อไปนี้:

"preinstall": "node setup.mjs"

เมื่อผู้พัฒนาหรือระบบ CI/CD เรียกใช้ npm install สคริปต์ setup.mjs ซึ่งทำหน้าที่เป็น dropper จะทำงานโดยอัตโนมัติก่อนการติดตั้งเสร็จสิ้น จากนั้นดาวน์โหลดไบนารีของรันไทม์ JavaScript Bun ที่ถูกต้องจาก GitHub Releases แล้วใช้ Bun เปิด payload ระยะที่สองซึ่งถูกทำให้อ่านได้ยาก ชื่อ Math_Symbol.js ขนาดประมาณ 710–728 KB

Microsoft Threat Intelligence ระบุว่า payload นี้เป็นสายพันธุ์ Mini Shai-Hulud โดยมุ่งเก็บข้อมูลรับรองและความลับจากสภาพแวดล้อมที่ติดเชื้อหลายประเภท รายการที่ถูกตรวจสอบว่าตกเป็นเป้าหมาย ได้แก่

• โทเคนยืนยันตัวตนของ npm
• GitHub Personal Access Tokens หรือ PATs
• คีย์ AWS
• ความลับของ Kubernetes
• โทเคน HashiCorp Vault
• คีย์ Stripe
• โทเคน Slack
• คีย์ SSH
• ไฟล์สถานะ Terraform
• ข้อมูลรับรอง Docker
• การตั้งค่า VPN

จากแพ็กเกจหนึ่งสู่หลายร้อยแพ็กเกจ: กลไกแพร่ตัวเอง

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

ตัวเลขการติดเชื้อเพิ่มขึ้นอย่างรวดเร็ว:

• ภายในเวลาประมาณ 2 ชั่วโมง StepSecurity ติดตามพบแพ็กเกจที่ถูกวางยาพิษ 435 รายการ รวม 1,557 เวอร์ชัน
• ช่วงบ่ายต้น ๆ ตามเวลา CEST Aikido Security นับได้ 868 แพ็กเกจ ใน 1,381 เวอร์ชัน
• เมื่อสิ้นวัน จำนวนเพิ่มเป็นมากกว่า 1,280 แพ็กเกจ และ 1,680 เวอร์ชัน ตามรายงานของ BleepingComputer และสื่ออื่น ๆ

หนอนไม่ได้จำกัดอยู่แค่ namespace keyv หรือ cacheable แต่ข้ามไปยังแพ็กเกจของผู้ดูแลและองค์กรอื่น เช่น Deliveroo, Ornikar, OneReach, Picsart, Qlik และ ServiceTitan

ข้อมูลที่ขโมยถูกส่งไปที่ใด

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

สิ่งที่ทีมความปลอดภัยควรทำทันที

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

1. ตรึงเวอร์ชันหรือย้อนกลับไปใช้รีลีสที่สะอาด

ใช้เวอร์ชันที่ตรวจสอบแล้วว่าปลอดภัย และกำหนด dependency ให้ชัดเจนเพื่อป้องกันการติดตั้งเวอร์ชันที่ถูกวางยาโดยไม่ตั้งใจ อาจใช้ overrides ใน package.json รวมถึงกลไก override ของ npm, Yarn หรือ pnpm

ตรวจสอบไฟล์ล็อกทั้งหมด ได้แก่ package-lock.json, yarn.lock และ pnpm-lock.yaml โดยต้องตรวจทั้ง dependency โดยตรงและ dependency ที่ถูกดึงเข้ามาต่อเนื่อง หรือ transitive dependencies

2. ถือว่าเครื่องที่ติดเชื้อถูกเจาะระบบทั้งหมด

หากเครื่องผู้พัฒนาหรือ runner ของ CI/CD เคยรัน npm install กับเวอร์ชันที่ได้รับผลกระทบ ให้ถือว่าข้อมูลลับทั้งหมดที่อยู่ในเครื่องอาจถูกขโมยแล้ว อย่าเชื่อว่าการลบ node_modules หรือไฟล์มัลแวร์จะทำให้ระบบกลับมาปลอดภัยทันที

3. เพิกถอนและสร้างข้อมูลรับรองใหม่

เพิกถอนและออกข้อมูลรับรองใหม่ทั้งหมดที่อาจถูกเปิดเผย ได้แก่

• npm tokens ทั้งแบบ classic และ granular
• GitHub PATs และ fine-grained tokens
• AWS IAM keys และ access keys
• Kubernetes service account tokens
• HashiCorp Vault tokens
• Stripe keys
• Slack tokens
• SSH keys
• ข้อมูลรับรอง Docker
• VPN tokens

4. ปิดตัวเฝ้าดูการเพิกถอนโทเคนก่อนหมุนโทเคนใหม่

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

5. ล้างแคชและสร้างระบบใหม่จากศูนย์

ล้างแคชของ npm, pnpm และ Yarn รวมถึง Docker build caches ทั้งบนเครื่องผู้พัฒนาและ runner ของ CI/CD จากนั้นสร้างอาร์ติแฟกต์ใหม่ทั้งหมด เพื่อป้องกัน dependency ที่ปนเปื้อนหลงเหลืออยู่ในแคช เลเยอร์ Docker หรือกระบวนการ build เดิม

6. ตรวจสอบ GitHub และระบบ CI/CD

ค้นหารีโพซิทอรีที่ถูกสร้างขึ้นใหม่ workflow ที่ไม่ได้รับอนุญาต และ commit ที่ผิดปกติ ควรตรวจสอบไฟล์ที่อาจถูกใช้เพื่อคงอยู่ในระบบ เช่น .claude/settings.json และ .vscode/tasks.json

บทเรียนสำคัญจากเหตุการณ์นี้

เหตุการณ์ Shai-Hulud วันที่ 4 สิงหาคม 2026 แสดงให้เห็นว่า บัญชีผู้ดูแลเพียงบัญชีเดียวสามารถกลายเป็นจุดเริ่มต้นของการโจมตีซัพพลายเชนขนาดใหญ่ได้ แม้ผู้โจมตีจะไม่ได้มีสิทธิ์โดยตรงกับแพ็กเกจส่วนใหญ่ที่ได้รับผลกระทบก็ตาม ภายในเวลาไม่กี่ชั่วโมง หนอนสามารถแพร่ตัวเองผ่านโทเคนที่ขโมยมาและทำให้แพ็กเกจมากกว่าพันรายการตกอยู่ในความเสี่ยง

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

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