کالبدشکافی سرقت ۶.۳۶ میلیارد دلاری بایننس؛ چگونه ضعف مسیر امضا بدون لو رفتن کلید خصوصی فاجعه آفرید؟

سرقت ۶.۳۶ میلیارد دلاری از بایننس در تاریخ ۲۹ اکتبر نیازی به سرقت کلید خصوصی نداشت. تنها یک مسیر نفوذ به سیستم امضای بایننس کافی بود؛ چرا که این سیستم بررسی نمی‌کرد آیا درخواستی که دریافت کرده اصلاً مجاز به امضا شدن هست یا خیر. هر شرکتی که تراکنش‌ها را از یک کیف پول آنلاین بدون تطبیق با یک سیاست مشخص امضا کند، دقیقاً با همین ریسک مواجه است. بستن این حفره بیش از آنکه به فناوری جدیدی وابسته باشد، به کنترل‌هایی از جمله سیاست‌گذاری تراکنش‌ها، سقف‌های محدودیت (Limits)، پایش کیف پول‌های خود شرکت و یک روش تمرین‌شده برای متوقف کردن تمام مسیرهای امضا متکی است که بانک‌ها همین حالا هم ملزم به رعایت آن‌ها هستند.

چه اتفاقی افتاد؟

در ۲۹ اکتبر ۲۰۲۶، حدود ۶.۳۶ میلیارد دلار از کیف پول‌های گرم بایننس در ده بلاکچین خارج شد که بیشتر آن در بازه ۲۰ دقیقه‌ای پس از ساعت ۲۰:۰۵ به وقت جهانی (UTC) رخ داد (به گزارش TRM Labs). بایننس اعلام کرده که هیچ مدرکی مبنی بر لو رفتن کلید خصوصی پیدا نکرده است. مهاجم نیازی هم به کلید نداشت؛ سیستم امضای خود بایننس هر آنچه را که برایش ارسال شده بود، امضا کرد.

در اکثر شبکه‌ها، این فرآیند شامل انتقال‌های عادی به آدرس مهاجم بود، اما ماجرای اتریوم تفاوت داشت. مهاجم ۵۰ مجوز EIP-7702 را برای کیف پول گرم شماره ۱۴ بایننس (Binance 14) ارسال کرد؛ به ازای هر نانس (Nonce) یک مجوز. یکی از آن‌ها تطبیق پیدا کرد و در ساعت ۲۰:۲۰:۵۹ اعمال شد و قرارداد هوشمند مهاجم را به عنوان کد روی این کیف پول نصب کرد.

۳ دقیقه و ۲۴ ثانیه بعد، تنها یک فراخوانی از تابع تخلیه (Sweep) آن قرارداد، کل کیف پول را خالی کرد. این عملیات ۱۶۷,۴۶۴ واحد ETH، حدود ۱.۶۱۵ میلیارد واحد USDT و نزدیک به ۶۰ توکن دیگر به ارزش تقریبی ۲.۵ میلیارد دلار را جابه‌جا کرد (به گزارش Blockaid). این قرارداد به تخلیه واریزی‌های جدید ادامه داد تا اینکه در ساعت ۰۰:۱۰ روز ۳۰ اکتبر، مجوز تفویض اختیار (Delegation) لغو شد.

کیف پول Binance 14 همچنین اپراتور کیف پول دومی به نام Hot Wallet 34 بود. مهاجم از طریق این دسترسی‌ها ۸۲۳ میلیون واحد یواس‌دی کوین (USDC) را از آن برداشت کرد که شرکت سرکل (Circle) در ساعت ۲۱:۰۴ آن‌ها را مسدود و فریز کرد.

این گزارش به داده‌هایی می‌پردازد که پلتفرم متریکا در آن شب ثبت کرده و استدلال می‌کند که بهترین زاویه دید برای تحلیل این رخداد، «شکست ریسک عملیاتی در مسیر امضا» است و یک بانک بلافاصله آن را تشخیص می‌دهد.

صادرکنندگان استیبل کوین پیش از خود بایننس بخشی از خسارت را مهار کردند. تتر در ساعت ۲۱:۰۱:۳۵ آدرس مهاجم را با ۹۷۱ میلیون USDT روی شبکه اتریوم در لیست سیاه قرار داد و سرکل در ساعت ۲۱:۰۴:۵۹ با مسدود کردن ۸۲۳ میلیون USDC روی اتریوم همین کار را تکرار کرد. تتر تا ساعت ۲۱:۲۱ مبلغ ۳۷۸.۷ میلیون USDT را روی شبکه ترون منجمد کرد و ریپل و پروژه World Liberty Financial نیز استیبل کوین‌های خود را ظرف یک ساعت بعدی مسدود کردند.

از آن زمان، اف‌بی‌آی (FBI) این سرقت را به گروه TraderTraitor وابسته به کره شمالی نسبت داده است؛ همان‌طور که TRM Labs و Chainalysis در شب حادثه اعلام کرده بودند. بایننس اعلام کرده که بیش از ۶.۳۴ میلیارد دلار از سرمایه شرکت را (از طریق صندوق SAFU، خزانه شرکت و بخشی از صندوق بیمه معاملات آتی خود) کنار گذاشته و تا اول نوامبر ۹۵ درصد از دارایی‌های سرقت‌شده را جایگزین کرده است. ۵ درصد باقی‌مانده مربوط به توکن‌هایی خارج از فهرست ده ارز برتر این صرافی است که بازخرید آن‌ها زمان بیشتری می‌برد. برداشت‌ها از اول نوامبر به صورت مرحله‌ای بازگشایی شد که ابتدا با بیت کوین و سپس ۱۵ شبکه آغاز گشت، اما هنوز تاریخی برای سایر شبکه‌ها اعلام نشده است. در ۲ نوامبر، بایننس یک اثبات ذخیره با دانش صفر (ZK Proof of Reserves) را برای اسنپ‌شات ۳۱ اکتبر خود تکمیل کرد که به کاربران اجازه می‌دهد بررسی کنند دارایی‌هایشان در ده توکن برتر با نسبت حداقل ۱ به ۱ پشتیبانی می‌شود. اسنپ‌شات بعدی که توکن‌های بیشتری را پوشش می‌دهد برای ۴ نوامبر برنامه‌ریزی شده است.

بایننس هنوز علت ریشه‌ای را منتشر نکرده و اکنون به بیش از یک نقطه نفوذ اشاره دارد. مهاجم همچنان حدود ۴۲۰,۰۰۰ واحد ETH و ۱۸,۲۷۰ واحد BTC در اختیار دارد.

پایشگرهای متریکا چه چیزی را نشان می‌دهند؟

شاخص‌های کلیدی ریسک (KRI) شبکه و دارایی در متریکا، این سرقت را در همان ساعت اول به صورت حجم انتقال غیرعادی، ازدحام شبکه و مسدودسازی توسط صادرکنندگان روی اتریوم ثبت کردند. در مقایسه با سه روز و نیم پیش از حادثه، آمار آن شب در تک‌تک این شاخص‌ها کاملاً متمایز است. در میان ۱۳ شاخص KRI که اتریوم، استیبل کوین‌ها و بایننس کوین (BNB) را پوشش می‌دهند، ۱۲ شاخص تا ساعت ۲۲:۰۰ از محدوده عادی خود (که بین صدک اول تا نود و نهم هفته قبل تعریف می‌شود) خارج شده بودند.

نگاه دقیق‌تر به چهار مورد از این شاخص‌ها نشان می‌دهد که «شکل سیگنال» به اندازه «بزرگی آن» اهمیت دارد.

در طول تاریخچه سه و نیم روزه، ساعات پس از تخلیه کیف پول، بالاترین عدد را در هر چهار شاخص ثبت کرده‌اند. پنل مربوط به هولدرهای برتر، کمترین مقدار را در سه ساعت متوالی ملاک قرار می‌دهد؛ این روش جهش‌های تک‌ساعته (مانند عدد ۸۹ میلیون دلاری در عصر ۲۸ اکتبر) را حذف کرده و تنها حرکت‌های مستمر را باقی می‌گذارد.

متریکا از پایش تمام این شاخص‌های KRI پشتیبانی می‌کند. جدول مربوطه، هر پایشگر را کمی بالاتر از بیشترین مقدار ثبت‌شده در روزهای پیش از سرقت تنظیم کرده و نشان می‌دهد که در شب حادثه، هر کدام در چه زمانی فعال شده‌اند. مقادیر ساعتی، ساعت منتهی به زمان نمایش‌داده‌شده را پوشش می‌دهند و در پایان آن ساعت ارزیابی می‌شوند.

در این ساختار، اولین هشدار در ساعت ۲۰:۴۰، یعنی ۱۶ دقیقه پس از تخلیه و ۳۵ دقیقه پیش از اولین تایید عمومی سرقت (در ساعت ۲۱:۱۵) صادر شد. این هشدار ناشی از ازدحام شبکه بود. بلاک‌های اتریوم پر شدند و به دنبال آن کارمزدها جهش کردند و در ساعت منتهی به ۲۲:۰۰ به بالای ۱۰۰ جی‌وی (gwei) رسیدند؛ در حالی که بالاترین کارمزد در سه روز و نیم قبل از آن تنها ۰.۳۸ gwei بود. اینکه یک شرکت با چه فاصله زمانی داده‌ها را بررسی کند، به اندازه موضوعی که بررسی می‌کند اهمیت دارد. با بررسی‌های ۵ دقیقه‌ای، اشغال فضای بلاک ۲۰ دقیقه زودتر از معیار ساعتی از مرز هشدار عبور کرد. اولین هشدار مختص استیبل کوین‌ها در ساعت ۲۱:۰۰ و به دنبال جابه‌جایی ۳.۶۶ میلیارد دلار تتر در یک ساعت فعال شد؛ یعنی همچنان ۱۵ دقیقه پیش از انتشار اخبار.

شاخص‌های ریسک شبکه و دارایی، ردپای یک سرقت را نشان می‌دهند، نه منشأ آن را. شاخص‌های سطح کیف پول و پایش اخبار منفی این شکاف را پر می‌کنند. متریکا تنها یک خبر درباره این سرقت را به بایننس و هفت شبکه و دارایی درگیر از جمله اتریوم، USDC، بیت کوین و سولانا متصل کرد. همین نگاشت و ارتباط‌دهی است که پایش اخبار منفی را کاربردی می‌کند؛ شرکت نه تنها متوجه می‌شود که یک صرافی هدف قرار گرفته، بلکه می‌فهمد کدام‌یک از دارایی‌های خودش در معرض ریسک است.

مسدودسازی‌ها نیز باید علاوه بر تعداد، بر اساس ارزش هم سنجیده شوند؛ چرا که هشت آدرس تتر که در یک ساعت وارد لیست سیاه شدند، در مجموع بیش از یک میلیارد دلار دارایی در خود جای داده بودند.

اولین سیگنال آن‌چین از خودِ فرآیند تصاحب کیف پول، ۳ دقیقه و ۲۴ ثانیه پیش از تخلیه ظاهر شد و یک کد روی کیف پولی قرار گرفت که هرگز نباید کدی روی آن باشد. بخش شاخص‌ها در ادامه به این موضوع می‌پردازد.

ریسک عملیاتی اصلی: امضاکننده‌ای که هر چه دریافت کند امضا می‌کند

شکست اصلی در «مسیر امضا» رخ داد، نه در «نگهداری کلید». تنها یک مسیر نفوذ به زیرساخت امضای بایننس برای صدور مجوز پرداخت روی ده شبکه کافی بود؛ چرا که هیچ مکانیزمی بین درخواست و امضا وجود نداشت تا بپرسد آیا این تراکنشی است که یک کیف پول گرم اصلاً باید امضا کند یا خیر و آیا حجم و مقصد آن با یک برداشت واقعی همخوانی دارد یا نه. در ریشه، این حادثه ناشی از عدم اعمال کنترل‌های پایه در این مسیر بود.

اینکه مهاجم چگونه وارد شده، اهمیت کمتری نسبت به جایی دارد که به آن دسترسی پیدا کرده است. یافته‌های اولیه بایننس نشان می‌دهد که لپ‌تاپ یک مهندس DevOps دسترسی به یک کانتینر سرویس را فراهم کرده که قادر به ثبت درخواست برداشت بوده است؛ هرچند بایننس بعداً اعلام کرد نقاط نفوذ دیگری نیز وجود داشته است. در نهایت همیشه یک نقطه پایانی (Endpoint) دچار شکست می‌شود؛ سوال طراحی این است که یک مسیر نفوذ تا چه حد می‌تواند پیش برود؟ و در این مورد، پاسخ «تمام دارایی موجود در کیف پول‌های گرم» بود.

نقطه‌ضعف اول، امضاکننده‌ای بدون سیاست در سطح تراکنش و فاقد سقف‌های موثر بر حجم، سرعت یا تعداد است. این دو، کنترل‌های متفاوتی هستند و هر دو به شرکت تعلق دارند؛ چه خودش آن‌ها را بسازد و چه در یک پلتفرم حضانتی (Custody) پیکربندی کند. سیاست تراکنش تصمیم می‌گیرد که امضاکننده اصلاً چه نوع درخواستی را امضا کند. یک کیف پول گرم که برداشت‌های کاربران را می‌پردازد، هیچ دلیل تجاری و منطقی برای امضای مجوز EIP-7702 ندارد؛ چه برسد به ۵۰ مجوز برای نانس‌های متوالی در یک دسته! یک موتور سیاست‌گذاری که هر درخواست را رمزگشایی کرده و انواع غیرمنتظره را رد کند، تصاحب کیف پول اتریوم را در نطفه خفه می‌کرد. در سوی دیگر، سقف‌ها (Limits) مشخص می‌کنند که امضاکننده چه میزان دارایی را جابه‌جا کند. در سایر شبکه‌ها که سرقت شامل مجموعه‌ای از انتقال‌های عادی بود، تعیین سقف ارزش برای هر دستور، حجم تک‌تک آن‌ها را محدود می‌کرد. قفل زمانی (Time lock) روی انتقال‌های بالاتر از یک حجم مشخص، پرداخت‌های کلان را به اندازه کافی نگه می‌داشت تا کسی آن‌ها را متوقف کند و تعیین سقف برای مجموع دارایی قابل جابه‌جایی توسط یک امضاکننده در یک بازه زمانی مشخص، کل خسارت را محدود نگه می‌داشت فرقی هم نمی‌کرد مهاجم چند دستور ارسال کند. بخش عمده ۶.۳۶ میلیارد دلار ظرف ۲۰ دقیقه خارج شد و هر یک از این دو کنترل می‌توانست آن را به یک خسارت محدود با زمان کافی برای واکنش تبدیل کند. با این حال، سقف‌های عددی به تنهایی کافی نبودند. تراکنشی که اختیار Binance 14 را به مهاجم داد، ارزش مالی صفر داشت؛ به همین دلیل است که بررسی «نوع تراکنش» به اندازه تعیین سقف ارزش اهمیت دارد.

نقطه‌ضعف دوم، اختیاری است که پس از اتمام دستور همچنان باقی می‌ماند. تفویض اختیار EIP-7702 تا زمانی که کیف پول مجوز جدیدی را امضا نکند پابرجا می‌ماند؛ بنابراین تنها یک مجوز، به جای یک پرداخت یک‌باره، یک موقعیت دائمی به مهاجم بخشید. از آنجا که Binance 14 اپراتور کیف پول Hot Wallet 34 نیز بود، این تفویض اختیار، کنترل ۸۲۳ میلیون USDC موجود در آن کیف پول را هم به ارث برد. تغییر کلیدها (Key rotation) نمی‌توانست این وضعیت را به عقب برگرداند؛ تنها راه چاره، ارسال یک مجوز جدید از خود کیف پول آلوده‌شده بود. کنترل لازم در اینجا، تهیه فهرستی از «اختیارات» در کنار «موجودی‌ها» است: هر نقش اپراتور، مجوز برداشت توکن (Allowance)، حق مدیریتی و تفویض اختیاری که از طریق آن یک کیف پول شرکت می‌تواند دارایی‌های کیف پول دیگر را جابه‌جا کند، باید در محاسبه میزان ریسک (Exposure) آن کیف پول لحاظ شود.

نقطه‌ضعف سوم، حجم دارایی انباشته‌شده پشت آن مسیر واحد و تداوم شارژ شدن آن بود. انتقال ۲۰۰ میلیون USDT به کیف پول Binance 14 در ساعت ۲۱:۴۲:۵۹ (یعنی بیش از یک ساعت پس از اولین تخلیه)، تنها ۷۲ ثانیه بعد توسط مهاجم جارو شد. فرآیندهای خزانه‌داری همچنان در حال پر کردن کیف پولی بودند که قبلاً از دست رفته بود.

نقطه‌ضعف چهارم، زمان واکنش است. تتر آدرس دریافت‌کننده اصلی مهاجم را در ساعت ۲۱:۰۱، یعنی ۳۷ دقیقه پس از تخلیه، مسدود کرد. بایننس تفویض اختیار را در ساعت ۰۰:۱۰، یعنی ۳ ساعت و ۴۹ دقیقه پس از نصب، حذف نمود. صادرکنندگان استیبل کوین که هیچ سهمی در این زیان نداشتند، سریع‌تر از شرکتی که مالک کیف پول‌ها بود خسارت را مهار کردند. متوقف کردن برداشت‌های مشتریان نیز جلوی فرآیند امضا را نگرفت: موج دوم انتقال‌ها حوالی ساعت ۲۳:۰۵، یعنی پس از توقف برداشت‌ها، از کیف پول‌های بایننس در شبکه‌های آوالانچ و پالیگان خارج شد.

نقطه‌ضعف پنجم، تغییر پروتکلی بود که هیچ‌کس آن را بازبینی نکرد. استاندارد EIP-7702 همراه با ارتقای پکترا (Pectra) در می ۲۰۲۵ (۱۷ ماه پیش از سرقت) روی شبکه اتریوم فعال شد و نوعی از تراکنش را ایجاد کرد که به یک کیف پول عادی اجازه می‌دهد اختیارات خود را به یک کد واگذار کند. یک بانک، چنین تغییری در یک کانال پرداخت حیاتی را به عنوان یک رویداد مدیریت تغییر (Change-management) تلقی می‌کند که نیازمند ارزیابی ریسک و به‌روزرسانی کنترل‌های پیرامون آن است. در اینجا، سیاست‌های امضاکننده آشکارا هرگز با این تغییر به‌روز نشده بود.

هیچ‌یک از این موارد به چارچوب کنترلی جدیدی نیاز ندارند. در «خودارزیابی ریسک و کنترل» یک بانک، هر کدام از این‌ها با هدفی که از قبل وجود دارد مطابقت پیدا می‌کند. این حادثه برای هر یک از آن‌ها یک مطالعه موردی در حوزه دارایی‌های دیجیتال فراهم می‌کند:

• دسترسی ممتاز (Privileged access): دستگاه یک مهندس به مسیر امضای محیط عملیاتی (Production) راه یافت.
• مجوزدهی تراکنش (Transaction authorization): امضاکننده با همان سهولتی که یک درخواست برداشت را امضا می‌کرد، یک مجوز تفویض اختیار را هم صادر کرد.
• مدیریت تغییر (Change management): ارتقای پروتکل هرگز به سیاست‌های امضاکننده راه پیدا نکرد.
• لغو دسترسی (Revocation): تفویض اختیار تقریباً چهار ساعت بیشتر از خود سرقت دوام آورد.
• ارتباطات بحران (Incident communication): اولین تایید عمومی ۵۱ دقیقه پس از تخلیه اصلی، از حساب شخصی بنیان‌گذار صرافی منتشر شد.

یک متولی (Custodian) چه مواردی را باید روی کیف پول‌های خود پایش کند؟

یک متولی نگهداری دارایی نمی‌تواند منتظر بماند تا بازار متوجه ماجرا شود. پایشگرهای کلیدی باید روی کیف پول‌ها و رکوردهای داخلی خود شرکت اجرا شوند و بیشتر آن‌ها مبتنی بر رخداد (Event) هستند تا آستانه عددی (Threshold)؛ یعنی تنها یک بار وقوع برای اقدام کافی است. پایشگرهای رخداد متریکا (Event Monitors) برای ردیابی حرکت توکن‌ها به/از آدرس‌های مشخص، مانند کیف پول‌های گرم خود شرکت، طراحی شده‌اند.

با اضافه کردن پایشگرهای کیف پول اختصاصی به جدول زمانی آن شب، اولین هشدار از ساعت ۲۰:۴۰ به ۲۰:۰۵ منتقل می‌شود؛ یعنی پیش از تفویض اختیار و ۱۹ دقیقه قبل از تخلیه کیف پول.‍

چهار مورد از این هفت پایشگر، هم‌زمان یا پیش از تخلیه اصلی فعال می‌شوند، پنجمی ظرف نیم دقیقه پس از آن و اولین مورد یک ربع ساعت پیش از تفویض اختیار به صدا درمی‌آید. هیچ‌کدام به داده‌های بازار وابسته نیستند و تنها پایشگرِ حجم تراکنش برای تعیین آستانه به داده‌های تاریخی نیاز دارد. هر یک از این‌ها باید روی زیرساختی مستقل از سیستم‌های ثبت و امضای تراکنش اجرا شوند تا نفوذ به یکی، دیگری را خاموش نکند.

دو مورد آخر، به جای «تشخیص»، محرک «واکنش» هستند. مسدودسازی توسط صادرکننده توکن روی آدرسی که شرکت همین تازگی به آن پرداخت داشته، یک تاییدیه بیرونی مبنی بر سرقت وجوه است که ۳۷ دقیقه پس از تخلیه و بسیار پیش از توقف برداشت‌ها توسط بایننس رخ داد. هشدار مربوط به ورودی‌ها (Inflows) نیز جلوی شرکت را می‌گیرد تا کیف پولی را که قبلاً از دست داده، دوباره شارژ نکند.

پایش اخبار منفی خارج از این فهرست قرار می‌گیرد. در ۲۹ اکتبر، رسانه‌ها سه ساعت و نیم پس از تخلیه نام بایننس را مطرح کردند؛ بنابراین برای خود متولی، این ابزار نقش تاییدکننده دارد نه تشخیص‌دهنده. ارزش اصلی آن برای شرکت‌هایی است که در معرض ریسک یک متولی قرار دارند: این سیستم یک خبر را به تمام شبکه‌ها و دارایی‌های تحت تاثیر متصل می‌کند و به آن‌ها می‌گوید کدام دارایی‌های خود را بررسی کنند.

اگر بایننس یک بانک بود

در یک بانک، این حادثه به عنوان یک «رویداد زیان واحد» تحت دسته‌بندی کمیته بال (Basel) با عنوان «تقلب خارجی» و زیرشاخه «امنیت سیستم‌ها» ثبت می‌شد. تعلیق برداشت‌ها، اطلاع‌رسانی به مشتریان و هرگونه اقدامات مربوط به تحریم‌ها در ادامه، پیامدهای همان رویداد واحد محسوب می‌شوند نه رخدادهایی جداگانه؛ هرچند هر کدام مجموعه متفاوتی از کنترل‌ها را به چالش می‌کشند.

یک شکست آشنا روی ریل‌های سریع‌تر

بانک‌ها پیش از این هم چنین الگویی را دیده‌اند. در فوریه ۲۰۱۶، مهاجمان در داخل بانک مرکزی بنگلادش از دسترسی سوئیفت (SWIFT) خود این بانک برای ارسال دستورات پرداخت به ارزش ۹۵۱ میلیون دلار به بانک فدرال رزرو نیویورک استفاده کردند که در نهایت ۸۱ میلیون دلار آن از دست رفت. ایالات متحده بعدتر یک برنامه‌نویس کره شمالی را متهم کرد؛ و اف‌بی‌آی اکنون سرقت بایننس را نیز به همین کشور نسبت داده است. در آن ماجرا هم هیچ رمز عبوری شکسته نشد: یک کانال قانونی دستوراتی را ارسال کرد که هیچ‌کس آن‌ها را بررسی نکرده بود.

بیشتر دستورات بانک بنگلادش با خوش‌شانسی متوقف شدند. فدرال رزرو نیویورک پس از پرداخت پنج دستور، بقیه را به صورت دستی بررسی کرد؛ بررسی‌ای که بخشی از آن به خاطر وجود کلمه «Jupiter» در یک آدرس بود که با نامی در لیست تحریم‌های آمریکا مطابقت داشت. اما ریل‌های پرداخت آنی، حتی همین حاشیه امنیت را هم از بین برده‌اند.

در جولای ۲۰۲۵، مهاجمان با استفاده از اطلاعات کاربری در شرکت C&M Software که موسسات کوچک‌تر را به سیستم پرداخت Pix برزیل متصل می‌کند، وجوهی را از حساب‌های ذخیره بانک مرکزی متعلق به شش موسسه خارج کردند. در آگوست ۲۰۲۵ نیز، اطلاعات کاربری لو رفته متعلق به یک پیمانکار فناوری اطلاعات شرکت Sinqia مورد استفاده قرار گرفت تا در یک روز حدود ۷۱۰ میلیون رئال برزیل تراکنش غیرمجاز از بانک HSBC و شرکت Artta از طریق محیط Pix انجام شود.

وقتی تسویه تراکنش چند ثانیه طول می‌کشد، کنترل‌ها باید «پیش از امضای تراکنش» عمل کنند، نه پس از تسویه آن. از دیدگاه ما، این یعنی سه چیز:

۱) سیاست امضایی که هیچ سیستم مهندسی یا لاگین پیمانکاری نتواند آن را تغییر دهد

۲) سقف‌های ارزش به ازای هر کیف پول و هر ساعت که توسط سیستمی مستقل از سیستم ارسال‌کننده اعمال شوند

۳) پایشی که به موازات هر دوی این‌ها اجرا شود. پس از حادثه بنگلادش، «برنامه امنیت مشتریان سوئیفت» این قبیل کنترل‌ها را برای تمامی اعضا اجباری کرد. زیرساخت امضا در دنیای دارایی‌های دیجیتال هنوز فاقد چنین استاندارد پایه‌ای است.

زیانی که بیش از خود حادثه دوام می‌آورد

پیامدهای سرمایه‌ای چنین رخدادی ماندگار خواهد بود. تحت رویکرد استاندارد کمیته بال برای ریسک عملیاتی، مولفه زیان معادل ۱۵ برابر میانگین زیان خالص سالانه یک بانک در طول ده سال است. این تک‌حادثه به صورت ناخالص حدود ۹.۵ میلیارد دلار به این شاخص اضافه می‌کرد؛ یا اگر فرض کنیم حدود ۲.۲۴ میلیارد دلار استیبل کوین منجمدشده در نهایت بازگردانده و به عنوان بازیابی (Recovery) محاسبه شود، این رقم حدود ۶.۲ میلیارد دلار خواهد بود. البته «منجمد شدن» به معنای «بازیابی شدن» نیست: تا زمانی که صادرکنندگان با حکم دادگاه توکن‌ها را نسوزانند و مجدداً صادر نکنند، همان رقم ناخالص پابرجاست. چندین حوزه قضایی از جمله اتحادیه اروپا و بریتانیا، ضریب زیان داخلی را روی عدد یک تنظیم می‌کنند که اثر سرمایه‌ای را حذف می‌کند، اما داده‌های زیان، نظارت نهادهای رگولاتوری یا سابقه ده ساله را از بین نمی‌برد.

اینکه چه مقدار از زیان قابل بازیابی است، به نوع دارایی سرقت‌شده بستگی دارد. دارایی‌های بومی مانند ETH و BTC صادرکننده ندارند، بنابراین سرقت تاییدشده آن‌ها قطعی و نهایی است؛ استیبل کوین‌ها را می‌توان مسدود و پس از طی مراحل قانونی دوباره صادر کرد و اوراق بهادار توکنیزه‌شده نیز معمولاً توسط نهاد ثبت‌کننده قابل صدور مجدد هستند. بنابراین، سقف کیف پول‌های گرم و برآوردهای زیان باید به تفکیک هر «طبقه دارایی» تعیین شوند، نه به عنوان یک نسبت کلی و واحد بین کیف پول گرم و سرد.

در صورت تفکیک بر اساس مسیر بازیابی، وضعیت زیان تا تاریخ ۲ نوامبر شکل مشخصی به خود می‌گیرد. هنوز هیچ مبلغی بازگردانده نشده و ارزش‌ها بر اساس قیمت‌های فعلی محاسبه شده‌اند، بنابراین مجموع ردیف‌ها با مبلغ سرقت‌شده در لحظه حادثه برابر نیست.

قدرت صادرکننده یک شمشیر دولبه است. تتر برای متوقف کردن تخلیه‌ها، خود کیف پول Binance 14 را هم در لیست سیاه قرار داد؛ بنابراین قابلیتی که در یک حادثه از شرکت محافظت می‌کند، در حادثه‌ای دیگر به ریسک عدم دسترسی (Availability risk) برای موجودی استیبل کوین‌های خود شرکت تبدیل می‌شود.

سرعت عمل این کنترل نیز توسط سیاستی تعیین می‌شود که در مالکیت شرکت نیست و ممکن است تغییر کند. زمانی که پلتفرم دریفت (Drift) در ماه آوریل هک شد، سرکل تنها با حکم دادگاه یا دستور رسمی نهادهای قضایی اقدام به مسدودسازی USDC می‌کرد و در نتیجه حدود ۲۳۰ میلیون دلار USDC سرقت‌شده بدون مسدود شدن بین شبکه‌ها جابه‌جا شد. در ۲۸ می، سرکل استثنایی را برای درخواست‌های فوری نهادهای مجری قانون اضافه کرد و در ۲۹ اکتبر توانست ۸۲۳ میلیون USDC را با هماهنگی ضابطان قضایی مسدود کند. شش ماه زودتر، احتمالاً در سرقت مشابهی، آن حجم از USDC آزادانه جابه‌جا می‌شد.

جایگزین کردن دارایی‌های مشتریان توسط بایننس نیز «بازیابی» محسوب نمی‌شود؛ بلکه «پرداخت کردن زیان» است. بایننس می‌گوید از خزانه شرکت، بخشی از صندوق SAFU و بخشی از صندوق بیمه معاملات آتی خود استفاده کرده، بدون اینکه مشخص کند چه سهمی از هر کدام برداشت شده است. یک بانک بابت جذب زیان عملیاتی از محلی که برای ریسک نکول مشتقات کنار گذاشته شده، با سوالات نظارتی مستقیم مواجه می‌شد. علاوه بر این، زیان یک مرز مشخص دارد: حدود ۶۲۸ میلیون دلار لیکویید شدن موقعیت‌ها در کل بازار در آن شب، زیان بازار سایر شرکت‌ها بود، نه بخشی از این زیان عملیاتی.

سناریویی که هیئت‌مدیره باید پیش‌بینی می‌کرد

تحلیل سناریو جایی است که از یک بانک انتظار می‌رود چنین رخدادی را از قبل ببیند. سناریویی که در آن مسیر امضا آلوده می‌شود و بزرگی آن بر اساس ارزشی که یک مسیر پیش از برخورد به سقف محدودیت می‌تواند جابه‌جا کند سنجیده می‌شود، رقمی چند میلیارد دلاری را پیش روی هیئت‌مدیره قرار می‌داد. چنین رقمی، سقف کیف پول‌های گرم را مدت‌ها پیش از آنکه مهاجمی از راه برسد، به چالش می‌کشید.

یک ناظر همچنین به تاب‌آوری عملیاتی (Operational resilience) نگاه می‌کند. برداشت‌های مشتریان یک سرویس تجاری حیاتی است و از یک بانک انتظار می‌رود که آستانه تحمل اثر (Impact tolerance) را برای آن تعیین کرده و سناریوی آلوده شدن سیستم امضا را آزمایش کرده باشد. سوالات مستقیماً از همین‌جا شکل می‌گیرند: با چه سرعتی می‌توان تمام مسیرهای امضا را متوقف کرد؟ چه کسی تصمیم می‌گیرد؟ و آیا این فرآیند تمرین شده است؟

الزامات گزارش‌دهی و حضانت

ساعت‌های نظارتی هم‌زمان شروع به تیک‌تاک می‌کنند. یک بانک آمریکایی موظف است حداکثر تا ۳۶ ساعت پس از احراز وقوع یک حادثه مهم، رگولاتور فدرال اصلی خود را مطلع کند (Federal Register). یک نهاد مالی در اتحادیه اروپا تحت قانون DORA باید گزارش اولیه را ظرف ۴ ساعت پس از طبقه‌بندی حادثه به عنوان بزرگ و حداکثر ۲۴ ساعت پس از مطلع شدن از آن ثبت کند، گزارش میانی را ظرف ۷۲ ساعت پس از اعلان اولیه ارائه دهد و گزارش نهایی را حداکثر یک ماه پس از آخرین گزارش میانی ارسال نماید.

در بخش حضانت، قانون MiCA مسئولیت حقوقی اضافه می‌کند. یک متولی در قبال دارایی‌های کریپتویی از دست رفته ناشی از حادثه‌ای که به او قابل انتساب باشد، تا سقف ارزش بازار آن‌ها در زمان فقدان، در برابر مشتریانش مسئول است. بنابراین، هر دلاری که در یک کیف پول گرم قرار دارد، دلاری است که شرکت ممکن است پس از نفوذ به سیستم امضا، به مشتریانش بدهکار شود و این زیان مستقیماً از منابع مالی خود شرکت کسر می‌گردد؛ کما اینکه بایننس بیش از ۶.۳۴ میلیارد دلار از پول شرکت را برای پوشش این حادثه کنار گذاشت. اندازه لایه کیف پول‌های گرم باید در اشتهای ریسک (Risk appetite) شرکت تعریف شود و در برابر سرمایه و بیمه موجود برای جذب آن زیان سنجیده شود، نه اینکه صرفاً به تیم‌های عملیات و امنیت واگذار گردد.

شاخص‌هایی که باید پایش شوند

شاخص‌های بااهمیت از دو منبع می‌آیند: داده‌های آن‌چین که هر شرکتی می‌تواند رصد کند، و داده‌های داخلی که تنها خود شرکت در اختیار دارد. در این چارچوب، هر مرحله از حمله به شاخص‌هایی متصل می‌شود که مکمل پایشگرهای کیف پول که بالاتر ذکر شد هستند و مشخص می‌کند چه کسی قادر به دیدن آن‌هاست.

«تعداد نقض سیاست‌های امضاکننده» در اینجا شاخص پیشرو (Leading indicator) محسوب می‌شود؛ سیگنال‌های سطح کیف پول نیز در بخش قبلی پوشش داده شدند. شاخص‌های KRI شبکه و دارایی، مقیاس و گستردگی حادثه را در همان ساعت اول تایید می‌کنند و دقیقاً همان چیزهایی هستند که یک طرف مقابل (Counterparty)، مشتری سرویس حضانتی یا ناظرِ فاقد دسترسی به سیستم‌های داخلی بایننس می‌تواند ببیند. آستانه‌های هشدار نیز باید توسط هر شرکت و با آزمایش روی حوادث گذشته تنظیم شوند.

تیم‌های ریسک اکنون چه باید بکنند؟

با «مسیر امضا» به عنوان دارایی اصلی که باید محافظت شود رفتار کنید. هر شرکتی که ارزش مالی را از طریق یک امضاکننده آنلاین جابه‌جا می‌کند، چه صرافی باشد، چه متولی، صادرکننده استیبل کوین یا بانکی که میز دارایی دیجیتال دارد، باید بتواند در فصل جاری به این پنج سوال پاسخ دهد:

• امضاکننده سیستم چه نوع تراکنش‌هایی را رد خواهد کرد؟
• یک مسیر امضا پیش از آنکه سقف محدودیت متوقفش کند، چه میزان ارزش را می‌تواند جابه‌جا کند؟
• با چه سرعتی می‌توان تمام مسیرها را متوقف کرد؟
• اگر کدی روی یکی از آدرس‌های خود شرکت ظاهر شود، چه کسی متوجه خواهد شد؟
• آیا تک‌تک دارایی‌های تحت نگهداری (و نه فقط بزرگ‌ترین آن‌ها) پایشگر خروج وجه (Outflow monitor) مختص به خود را دارند؟

برای شرکت‌هایی که به جای مدیریت یک صرافی یا سرویس حضانتی، در معرض ریسک آن‌ها قرار دارند، همین سوالات باید در فرآیند ارزیابی دقیق (Due diligence) گنجانده شوند و شاخص‌های آن‌چینِ ذکرشده، بخشی است که خودشان می‌توانند مستقیماً رصد کنند. سرقت ۲۹ اکتبر دقایقی پیش از وقوع، روی بلاکچین قابل مشاهده بود؛ شکاف اصلی در چیزی بود که دیگران به آن نگاه می‌کردند.

در گزارش بعدی، به سراغ شرکت‌هایی می‌رویم که در سمت دیگر این سرقت قرار داشتند: طرف‌های تجاری دارای موجودی در یک پلتفرم، دارندگان استیبل کوین، و بانک‌هایی که محصولات وام‌دهی را روی پروتکل‌هایی نظیر آوه (Aave) بنا می‌کنند. تمام آن‌ها در آن شب به کنترل‌هایی تکیه کرده بودند که مالکشان نبودند.

منابع

• سرقت بایننس: گزارش TRM Labs با عنوان «کره شمالی ۶.۳۶ میلیارد دلار از بایننس سرقت کرد»، ۲۹ اکتبر ۲۰۲۶. تحلیل هک ۵.۵ میلیارد دلاری بایننس توسط Blockaid. گزارش Tech Insider با عنوان «بایننس ۹۰ درصد از خسارت هک ۶.۳ میلیارد دلاری را پوشش می‌دهد»، ۱ نوامبر ۲۰۲۶. رکوردهای تراکنش اتریوم: تخلیه اصلی از Binance 14 و دو انتقال USDC از Hot Wallet 34 شامل ۷۸۰ میلیون در ساعت ۲۰:۴۱ و ۴۳ میلیون در ساعت ۲۰:۵۹.
• وضعیت بازیابی: گزارش Elliptic با عنوان «بزرگ‌ترین سرقت تاریخ: کره شمالی پشت پرده هک ۶.۴ میلیارد دلاری بایننس»، آخرین به‌روزرسانی ۱ نوامبر ۲۰۲۶. بیانیه بایننس، «به‌روزرسانی حادثه امنیتی شماره ۲»، ۳۰ اکتبر ۲۰۲۶. بیانیه بایننس، «حادثه امنیتی | به‌روزرسانی بازیابی شماره ۳: ۹۰ درصد دارایی‌های مسروقه جایگزین شد؛ ارائه اسنپ‌شات اثبات ذخیره»، ۳۱ اکتبر ۲۰۲۶. بیانیه بایننس، «حادثه امنیتی | به‌روزرسانی بازیابی شماره ۵: اسنپ‌شات اثبات ذخیره ۳۱ اکتبر اکنون با تولید اثبات ZK کاملاً توسط کاربران قابل راستی‌آزمایی است»، ۲ نوامبر ۲۰۲۶. گزارش Bitcoin.com News با عنوان «بایننس ۱۵.۷ میلیارد دلار از دست داد؛ اثبات ذخیره سه‌شنبه ارائه می‌شود»، ۲ نوامبر ۲۰۲۶. موقعیت آوه خوانده‌شده از قرارداد استخر Aave V3 در ۲ نوامبر ۲۰۲۶.
• سیاست مسدودسازی استیبل کوین: گزارش CoinDesk با عنوان «مدیرعامل سرکل می‌گوید بدون حکم دادگاه USDC را مسدود نخواهد کرد»، ۱۳ آوریل ۲۰۲۶. گزارش American Banker با عنوان «سرقت ۶ میلیارد دلاری بایننس معمای مسدودسازی استیبل کوین‌ها را برانگیخت»، اکتبر ۲۰۲۶.
• حوادث پیشین: وزارت دادگستری ایالات متحده، «اعلام جرم علیه برنامه‌نویس تحت حمایت رژیم کره شمالی»، ۶ سپتامبر ۲۰۱۸. گزارش رویترز، «چگونه فدرال رزرو نیویورک در ماجرای سرقت بانک بنگلادش لغزش کرد»، ۲۱ جولای ۲۰۱۶. گزارش رویترز، «حمله سایبری به ارائه‌دهنده فناوری در برزیل حساب‌های ذخیره برخی موسسات مالی را هدف قرار داد»، ۳ جولای ۲۰۲۵. فرم 8-K شرکت Evertec درباره حادثه Sinqia، سپتامبر ۲۰۲۵.
• مقررات: نهادهای OCC، فدرال رزرو و FDIC، «الزامات اطلاع‌رسانی حوادث امنیت کامپیوتری برای سازمان‌های بانکی»، Federal Register، ۲۳ نوامبر ۲۰۲۱. کمیسیون اروپا، مقررات تفویضی (EU) 2025/301 در مورد محتوا و محدودیت‌های زمانی برای گزارش حوادث بزرگ مرتبط با فناوری اطلاعات و ارتباطات (ICT)، ماده ۵. نهاد ESMA، ماده ۷۵ قانون MiCA: حضانت و مدیریت دارایی‌های کریپتویی از طرف مشتریان، پاراگراف ۸.
• داده‌ها: داده‌های KRI و پایش اخبار منفی متریکا، ۲۷ تا ۳۰ اکتبر ۲۰۲۶. زمان‌های تراکنش، مبالغ انتقال و سطوح کارمزد تطبیق داده‌شده با داده‌های شبکه اصلی اتریوم.