TeamPCP เปิดซอร์สโค้ดหนอน Shai‑Hulud บน GitHub กระทบความปลอดภัยซัพพลายเชนซอฟต์แวร์ทั่วโลก

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

หลังจากนั้นไม่นาน ทีมวิจัยพบว่า TeamPCP ได้ เผยแพร่ซอร์สโค้ดเต็มของหนอนลงบน GitHub สอง repository ภายใต้ MIT License ซึ่งเปิดให้ทุกคน fork หรือแก้ไขโค้ดได้อย่างอิสระ

ทำไมการปล่อยโค้ดภายใต้ MIT License จึงสำคัญ

การเผยแพร่มัลแวร์พร้อมใบอนุญาตโอเพนซอร์สแบบ permissive อย่าง MIT ถือเป็นเรื่องที่พบไม่บ่อย และมีผลเชิงกลยุทธ์

สำหรับ ฝ่ายป้องกัน การเข้าถึงโค้ดจริงช่วยให้สามารถ

• สร้างกฎตรวจจับที่แม่นยำขึ้น เช่น YARA, Sigma หรือ EDR
• จำลองพฤติกรรมของ worm ใน sandbox เพื่อศึกษาวิธีการโจมตี
• ทดสอบว่าระบบตรวจจับใน CI/CD สามารถจับการโจมตีได้หรือไม่

แต่สำหรับ ฝ่ายโจมตี ความโปร่งใสนี้กลับลดอุปสรรคในการสร้างเวอร์ชันใหม่ เพราะ MIT License อนุญาตให้คัดลอก แก้ไข และแจกจ่ายโค้ดได้เกือบโดยไม่มีข้อจำกัด

ความกังวลหลักคือ Shai‑Hulud ไม่ใช่ exploit เดี่ยว ๆ แต่เป็น รูปแบบการโจมตีซัพพลายเชนที่สามารถนำไปใช้ซ้ำได้ ใน workflow ของนักพัฒนา

ความสามารถหลักของหนอน Shai‑Hulud

จากการวิเคราะห์ของนักวิจัย หนอนตัวนี้ผสมผสานเทคนิคหลายอย่างที่มักพบใน supply‑chain attack ระดับสูง

การขโมย OIDC Token จาก CI/CD

หนึ่งในความสามารถที่สำคัญที่สุดคือการ ดึง OpenID Connect (OIDC) token จาก pipeline CI/CD โดยเฉพาะ GitHub Actions ที่ใช้ในการเผยแพร่แพ็กเกจ

แทนที่จะใช้ credential แบบ static ที่ถูกขโมย ผู้โจมตีสามารถดักจับ token ที่ถูกสร้างขึ้นใน runtime ของ pipeline แล้วใช้ token นั้นเพื่อเผยแพร่แพ็กเกจอันตรายผ่านระบบ automation ที่ดูเหมือนถูกต้อง

เผยแพร่แพ็กเกจอันตรายพร้อม Provenance ที่ถูกต้อง

อีกประเด็นสำคัญคือการโจมตีความเชื่อมั่นในระบบ software provenance

มีรายงานว่าแพ็กเกจที่ถูกฝังมัลแวร์บางรายการถูกเผยแพร่พร้อม SLSA Build Level 3 provenance attestations ซึ่งทำให้ artifact ดูเหมือนสร้างมาจาก pipeline ที่เชื่อถือได้ แม้ภายในจะมีโค้ดอันตรายก็ตาม

การขโมย Credential จากเครื่องนักพัฒนา

เมื่อแพ็กเกจที่ติดเชื้อถูกติดตั้ง มัลแวร์จะทำงานเป็น credential stealer โดยพยายามค้นหาข้อมูลสำคัญจากเครื่องนักพัฒนาและระบบ CI

ข้อมูลที่ตกเป็นเป้าหมาย เช่น

• AWS และ credential ของ cloud provider อื่น
• SSH private keys
• token สำหรับ publish npm และ PyPI
• GitHub Personal Access Tokens
• secret จาก Kubernetes และ HashiCorp Vault

รายงานบางฉบับระบุว่ามัลแวร์สามารถสแกน เส้นทางจัดเก็บ credential มากกว่า 100 ตำแหน่ง บนระบบที่ติดเชื้อ

การแพร่กระจายตัวเองผ่าน ecosystem ของแพ็กเกจ

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

กลไกทำลายข้อมูลแบบ Dead‑Man’s Switch

การวิเคราะห์บางส่วนยังพบว่ามัลแวร์อาจมี กลไกทำลายข้อมูลหรือ wiper ที่ทำงานเมื่อเงื่อนไขบางอย่างเกิดขึ้น ซึ่งเรียกว่า dead‑man’s switch

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

ความเชื่อมโยงกับการโจมตีของ TeamPCP ก่อนหน้า

แคมเปญเดือนพฤษภาคม 2026 ไม่ใช่ครั้งแรกที่ TeamPCP โจมตีซัพพลายเชนซอฟต์แวร์

รายงานของ Cloud Security Alliance ระบุว่า ก่อนหน้านั้นในช่วง 29–30 เมษายน 2026 กลุ่มเดียวกันได้โจมตี npm, PyPI และ Packagist พร้อมกัน ส่งผลกระทบต่อ repository ประมาณ 1,800 รายการ จากการใช้ credential ที่รั่วไหลและการตั้งค่า CI/CD ที่ผิดพลาด

แต่แคมเปญ Shai‑Hulud รอบล่าสุดมีการพัฒนาเทคนิคอย่างชัดเจน

• การโจมตีเดิมอาศัย token ของ registry ที่ถูกขโมย
• การโจมตีเดือนพฤษภาคมใช้การ ยึด pipeline ที่เชื่อถือได้ และดึง OIDC token จาก CI runner
• มัลแวร์เพิ่มความสามารถแบบ worm ที่แพร่กระจายตัวเองข้าม ecosystem

แนวโน้มนี้แสดงให้เห็นว่าผู้โจมตีกำลังปรับตัวอย่างรวดเร็วต่อมาตรการป้องกันใหม่ของซัพพลายเชนซอฟต์แวร์

ความเสี่ยงเร่งด่วนสำหรับทีมพัฒนาและทีมความปลอดภัย

องค์กรที่ติดตั้งแพ็กเกจที่ได้รับผลกระทบในช่วงเวลาการโจมตีควรระวังเป็นพิเศษ

แนวทางจากนักวิจัยด้านความปลอดภัยระบุว่า environment ใดที่ติดตั้งแพ็กเกจเหล่านั้นควรถูกมองว่าอาจถูก compromise แล้ว เพราะมัลแวร์สามารถขโมย credential และคงอยู่ในเครื่องนักพัฒนาและ pipeline ได้

อีกบทเรียนสำคัญคือ

provenance ที่ลงลายเซ็นถูกต้อง ไม่ได้หมายความว่าปลอดภัยเสมอไป หาก pipeline ที่สร้าง artifact นั้นถูกยึดโดยผู้โจมตี

แนวทางตอบสนองที่แนะนำ

ทีมความปลอดภัยที่กำลังตรวจสอบเหตุการณ์ควรดำเนินการอย่างเร่งด่วน เช่น

• ตรวจสอบ dependency จาก npm และ PyPI ที่ถูกติดตั้งตั้งแต่วันที่ 11 พฤษภาคม 2026
• rebuild ระบบจาก environment ที่สะอาดและ lockfile ที่เชื่อถือได้
• เปลี่ยน credential ทั้งหมดของ developer, CI/CD, cloud และ registry
• ตรวจสอบ workflow ของ GitHub Actions หรือ CI อื่น ๆ ว่ามีการ publish หรือแก้ไขที่ผิดปกติหรือไม่
• จำกัดสิทธิ์ของ OIDC และใช้ runner ที่ hardened สำหรับขั้นตอน publish

องค์กรควรเฝ้าระวัง เวอร์ชันดัดแปลงของ Shai‑Hulud ที่อาจเกิดขึ้นตามมา เพราะเมื่อซอร์สโค้ดถูกเผยแพร่สาธารณะ ความเป็นไปได้ของการโจมตีเลียนแบบหรือเวอร์ชันใหม่จะเพิ่มขึ้นอย่างมาก

จุดเปลี่ยนของความปลอดภัยในซัพพลายเชนซอฟต์แวร์

เหตุการณ์ Shai‑Hulud แสดงให้เห็นแนวโน้มใหม่ของการโจมตี: ผู้โจมตีไม่ได้มุ่งเป้าแค่ช่องโหว่ของ dependency แต่กำลังโจมตี workflow ของนักพัฒนาและระบบ build เอง

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