ผู้ไม่ประสงค์ดีฝัง Malware ใน Software Update ที่น่าเชื่อถือ เพื่อขโมย Developer และ Cloud Credentials

ReversingLabs เผยแพร่รายงานที่วิเคราะห์กลุ่มเหตุการณ์ Supply Chain Attack ล่าสุด ได้แก่ S1ngularity, Shai-Hulud และ TeamPCP ซึ่งแสดงให้เห็นว่าผู้โจมตีใช้ช่องทาง Software Update, Package Release และ CI/CD Pipeline ที่ผู้ใช้และ Security Tool เชื่อถือแล้ว เพื่อแอบฝัง Malicious Code เข้าสู่ Development Workflow จุดร่วมของทุกกรณีคือการขโมย Publishing Token หรือ Credentials เพียงจุดเดียวบน Developer Machine สามารถขยายผลไปยังองค์กรปลายทางได้จำนวนมาก

รายละเอียดทางเทคนิค

กรณี S1ngularity — เมื่อ Pull Request กลายเป็นจุดเริ่มต้น

S1ngularity เป็นแคมเปญที่เจาะจงแพ็กเกจ Nx ซึ่งเป็น Build System ยอดนิยมสำหรับ JavaScript/TypeScript ผู้โจมตีดำเนินการเป็นลำดับขั้นตอนดังนี้:

• ▸ ขั้นที่ 1 — Crafted Pull Request: ส่ง Pull Request ที่ออกแบบมาเป็นพิเศษเพื่อดึง npm Publishing Token ออกจาก CI System ของ Nx Project (เหตุการณ์นี้เกิดขึ้นเมื่อ 26 สิงหาคม 2568)
• ▸ ขั้นที่ 2 — แทนที่ CI Script: ใช้ Token ที่ขโมยได้เพื่อแก้ไข CI Script และ Trigger Publishing Workflow ทำให้ Package เวอร์ชันที่ฝัง Malware ถูก Publish ขึ้น npm Registry
• ▸ ขั้นที่ 3 — Post-Install Hooks: Package ที่ติดเชื้อจะรัน Post-Install Hook บน Developer Machine โดยอัตโนมัติเมื่อมีการ npm install
• ▸ ขั้นที่ 4 — Credential Harvesting: Hook ค้นหาและขโมย GitHub Token, npm Token, Cloud Credentials และ SSH Key จากเครื่องของเหยื่อ
• ▸ ขั้นที่ 5 — AI-Assisted Discovery: Malware สั่งให้ Local AI Assistant (ถ้ามี) ค้นหา File System เพื่อหา Credential Location โดยเฉพาะ — ทำให้การขโมยมีประสิทธิภาพมากขึ้น
• ▸ ขั้นที่ 6 — Exfiltration: Credentials ที่ขโมยได้ถูกส่งไปยัง Public GitHub Repository ชื่อ s1ngularity-repository เพื่อให้ผู้โจมตีเข้าถึงได้

หลังจากเหตุการณ์นี้ Nx ได้เปลี่ยนมาใช้ Trusted-Publisher Approach ที่ใช้ Short-Lived Per-Run Credentials แทน Long-Lived Token เพื่อลดความเสี่ยง

กรณี Shai-Hulud — Credential Worm ที่แพร่ตัวเอง

Shai-Hulud ยกระดับ Attack Model ของ S1ngularity โดยเพิ่มความสามารถ Self-Propagating:

• ▸ เมื่อติดเครื่อง Developer เหยื่อ Worm จะค้นหา npm Publishing Credentials ทั้งหมดในระบบ
• ▸ ระบุ Package ที่เหยื่อมีสิทธิ์ Publish ได้
• ▸ ฝัง Malicious Code เข้าไปใน Package เหล่านั้นและ Publish เวอร์ชันติดเชื้อออกไป
• ▸ ทำให้ Worm แพร่กระจายจากเหยื่อสู่เหยื่อโดยไม่ต้องหาช่องโหว่ใหม่ในแต่ละขั้นตอน

กรณี TeamPCP / Trivy — Token ที่ Rotate ไม่สมบูรณ์

เหตุการณ์ที่เกี่ยวข้องกับ Trivy (เครื่องมือ Container Security Scanning ยอดนิยม) แสดงให้เห็นอีกมิติหนึ่งของ Supply Chain Risk:

• ▸ กุมภาพันธ์ 2569: Privileged Token ถูกขโมยออกไป
• ▸ Incomplete Rotation: การ Rotate Credential ทำไม่สมบูรณ์ ทิ้ง Access Path ไว้
• ▸ 19 มีนาคม 2569: ผู้โจมตีใช้ Token ที่เหลืออยู่ Publish Malicious Update ผ่านระบบ Automated CI/CD
• ▸ ผู้โจมตีแก้ไข Version Tag ที่ใช้โดย CI/CD Workflow เพื่อให้ระบบ Downstream ดึง Version ที่ติดเชื้อมาใช้โดยอัตโนมัติ
• ▸ หลังจาก Trivy: ใช้ npm Token ที่ขโมยได้ต่อยอดเป็น CanisterWorm ซึ่งแพร่ระบาดไปยังแพ็กเกจ npm มากกว่า 60 รายการ กระทบ Checkmarx, LiteLLM และ Telnyx

Indicators of Compromise (IoCs)

• ▸ Repository: s1ngularity-repository — Public GitHub Repository ที่ใช้ Exfiltrate ข้อมูลที่ขโมย
• ▸ SHA-1: d2438106211ebd12c4f0a248848bc9864c97a3c0 — S1ngularity Malware Sample
• ▸ SHA-1: b4f20b39aa6df1002872f07973024d85aa49abaf — S1ngularity Malware Sample
• ▸ SHA-1: 2379ac0e03b1a67c4ca5693136eff4945e644a91 — S1ngularity Malware Sample
• ▸ SHA-1: e5d1f3c45ee7cca6ae59cf64e0573050bbe136ec — S1ngularity Malware Sample

ผลกระทบที่อาจเกิดขึ้น

1. Trusted Distribution Channel กลายเป็นอาวุธ — เมื่อผู้โจมตีเข้าถึง Publishing Pipeline ได้ Code ที่ส่งออกผ่านช่องทางปกติ (npm install, Package Update) กลายเป็น Malware ที่ Security Tool ส่วนใหญ่จะไม่ตรวจจับเพราะ Source น่าเชื่อถือ
2. Credential จาก Developer Machine มีมูลค่าสูงมาก — GitHub Token, Cloud Credentials และ SSH Key บนเครื่อง Developer เพียงคนเดียวอาจเปิดทางเข้าสู่ Source Code, Cloud Infrastructure และ CI/CD Pipeline ขององค์กรทั้งหมด รวมถึงยังสามารถใช้ต่อยอดโจมตี Downstream ผู้ใช้รายอื่นได้
3. AI Assistant กลายเป็นเครื่องมือ Discovery — การที่ S1ngularity ใช้ Local AI Tool ค้นหา Credential Location บ่งชี้แนวโน้มใหม่ที่น่ากังวล เมื่อ Developer มี AI Assistant ที่มีสิทธิ์เข้าถึง File System กว้าง อาจถูกใช้เป็นช่องทาง Discovery โดยไม่รู้ตัว
4. Incomplete Credential Rotation คือช่องโหว่ที่มองข้ามบ่อย — กรณี Trivy แสดงว่าแม้จะรู้ว่า Token ถูกขโมยแล้ว หาก Rotate ไม่สมบูรณ์ ผู้โจมตียังสามารถใช้ช่องว่างที่เหลือได้ภายในเดือนถัดมา

สิ่งที่องค์กรควรทำ

1. Audit Publishing Tokens และ CI/CD Secrets — ตรวจสอบว่าองค์กรใช้ Long-Lived Publishing Token ใน npm, PyPI หรือ Package Registry อื่นๆ หรือไม่ ให้เปลี่ยนมาใช้ Short-Lived Per-Run Credentials (OIDC/Trusted Publisher) ทันที
2. Pin CI/CD Dependencies ไปที่ Reviewed Commit Hash — แทนที่จะ Pin เป็น Version Tag เพียงอย่างเดียว ให้ Pin เป็น Commit Hash ที่ผ่านการ Review แล้ว เพื่อป้องกัน Tag Poisoning ที่เกิดกับ Trivy
3. ตรวจสอบ Post-Install Hooks ใน Package Dependencies — Audit package.json ของ Project สำหรับ postinstall Script ที่ไม่คาดคิด โดยเฉพาะใน Dependency ที่อัปเดตล่าสุด และพิจารณาใช้ npm ci --ignore-scripts ในสภาพแวดล้อม CI/CD
4. Rotate Credentials ทันทีหากสงสัยว่าถูก Expose — หากพบว่าเคย Install Package ที่อาจติดเชื้อ ให้ Rotate GitHub Token, npm Token, Cloud Credentials และ SSH Key ทั้งหมดบนเครื่องนั้นอย่างสมบูรณ์ และตรวจสอบ Repository, Workflow และ Package ที่อาจถูกสร้างโดยไม่ได้รับอนุญาต

แนวทางลดความเสี่ยงระยะยาว

1. ใช้ Minimal Permission สำหรับ Publishing Token — จำกัด Token แต่ละตัวให้มีสิทธิ์เฉพาะที่จำเป็น ไม่ควรใช้ Token เดียวที่สามารถ Publish ได้ทุก Package ในองค์กร เพราะการขโมย Token เดียวจะกระทบทุก Package
2. Monitor Package Publishing Activity — ตั้ง Alert เมื่อมีการ Publish Package Version ใหม่ โดยเฉพาะนอก Scheduled Release Cycle และตรวจสอบ Diff ของ Package ที่ Publish ทุกครั้งก่อนที่ Downstream จะดึงไปใช้
3. จำกัดสิทธิ์ AI Assistant ในสภาพแวดล้อม Development — หากทีม Developer ใช้ AI Coding Assistant ที่มีสิทธิ์เข้าถึง File System ให้กำหนด Policy ว่า AI ไม่ควรมีสิทธิ์อ่านไฟล์ใน Credential Directories เช่น ~/.ssh, ~/.aws, ~/.config/gh โดยไม่จำเป็น
4. ฝึกอบรม Developer ด้าน Supply Chain Security — เพิ่ม Awareness เรื่อง Supply Chain Risk ใน Security Training โดยเฉพาะการตรวจสอบ Release Note, Changelog และ Diff ก่อน Update Dependency ที่มี Critical Access

วิเคราะห์ในมุมมองจาก TXEC

รายงานของ ReversingLabs ชี้ให้เห็นแนวโน้มที่น่าเป็นห่วงอย่างยิ่ง — ผู้โจมตีมีกลยุทธ์ที่ "ประหยัดพลังงาน" มาก: แทนที่จะหาช่องโหว่ Zero-Day ราคาแพง พวกเขาหาทางเข้าถึง Trusted Distribution Channel เพียงครั้งเดียว แล้วให้ Ecosystem ที่เชื่อถืออยู่แล้วช่วยแพร่กระจาย Malware ต่อไปเอง

กรณี S1ngularity ที่ใช้ AI Assistant ช่วย Discover Credentials เป็นสัญญาณที่ชัดเจนว่าผู้โจมตีปรับ Tactic ให้ทันกับ Tool ที่ Developer ใช้ในปัจจุบัน

สำหรับองค์กรไทยที่มีทีม Developer หรือใช้ Open-Source Package จาก npm/PyPI ในสภาพแวดล้อม Production คำแนะนำเร่งด่วนคือ Audit Publishing Token และ Post-Install Hooks ก่อน แล้วค่อยวางแผน Pin Strategy ระยะยาว

[ แหล่งอ้างอิง: CyberSecurity News , ReversingLabs Research Report ]