اف‌بی‌آی در اطلاعیه ۳۱ اکتبر ۲۰۲۶، سرقت بیش از شش میلیارد دلار دارایی دیجیتال از بایننس را به کرهٔ شمالی نسبت داد و فعالیت عاملان را با نام TraderTraitor معرفی کرد. حادثه در حدود ۲۹ اکتبر رخ داده است. بنابراین کشوری که در گزارش رسمی نام برده شده کرهٔ شمالی است. بایننس در اطلاعیه بازیابی اول نوامبر، از بازگشایی مرحله‌ای برداشت‌ها و جبران اثر مالی سرقت با منابع شرکت خبر داد. این گزارش، اطلاعات منتشرشده تا دوم نوامبر را همراه با توضیح فنی و تحلیل دفاعی IROSG مرور می‌کند.
چه چیزی رسماً اعلام شده است؟
اطلاعیه اف‌بی‌آی سه بخش مهم دارد. نخست، انتساب عملیات به کرهٔ شمالی و نام‌گذاری فعالیت به‌عنوان TraderTraitor است. دوم، مشاهده تبدیل دارایی‌های سرقت‌شده عمدتاً به اتر با همکاری سرویس مخفی آمریکا و بخش تحقیقات جنایی اداره مالیات است. سوم، درخواست از ارائه‌دهندگان خدمات دارایی دیجیتال برای جلوگیری از تراکنش‌های مرتبط با نشانی‌های معرفی‌شده است. فهرست نشانی‌ها در همان صفحه رسمی قرار دارد و باید از نسخه اصلی بررسی شود، زیرا بازنشر یک فهرست ثابت ممکن است با ادامه تحقیق قدیمی شود.
این اطلاعیه، گزارش کامل پزشکی قانونی درباره ورود اولیه مهاجم نیست. همچنین نام و تصویر اشخاصی را به‌عنوان عاملان فردی همین حمله منتشر نمی‌کند. از نظر نگارش خبر، انتساب یک عملیات به یک دولت یا مجموعه فعالیت سایبری با شناسایی اشخاص حاضر در عملیات تفاوت دارد. خواننده باید بتواند بفهمد کدام ادعا را مرجع رسمی مطرح کرده، کدام برداشت متعلق به یک شرکت تحلیل بلاک‌چین است و کدام قسمت توضیح آموزشی تحریریه محسوب می‌شود.
چرا رقم خسارت در گزارش‌ها متفاوت است؟
بایننس اثر مالی حادثه را حدود ۶٫۳ میلیارد دلار برآورد کرده است. TRM Labs در گزارش خود رقم حدود ۶٫۳۶ میلیارد دلار و Elliptic در بررسی به‌روزشده رقم ۶٫۴۳ میلیارد دلار را آورده‌اند. این ارقام، برآوردهای منابع مختلف‌اند و نباید با میانگین گرفتن از آن‌ها یک عدد ظاهراً دقیق ساخت. زمان ارزش‌گذاری دارایی، دامنه تراکنش‌های محاسبه‌شده و تشخیص انتقال داخلی از انتقال مهاجم می‌توانند در نتیجه اثر بگذارند. برای مقایسه، نام منبع و زمان مشاهده را کنار عدد نگه می‌داریم.
Elliptic تا به‌روزرسانی اول نوامبر، حدود ۲٫۸۵ میلیارد دلار دارایی مسدود یا توقیف‌شده را تأیید کرده بود. مسدود شدن دارایی با بازگشت قطعی آن به مالک یکسان نیست. فرایند بازگرداندن ممکن است به بررسی مالکیت، هماهنگی ناشر و مراحل اجرایی وابسته باشد. به همین ترتیب، جایگزینی دارایی با منابع صرافی، اقدام مالی جداگانه‌ای از بازیابی پول سرقت‌شده است. در خواندن خبر باید مبلغ سرقت، مبلغ مهارشده و مبلغ تأمین‌شده برای پوشش تعهدات را جدا دنبال کرد.
برداشت‌ها چگونه برمی‌گردند؟
اطلاعیه رسمی بایننس در اول نوامبر بازگشایی برداشت‌ها را مرحله‌ای توصیف می‌کند. شرکت گفته است هر جفت شبکه و دارایی پس از بررسی آمادگی و امنیت فعال می‌شود. وضعیت یک شبکه را نمی‌توان به همه توکن‌ها تعمیم داد. در همان اطلاعیه، بایننس مسئولیت پوشش اثر مالی را پذیرفته و از ادامه تأمین دارایی‌های باقی‌مانده خبر داده است. متن صفحه طی فرایند بازیابی به‌روز شده و در بخش پایانی آن پوشش حدود ۹۵ درصد مبلغ آسیب‌دیده ذکر شده است؛ این عدد باید همراه با تاریخ همان اطلاعیه خوانده شود.
برای کاربر، موجودی نمایشی حساب، پشتوانه اعلام‌شده و امکان برداشت سه مشاهده متفاوت‌اند. باز بودن صفحه حساب لزوماً وضعیت مسیر خروج یک دارایی خاص را نشان نمی‌دهد. روش بررسی روشن این است که نام دارایی، شبکه انتخابی و وضعیت سرویس در صفحه رسمی صرافی با هم تطبیق داده شوند. این توضیح به معنی توصیه خرید، فروش یا نگهداری دارایی خاص نیست؛ هدف آن جلوگیری از برداشت نادرست از خبر بازگشایی است.
مسیر فنی شناخته‌شده تا این مرحله
TRM گزارش کرده که بخش بزرگی از انتقال‌ها در یک بازه کوتاه انجام شده و در اتریوم از قابلیت واگذاری رفتار حساب در EIP-7702 استفاده شده است. این شرکت، شواهد چند شبکه را نشانه‌ای از آسیب به زیرساخت امضای کیف‌پول‌های گرم ارزیابی می‌کند. این تعبیر، ارزیابی پژوهشگران درباره آثار مشاهده‌شده است. گزارش نهایی داخلی بایننس هنوز برای توضیح همه نقاط ورود و عبور از کنترل‌ها اهمیت دارد و نباید جای خالی آن را با یک داستان قطعی پر کرد.
طبق بررسی Elliptic، توضیح اولیه درباره لپ‌تاپ یک مهندس DevOps بعداً با اعلام کشف نقاط نفوذ دیگر تکمیل شده است. به همین دلیل خلاصه کردن همه حادثه در عبارت «یک لپ‌تاپ هک شد» می‌تواند دامنه مسئله را پنهان کند. در یک سامانه واقعی، دستگاه کاربر، نشست دسترسی، سرویس داخلی، سیاست تأیید و بخش امضا اجزای جداگانه‌اند. تحلیل دفاعی باید نشان دهد مهاجم در هر مرز چه اختیاری به دست آورده و کدام شاهد این عبور را تأیید می‌کند.
عکس منتشرشده از افراد به کدام پرونده تعلق دارد؟
عکس دوم — کیم ایل در چپ و جون چانگ هیوک در راست. منبع عکس اف‌بی‌آی، بازنشر آرشیوی CBS News در ۱۷ فوریه ۲۰۲۱. این تصویر مربوط به پرونده پیشین است؛ اطلاعیه بایننس در اکتبر ۲۰۲۶ این دو نفر را به‌صورت فردی عامل حمله اخیر معرفی نکرده است.
وزارت دادگستری آمریکا در فوریه ۲۰۲۱، پرونده‌ای درباره جون چانگ هیوک، کیم ایل و پارک جین هیوک منتشر کرد. طبق اتهامات آن پرونده، این افراد با واحدهای مرتبط با اداره شناسایی عمومی کرهٔ شمالی همکاری داشته‌اند. منابع رسمی برای هر سه شخص صفحه جداگانه دارند. استفاده از تصویر آرشیوی برای توضیح سابقه این شبکه‌ها زمانی دقیق است که نام، تاریخ و ماهیت اتهامی پرونده کنار تصویر دیده شود. عکس قدیمی، مدرک تازه درباره حضور یک فرد در رویداد جدید محسوب نمی‌شود.
واگذاری حساب چه تفاوتی با انتقال ساده دارد؟
در استاندارد EIP-7702، یک حساب معمولی اتریوم می‌تواند با مجوز امضاشده، اجرای رفتار خود را به کد مشخصی واگذار کند. این قابلیت برای امکاناتی مانند اجرای چند عمل در یک تراکنش طراحی شده است. در نتیجه بررسی امنیتی امضا باید معنای مجوز را نیز پوشش دهد. امضای یک درخواست صرفاً تأیید رشته‌ای از داده نیست؛ ممکن است اختیار آینده حساب را تغییر دهد. پرسش کاربردی برای تیم نگهداری این است که کاربر یا سامانه تأییدکننده، پیش از امضا دقیقاً چه اثر و اختیاری را مشاهده می‌کند.
در یک سناریوی آموزشی، انتقال مقدار محدودی توکن به یک مقصد شناخته‌شده را با اعطای اختیار اجرای کد مقایسه کنید. هر دو ممکن است در رابط کاربری با دکمه تأیید نمایش داده شوند، اما پیامدشان یکسان نیست. سامانه امضای سازمانی باید نوع درخواست، مقصد، محدوده اختیار و وضعیت سیاست را به‌صورت قابل بررسی ارائه کند. این مثال، بازسازی جزئیات نفوذ بایننس نیست؛ نشان می‌دهد چرا یک کنترل عمومی برای همه انواع امضا ممکن است اطلاعات کافی به تصمیم‌گیرنده ندهد.
تحلیل دفاعی IROSG برای تیم‌های زیرساخت
اولین تمرین مفید، ترسیم مسیر کامل یک درخواست برداشت است. تیم باید مشخص کند درخواست از کجا ایجاد می‌شود، چه سرویسی آن را معتبر می‌داند، چه کسی سیاست را تغییر می‌دهد و کدام بخش امضا را تولید می‌کند. سپس برای هر مرحله، هویت انجام‌دهنده و محل ثبت رویداد را تعیین کند. اگر یک حساب مدیریتی بتواند هم درخواست بسازد و هم سیاست تأیید را تغییر دهد، استقلال کنترل‌ها باید دوباره بررسی شود. داشتن چند صفحه مدیریتی به‌تنهایی به معنی وجود چند مرز مستقل اعتماد نیست.
تمرین دوم، آزمون واکنش به توقف اضطراری است. در محیط آزمایشی می‌توان بررسی کرد که با متوقف کردن سرویس برداشت، صف‌های قبلی چه می‌شوند و آیا کارهای زمان‌بندی‌شده همچنان مجوز اجرا دارند. هدف این آزمون، شمارش همه مسیرهای تولید تراکنش است. گزارش پذیرش باید نشان دهد درخواست در حال پردازش، درخواست جدید و تلاش مجدد پس از خطا چه رفتاری دارند. جمله کلی «برداشت متوقف شد» بدون این جزئیات برای ارزیابی مهار کافی نیست.
تمرین سوم به نشست‌ها و حساب‌های سرویس مربوط می‌شود. تعویض رمز عبور یک کارمند لزوماً همه توکن‌های صادرشده یا مجوزهای سرویس وابسته را بی‌اعتبار نمی‌کند. تیم پاسخ باید فهرست نشست‌های فعال، زمان صدور، اختیار و مسیر ابطال را بشناسد. برای هر نوع اعتبارنامه، یک مالک فنی و یک روش آزمون ابطال لازم است. این تحلیل عمومی است و ادعایی درباره نوع دقیق اعتبارنامه‌های استفاده‌شده در حادثه بایننس مطرح نمی‌کند.
ثبت شواهد و حفظ قابلیت بازسازی
پس از مشاهده برداشت مشکوک، هماهنگ کردن ساعت سامانه‌ها و حفظ نسخه اصلی رویدادها اهمیت عملی دارد. شناسه درخواست داخلی، شناسه تراکنش، نام سرویس و زمان دریافت پاسخ باید قابل ارتباط باشند. اگر گزارش شبکه فقط زمان محلی دارد و گزارش امضا با زمان دیگری ذخیره می‌شود، بازسازی ترتیب رخداد دشوار خواهد شد. یک خط زمانی خوب، میزان اطمینان هر پیوند را نیز ثبت می‌کند؛ نزدیکی دو رویداد از نظر زمان، به‌تنهایی رابطه علت و معلولی را ثابت نمی‌کند.
برای نمونه، فرض کنید یک تراکنش خارج از الگوی معمول ثبت شده اما رویداد تأیید آن در سامانه مدیریت پیدا نمی‌شود. این وضعیت یک پرسش تحقیقاتی ایجاد می‌کند. باید سلامت ثبت وقایع، مسیرهای جایگزین و امکان تأخیر انتقال لاگ بررسی شود. نتیجه عجولانه درباره حذف عمدی لاگ ممکن است تحقیق را منحرف کند. نگهداری شواهد اولیه و مستندسازی هر تغییری که تیم پاسخ روی سرویس انجام می‌دهد، امکان بازبینی مستقل نتیجه را بیشتر می‌کند.
ردیابی دارایی و پاسخ به هشدار
فهرست نشانی‌های منتشرشده یک ورودی برای بررسی است. سامانه دریافت‌کننده باید شبکه، قالب نشانی، زمان دریافت فهرست و منبع آن را ثبت کند. یک نشانی مشابه روی دو شبکه لزوماً همان زمینه عملیاتی را ندارد. همچنین هشدار درباره ارتباط یک انتقال با مسیر مشکوک باید همراه با دلیل و درجه اطمینان به بررسی‌گر ارائه شود. حذف تاریخچه تصمیم‌ها باعث می‌شود بعداً روشن نباشد توقف یا آزادسازی یک انتقال بر اساس چه اطلاعاتی انجام شده است.
در تحلیل مدیریتی، سرعت کشف و زمان اعمال مهار را می‌توان جدا اندازه گرفت. ممکن است ابزار تحلیل بسیار زود هشدار دهد، اما فرایند تأیید داخلی ساعت‌ها طول بکشد. ممکن است امکان مسدودسازی فقط برای بخشی از انواع دارایی وجود داشته باشد. بنابراین یک برنامه پاسخ باید از قبل بداند هر شریک چه اقدامی می‌تواند انجام دهد و چه اطلاعاتی لازم دارد. نتیجه این تمرین، فهرست تماس عمومی نیست؛ یک مسیر عملی و آزموده برای انتقال شواهد معتبر بین مسئولان مجاز است.
از خبر بعدی چه انتظاری باید داشت؟
گزارش فنی نهایی زمانی ارزش بیشتری دارد که زنجیره دسترسی، علت عبور از سیاست‌های امضا، دامنه دارایی‌های درگیر و اقدامات اصلاحی قابل سنجش را توضیح دهد. وعده تقویت امنیت بدون معیار آزمون، مقایسه وضعیت قبل و بعد را دشوار می‌کند. برای مثال، اگر کنترل تازه‌ای برای نوع خاصی از مجوز اضافه شده، باید معلوم شود درخواست ناسازگار چگونه رد می‌شود و آیا مسیرهای خودکار نیز همان کنترل را اجرا می‌کنند. این‌ها پرسش‌های ارزیابی‌اند و پاسخشان را باید از شواهد بعدی گرفت.
برای خواننده نیز سه نقطه پیگیری روشن باقی می‌ماند. اطلاعیه رسمی صرافی وضعیت خدمات و جبران را توضیح می‌دهد، مرجع تحقیق انتساب و درخواست همکاری را منتشر می‌کند و پژوهشگران مستقل مسیر دارایی‌ها را بررسی می‌کنند. هیچ‌کدام به‌تنهایی جای دو مورد دیگر را نمی‌گیرد. ثبت تاریخ هر به‌روزرسانی کمک می‌کند یک ادعای اولیه با یافته نهایی مخلوط نشود. این پرونده نشان می‌دهد کیفیت توضیح یک حادثه به تفکیک دقیق واقعیت، برآورد، سابقه و تحلیل وابسته است.
