พบแคมเปญ npm Package อันตราย 18 ตัว แอบอ้างเป็นแพ็กเกจ Alibaba แพร่ RAT ข้ามแพลตฟอร์ม

นักวิจัยด้านความปลอดภัยพบแคมเปญ Software Supply Chain Attack ที่มุ่งเป้านักพัฒนาผ่าน npm Package อันตราย 18 ตัว โดยแอบอ้างชื่อคล้ายแพ็กเกจภายในของ Alibaba (@ali Scope) เพื่อหลอกให้นักพัฒนาติดตั้ง ก่อนดาวน์โหลด Remote Access Trojan (RAT) ข้ามแพลตฟอร์ม ลงเครื่องเหยื่อ มุ่งเป้าไปที่กลุ่มผู้ใช้เครื่องมือของ Alibaba โดยเฉพาะในสภาพแวดล้อมที่พูดภาษาจีน

กลไกการโจมตี: Layered Dependency Chain

แคมเปญนี้ใช้เทคนิค Layered Dependency Chain ที่ออกแบบมาเพื่อหลบเลี่ยงการตรวจสอบโค้ดแบบแยกไฟล์ (Isolated Code Review) โดยมีโครงสร้างดังนี้:

1. Package ชั้นบนสุด (Lure Package) ปลอมแปลงชื่อให้คล้ายกับแพ็กเกจ Private ภายในของ Alibaba ภายใต้ @ali Scope ทำหน้าที่เป็นตัวล่อกระตุ้นให้นักพัฒนาติดตั้ง
2. เมื่อติดตั้งแล้ว ระบบจะดึง Dependency Tree เพิ่มเติม ที่แยกส่วนประกอบของ RAT ออกเป็นหลาย Package กระจายอยู่ในหลายชั้นของ Dependency แทนที่จะรวมโค้ดอันตรายไว้ในไฟล์เดียว ทำให้การตรวจสอบโค้ดแบบแยกไฟล์มักมองข้ามความเชื่อมโยงของทั้งระบบ
3. Dependency Chain ดึงไฟล์ Configuration จาก GitHub Repository ที่ผู้โจมตีควบคุม แล้วบันทึกไว้ในเครื่องของเหยื่อเป็นไฟล์ชื่อ .cloud-preferences.json

การพรางตัวของ Command and Control (C2)

การสื่อสารกับ C2 Server ของแคมเปญนี้พรางตัวอย่างแนบเนียนด้วยการ ปลอมแปลง HTTP Header ให้อ้างอิงบริการของ Alibaba ที่มีอยู่จริง เช่น alidocs.dingtalk.com ทำให้ทราฟฟิกที่ส่งออกไปดูเหมือนเป็นการเชื่อมต่อกับบริการที่ถูกต้องตามกฎหมาย ยากต่อการแยกแยะด้วยเครื่องมือตรวจจับเครือข่ายทั่วไป

RAT ที่ถูกติดตั้งรองรับคำสั่งหลากหลาย ได้แก่:

• การสำรวจระบบ (System Reconnaissance)
• การติดตั้ง Module เพิ่มเติม
• การรันโค้ดตามคำสั่งของผู้โจมตี (Arbitrary Code Execution)

โดย RAT จะ Poll เชื่อมต่อกับ C2 Server อย่างต่อเนื่อง เพื่อรอรับคำสั่งใหม่

เบาะแสของผู้อยู่เบื้องหลัง

จากการตรวจสอบพบว่า บัญชีผู้เผยแพร่ npm หลายบัญชีถูกสร้างขึ้นในช่วงเวลาใกล้เคียงกันในปลายเดือนเมษายน 2026 สอดคล้องกับการทยอยเปิดใช้งานแคมเปญนี้เป็นระยะ นอกจากนี้ GitHub Commit ที่เกี่ยวข้องกับ Configuration และ Payload อันตรายมี Timestamp ตรงกับ China Standard Time (UTC+0800) และมี Comment เป็นภาษาจีน ซึ่งบ่งชี้ (แต่ยังไม่สามารถยืนยันได้แน่ชัด) ว่าอาจเกี่ยวข้องกับกลุ่มผู้โจมตีที่ใช้ภาษาจีน

ระบบที่ได้รับผลกระทบ

• นักพัฒนาที่ใช้เครื่องมือหรือ Dependency ที่เกี่ยวข้องกับ Alibaba โดยเฉพาะกลุ่มที่ทำงานในสภาพแวดล้อมที่พูดภาษาจีน
• ระบบ CI/CD Pipeline ที่ดึง Dependency จาก npm โดยอัตโนมัติ มีความเสี่ยงติดมัลแวร์ไปพร้อมกับกระบวนการ Build โดยไม่มีการตรวจสอบจากมนุษย์

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

1. เครื่อง Developer ที่ติดตั้ง Package อันตรายถูกควบคุมจากระยะไกลได้ทันที ผ่าน RAT ที่รองรับคำสั่งหลากหลาย
2. ความเสี่ยงต่อการรั่วไหลของ Source Code, Credential และข้อมูลสำคัญอื่นๆ ที่จัดเก็บอยู่บนเครื่อง Developer หรือเข้าถึงได้จากเครื่องนั้น
3. ความเสี่ยงต่อ CI/CD Pipeline ที่ดึง Dependency อัตโนมัติ อาจนำมัลแวร์เข้าสู่กระบวนการ Build โดยไม่มีใครรู้ตัว เปิดทางสู่การโจมตี Supply Chain ต่อเนื่องไปยังผลิตภัณฑ์ปลายทาง
4. ตรวจจับได้ยากด้วยเครื่องมือ Network Monitoring ทั่วไป เนื่องจากการปลอมแปลง HTTP Header ให้ดูเหมือนทราฟฟิกของ Alibaba ที่ถูกต้อง

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

1. ตรวจสอบ package.json และ Lock File ของโปรเจกต์ว่ามีการเรียกใช้แพ็กเกจในกลุ่มที่แอบอ้าง @ali Scope หรือ Pattern การตั้งชื่อที่คล้ายกันแต่ไม่คุ้นเคยหรือไม่
2. ตรวจสอบไฟล์ .cloud-preferences.json หรือ Process ที่เชื่อมต่อออกไปยัง GitHub Repository ที่ไม่รู้จัก บนเครื่อง Developer และ CI/CD Server ทั้งหมด
3. ใช้เครื่องมือ Software Composition Analysis (SCA) สแกน Dependency Tree ทั้งหมดก่อน Build เพื่อตรวจจับ Package อันตรายที่แฝงอยู่ในหลายชั้นของ Dependency ไม่ใช่ตรวจสอบเฉพาะ Package ระดับบนสุด
4. ตรวจสอบทราฟฟิกเครือข่ายที่อ้างอิงโดเมนของ Alibaba เช่น alidocs.dingtalk.com จาก Process ที่ไม่ควรเชื่อมต่อกับบริการดังกล่าว

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

1. ใช้ Lockfile และ Dependency Pinning อย่างเคร่งครัดในทุกโปรเจกต์

เพื่อป้องกันการติดตั้ง Package เวอร์ชันใหม่ที่อาจถูกแทรกโค้ดอันตรายโดยไม่ได้ตรวจสอบก่อน

2. ตรวจสอบ Dependency ใหม่ทุกตัวก่อนเพิ่มเข้าโปรเจกต์ โดยเฉพาะ Package ที่มีประวัติผู้เผยแพร่สั้นหรือไม่มีประวัติการใช้งานมาก่อน

Package ที่เพิ่งสร้างบัญชีใหม่หรือมี Download Count ต่ำควรได้รับการตรวจสอบเป็นพิเศษก่อนนำไปใช้

3. แยก Environment ของ CI/CD Pipeline ออกจากเครื่อง Developer ส่วนบุคคล

เพื่อจำกัดผลกระทบหากเครื่อง Developer ติดมัลแวร์ ไม่ให้ลุกลามไปถึงกระบวนการ Build และ Deploy จริง

4. เปิดใช้งาน Dependency Scanning อัตโนมัติในทุก CI/CD Pipeline

เพื่อตรวจจับ Package อันตรายก่อนที่จะถูกรวมเข้าสู่ Codebase หรือ Build Artifact จริง

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

แคมเปญนี้เป็นตัวอย่างที่ชัดเจนของวิวัฒนาการเทคนิคการโจมตี Supply Chain ผ่าน Package Repository ที่ซับซ้อนขึ้นเรื่อยๆ การแยกส่วนประกอบของมัลแวร์ออกเป็นหลาย Package ในหลายชั้นของ Dependency Tree สะท้อนว่าผู้โจมตีเข้าใจข้อจำกัดของกระบวนการตรวจสอบโค้ดแบบดั้งเดิมที่มักตรวจสอบเฉพาะ Package ระดับบนสุดหรือไฟล์เดี่ยวๆ เป็นอย่างดี

TXEC มองว่าการมุ่งเป้าไปที่กลุ่มผู้ใช้เครื่องมือของ Alibaba โดยเฉพาะ สะท้อนแนวโน้มการโจมตี Supply Chain ที่มีความเจาะจงกลุ่มเป้าหมายมากขึ้น (Targeted Supply Chain Attack) แทนที่จะเป็นการโจมตีแบบกระจายวงกว้างเหมือนในอดีต องค์กรไทยที่มีทีมพัฒนาซอฟต์แวร์ใช้ npm เป็นเครื่องมือหลัก ควรทบทวนกระบวนการตรวจสอบ Dependency ให้ครอบคลุมถึงระดับ Transitive Dependency ไม่ใช่ตรวจสอบเฉพาะ Package ที่เพิ่มเข้าโปรเจกต์โดยตรงเท่านั้น

รู้ก่อน ตรวจพบเร็ว ลดความเสียหายได้มากกว่า

[ แหล่งอ้างอิง: Socket.dev, The Hacker News, GBHackers, CyberSecurityNews, Corgea ]