وقتی باطلکردن توکن، بکدور رو نمیکشه
خلاصهٔ کاملتر
نویسندهٔ مقاله میگه تقریباً تو هر runbook پاسخ به حادثهٔ هویتی، یکی از اولین قدمها باطلکردن توکنهاست و مقابل فیشینگ adversary-in-the-middle هم درست جواب میده. ولی بعد از چند روز کالبدشکافی یه بکدور، به موردی رسیده که همین قدم اصلاً کار نمیکنه. نمونه GraphWorm هست، ایمپلنتی سفارشی که به گروه APT چینیِ Webworm نسبت داده میشه.
GraphWorm نه دامنهٔ C2 داره، نه beacon به یه VPS اجارهای، نه آدرس هاردکدشدهای که بشه بلاکش کرد. بهجاش بهعنوان یه اپلیکیشن OAuth به Microsoft Graph لاگین میکنه و از یه اکانت OneDrive بهعنوان dead drop یعنی صندوق واسط استفاده میکنه. اپراتور فایل تسک رمزشده رو تو یه پوشه میذاره، ایمپلنت پوشه رو چک میکنه، تسک رو اجرا میکنه و نتیجهٔ رمزشده رو تو پوشهٔ دیگه آپلود میکنه. همهش روی graph.microsoft.com و TLS، از هاستی که کل روز داره با Microsoft 365 حرف میزنه.
یعنی لایهٔ شبکه هیچی برای گفتن نداره: نه مقصد غیرعادی، نه دامنهٔ تازه ثبتشده، نه پورت عجیب. اعتبارنامهها هم همگی بهصورت cleartext تو باینری نشستن، یه client ID، یه client secret، یه tenant ID و یه refresh token بیشتر از ۱۳۰۰ کاراکتری. نویسنده اضافه میکنه که ایمپلنت قربانیها رو با hostname یا آدرس نمیشناسه؛ یه شناسه میسازه از هشِ آدرس سختافزاری کارت شبکه بهعلاوهٔ سریال CPU و دیسک که از WMI میگیره. پس اسم ماشین رو عوض کنی یا ببریش زیر یه subnet دیگه، اپراتور بازم همون باکس رو میشناسه.
نکتهٔ اصلی اما تو هندلر تسکهاست. بین دستورهایی که ایمپلنت قبول میکنه یکی به اسم upgrade هست: یه بلاک کانفیگ از تسک ورودی میخونه، هر پنج رشتهٔ اعتبارنامه رو از بین میبره، پنج تای جدید رو جاش میذاره، ساختار scope مربوط به OAuth رو بازسازی میکنه، اتصال به اکانت OneDrive جدید رو تست میکنه، کانفیگ جایگزین رو روی دیسک مینویسه و نمونهٔ زندهٔ API رو عوض میکنه. یک تسک، تعویض کامل هویت.
پیامدش اینه: شما اپلیکیشن رو پیدا میکنی، به پلتفرم گزارش میدی و توکنها باطل میشن. ولی اپراتوری که هر بازه یه فایل heartbeat مینویسه داره تماشا میکنه و یه تسک upgrade به سمت اکانت OneDrive دومی که ماهها قبل ثبت کرده صف میکنه. ایمپلنت میگیرتش و ادامه میده، بدون هیچ باینری جدید یا مکانیزم persistence جدید. نویسنده میگه این رو دو بار تأیید کرده، یکبار از رشتههای استخراجشده و یکبار از خود تابع دیکامپایلشده.
نویسنده سه چیز رو بعدش تو رویهٔ پاسخش عوض کرده. اول اینکه وقتی C2 روی یه application identity سواره، باطلکردن توکن رو یه تأخیر بدونی نه اخراج، چون چیز ماندگار خودِ registration هست نه توکنهایی که صادر میکنه؛ پس اگه اون registration تو تنانتی باشه که دستت بهش نمیرسه، زودتر گزارشش بده نه بهعنوان آخرین قدم. دوم اینکه فرض کنی اپراتور نسخهٔ یدکی داره، پس همزمان با سوزوندن اعتبارنامه دسترسی endpoint به کانال رو هم قطع کن. سوم اینکه روی لایهٔ هویت شکار کنی، چون لایهٔ شبکه اینجا کوره.
نکات کلیدی:
- GraphWorm ایمپلنتی منسوب به گروه APT چینیِ Webworm هست که بهجای دامنهٔ C2 از OneDrive استفاده میکنه
- ترافیکش روی graph.microsoft.com و TLS میره، پس هیچ مقصد غیرعادیای برای فایروال نمیسازه
- client ID، client secret، tenant ID و یه refresh token بیش از ۱۳۰۰ کاراکتری بهصورت cleartext تو باینری هستن
- دستور upgrade با یک تسک هر پنج اعتبارنامه رو عوض میکنه، بدون هیچ تغییری روی endpoint
- شناسهٔ قربانی از هشِ آدرس سختافزاری کارت شبکه بهعلاوهٔ سریال CPU و دیسک ساخته میشه، پس تغییر نام یا شبکه فایده نداره
- تشخیص روی لایهٔ هویت انجام میشه: دیدن application ID اپراتور تو رویدادهای sign-in و یه user agent غیرمرورگری که به OneDrive وصل میشه




