هنگامی که مهاجمان برای سرقت اطلاعات، سازمانی را هدف قرار میدهند، پنهان ماندن برای آنها اهمیت بسیار زیادی دارد. هدف آنها معمولاً حفظ دسترسی بلندمدت است؛ موضوعی که مستلزم جلوگیری از ایجاد هشدارهای امنیتی و درعینحال حفظ دسترسی در صورت شناسایی حمله و آغاز فرایند پاسخگویی به رخداد یا بازنشانی دورهای رمزهای عبور است.
بدافزارهایی مانند Infostealerها یا ابزارهای ظاهراً قانونی کنترل و مدیریت از راه دور (RMM) شرط نخست را برآورده نمیکنند؛ زیرا استفاده از آنها موجب فعال شدن EDR و ثبت رویدادهای مشکوک در کنسولهای SIEM میشود.
اتکا به اطلاعات احراز هویت سرقتشده نیز با شرط دوم در تضاد است. بهمحض اینکه تیم امنیتی به وقوع نفوذ مشکوک شود، میتواند رمزهای عبور را فوراً تغییر دهد و دسترسی مهاجمان را قطع کند.
اگر مهاجمان بهجای رمز عبور، کوکیهای مرورگر را سرقت کنند، با چالش دیگری روبهرو میشوند. بسیاری از سرویسهای آنلاین اکنون ویژگیهای دستگاه را با کوکی مورد انتظار نشست تطبیق میدهند و اگر کوکی روی دستگاهی ناشناس استفاده شود، دسترسی را مسدود میکنند. علاوه بر این، سازوکارهای محافظت در برابر سرقت کوکی که امسال در مرورگرهای مبتنی بر Chromium، مانند Chrome، Edge و Opera، پیادهسازی شدهاند، این روش را بهطور قابلتوجهی دشوارتر کردهاند.
برای حل این مشکل و حفظ دسترسی مداوم، گروه APT موسوم به ToddyCat که فعالیت اصلی آن جاسوسی است، تکنیک جدیدی توسعه داده است. کارشناسان کسپرسکی این روش را در جریان بررسی یک رخداد شناسایی کردند و آن را Shadow Token via Remote Debug یا STRD نامیدند.
این تکنیک به مهاجمان اجازه میدهد دسترسی پایدار و قابلاعتمادی به صندوق ایمیل قربانی و سایر منابع موجود در Google Workspace برقرار کنند. با اعمال تغییرات جزئی، همین روش میتواند برای هدف قرار دادن سرویسهای دیگری نیز به کار گرفته شود که از طریق احراز هویت OAuth 2.0، دسترسی برنامههای شخص ثالث را فراهم میکنند.
حمله STRD چگونه انجام میشود؟
در مرحله نخست، مهاجمان باید سیستم قربانی را به بدافزار آلوده کنند.
در کارزارهای قبلی، ToddyCat با سوءاستفاده از آسیبپذیریهای شناختهشده در نرمافزارهای سرور و توزیع Loaderهای مخرب از طریق برنامههای پیامرسان، به سازمانها دسترسی اولیه پیدا کرده بود.
ممکن است کارمند مشخصی که هدف مهاجمان قرار گرفته، اصلاً متوجه نفوذ نشود. برای مثال، مهاجم ممکن است ابتدا اطلاعات احراز هویت یک حساب مدیریتی دارای سطح دسترسی بالا را به دست آورد و سپس از آن برای استقرار از راه دور بدافزار روی سیستمهای هدف استفاده کند.
نکته مهم این است که استقرار و اجرای این بدافزار نباید بلافاصله هشدارهای امنیتی ایجاد کند.
پس از فعال شدن، بدافزار حمله STRD را اجرا کرده و سرویس راه دور مهاجمان را از طریق پروتکل OAuth 2.0 به صندوق ایمیل قربانی متصل میکند.
این فرایند به هیچگونه تعامل کاربر نیاز ندارد و هیچ فعالیت قابلمشاهدهای روی صفحه نمایش ایجاد نمیکند. از دید محیط ابری، که در این مورد Google Workspace است، این فعالیت بهگونهای به نظر میرسد که کاربر بهطور قانونی به یک برنامه شخص ثالث اجازه دسترسی به ایمیل یا پشتیبانگیری از دادهها را داده است.
پس از آن، بدافزار میتواند فعالیت خود را متوقف کند و حتی خودش را از روی سیستم حذف کند.
مهاجم با استفاده از توکن OAuth بهدستآمده، همچنان دسترسی مستقیم به صندوق ایمیل را حفظ میکند و دیگر به هیچ ارتباطی با Endpoint قربانی یا شبکه سازمانی نیاز ندارد.
بسته به تنظیمات Google Workspace سازمان، این دسترسی میتواند برای مدت طولانی برقرار بماند و حتی پس از بازنشانی رمز عبور نیز از بین نرود.
مفهوم اصلی Shadow Token via Remote Debug
هسته اصلی این حمله، اتصال به سرویسهای Google Workspace از طریق OAuth 2.0 است.
این یک فرایند کاملاً قانونی است که هر زمان یک برنامه شخص ثالث درخواست دسترسی به دادههای تقویم، ایمیلها یا فایلهای Google Drive را داشته باشد، مورد استفاده قرار میگیرد.
برای مثال، برای نمایش جلسات تقویم در Zoom و تولید خودکار لینکهای کنفرانس، کاربر باید به Zoom اجازه دسترسی به سرویسهای Google را بدهد. به همین ترتیب، پیکربندی یک برنامه ایمیل یا تقویم شخص ثالث نیز نیازمند صدور مجوز است.
در جریان این فرایند احراز هویت، سرویسی که درخواست دسترسی دارد، پنجره جدیدی در مرورگر باز میکند.
در این پنجره، Google Workspace ابتدا از کاربر میخواهد حساب مناسب را انتخاب کند. پس از انتخاب حساب، صفحه بعدی مجوزهای مشخصی را نمایش میدهد که برنامه شخص ثالث درخواست کرده است و کاربر میتواند آنها را تأیید یا رد کند.
برای اینکه این فرایند بدون وقفه انجام شود، کاربر باید از قبل در مرورگر خود وارد سرویسهای Google شده باشد؛ موضوعی که معمولاً در سازمانهای استفادهکننده از Google Workspace صدق میکند.
اگر کاربر وارد حساب نشده باشد، مراحل دیگری برای وارد کردن اطلاعات احراز هویت و تکمیل احراز هویت چندمرحلهای به این فرایند اضافه میشود.
هکرهای ToddyCat برای اجرای مخفیانه یک فرایند احراز هویت دومرحلهای، در شرایطی که کاربر از قبل وارد حساب Google شده است، ابزار مخربی به نام Umbrij توسعه دادهاند.
در مرحله نخست، بدافزار مرورگرهای نصبشده روی سیستم را شناسایی کرده و پوشهای را پیدا میکند که پروفایل فعال کاربر در هر مرورگر در آن ذخیره شده است.
مهاجمان Chrome و Edge را هدف قرار میدهند، زیرا به احتمال زیاد این مرورگرها، مرورگرهای اصلی مورد استفاده در سازمان هستند.
سپس Umbrij کل پوشه پروفایل کاربر را در مسیر دیگری روی همان سیستم کپی میکند.
پس از آن، نمونهای جدید از مرورگر را اجرا کرده و از طریق خط فرمان، مسیر پروفایل کپیشده را به آن معرفی میکند.
ازآنجاکه این پروفایل تکراری حاوی کوکیهای نشست کاربر است، وبسایتهایی که اطلاعات ورود در آنها ذخیره شدهاند، درخواست احراز هویت مجدد نمیکنند.
علاوه بر این، چون این فرایند روی همان سیستمی انجام میشود که مرورگر اصلی روی آن اجرا شده است، سرویسهای آنلاین هیچ ناهنجاریای شناسایی نمیکنند.
سابقه مرور در این نمونه جدید مرورگر نیز در پوشه جداگانه ذخیره میشود و از فعالیتهای حساب اصلی کاربر پنهان میماند.
نکته کلیدی این است که مرورگر در حالت ویژه Debugging اجرا میشود؛ حالتی که معمولاً برای توسعه وب در نظر گرفته شده است.
پنجره مرورگر و رابط کاربری آن اصلاً روی صفحه نمایش ظاهر نمیشوند و مرورگر در حالت Headless اجرا میشود.
در عوض، مرورگر را میتوان از طریق یک پورت Debugging و با استفاده از پروتکل DevTools کنترل کرد. این قابلیت به بدافزار اجازه میدهد فرمان صادر کند و وضعیت صفحه را بخواند.
Umbrij برای هماهنگسازی این اقدامات از Puppeteer، یک کتابخانه قانونی برای خودکارسازی مرورگر، استفاده میکند.
پس از اطمینان از اجرای موفق نمونه مرورگر در حالت Debugging، Umbrij یک صفحه قانونی OAuth مربوط به Google Workspace را در آن باز میکند.
درخواستی که برای Google ارسال میشود، بهگونهای طراحی شده است که ضمن درخواست حداکثر سطح دسترسی، کنترلهای امنیتی اضافی را نیز دور بزند.
بدافزار برای شناسه برنامه، یعنی هویتی که ظاهراً درخواستکننده این مجوزهای گسترده است، خود را بهجای یکی از دو ابزار قانونی زیر معرفی میکند:
- Google Workspace Migration for Microsoft Outlook یا GWMMO
- Google Workspace Sync for Microsoft Outlook یا GWSMO
هنگامی که Google پنجره مربوطه را در مرورگر Headless باز میکند، Umbrij با استفاده از ابزارهای Debugging بهصورت برنامهریزیشده روی نام حساب سازمانی و دکمههای تأیید کلیک میکند.
در نتیجه، Google یک کد مجوز برای برنامه ایجاد میکند.
Umbrij این کد را استخراج و ذخیره کرده و سپس آن را به سرور فرماندهی و کنترل مهاجمان ارسال میکند.
در پایان، مهاجمان این کد مجوز را در زیرساخت خودشان، و نه روی سیستم قربانی، با یک توکن دسترسی OAuth مبادله میکنند.
همین یک توکن برای حفظ دسترسی بلندمدت و نامحدود به صندوق ایمیل کافی است.
چگونه از سرقت توکن OAuth محافظت کنیم؟
اگر یک حساب Google Workspace به خطر افتاده باشد، اقدامات پاسخگویی به رخداد، پس از جمعآوری لاگها و سایر دادههای جرمشناسی موردنیاز برای بررسی، باید شامل مراحل زیر باشد:
- بازنشانی رمز عبور کاربر آسیبدیده
- پایان دادن به تمام نشستهای وب فعال کاربر
- لغو توکنهای OAuth و مجوزهای برنامههای شخص ثالث
- بررسی و حذف دسترسیهای اعطاشده از طریق App Passwordهای قدیمی
علاوه بر این، تیمهای امنیت و فناوری اطلاعات باید مجوزهای صادرشده OAuth را بهصورت منظم بررسی کنند، دسترسیهای غیرقابلتوجیه را لغو کنند و قابلیتهایی را که امکان اعطای مجوزهای بیشازحد یا غیرمجاز فراهم میکنند، محدود سازند.
این موضوع را پیشتر در مقاله مربوط به مسدودسازی دستیارهای هوش مصنوعی ناخواسته بهطور کامل بررسی کردهایم.
چگونه از سوءاستفاده از Shadow Token via Remote Debug جلوگیری کنیم؟
اگرچه کاربران کسپرسکی در برابر ابزار Umbrij محافظت میشوند، تیمهای امنیتی باید بهصورت پیشگیرانه سیاستهایی اجرا کنند که مانع از اجرای مرورگرها در حالت Debugging توسط کاربران عادی شوند.
این قابلیت صرفاً برای توسعهدهندگان وبسایتها و برنامههای تحت وب در نظر گرفته شده است.
این محدودیت را میتوان از طریق Group Policy مربوط به DeveloperToolsAvailability اعمال کرد که برای Chrome و Edge در دسترس است.
همچنین در SIEM یا XDR خود کنترلهایی برای شناسایی اجرای نمونههای مرورگر با پورت Debugging فعال پیکربندی کنید.
ثبت چنین رویدادی میتواند شاخص قدرتمندی از استفاده از این تکنیک حمله باشد.