สรุปสั้น

Shai-Hulud คือ worm ที่แพร่ผ่านแพ็กเกจ npm และขโมยข้อมูลยืนยันตัวตนของนักพัฒนา ซึ่งกลับมาหลายระลอกตลอดปีนี้ ตามที่รายงานไว้ใน 2026/05/007 และ 2026/09/022 ข่าวส่วนใหญ่เล่าว่าแพ็กเกจไหนโดนและมัลแวร์ขโมยอะไร แต่บนเวที ISC2 Security Congress 2026 ที่เมืองเดนเวอร์ สหรัฐฯ นาย Deepam Kanjani ผู้จัดการด้านความปลอดภัยผลิตภัณฑ์ของบริษัท Atlassian เล่าอีกด้านหนึ่ง คือ ทีมรับมือเหตุการณ์ต้องเจออะไรเมื่อ worm นี้หลุดเข้ามาในระบบ SaaS ขนาดใหญ่ แพ็กเกจที่ดูน่าเชื่อถือซ่อน dependency อันตรายไว้ลึก 3 ชั้น SBOM รายงานว่าระบบสะอาดเพราะข้อมูลเก่า และทีมตอบไม่ได้ว่าเซอร์วิสใดรันโค้ดนั้นบ้าง

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

รายละเอียดข่าว

เว็บไซต์ Dark Reading รายงานเมื่อวันที่ 26 ตุลาคม 2569 จากการบรรยายของนาย Deepam Kanjani ในงาน ISC2 Security Congress 2026 ว่าเขาใช้เคสการเจาะระบบด้วย worm Shai-Hulud เป็นกรณีศึกษา เพื่อชี้ช่องว่างของการรับมือเหตุการณ์ใน 3 เรื่อง ได้แก่ การมองไม่เห็นสิ่งที่เกิดขึ้นขณะรัน การไม่มีเจ้าของ dependency ทางอ้อม และการสืบหาตัวผู้โจมตี

ไทม์ไลน์ของเหตุเริ่มจากเครื่องสแกนพฤติกรรมแจ้งเตือนว่าแพ็กเกจตัวหนึ่งรันสิ่งที่ไม่ควรรัน ทีมรับมือเหตุการณ์ตอนแรกมองว่าเป็น false positive เพราะค่า hash ตรงและไม่มีสัญญาณอื่น เมื่อเปิด SBOM ก็พบว่าระบบสะอาด ภายหลังจึงรู้ว่า SBOM นั้นเก่าไป 2 สปรินต์การพัฒนา ระหว่างการรับมือ ทีมไม่สามารถยืนยันได้ว่าเซอร์วิสใดใช้แพ็กเกจนี้ และข้อความ Slack ฉบับแรกที่ส่งถึงผู้เกี่ยวข้องก็คลุมเครือจนเกิดการสอบสวนซ้อนกันหลายทาง

ความพยายามระบุตัวผู้โจมตีก็ไปไม่ถึงไหน ทีมไล่ดูความเป็นเจ้าของใน registry ประวัติผู้ดูแลแพ็กเกจบน npm ตัวตนผู้เผยแพร่ และบันทึกบน GitHub แต่พบว่ารีโพสิทอรีถูกคัดลอกมาจากโครงการจริง ส่วนตัวตนและประวัติบัญชีของผู้เผยแพร่ถูกสร้างขึ้นเอง ด้านนักวิจัยภายนอกระบุภายหลังว่าการโจมตี Shai-Hulud ระลอกหลังอย่างน้อยบางส่วนเป็นฝีมือของกลุ่ม TeamPCP

ข้อจำกัดสำคัญของเรื่องนี้ คือ นาย Kanjani แจ้งว่าได้เปลี่ยนรายละเอียดที่ระบุตัวตนได้ ตัวเลข และลำดับเหตุการณ์ทั้งหมดเพื่อรักษาความลับ เหลือไว้เฉพาะเทคนิคการโจมตี พฤติกรรมทางเทคนิค และความท้าทายที่อิงจากเหตุการณ์จริงในระบบ SaaS ขนาดใหญ่ ตัวเลขในเคสนี้จึงควรอ่านเป็นภาพประกอบ ไม่ใช่สถิติของเหตุการณ์จริง และการบรรยายไม่ได้ระบุว่าเป็นระบบของ Atlassian เอง

วิธีการโจมตี

ปลอมแพ็กเกจให้ผ่านการตรวจความน่าเชื่อถือ — แพ็กเกจต้นทางดูถูกต้องทุกด้าน ค่า SHA hash ตรง มีดาวบน GitHub กว่า 3,400 ดวง และรีโพสิทอรีดูน่าเชื่อถือสำหรับเครื่องมือความปลอดภัยของบริษัท วิธีนี้ได้ผลเพราะเครื่องมือส่วนใหญ่ใช้สัญญาณเหล่านี้วัดความน่าเชื่อถือ ทั้งที่รีโพสิทอรีคัดลอกมาจากโครงการจริงและบัญชีผู้เผยแพร่ถูกสร้างขึ้นใหม่

ซ่อนของอันตรายเป็น dependency ทางอ้อม — ตัวอันตรายจริงเป็น transitive dependency ชื่อ shai-hulud ซึ่งซ่อนลึกลงไป 3 ชั้น transitive dependency คือ แพ็กเกจที่ไม่ได้ถูกเรียกใช้โดยตรง แต่ถูกดึงเข้ามาโดยแพ็กเกจอื่นอีกที เมื่อไม่ใช่ dependency โดยตรง การตรวจ dependency ระดับบนสุดจึงมองไม่เห็น

อาศัยช่องว่างของ SBOM และ IoC — SBOM ที่ไม่ได้อัปเดตบอกว่าระบบสะอาด ส่วน IoC ช่วยได้แค่เป็นเบาะแสแรก แต่บอกไม่ได้ว่าเซอร์วิสใดโดนหรือการเจาะลามไปไกลแค่ไหน เมื่อไม่มีข้อมูล runtime ทีมต้องเทียบล็อกด้วยมือข้ามกว่า 400 เซอร์วิส

ทิ้งร่องรอยตัวตนที่สืบต่อไม่ได้ — ตัวตนผู้เผยแพร่ที่ถูกสร้างขึ้นทำให้การไล่ต้นตอผ่าน registry และ GitHub ไปจบที่ทางตัน นาย Kanjani จึงสรุปว่าสัญญาณด้านตัวตนเปลี่ยนได้ตลอด แต่สิ่งที่ worm จำเป็นต้องทำเพื่อทำงานนั้นเปลี่ยนไม่ได้

ผลกระทบ

กลุ่มที่เสี่ยงที่สุด คือ องค์กรที่พัฒนาซอฟต์แวร์บน npm และมีเซอร์วิสจำนวนมากใน production โดยเฉพาะผู้ให้บริการ SaaS ที่พึ่ง SBOM หรือการตรวจ dependency ระดับบนสุดเป็นหลักในการประเมินความเสี่ยงซัพพลายเชน Shai-Hulud กลับมาหลายระลอกในปีนี้ และแต่ละระลอกแพร่ผ่านแพ็กเกจจำนวนมาก โอกาสที่ dependency ทางอ้อมของแต่ละองค์กรจะโดนจึงไม่ต่ำ

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

คำแนะนำ

  • ทำ SBOM ของสิ่งที่ deploy ให้สดเสมอ — นาย Kanjani เสนอเป้าให้ SBOM ที่ deploy อายุไม่เกิน 72 ชั่วโมง และให้เซอร์วิส production มากกว่า 98% ผ่านเกณฑ์นี้ โดยถือเป็นเป้าที่แต่ละองค์กรปรับให้เข้ากับสภาพแวดล้อมของตน
  • เปิดความสามารถตรวจจับขณะรัน — ตั้งเป้าให้ตรวจพบการโหลดโมดูลที่ไม่รู้จักได้ภายใน 90 วินาที เพื่อรู้ว่าโค้ดใดรันจริงและเข้าถึงอะไร แทนการเดาจากไฟล์ dependency
  • ตรวจ registry หาชื่อแพ็กเกจเลียนแบบทุกวัน — ตรวจหาแพ็กเกจที่ชื่อคล้ายแพ็กเกจภายในขององค์กรให้พบภายใน 24 ชั่วโมงหลังถูกเผยแพร่
  • อย่าปัดตกการแจ้งเตือนเพียงเพราะ hash ตรง — hash ที่ตรงยืนยันแค่ว่าไฟล์ไม่ถูกแก้ระหว่างทาง ไม่ได้ยืนยันว่าแพ็กเกจปลอดภัย ควรไล่ดู dependency ทางอ้อมทุกครั้งที่เครื่องสแกนพฤติกรรมแจ้งเตือน
  • สร้างการตรวจจับจากพฤติกรรม ไม่ใช่ตัวตน — เน้นสิ่งที่ worm ต้องทำ เช่น อ่านไฟล์ข้อมูลยืนยันตัวตน เรียกเครือข่ายออกนอก และเผยแพร่แพ็กเกจต่อ แทนการไล่ชื่อผู้เผยแพร่ที่ปลอมได้
  • สื่อสารเหตุการณ์ให้ชัดตั้งแต่ข้อความแรก — บอกความจริงด้วยภาษาที่ผู้รับเข้าใจ ระบุสิ่งที่รู้และไม่รู้ และกำหนดผู้รับผิดชอบเพื่อไม่ให้เกิดการสอบสวนซ้อนกัน

แหล่งอ้างอิง