tensorlake 0.5.144 ขโมยคีย์ตอนติดตั้ง—อย่าเพิ่งหมุนโทเค็นผิดลำดับ

ตามรายงานของ Socket แพ็กเกจ npm ชื่อ [email protected] ที่เผยแพร่เมื่อ 8 ตุลาคม 2026 มีคำสั่ง preinstall เรียกโค้ดขโมยข้อมูลรับรองระหว่างติดตั้ง ผู้พัฒนาไม่ต้องนำ SDK ไปใช้ในโปรแกรมก่อน โค้ดนี้ก็มีโอกาสทำงานได้ ทีมที่ติดตั้งรุ่นดังกล่าวจึงควรแยกเครื่องที่เกี่ยวข้อง ตรวจเส้นทางการติดตั้ง และกำจัดกลไกเฝ้า GitHub token ก่อนเพิกถอนโทเค็น

จุดที่ต้องแยกให้ชัดคือ การพบรุ่นอันตรายใน lockfile การดาวน์โหลดแพ็กเกจ และการทำงานของ preinstall เป็นหลักฐานคนละระดับ หากสคริปต์ทำงาน ให้ถือว่าข้อมูลรับรองซึ่งบัญชีที่ติดตั้งอ่านได้อาจรั่วไหล รวมทั้งสิทธิ์ที่ส่งให้เครื่องนักพัฒนาหรือ CI runner การลบ dependency หรือเปลี่ยนคีย์ทันทีบนเครื่องเดิมไม่ช่วยกำจัดโค้ดที่อาจฝังตัวอยู่ และการเพิกถอน GitHub token ผิดลำดับอาจกระตุ้นคำสั่งทำลายข้อมูล

ตามหาแพ็กเกจให้ครบ แล้วแยกหลักฐานการติดตั้งออกจากการรันโค้ด

เริ่มจากระบุทุกโครงการที่ประกาศใช้ tensorlake ไม่ว่าจะเป็น dependency โดยตรงหรือถูกดึงเข้ามาผ่านแพ็กเกจอื่น ตรวจ package.json ควบคู่กับ package-lock.json, yarn.lock หรือ pnpm-lock.yaml โดยเทียบชื่อแพ็กเกจและรุ่นให้ตรงทั้งคู่ การค้นเพียงคำว่า tensorlake ในไฟล์อาจพบชื่อที่คล้ายกัน ส่วนการดูช่วงรุ่นที่อนุญาตใน manifest อย่างเดียวอาจพลาดรุ่นที่ถูกตรึงไว้จริงใน lockfile

จากนั้นจับคู่ผลกับ node_modules แคชของ package manager บันทึกการดาวน์โหลดจาก registry และบันทึกงาน build ระบุให้ได้ว่าเครื่องใด ผู้ใช้หรือบัญชีบริการใด และงานใดเป็นผู้ดึงแพ็กเกจ การพบสำเนาในแคชบอกได้ว่ามีการดาวน์โหลด แต่ยังไม่บอกว่าสคริปต์ติดตั้งทำงาน บันทึกการติดตั้ง การตั้งค่า lifecycle scripts และช่วงเวลาที่เครื่องรันคำสั่งจึงเป็นหลักฐานสำคัญกว่าในการประเมินการเปิดเผยข้อมูลลับ

ให้ตรวจ package manifest ของสำเนาที่ติดตั้งว่ามี preinstall เรียก lib/setup.mjs หรือไม่ และเก็บสำเนาไฟล์กับบันทึกที่เกี่ยวข้องไว้ก่อนทำความสะอาด เครื่องที่มีหลักฐานว่ารันสคริปต์ควรเข้าสู่การตอบสนองเหตุการณ์ทันที หากหลักฐานยังไม่ครบแต่เครื่องติดตั้งรุ่นดังกล่าวในสภาพแวดล้อมที่อนุญาตให้ lifecycle scripts ทำงาน ให้จัดเป็นเครื่องต้องสงสัยจนกว่าจะตรวจได้ ไม่ควรตีความการไม่พบข้อความผิดพลาดใน install log ว่าโค้ดไม่เคยเริ่มทำงาน

โค้ดติดตั้งใช้ lib/setup.mjs เป็นตัวโหลด และมี payload อยู่ใน lib/Math_Symbol.js การตรวจเพียงว่ามีไฟล์สองรายการนี้อยู่ในแพ็กเกจจึงช่วยระบุสิ่งที่ถูกนำเข้ามา แต่ไม่ได้แสดงว่าข้อมูลถูกส่งออกไปแล้ว หลักฐานที่ต้องหาต่อคือกระบวนการที่ถูกเรียก การเชื่อมต่อเครือข่ายในช่วงติดตั้ง ไฟล์ที่ถูกสร้างหรือแก้ไข และกิจกรรมของบัญชีที่เครื่องเข้าถึงได้

แยก workstation กับ CI runner ตามสิทธิ์และเงื่อนไขที่โค้ดทำงาน

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

CI runner ต้องตรวจเป็นรายงาน ไม่ใช่เหมารวมทั้งระบบ การวิเคราะห์โค้ดของ Sonatype พบว่าตัวโหลดออกก่อนเรียก payload เมื่อ CI มีค่าเป็น true หรือ 1 เมื่อ GITHUB_ACTIONS หรือ GITLAB_CI เป็น true หรือเมื่อ RUNNER_ENVIRONMENT เป็น github-hosted เงื่อนไขเหล่านี้ใช้ประเมินเส้นทาง preinstall ที่ตรวจพบเท่านั้น งานบน runner ที่ไม่มีค่าตรงตามเงื่อนไขยังต้องตรวจการทำงานของสคริปต์และข้อมูลลับที่งานนั้นได้รับ

สำหรับแต่ละงาน build ให้บันทึกคำสั่งติดตั้ง ค่า environment ที่เกี่ยวข้อง การตั้งค่าให้ข้าม install scripts และชนิดของ runner ที่ใช้ หากเป็น runner ใช้ซ้ำ ให้ตรวจงานก่อนและหลังช่วงติดตั้งด้วย เพราะไฟล์หรือกระบวนการที่คงอยู่สามารถกระทบงานถัดไปได้ หาก runner ถูกสร้างใหม่ทุกครั้ง ให้ตรวจภาพเครื่อง ต้นทาง dependency แคช และข้อมูลลับที่ถูกส่งเข้ามาในงานที่สงสัย การสร้าง runner ใหม่ลดความเสี่ยงจากโค้ดที่ค้างบนเครื่อง แต่ไม่เพิกถอนคีย์ที่ payload อาจอ่านไปแล้ว

อย่าให้ผลตรวจ CI กลบความเสี่ยงจาก workstation ของผู้พัฒนา เครื่องส่วนตัวอาจไม่มีตัวแปรที่ทำให้ตัวโหลดออก และมักเก็บโทเค็น GitHub หรือ npm ไว้ในบริบทเดียวกับเครื่องมือเขียนโค้ด หลักฐานว่า pipeline หนึ่งข้าม payload จึงไม่ใช่หลักฐานว่าโครงการเดียวกันปลอดภัยบนเครื่องอื่น

ตรวจร่องรอยการใช้สิทธิ์ ก่อนสรุปว่าข้อมูลใดต้องเปลี่ยน

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

ตรวจไดเรกทอรีและการตั้งค่าของเครื่องมือพัฒนา AI รวมถึงไฟล์ .claude และ .vscode ใน repository ที่บัญชี GitHub เข้าถึงได้ โค้ดอันตรายมีความสามารถแก้ไขไฟล์ตั้งค่าใน repository และอาจสร้าง repository สาธารณะเพื่อเผยแพร่ข้อมูลที่เก็บมา จึงควรดู repository ใหม่ การแก้ไข branch, commit ที่ไม่คุ้นเคย และไฟล์ภายใต้ results/ ควบคู่กับบันทึกการเข้าถึงบัญชี ความสามารถที่พบในโค้ดยังไม่เท่ากับหลักฐานว่าการกระทำเหล่านี้เกิดขึ้นกับทุกบัญชี

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

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

หยุด gh-token-monitor ก่อนเพิกถอน GitHub token

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

หลังแยกเครื่อง ให้ตรวจทั้งกระบวนการที่กำลังทำงานและช่องทางเริ่มทำงานอัตโนมัติของบัญชีผู้ใช้ที่ติดตั้งแพ็กเกจ บน Linux ให้ดูบริการระดับผู้ใช้และไดเรกทอรีที่เกี่ยวกับ gh-token-monitor; บน macOS ให้ดู LaunchAgent; บน Windows ให้ดู scheduled task ที่เรียกสคริปต์เฝ้าโทเค็น บันทึกร่องรอยที่จำเป็นก่อนหยุดบริการ แล้วกำจัดกลไกเริ่มทำงานและตรวจว่ากระบวนการไม่กลับมาอีก

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

เมื่อยืนยันว่าตัวเฝ้าหยุดและไม่เริ่มใหม่แล้ว จึงเพิกถอน GitHub token จากเครื่องที่เชื่อถือได้ ตรวจว่ามีโทเค็นอื่นของบัญชีเดียวกันอยู่บนเครื่องต้องสงสัยหรือไม่ และทบทวนสิทธิ์ repository กับ workflow ที่โทเค็นนั้นเคยเข้าถึง ขั้นตอนนี้ยังไม่ใช่การคืนเครื่องสู่การใช้งาน เพราะอาจมีไฟล์หรือกลไกอื่นของ payload หลงเหลืออยู่

หมุนคีย์จากเครื่องที่เชื่อถือได้ โดยแยกตามบริการ

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

• npm: ตรวจ .npmrc โทเค็นสำหรับเผยแพร่ และสิทธิ์ที่บัญชีบนเครื่องใช้กับแพ็กเกจขององค์กร เพิกถอนโทเค็นในขอบเขตเสี่ยง ออกโทเค็นใหม่จากเครื่องที่เชื่อถือได้ แล้วเทียบประวัติการเผยแพร่กับรายการที่ทีมอนุมัติ หากพบรุ่นที่ไม่รู้จัก ให้ตรวจแพ็กเกจนั้นด้วยก่อนให้ผู้ใช้อื่นติดตั้งต่อ
• GitHub: ดำเนินการหลังตรวจและกำจัด gh-token-monitor แล้ว เพิกถอนโทเค็นที่เครื่องเข้าถึงได้ รวมถึงข้อมูลรับรองที่เก็บในเครื่องมือพัฒนาซึ่งมีสิทธิ์เทียบเท่ากัน ตรวจการสร้าง repository, การเปลี่ยน branch, commit, workflow และไฟล์ตั้งค่า .claude หรือ .vscode ในโครงการที่บัญชีนั้นเข้าถึงได้
• AWS: ตรวจไฟล์ข้อมูลรับรอง ตัวแปรสภาพแวดล้อม และบทบาทที่ workstation หรือ runner ใช้ได้ ระบุว่าบัญชีดังกล่าวเข้าถึง Secrets Manager, Systems Manager Parameter Store หรือบริการอื่นใด แล้วเทียบบันทึก API กับกิจกรรมตามปกติ เปลี่ยนข้อมูลรับรองที่เปิดเผยและทบทวนสิทธิ์ของบทบาทที่เกี่ยวข้อง
• Kubernetes: ตรวจ kubeconfig บนเครื่องและ service-account token ที่ถูกส่งเข้ามาในงาน build ดูว่าข้อมูลเหล่านั้นเปิดทางให้เข้าถึงคลัสเตอร์หรือ namespace ใด เพิกถอนหรือเปลี่ยนสิทธิ์ที่เสี่ยง พร้อมตรวจบันทึกการเข้าถึงและการเปลี่ยนทรัพยากรในขอบเขตดังกล่าว
• HashiCorp Vault: ตรวจโทเค็นที่บันทึกไว้ วิธีรับรองตัวตน และความสามารถของบัญชีที่รันการติดตั้งในการขอข้อมูลลับจาก Vault เพิกถอนโทเค็นหรือเซสชันที่เสี่ยง แล้วใช้ audit log ระบุเส้นทางข้อมูลลับที่ถูกอ่าน หากข้อมูลรับรองปลายทางอาจถูกดึงออกมา ต้องหมุนข้อมูลปลายทางนั้นด้วย
• เครื่องมือพัฒนาและไฟล์โครงการ: รวม SSH key, ไฟล์ .env และการตั้งค่าเครื่องมือเขียนโค้ด AI ที่บัญชีติดตั้งอ่านได้ไว้ในรายการตรวจสอบ ตรวจว่าคีย์เดียวกันถูกใช้กับบริการอื่นหรือไม่ และเปลี่ยนคีย์ที่เสี่ยงตามขอบเขตการเข้าถึง ไม่จำกัดการตอบสนองไว้เพียงโทเค็นของ npm กับ GitHub

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

คืนเครื่องและ pipeline เมื่อเส้นทางแพร่ต่อถูกปิด

ก่อนนำ workstation หรือ runner กลับมาใช้ ให้สร้างสภาพแวดล้อมใหม่จากแหล่งที่เชื่อถือได้และติดตั้ง dependency โดยไม่มีรุ่นอันตราย ตรวจ lockfile กับแคชอีกครั้งเพื่อไม่ให้การ build ถัดไปดึงสำเนาเดิมกลับมา หากมี mirror หรือ registry ภายใน ให้กักสำเนาที่เก็บไว้และตรวจบันทึกว่าเครื่องใดเคยดาวน์โหลดไปแล้ว

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

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