เจาะปมโจมตีซัพพลายเชน Mastra AI: แฮกเกอร์ขโมยบัญชีเดียว กระจายโค้ดอันตราย 145 แพ็กเกจ

Mastra เป็นเฟรมเวิร์ก JavaScript และ TypeScript แบบโอเพนซอร์สสำหรับสร้างแอปพลิเคชันและเอเจนต์ AI เหตุการณ์นี้จึงไม่ได้กระทบแค่แพ็กเกจรายย่อย แต่ทำให้ผู้พัฒนาในระบบนิเวศ AI ต้องเร่งตรวจสอบเครื่องมือและระบบ build ของตนเอง

การโจมตีเกิดขึ้นได้อย่างไร

1. หลอกลวงผู้ดูแล แล้วเข้ายึดบัญชี npm

ผู้โจมตีเริ่มจากการใช้วิศวกรรมสังคมโจมตีผู้ดูแล Mastra ที่ถูกต้องตามกฎหมาย จนได้ข้อมูลรับรองบัญชี npm มา

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

2. เผยแพร่แพ็กเกจจำนวนมากในเวลาอันสั้น

ผู้โจมตีใช้บัญชีที่ยึดมาได้เผยแพร่แพ็กเกจทั้งหมดใน namespace @mastra/* ภายในช่วงเวลา 88 นาที โดยบางรายงานระบุว่าการเผยแพร่ชุดใหญ่เกิดขึ้นภายในเวลาเพียง 19 นาที

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

3. แทรก dependency ที่ตั้งชื่อเลียนแบบแพ็กเกจจริง

แพ็กเกจที่ถูกบุกรุกถูกฝัง dependency ชื่อ easy-day-js ซึ่งเป็นชื่อเลียนแบบไลบรารีวันที่ยอดนิยมอย่าง dayjs

แคมเปญนี้จึงถูกเรียกว่า “easy-day-js” การใช้ชื่อที่คล้ายแพ็กเกจจริงเป็นเทคนิคที่ทำให้ผู้พัฒนาหรือระบบตรวจสอบมองข้ามความผิดปกติได้ง่ายขึ้น

4. โค้ดเริ่มทำงานทันทีระหว่าง npm install

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

จุดนี้ทำให้ความเสี่ยงไม่ได้จำกัดอยู่เฉพาะแอปที่สร้างด้วย Mastra แต่ครอบคลุมถึงเครื่องนักพัฒนา เซิร์ฟเวอร์ build และระบบ CI/CD ที่ติดตั้งแพ็กเกจดังกล่าวด้วย

5. มุ่งขโมยคีย์และข้อมูลลับ

เมื่อทำงานแล้ว เพย์โหลดจะค้นหาคีย์กระเป๋าเงินคริปโต ข้อมูลรับรองระบบคลาวด์ และความลับของ CI/CD จากเครื่องนักพัฒนาและระบบ build ที่ได้รับผลกระทบ

นอกจากนี้ยังมีรายงานว่าเพย์โหลดปิดการตรวจสอบ TLS และดาวน์โหลดโปรแกรมขโมยข้อมูลระยะที่สองจากโครงสร้างพื้นฐานที่ผู้โจมตีควบคุม

Microsoft ระบุผู้ก่อเหตุเป็น Sapphire Sleet

เมื่อวันที่ 19 มิถุนายน 2026 Microsoft ประเมินด้วยความมั่นใจสูงว่าเหตุการณ์นี้เชื่อมโยงกับ Sapphire Sleet กลุ่มภัยคุกคามจากเกาหลีเหนือที่มุ่งเป้าไปยังภาคการเงินเป็นหลัก

Microsoft อ้างอิงโครงสร้างพื้นฐานและรูปแบบการโจมตีหลังการบุกรุก หรือ TTPs ที่สอดคล้องกับปฏิบัติการของ Sapphire Sleet ซึ่งเคยมีการบันทึกไว้ก่อนหน้านี้ ขณะเดียวกัน Amazon Threat Intelligence ระบุว่ากลุ่มเดียวกันอาจเชื่อมโยงกับแคมเปญโจมตีแพ็กเกจ npm อื่น เช่น axios, debug, chalk และ typo-crypto

มาตรการตอบสนองของ Microsoft

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

1. ลดอายุ NuGet API key เหลือสูงสุด 30 วัน

ตั้งแต่วันที่ 17 สิงหาคม 2026 เป็นต้นไป NuGet.org จะจำกัดอายุสูงสุดของ API key ที่สร้างใหม่จากเดิม 365 วัน เหลือ 30 วัน

ส่วน API key ที่สร้างก่อนวันที่ดังกล่าวจะถูกทำให้หมดอายุทั้งหมดในวันที่ 1 พฤศจิกายน 2026

Microsoft ให้เหตุผลว่า API key อายุยาวเป็น “สตริงที่หลุดหรือสูญหายได้ง่าย” และกลายเป็นช่องทางสำคัญของการโจมตีซัพพลายเชน หากคีย์ถูกขโมย ผู้โจมตีจะมีเวลานานในการเผยแพร่แพ็กเกจที่ฝังโค้ดโทรจันภายใต้ชื่อโครงการที่ผู้ใช้ไว้วางใจ

2. ผลักดัน Trusted Publishing ที่ใช้ OIDC

Microsoft แนะนำให้ผู้ดูแลแพ็กเกจย้ายไปใช้ Trusted Publishing ซึ่งเปิดตัวในเดือนกันยายน 2025 แนวทางนี้ใช้การยืนยันตัวตนแบบ OpenID Connect (OIDC) แทนการเก็บ API key อายุยาวไว้ใน repository หรือระบบ CI/CD

ข้อดีหลักของ Trusted Publishing ได้แก่ :

• ไม่ต้องเก็บ secret อายุยาวไว้ใน repository หรือระบบ CI/CD
• ออกข้อมูลรับรองอายุสั้นเฉพาะตอนเผยแพร่ โดยมักมีอายุประมาณ 1 ชั่วโมง
• ตรวจสอบตัวตนของ workload ตาม repository, workflow และ environment ที่กำหนดไว้ในนโยบาย
• ไม่ต้องหมุนหรือเปลี่ยน secret ด้วยตนเองเป็นระยะ
• ลดขอบเขตความเสียหายได้มาก หากข้อมูลรับรองถูกเปิดเผย

ในขั้นตอนการทำงาน CI/CD จะขอโทเค็น OIDC ที่มีลายเซ็นเข้ารหัสจากผู้ให้บริการ เช่น GitHub Actions จากนั้น NuGet.org จะตรวจสอบโทเค็นกับนโยบาย publisher ที่ลงทะเบียนไว้ และออก API key ชั่วคราวแบบใช้ครั้งเดียวสำหรับการเผยแพร่รอบนั้น

แนวคิดสำคัญคือ การเปลี่ยนจากการฝาก “กุญแจถาวร” ไว้ในระบบ มาเป็นการตรวจสอบว่า workflow ใด repository ใด และสภาพแวดล้อมใดได้รับอนุญาตให้เผยแพร่

3. npm และระบบนิเวศแพ็กเกจออกมาตรการเสริม

การเปลี่ยนแปลงอื่นในระบบนิเวศ npm ช่วยอุดช่องโหว่ประเภทเดียวกับที่ Sapphire Sleet ใช้โจมตี ได้แก่

• ยกเลิก classic token ของ npm: npm เพิกถอน classic token อายุยาวทั้งหมดอย่างถาวรในเดือนธันวาคม 2025 และคำสั่ง npm login จะออก session token ที่มีอายุเพียง 2 ชั่วโมง
• จำกัดอายุ granular token: granular access token ที่มีสิทธิ์เขียนรายการใหม่มีค่าเริ่มต้น 7 วัน และมีอายุสูงสุด 90 วัน จากเดิมที่ไม่มีเพดานอายุและมีค่าเริ่มต้น 30 วัน
• เพิ่ม staged publishing: ฟีเจอร์นี้เปิดให้ใช้งานทั่วไปตั้งแต่เดือนพฤษภาคม 2026 โดยกำหนดให้ผู้ดูแลยืนยันผ่าน 2FA และอนุมัติ release อย่างชัดเจน ก่อนที่แพ็กเกจจะเปิดให้ติดตั้งจากสาธารณะ

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

สิ่งที่นักพัฒนาและผู้ดูแลแพ็กเกจควรทำ

• ตรวจสอบและเปลี่ยน NuGet API key ที่มีอยู่: คีย์ที่สร้างก่อน 17 สิงหาคม 2026 จะหมดอายุในวันที่ 1 พฤศจิกายน 2026 ควรสร้างคีย์ใหม่หรือย้ายไปใช้ Trusted Publishing ก่อนถึงกำหนด
• ย้ายระบบเผยแพร่ไปใช้ OIDC: Trusted Publishing ช่วยลดความจำเป็นในการเก็บ secret อายุยาวใน pipeline และรองรับโดย NuGet.org, npm และ PyPI
• ทบทวน workflow สำหรับเผยแพร่แพ็กเกจ npm: ตรวจสอบว่า pipeline ใช้ session token, granular token ที่มีอายุจำกัด หรือ Trusted Publishing ตามแนวทางที่รองรับ
• ล็อกเวอร์ชัน dependency: สำหรับระบบสำคัญ ควร pin เวอร์ชันที่ผ่านการตรวจสอบแล้ว และหลีกเลี่ยงการอัปเกรด dependency อัตโนมัติจนกว่าจะตรวจสอบเรียบร้อย
• ปิดการทำงานของสคริปต์ติดตั้งอัตโนมัติเมื่อเหมาะสม: การใช้ npm install --ignore-scripts หรือตั้งค่า ignore-scripts = true ช่วยป้องกันไม่ให้สคริปต์ postinstall ที่เป็นอันตรายทำงานระหว่างติดตั้ง

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