สรุปผลการสืบสวน Binance Hack ตุลาคม 2026: ความจริง 6.3B USD ข้าม 10 เชน, ปมจุดบุกรุก และข้อเท็จจริง EIP-7702

⚠️ สถานะข้อมูล ณ 31 ตุลาคม 2026:
บทความนี้เป็น บทวิเคราะห์อิสระ ไม่ใช่รายงานสืบสวนอย่างเป็นทางการของ Binance และไม่ใช่ technical post-mortem ฉบับสมบูรณ์ ข้อเท็จจริงบางส่วนอาจเปลี่ยนแปลงได้เมื่อมีข้อมูลใหม่ โปรดอ่านป้ายกำกับ [ยืนยันโดย Binance], [รายงานโดยนักวิเคราะห์], [ข้อสันนิษฐาน], และ [ยังไม่ทราบ] ประกอบทุกประเด็น
บทความนี้ต่อยอดจากบทวิเคราะห์เบื้องต้นวันที่ 30 ตุลาคม 2026 (เพิ่มลิงก์สาธารณะของบทความเดิมเมื่อเผยแพร่แล้ว)

---

สรุปสำหรับผู้อ่าน (Executive Summary)

เมื่อวันที่ 29 ตุลาคม 2026 เวลาประมาณ 20:05 UTC Binance รายงานเหตุการณ์ถอนสินทรัพย์ออกจาก hot wallets โดยไม่ได้รับอนุญาต บริษัทประเมินมูลค่าความเสียหายที่ ประมาณ 6.3 พันล้านดอลลาร์สหรัฐ และระบุว่ามีสินทรัพย์ถูกอายัดบนบล็อกเชนแล้วประมาณ 3 พันล้านดอลลาร์ บริษัทประกาศว่าจะรับภาระความเสียหายด้วยกองทุน SAFU และเงินของบริษัท พร้อมระบุว่าการสอบสวนยังดำเนินอยู่ [1]

TRM Labs ประเมินมูลค่าการเคลื่อนย้ายสินทรัพย์ราว 6.36 พันล้านดอลลาร์ ข้าม 10 บล็อกเชน ส่วน Elliptic ประเมิน 6.43 พันล้านดอลลาร์ ตัวเลขเหล่านี้เป็นประมาณการจากต่างหน่วยงานและช่วงเวลาประเมิน จึงไม่ควรนำมารวมกันหรือเรียกว่าเป็นตัวเลขเดียวกัน [2][3]

ตารางระดับความมั่นใจ (Confidence Matrix)

ประเด็น	สิ่งที่กล่าวได้ ณ วันตรวจสอบ	สถานะ / แหล่งข้อมูล
เกิดการถอนเงินโดยไม่ได้รับอนุญาต	Binance ระบุผลกระทบประมาณ 6.3B USD	[ยืนยันโดย Binance] [1]
ครอบคลุม 10 บล็อกเชน	TRM Labs ระบุ 10 เชน และส่วนใหญ่เกิดในเวลาราว 20 นาที	[รายงานโดยนักวิเคราะห์] [2]
ผู้โจมตีคือ TraderTraitor	TRM Labs ประเมินด้วยความเชื่อมั่นสูง แต่ Binance ยังไม่ได้ยืนยันตัวผู้กระทำ	[การระบุผู้โจมตีโดยนักวิเคราะห์] [2][1]
จุดเริ่มต้นจากแล็ปท็อป DevOps	เป็นสมมติฐานการสอบสวนเบื้องต้น ต่อมาพบจุดบุกรุกอื่นเพิ่มเติม	[ยังไม่ใช่ root cause ขั้นสุดท้าย] [1][4]
มี private key หลุดหรือไม่	Binance ระบุว่า ยังไม่พบหลักฐาน การรั่วไหล	[ยังไม่พิสูจน์ว่าเป็นไปไม่ได้] [1]
ใช้ EIP-7702 และ 50 authorizations	TRM Labs และ Elliptic รายงานเทคนิคนี้บน Ethereum	[รายงานโดยนักวิเคราะห์] [2][3]
สินทรัพย์ถูกอายัด	Binance ระบุ ~3B USD; Elliptic ตรวจพบ ~2.84B USD ณ เวลาสำรวจของตน	[ตัวเลขต่างแหล่ง/เวลาต่างกัน] [1][3]
เงินผู้ใช้จะได้รับการคุ้มครอง	Binance ประกาศรับภาระความเสียหาย และกันเงินไว้มากกว่า 6.34B USD	[คำประกาศ/แผนของบริษัท ไม่ใช่หลักฐานว่าชดเชยเสร็จสิ้น] [1]
ถอนเงินกลับมาใช้งานได้ทั้งหมด	Binance ตั้งเป้าเปิดถอนเงินแบบทยอยเป็นระยะหลังผ่านการตรวจสอบ	[ยังไม่ยืนยันว่ากลับมาเต็มรูปแบบ] [1]

---

1. เกิดอะไรขึ้น และตัวเลข 6.3B หมายถึงอะไร?

[ยืนยันโดย Binance] บริษัทระบุว่า hot wallets ถูกโจมตีและเกิดการถอนสินทรัพย์โดยไม่ได้รับอนุญาตในวันที่ 29 ตุลาคม 2026 เวลาประมาณ 20:05 UTC มูลค่าราว 6.3B USD [1]

[รายงานโดยนักวิเคราะห์] TRM Labs รายงานสินทรัพย์ถูกเคลื่อนย้ายออกจากกระเป๋าของ Binance บน 10 บล็อกเชน โดยส่วนใหญ่เกิดขึ้นภายในประมาณ 20 นาที และประเมินที่ 6.36B USD ขณะที่ Elliptic ประเมินที่ 6.43B USD [2][3]

⚠️ ข้อควรระวังในการตีความตัวเลขทางการเงิน:
ตัวเลข มูลค่าที่ถูกขโมย, มูลค่าที่ถูกอายัด, มูลค่าที่สามารถกู้คืนได้จริง, และ ผลขาดทุนสุดท้ายที่บริษัทต้องรับ ไม่ใช่ตัวเลขเดียวกัน การอายัดสินทรัพย์ไม่ได้แปลว่าเงินถูกโอนคืนให้ Binance แล้ว และไม่ควรนำยอดที่อายัดไปลบออกแล้วเรียกผลลัพธ์ว่า “ความเสียหายสุทธิที่ยืนยันแล้ว”

---

2. ใครอยู่เบื้องหลัง?

[รายงานโดยนักวิเคราะห์] TRM Labs ประเมินด้วยความเชื่อมั่นสูงว่ากลุ่ม TraderTraitor ซึ่งเชื่อมโยงกับเกาหลีเหนือเกี่ยวข้องกับเหตุการณ์นี้ [2] สำนักข่าวและบริษัทวิเคราะห์รายอื่นรายงานการประเมินในทิศทางเดียวกัน [3][5]

[ยังไม่ยืนยันโดย Binance] การระบุผู้กระทำยังไม่ใช่ข้อสรุปสุดท้ายของบริษัท Binance ระบุว่ากำลังทำงานร่วมกับหน่วยงานบังคับใช้กฎหมายและผู้เชี่ยวชาญเพื่อพิสูจน์ตัวผู้โจมตี [1] ความคล้ายคลึงของรูปแบบธุรกรรมหรือความเชื่อมโยงของกระเป๋าเงินเป็นหลักฐานที่ใช้ประกอบ attribution แต่ไม่ควรนำเสนอเป็นคำพิพากษาหรือข้อยืนยันจากทุกฝ่าย

Elliptic รายงานว่าเงินบางส่วนเชื่อมโยงกับที่อยู่ซึ่งเคยได้รับเงินจากเหตุการณ์ Bitget ในเดือนกันยายน 2026 โดยอ้างการค้นพบของ ZachXBT ด้วย [3] อย่างไรก็ตาม ความเชื่อมโยงของที่อยู่ไม่ได้พิสูจน์ด้วยตัวเองว่าเป็นผู้ควบคุมคนเดียวกันในทุกช่วงเวลา

---

3. เส้นทางการบุกรุก: DevOps, Service Container และระบบลงนาม

[ยืนยันว่าเป็นข้อค้นพบเบื้องต้นของ Binance] ประกาศฉบับแรกระบุว่าอาจมีแล็ปท็อปของวิศวกร DevOps ถูกโจมตี จนผู้โจมตีเข้าถึง service container และส่งคำขอถอนเงินโดยไม่ได้รับอนุญาต [4]

[ข้อมูลใหม่จาก Binance] ประกาศฉบับที่สองระบุว่าการสอบสวนภายหลังพบ จุดบุกรุกเพิ่มเติม ดังนั้นจึงไม่ถูกต้องที่จะสรุปว่าแล็ปท็อปเพียงเครื่องเดียวคือ root cause ที่ยืนยันแล้ว นอกจากนี้ Binance ยังระบุว่า ไม่พบหลักฐานว่า wallet private keys รั่วไหล ณ ขณะรายงาน ซึ่งไม่เท่ากับการพิสูจน์ว่าระบบ signing ไม่มีจุดอ่อน [1]

flowchart LR
  A["จุดเข้าถึงระบบที่ยังอยู่ระหว่างสอบสวน"] --> B["ระบบภายใน / การอนุมัติธุรกรรม"]
  B --> C["ธุรกรรมถอนสินทรัพย์ที่ไม่ได้รับอนุญาต"]
  C --> D["หลายบล็อกเชน (10 Chains)"]
  E["แล็ปท็อป DevOps: สมมติฐานเบื้องต้น"] -.-> A
  F["จุดบุกรุกเพิ่มเติม: Binance ระบุว่าพบ"] -.-> A

  style A fill:#1e1b19,stroke:#f59e0b,stroke-width:2px,color:#fff
  style B fill:#1e1b19,stroke:#60a5fa,stroke-width:2px,color:#fff
  style C fill:#2a1b1b,stroke:#e53e3e,stroke-width:2px,color:#fff
  style D fill:#1e1b19,stroke:#38a169,stroke-width:2px,color:#fff
  style E fill:#2d241e,stroke:#9ca3af,stroke-width:1.5px,color:#fff
  style F fill:#2d241e,stroke:#9ca3af,stroke-width:1.5px,color:#fff

💡 หมายเหตุทางสถาปัตยกรรม:
แผนภาพนี้เป็น ภาพรวมเชิงแนวคิด ไม่ใช่ attack graph ที่ผ่านการพิสูจน์ทางนิติวิทยาศาสตร์ การเจาะระบบ signing หรือ authorization pipeline ไม่ได้หมายความว่าบล็อกเชนทั้งสิบมีช่องโหว่ในโปรโตคอลพร้อมกัน

---

3.1 การ Compromise DevOps Laptop ไม่เท่ากับการควบคุม Withdrawal Infrastructure

ในมุมมองของ Infrastructure Security การที่ระบบอย่าง Binance ซึ่งเป็น Exchange ระดับโลก อาจมี Microservices, Internal APIs, ระบบจัดการสิทธิ์ IAM, Secrets Management และระบบ Transaction Signing หลายชั้น (องค์ประกอบเหล่านี้เป็นตัวอย่างเชิงสถาปัตยกรรม ไม่ใช่การยืนยันว่า Binance ใช้เทคโนโลยีทุกตัวดังกล่าว)… แล้วจู่ๆ ผู้โจมตีที่เพิ่งเข้าถึงแล็ปท็อปของวิศวกรคนหนึ่ง จะรู้ได้อย่างไรว่าต้องเรียก Service ไหน ใช้ Endpoint ใด และผ่านการ Authorization ระดับลึกอย่างไร จนสั่งถอนเงินข้าม 10 บล็อกเชนได้พร้อมกัน?

ลองพิจารณา แบบจำลองสถาปัตยกรรมระบบถอนเงินภายใน (Conceptual Architecture):

flowchart TD
  subgraph CONTROL_PLANE["BINANCE INTERNAL CONTROL PLANE (แบบจำลองเชิงแนวคิด)"]
    GW["API Gateway"]
    WS["Withdrawal Service"]
    RM["Risk Management"]
    AE["Approval Engine"]
    SC["Signing Coordinator (MPC / HSM)"]

    GW --> WS
    WS --> RM
    RM --> AE
    AE --> SC
  end

  subgraph SIGNERS["MULTI-CHAIN SIGNERS"]
    BTC_S["BTC Signer"]
    ETH_S["ETH Signer"]
    SOL_S["SOL Signer"]
    OTH_S["Other Signers (10 Chains)"]

    SC --> BTC_S & ETH_S & SOL_S & OTH_S
  end

  BTC_S --> N_BTC["Bitcoin Network"]
  ETH_S --> N_ETH["Ethereum Network"]
  SOL_S --> N_SOL["Solana Network"]
  OTH_S --> N_OTH["Other Blockchains"]

  style CONTROL_PLANE fill:#141211,stroke:#60a5fa,stroke-width:1.5px,color:#fff
  style SIGNERS fill:#141211,stroke:#f59e0b,stroke-width:1.5px,color:#fff

ต่อให้ผู้โจมตีเข้าถึง DevOps Laptop ได้จริง ก็ยังคงมีคำถามเชิงสถาปัตยกรรมอีกมากที่ยังไม่มีคำตอบ:

• DevOps คนดังกล่าวมีสิทธิ์เข้าถึง Production โดยตรงหรือไม่?
• มีสิทธิ์ใน Kubernetes RBAC ระดับไหน? (เป็นเพียง Read-Only หรือ Cluster-Admin?)
• สามารถเข้าถึง Secrets และ Environment Variables ของระบบ Signing ได้หรือไม่?
• มีสิทธิ์ Deploy หรือแก้ไขโค้ดของ Withdrawal Service โดยไม่ผ่านกระบวนการ Peer Review / CI/CD หรือไม่?
• Signing Coordinator ตรวจสอบตัวตนและ Policy ของผู้ส่งคำขออย่างไร? มีระบบ Multi-Party Approval หรือไม่?

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

---

3.2 ผู้โจมตีอาจเรียนรู้ Internal Endpoints ได้โดยไม่ต้องมี Malicious Insider

มีข้อควรระวังสำคัญในการวิเคราะห์: การที่แฮกเกอร์รู้จักสถาปัตยกรรมภายในอย่างทะลุปรุโปร่ง ไม่ได้พิสูจน์ว่าต้องมีพนักงานจงใจสมรู้ร่วมคิด (Malicious Insider) เสมอไป

เมื่อเครื่องวิศวกร DevOps ถูก Compromise ข้อมูลที่แฮกเกอร์สามารถกวาดต้อนได้นั้นมีมหาศาลยิ่งกว่าแค่ Credentials:

แหล่งข้อมูลที่เข้าถึงได้	ข้อมูลสถาปัตยกรรมที่อาจรั่วไหลสู่ผู้โจมตี
Internal Git Repositories	Source Code, API Routes, Service Dependencies, Data Schemas
Kubernetes Manifests	Service Names, Namespaces, Ingress/Egress Rules, Deployment Configurations
Helm Charts	Internal Service Discovery, Inter-Service Communication Endpoints
CI/CD Pipelines	Deployment Workflows, Automation Tokens, Service Accounts
Internal Documentation	Confluence, Architecture Diagrams, API Specifications, Post-Mortems เก่า
Observability Platforms	Distributed Traces (Jaeger, Zipkin, OpenTelemetry) ที่อาจแสดงเส้นทางการเรียก Service-to-Service บางส่วนตามระดับสิทธิ์และการเก็บข้อมูล
Shell History	บันทึกคำสั่งจริงที่วิศวกรเคยพิมพ์จัดการคลัสเตอร์ใน Production
Infrastructure as Code (IaC)	Terraform, Ansible, Network Topologies, VPC Peering และ IAM Policies

ตัวอย่างเช่น หากผู้โจมตีสามารถเปิดดูระบบ Distributed Tracing ได้เพียงระบบเดียว แฮกเกอร์อาจมองเห็น Call Graph บางส่วน (ขึ้นกับ sampling, instrumentation และสิทธิ์เข้าถึง) ว่าเมื่อมีคำขอถอนเงิน ระบบจะยิงต่อไปที่ Risk Engine ตัวไหน ผ่าน Approval Engine อย่างไร และส่งต่อไปยัง Signing Service ใด… โดยไม่จำเป็นต้องมีพนักงานจงใจให้ข้อมูล ทั้งนี้ยังไม่มีหลักฐานสาธารณะว่าผู้โจมตีเข้าถึงระบบ tracing ของ Binance จริง

---

3.3 ปริศนา Dwell Time และความพร้อมในการโจมตี (Attack Preparation)

ความแม่นยำในการโจมตี 10 เครือข่ายพร้อมกันภายในหน้าต่างเวลาเพียง 20 นาที ทำให้คำถามที่สำคัญที่สุดในเชิงนิติวิทยาศาสตร์ไม่ใช่แค่ “เข้าถึงได้อย่างไร” แต่คือ:

❓ “How long did the attacker maintain access to Binance’s internal infrastructure before the first unauthorized withdrawal?”
(ผู้โจมตีแฝงตัวอยู่ในระบบภายในของ Binance นานเท่าใดก่อนจะเริ่มการถอนเงินครั้งแรก?)

flowchart TD
  DWELL{"Dwell Time (เวลาแฝงตัวในระบบ)"}

  DWELL -->|"พบการเข้าถึงนาน"| H4["ตรวจสอบการสอดแนมและการใช้สิทธิ์ต่อเนื่อง<br/>อาจมีเวลาศึกษาระบบ แต่ไม่ระบุผู้ร่วมกระทำ"]
  DWELL -->|"พบการเข้าถึงสั้น"| H1_H3["ตรวจสอบการเตรียมการก่อนหน้า<br/>เช่น เอกสารที่รั่ว การเข้าถึงช่องทางอื่น หรือข้อมูลจากบุคคลภายใน"]
  NOTE["First observed access ≠ initial compromise ≠ total reconnaissance time"]
  DWELL -.-> NOTE

  style DWELL fill:#2a2421,stroke:#d97706,stroke-width:2px,color:#fff
  style H4 fill:#1e1b19,stroke:#60a5fa,stroke-width:2px,color:#fff
  style H1_H3 fill:#2a1b1b,stroke:#e53e3e,stroke-width:2px,color:#fff

• หาก Dwell Time ยาวนาน (สัปดาห์หรือเดือน): ผู้โจมตีระดับ State-Sponsored (เช่น TraderTraitor) มีศักยภาพสูงมากในการซุ่มสังเกตการณ์ แกะรอยสถาปัตยกรรม และเตรียมสคริปต์อัตโนมัติให้พร้อมโจมตีพร้อมกัน 10 เชนได้ด้วยตนเอง
• หาก Dwell Time สั้นมาก (หลักชั่วโมงหรือวัน): แต่กลับสามารถเลือกยิง Service และ Bypass นโยบายถอนเงินได้แม่นยำแบบสายฟ้าแลบ ควรตรวจสอบว่ามีการเตรียมการก่อนหน้า การเข้าถึงจากช่องทางอื่น เอกสารรั่ว หรือข้อมูลจากบุคคลภายในหรือไม่ โดย ระยะเวลาที่สังเกตเห็นในระบบไม่ใช่หลักฐานการสมรู้ร่วมคิด

---

3.4 กรอบสมมติฐาน 4 รูปแบบ (The 4-Hypotheses Matrix)

เพื่อความเป็นกลางทางนิติวิทยาศาสตร์ สมมติฐานด้านความเกี่ยวข้องของบุคคลภายใน (Insider Scenarios) ควรถูกแบ่งออกเป็น 4 รูปแบบที่ต้องตรวจสอบด้วยพยานหลักฐานที่ต่างกัน:

สมมติฐาน	คำอธิบายกลไก	สิ่งที่ต้องตรวจสอบทางนิติวิทยาศาสตร์
H1: Malicious Insider	พนักงานหรือผู้มีสิทธิ์ภายในจงใจสมรู้ร่วมคิดกับผู้โจมตี	หลักฐานการสื่อสาร, การสร้าง Backdoors, ธุรกรรมทางการเงินผิดปกติ
H2: Unwitting Insider	พนักงานตกเป็นเหยื่อของการโจมตี (Phishing, มัลแวร์, Session Hijacking) โดยไม่รู้ตัว	Endpoint Forensics, พฤติกรรมการล็อกอิน, ประวัติการติดมัลแวร์
H3: Former Insider	ผู้โจมตีได้รับพิมพ์เขียวหรือใช้ Credentials/Tokens ที่ยังไม่ถูกเพิกถอนของอดีตพนักงาน	บันทึก IAM Offboarding, ประวัติการเข้าถึงหลังพ้นสภาพพนักงาน
H4: External Reconnaissance	ผู้โจมตีเรียนรู้ระบบทั้งหมดด้วยตนเองผ่านการเข้าถึงระบบสังเกตการณ์และเอกสารภายใน	Access Logs ย้อนหลัง, Distributed Tracing Queries, Git Access Timelines

---

3.5 Key Compromise vs. Authorization Compromise

สมมติว่า Binance ปกป้อง Master Private Keys ด้วยฮาร์ดแวร์ระดับสูงสุด เช่น MPC (Multi-Party Computation) หรือ HSM (Hardware Security Module)

MPC และ HSM มี trust model และกลไกจัดการกุญแจต่างกัน แต่ต่างถูกใช้เพื่อช่วยลดความเสี่ยงด้านการเปิดเผยกุญแจ แต่มันไม่สามารถป้องกันธุรกรรมที่ผิดปกติได้ หากคำสั่งที่ส่งเข้ามาผ่านการอนุมัติตามขั้นตอนของ Authorization Layer มาแล้ว!

นี่คือความแตกต่างอย่างสิ้นเชิงระหว่างสองนิยาม:

• Key Compromise (กุญแจรั่วไหล): ผู้โจมตีได้มาซึ่ง key material หรือความสามารถในการใช้กุญแจนอกขอบเขตที่ได้รับอนุญาต ซึ่งไม่จำเป็นต้องอยู่ในรูปไฟล์คีย์ดิบ
• Authorization Compromise (ระบบอนุมัติถูกครอบงำ): ผู้โจมตีไม่ได้กุญแจ แต่สามารถแทรกซึมหรือหลอกให้ระบบ Coordinator ที่ถือสิทธิ์ควบคุม HSM/MPC ทำการประทับตราอนุมัติคำสั่งถอนเงินที่ไม่พึงประสงค์ โดยไม่จำเป็นต้องมีหลักฐานว่า private key ถูกนำออกจากระบบ

สำหรับเหตุการณ์ที่มีธุรกรรมหลายบล็อกเชน TRM Labs ประเมินว่าข้อมูล on-chain ชี้ไปที่การถูกเจาะระบบ hot-wallet signing infrastructure [2] อย่างไรก็ตาม ยังไม่อาจแยกได้จากหลักฐานสาธารณะว่าผู้โจมตีได้คีย์ไป ใช้สิทธิ์สั่งระบบลงนามโดยมิชอบ หรืออาศัยช่องทางอื่น การที่ Binance ระบุว่า “ยังไม่พบหลักฐานว่า Wallet Private Keys รั่วไหล” [1] ไม่ได้พิสูจน์สมมติฐานใดเป็นการเฉพาะ

---

4. EIP-7702 และเทคนิค 50 Pre-signed Authorizations

[ข้อเท็จจริงระดับโปรโตคอล] EIP-7702 เป็นกลไกบน Ethereum ที่อนุญาตให้บัญชี EOA กำหนด delegation ไปยังโค้ดของ smart contract ผ่าน authorization ที่ลงนามอย่างถูกต้อง โดยธุรกรรมชนิด 0x04 สามารถแนบ authorization_list ซึ่งมีหลาย authorization tuples ได้ การตั้งค่า delegation ที่สำเร็จยังคงมีผลหลังธุรกรรมสิ้นสุดจนกว่าจะมีการเปลี่ยนหรือล้าง delegation ตามกลไกที่รองรับ [6]

[รายงานโดยนักวิเคราะห์] TRM Labs และ Elliptic ระบุว่าผู้โจมตีใช้ 50 pre-signed authorizations ที่ครอบคลุม nonce ต่างกันเพื่อเพิ่มโอกาสให้มี authorization ที่ใช้ได้เมื่อประมวลผลบนเชน และใช้ delegation เพื่อทำให้ Ethereum hot wallet ทำงานตามโค้ด sweeper [2][3]

flowchart TD
  A["Authorization list: 50 รายการ"] --> B["แต่ละรายการมี nonce และลายเซ็น"]
  B --> C["ตรวจสอบเงื่อนไขตาม EIP-7702"]
  C --> D{"มี authorization ที่ถูกต้องหรือไม่?"}
  D -->|"มี"| E["อาจตั้งค่า delegation สำเร็จ"]
  D -->|"ไม่มี"| F["ไม่เกิด delegation ตามที่ผู้โจมตีต้องการ"]

  style A fill:#1e1b19,stroke:#60a5fa,stroke-width:2px,color:#fff
  style B fill:#1e1b19,stroke:#60a5fa,stroke-width:1.5px,color:#fff
  style C fill:#1e1b19,stroke:#f59e0b,stroke-width:2px,color:#fff
  style D fill:#2a2421,stroke:#d97706,stroke-width:2px,color:#fff
  style E fill:#1e1b19,stroke:#38a169,stroke-width:2px,color:#fff
  style F fill:#2a1b1b,stroke:#e53e3e,stroke-width:2px,color:#fff

การอธิบายที่แม่นยำทางเทคนิคต้องแยก 5 ประเด็นต่อไปนี้:

1. Nonce ของ authorization ไม่ใช่การข้ามลายเซ็น: ทุก authorization ที่ถูกยอมรับยังต้องผ่านการตรวจสอบลายเซ็นและเงื่อนไขของโปรโตคอล [6]
2. หลาย nonce ช่วยรับมือความไม่แน่นอน: การเตรียม authorization สำหรับหลาย nonce เพิ่มโอกาสที่หนึ่งรายการจะตรงกับสถานะบัญชี ณ เวลาประมวลผล แต่ ไม่รับประกันความสำเร็จ 100% ในทุกสถานการณ์
3. การนับจำนวนให้ตรงกัน: ถ้าต้องการ 50 ค่าเริ่มที่ nonce 10,000 แบบต่อเนื่อง ค่าสุดท้ายคือ 10,049 ไม่ใช่ 10,050
4. การตรวจสอบ tuple: authorization ที่ไม่ผ่านเงื่อนไขอาจถูกข้ามระหว่างการประมวลผลรายการ ไม่ใช่ทุกกรณีที่จะทำให้ธุรกรรมทั้งหมด revert [6]
5. ขอบเขตของช่องทางโจมตี: EIP-7702 เป็นกลไกของ Ethereum ไม่ใช่คำอธิบายว่าทำไม BTC, SOL หรือ XRP จึงถูกเคลื่อนย้ายได้ ผู้โจมตีต้องมีเส้นทาง authorization/signing อื่นสำหรับแต่ละระบบ [2]

🛑 ข้อจำกัดสำคัญ:
การมี 50 ลายเซ็นที่รายงานโดยผู้วิเคราะห์ไม่ได้อธิบายด้วยตัวเองว่าผู้โจมตีได้รับลายเซ็นที่ถูกต้องเหล่านั้นมาอย่างไร ต้องรอผลสืบสวนระบบอนุมัติและลงนามของ Binance เพิ่มเติม

---

5. อายัดสินทรัพย์ 3B USD ได้จริงแค่ไหน?

[ยืนยันโดย Binance] Binance ระบุว่ามีสินทรัพย์ที่เกี่ยวข้องถูกอายัดบนเชนประมาณ 3 พันล้านดอลลาร์ (3B USD) และกำลังประสานงานเพื่อติดตามและกู้คืนเพิ่มเติม [1]

[รายงานโดยนักวิเคราะห์] Elliptic ตรวจสอบพบประมาณ 2.84 พันล้านดอลลาร์ (2.84B USD) ณ เวลาสำรวจที่ระบุในรายงานของตน โดยสินทรัพย์ที่อายัดส่วนใหญ่เป็น stablecoins และมีความแตกต่างจากยอดที่ Binance รายงานเนื่องจากวิธีประเมินและเวลาเก็บข้อมูล [3]

การจำแนกตามประเภทสินทรัพย์:

• สินทรัพย์ที่มีผู้ออกส่วนกลาง (Centralized Stablecoins): ผู้ออกเหรียญบางรายสามารถจำกัดการเคลื่อนย้ายโทเค็นของตนผ่าน smart contract ได้ เช่น USDT และ USDC
• สินทรัพย์พื้นฐานของเครือข่าย (Native Assets): native BTC, native ETH, native SOL และ XRP ไม่ได้มีปุ่ม freeze ส่วนกลางแบบเดียวกับ stablecoin ที่มีผู้ออก โดย Elliptic ระบุชัดว่า Ripple สามารถอายัดเหรียญใหม่อย่าง RLUSD ได้ แต่ไม่ใช่ตัวเหรียญ XRP [3]
• การจำกัดใน DeFi: การหยุดตลาด DeFi หรือระงับการทำธุรกรรมบางชนิดไม่ใช่การยึดสินทรัพย์ทั้งหมดกลับคืน จึงไม่ควรกล่าวว่า “Ripple หรือ Arbitrum กดปุ่ม freeze เหรียญพื้นฐานทั้งเชน” โดยไม่มีรายละเอียดสินทรัพย์และกลไกที่ตรวจสอบได้

---

6. เงินของลูกค้าและสถานะบริการ

[คำประกาศจาก Binance] บริษัทระบุว่าจะรับภาระความเสียหายจากเหตุการณ์นี้โดยใช้ SAFU และ corporate treasury และประกาศว่าได้กันเงินมากกว่า 6.34 พันล้านดอลลาร์ (6.34B USD) ไว้รองรับ โดยประมาณ 5 พันล้านดอลลาร์ (5B USD) อยู่ในสินทรัพย์ชนิดเดียวกับที่ได้รับผลกระทบ ณ เวลาประกาศ บริษัทกำลังจัดหาสินทรัพย์ส่วนที่เหลือ [1]

⚠️ ข้อจำกัดของคำกล่าว:
การกันเงินและการให้คำมั่นว่าจะชดเชย ไม่เท่ากับ การพิสูจน์ว่าทุกบัญชีได้รับชดเชยครบแล้ว หรือว่า Proof of Reserves ฉบับใหม่เผยแพร่และผ่านการตรวจสอบแล้ว Binance ระบุว่าจะจัดทำ snapshot และคาดว่าจะเผยแพร่ผลในวันที่ 2 พฤศจิกายน 2026 [1]

---

7. บทเรียนสำหรับทีม Engineering และ Web3

1. Endpoint และ Identity Security: ป้องกันเครื่องนักพัฒนาและบัญชีที่เข้าถึง production ด้วย phishing-resistant MFA, device posture, short-lived credentials และ least privilege แต่ยังไม่ควรสรุปว่า endpoint เป็น root cause ขั้นสุดท้ายของเหตุการณ์นี้
2. Signing Infrastructure: แยกการสร้างคำขอถอนเงินออกจากการอนุมัติและการลงนาม บังคับ policy checks, destination allowlists, withdrawal velocity limits, dual control และ out-of-band anomaly detection
3. EIP-7702 Risk Controls: ตรวจสอบ authorization, nonce, delegated code และการเปลี่ยน delegation; จำกัดสิทธิ์ของระบบที่สามารถร้องขอลายเซ็น EIP-7702
4. Cross-Chain Incident Response: ต้องมีแผนรับมือหลายเชนพร้อมกัน โดยแยกสิ่งที่อายัดได้ผ่านผู้ออกโทเค็นออกจาก native assets ที่ไม่สามารถอายัดด้วยวิธีเดียวกัน
5. Forensic Discipline: ติดป้ายกำกับหลักฐาน, timestamp, chain, token, transaction hash, แหล่งอ้างอิง และระดับความมั่นใจทุกครั้ง โดยไม่สรุปจากรูปแบบธุรกรรมอย่างเดียวว่ารู้ตัวผู้โจมตีหรือเส้นทางเข้าระบบครบแล้ว

---

สรุป (Conclusion)

เหตุการณ์ Binance วันที่ 29 ตุลาคม 2026 มีมูลค่าประมาณ 6.3 พันล้านดอลลาร์ (6.3B USD) ตามคำประกาศบริษัท และอาจเป็นการโจรกรรมคริปโตที่มีมูลค่าสูงที่สุดเท่าที่มีรายงาน ข้อมูลจาก TRM Labs และ Elliptic ช่วยอธิบายขอบเขตหลายบล็อกเชนและการใช้ EIP-7702 บน Ethereum แต่ root cause, ลำดับการบุกรุกทั้งหมด และตัวผู้โจมตีในระดับการยืนยันอย่างเป็นทางการยังอยู่ระหว่างสอบสวน [1][2][3]

💡 Editorial Note: ข้อมูลและจำนวนเงินเป็น snapshot ตามรายงานที่อ้างถึง ณ 31 ตุลาคม 2026 ไม่ใช่การรับรองผลการสอบสวนสุดท้าย

---

เอกสารอ้างอิงที่ตรวจสอบได้ (Verified Primary References)

1. Binance — Security Incident Update #2 (30 Oct 2026) — ประกาศทางการของ Binance ฉบับที่สองเรื่องการกันเงิน 6.34 พันล้านดอลลาร์ (6.34B USD), แผน Proof of Reserves 2 พ.ย., และการพบจุดบุกรุกเพิ่มเติม
2. TRM Labs — North Korea Steals USD 6.36 Billion From Binance (29 Oct 2026) — รายงานการประเมินความเสียหาย 6.36 พันล้านดอลลาร์ (6.36B USD) ข้าม 10 เชน และการระบุ TraderTraitor
3. Elliptic — The largest theft in history: North Korea likely behind the 6.4 billion USD Binance hack (30 Oct 2026) — รายงานการประเมิน 6.43 พันล้านดอลลาร์ (6.43B USD), การตรวจพบสินทรัพย์อายัด 2.84 พันล้านดอลลาร์ (2.84B USD), การอายัด RLUSD ไม่ใช่ XRP, และความเชื่อมโยงกับ Bitget
4. Binance — Security Incident Update (30 Oct 2026) — แถลงการณ์ฉบับแรกเรื่องการประเมินความเสียหายเบื้องต้นและสมมติฐานแล็ปท็อป DevOps
5. Reuters — Gone in 20 minutes: How the biggest heist in crypto history unfolded (30 Oct 2026) — รายงานสรุปเส้นเวลา 20 นาที และการเคลื่อนไหวของอุตสาหกรรม
6. Ethereum Improvement Proposals — EIP-7702: Set Code for EOAs — เอกสารข้อกำหนดมาตรฐานทางเทคนิคของ EIP-7702 และโครงสร้าง authorization_list

หมายเหตุการตรวจทาน: การวิเคราะห์ส่วน Insider Threat, Dwell Time และระบบ MPC/HSM เป็นสมมติฐานทางวิศวกรรม ไม่ใช่ข้อค้นพบเชิงนิติวิทยาศาสตร์ของ Binance