กลับ

2026/11/02

การโจรกรรมคริปโตครั้งใหญ่ที่สุดไม่ได้เริ่มบนบล็อกเชน แต่เริ่มจากแล็ปท็อปเครื่องเดียว: บทเรียนจาก Binance

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

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

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

ประเด็นสำคัญ

  • การสอบสวนเบื้องต้นของ Binance ชี้ว่าจุดเริ่มต้นของการเจาะระบบคือแล็ปท็อปของวิศวกร DevOps ที่ถูกเจาะ และ Binance ระบุว่ายังไม่พบหลักฐานว่ากุญแจส่วนตัว (private key) ของวอลเล็ตรั่วไหล ข้อสรุปทั้งสองข้อนี้ยังเป็นข้อมูลเบื้องต้น
  • ผู้โจมตีที่ควบคุมระบบที่ใช้ร้องขอและอนุมัติลายเซ็นได้ ไม่จำเป็นต้องขโมยกุญแจเลย
  • FBI และบริษัทวิเคราะห์บล็อกเชนหลายแห่งระบุว่าการโจรกรรมนี้เป็นฝีมือของกลุ่ม TraderTraitor จากเกาหลีเหนือ ส่วน Binance เองยังไม่ได้ระบุชื่อผู้โจมตี
  • มาตรการป้องกันที่สำคัญที่สุดคือการปกป้องบุคลากร เอนด์พอยต์ และเส้นทางการอนุมัติที่อยู่รอบกุญแจ ไม่ใช่ปกป้องเฉพาะตัวกุญแจเท่านั้น
  • รูปแบบเดียวกันนี้ใช้ได้กับคอนโซลคลาวด์ SSH ไปป์ไลน์ CI/CD และเอเจนต์ AI ที่สามารถดำเนินการในระบบ production ได้

เกิดอะไรขึ้น และอะไรที่ยังเป็นข้อมูลเบื้องต้น

บริษัทวิเคราะห์บล็อกเชน TRM Labs รายงานว่าเงินเริ่มไหลออกจากวอลเล็ตของ Binance เมื่อเวลาประมาณ 20:05 UTC ของวันที่ 29 ตุลาคม โดยมูลค่าส่วนใหญ่ถูกโอนออกไปภายในราว 20 นาที ในแถลงการณ์เบื้องต้นที่ BleepingComputer รายงาน Binance ระบุว่าเหตุการณ์นี้อาจเกี่ยวข้องกับแล็ปท็อปของวิศวกร DevOps ที่ถูกเจาะ ซึ่งผู้โจมตีใช้เป็นช่องทางเข้าถึงคอนเทนเนอร์ของบริการและส่งธุรกรรมถอนเงินที่ไม่ได้รับอนุญาต Binance ได้ระงับการถอนเงิน เพิกถอนการอนุญาตที่ได้รับผลกระทบ และเริ่มประสานงานกับหน่วยงานบังคับใช้กฎหมาย

ต่อมา Binance ระบุว่าการสอบสวน “พบจุดที่ถูกเจาะระบบเพิ่มเติม” Richard Teng ซีอีโอร่วม กล่าวว่าการโจมตีครั้งนี้ไม่ได้เกิดจากสิทธิ์ของวิศวกรเพียงคนเดียว และตามที่ Elliptic อ้างคำพูดของเขา การโจมตี “ไม่ได้ผ่านกลไกควบคุมการอนุมัติตามปกติของเรา” Binance สัญญาว่าจะเผยแพร่รายงานวิเคราะห์หลังเหตุการณ์ (post-mortem) โดยละเอียด ซึ่ง ณ เวลาที่เขียนบทความนี้ (2 พฤศจิกายน) ยังไม่ได้เผยแพร่

ประเด็นสถานะ ณ เวลาที่เขียนบทความ
มูลค่าที่ได้รับผลกระทบประมาณ 6.3 พันล้านดอลลาร์สหรัฐตามการประเมินของ Binance ส่วนบริษัทวิเคราะห์รายงานไว้ที่ 6.36 ถึง 6.43 พันล้านดอลลาร์สหรัฐ ขึ้นอยู่กับวิธีการและการตีราคา
จุดเริ่มต้นการเจาะระบบข้อมูลเบื้องต้น: แล็ปท็อปของวิศวกร DevOps ที่ถูกเจาะ ต่อมา Binance รายงานว่าพบจุดที่ถูกเจาะระบบเพิ่มเติม
การรั่วไหลของกุญแจส่วนตัวBinance ระบุว่ายังไม่พบหลักฐานว่ากุญแจส่วนตัวของวอลเล็ตรั่วไหล การสอบสวนยังดำเนินอยู่
ผู้ก่อเหตุFBI ระบุเมื่อวันที่ 31 ตุลาคมว่าการโจรกรรมเป็นฝีมือของ TraderTraitor จากเกาหลีเหนือ ซึ่งสอดคล้องกับ TRM Labs, Chainalysis และ Elliptic ส่วน Binance ยังไม่ได้ระบุชื่อผู้โจมตี
เงินที่ถูกอายัดยังไม่ใช่ตัวเลขสุดท้าย Binance ระบุว่ามีเงินประมาณ 3 พันล้านดอลลาร์สหรัฐที่ถูกตรึงไว้ ส่วน Elliptic ยืนยันบนเชนแล้วว่ามีประมาณ 2.85 พันล้านดอลลาร์สหรัฐที่ถูกอายัดหรือยึด ณ วันที่ 1 พฤศจิกายน ซึ่งส่วนใหญ่เป็นสเตเบิลคอยน์
ผลกระทบต่อลูกค้าBinance ระบุว่าจะรับผิดชอบความเสียหายเอง และเงินของผู้ใช้ปลอดภัย การถอนเงินเริ่มเปิดให้บริการอีกครั้งเป็นระยะตั้งแต่วันที่ 1 พฤศจิกายน

การอายัดไม่ได้หมายความว่าได้เงินคืนแล้ว ผู้ออกสเตเบิลคอยน์อย่าง Tether และ Circle สามารถอายัดโทเคนที่ตนออกได้ แต่บิตคอยน์ XRP และสินทรัพย์ดั้งเดิม (native asset) อื่น ๆ ไม่สามารถอายัดด้วยวิธีนั้นได้ และมูลค่าที่ถูกขโมยส่วนใหญ่ยังอยู่ระหว่างการฟอกเงิน

ทำไมเอนด์พอยต์ที่มีสิทธิ์พิเศษซึ่งถูกเจาะระบบจึงอาจอันตรายกว่ากุญแจที่ถูกขโมย

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

หลักฐานบนเชนสอดคล้องกับภาพนี้ TRM Labs ประเมินว่ารูปแบบที่พบในหลายเชน “ชี้ไปที่การเจาะระบบโครงสร้างพื้นฐานการลงนามของฮอตวอลเล็ตของ Binance” หมายความว่าผู้โจมตีสามารถทำให้ระบบของ Binance เองลงนามในธุรกรรมที่ผู้โจมตีเลือกได้ บน Ethereum บริษัทด้านความปลอดภัย Blockaid พบว่าฮอตวอลเล็ตแห่งหนึ่งได้ลงนามในชุดการอนุญาต EIP-7702 ที่มอบการควบคุมวอลเล็ตให้กับสัญญาของผู้โจมตี ส่วนลายเซ็นเหล่านั้นได้มาอย่างไรยังไม่ได้รับการยืนยัน และเราจะอธิบายกลไกดังกล่าวในบทความติดตามผลอีกฉบับหนึ่ง

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

5 จุดตรวจสอบเพื่อการป้องกัน

1. แยกอุปกรณ์ที่มีสิทธิ์พิเศษออกจากงานประจำวัน

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

2. กำหนดให้ต้องมีผู้อนุมัติมากกว่าหนึ่งคน และเพิ่มระยะเวลาหน่วง

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

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

3. เสริมความปลอดภัยให้เอนด์พอยต์และเฝ้าระวังอย่างต่อเนื่อง

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

4. ตรวจจับความผิดปกติและสามารถอายัดได้อย่างรวดเร็ว

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

5. ตรวจสอบว่าใครและอะไรบ้างที่สามารถเรียกใช้การลงนามและการเข้าถึงระบบ production ได้

ทำรายการบุคคล บัญชีบริการ คอนเทนเนอร์ ไปป์ไลน์ และคีย์ API ทั้งหมดที่สามารถร้องขอลายเซ็น อนุมัติการชำระเงิน หรือเปลี่ยนแปลงระบบ production ได้ สำหรับแต่ละรายการ ให้ตรวจสอบว่ายังจำเป็นต้องมีสิทธิ์นั้นอยู่หรือไม่ ขอบเขตสิทธิ์แคบที่สุดเท่าที่ทำได้หรือยัง และการใช้งานถูกบันทึกไว้ในที่ที่ผู้โจมตีไม่สามารถลบได้หรือไม่ ยกเลิกสิทธิ์ถาวร (standing privilege) เมื่อทำได้ และเปลี่ยนไปใช้การเข้าถึงแบบ just-in-time แทน

บทเรียนสำหรับคลาวด์องค์กร SSH, CI/CD และการปฏิบัติการด้วย AI

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

  • คลาวด์: แล็ปท็อปของผู้ดูแลระบบที่มีเซสชันคอนโซลเปิดอยู่หรือมีข้อมูลรับรอง CLI แคชไว้ มีค่าเท่ากับบัญชี root ควรใช้ข้อมูลรับรองอายุสั้น เซสชันที่ผูกกับอุปกรณ์ และขั้นตอนการอนุมัติสำหรับการดำเนินการที่ทำลายล้างหรือมีผลกระทบสูง
  • SSH: กุญแจอายุยาวที่เก็บอยู่บนเครื่องของวิศวกรเปิดทางให้ผู้โจมตีเข้าถึงเซิร์ฟเวอร์ได้โดยตรง ควรใช้ใบรับรอง SSH อายุสั้นที่ออกให้ต่อเซสชัน และบันทึกทุกเซสชันที่มีสิทธิ์พิเศษไว้ที่ศูนย์กลาง
  • CI/CD: ไปป์ไลน์มักถือข้อมูลรับรองสำหรับการ deploy และการลงนาม ควรปกป้องนิยามไปป์ไลน์ด้วยข้อกำหนดการรีวิว แยกข้อมูลรับรองสำหรับการ build และการ release ออกจากกัน และกำหนดให้การ release ขึ้นระบบ production ต้องได้รับอนุมัติ
  • การปฏิบัติการที่ขับเคลื่อนด้วย AI: เอเจนต์ AI ที่สามารถรันคำสั่ง เปิด pull request หรือเรียก API ของระบบ production ได้ ถือเป็นตัวตนที่มีสิทธิ์พิเศษรูปแบบใหม่ ควรให้ข้อมูลรับรองเฉพาะของตัวเองที่มีขอบเขตแคบ คงขั้นตอนการอนุมัติโดยมนุษย์ไว้สำหรับการดำเนินการที่อ่อนไหว และบันทึกสิ่งที่เอเจนต์ทำ

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

สิ่งที่ต้องติดตามต่อไป

รายงาน post-mortem ของ Binance น่าจะยืนยันหรือแก้ไขสมมติฐานเรื่องแล็ปท็อป อธิบายว่าได้ลายเซ็นมาอย่างไร และแสดงให้เห็นว่ามีกลไกควบคุมใดบ้างที่ถูกหลบเลี่ยง จนกว่าจะถึงตอนนั้น ให้ถือว่าสาเหตุที่แท้จริงยังเป็นข้อมูลเบื้องต้น บทเรียนด้านการป้องกันข้างต้นไม่ได้ขึ้นอยู่กับรายละเอียดสุดท้าย ไม่ว่าเส้นทางที่แท้จริงจะเป็นอย่างไร ผู้โจมตีก็เข้าถึงระบบที่สามารถอนุมัติการดำเนินการที่อ่อนไหวได้

LOGIQ ช่วยคุณได้อย่างไร

LOGIQ ช่วยองค์กรตรวจสอบการเข้าถึงด้วยสิทธิ์พิเศษบนเซิร์ฟเวอร์ Linux สภาพแวดล้อมคลาวด์ และไปป์ไลน์ CI/CD รวมถึงออกแบบกลไกการอนุมัติและการเฝ้าระวังที่เหมาะกับวิธีการทำงานจริงของทีม หากคุณต้องการให้มีผู้ช่วยตรวจสอบอีกชั้นว่าใครและอะไรบ้างที่สามารถดำเนินการด้วยอำนาจสิทธิ์ในสภาพแวดล้อมของคุณ ติดต่อเรา

แหล่งที่มา