هکرها صفحات فیشینگ را داخل مرورگر قربانی میسازند؛ حمله با Microsoft OAuth و Teams
هکرها با سوءاستفاده از Microsoft OAuth و Teams صفحات فیشینگ را با Blob URL مستقیماً داخل مرورگر قربانی ایجاد میکنند؛ روشی جدید برای دور زدن ابزارهای امنیتی.
مهاجمان سایبری روش جدیدی برای اجرای حملات فیشینگ ابداع کردهاند که شناسایی آنها را دشوارتر میکند. در این روش، مهاجمان قربانی را ابتدا از طریق زیرساختهای واقعی Microsoft OAuth و Microsoft Teams عبور میدهند و سپس صفحه ورود جعلی را مستقیماً داخل مرورگر خود قربانی ایجاد میکنند.
پژوهشگران Barracuda میگویند در این حمله، صفحه فیشینگ برخلاف روشهای سنتی از یک وبسرور معمولی تحویل داده نمیشود؛ بلکه محتوای مخرب با استفاده از Blob URL داخل مرورگر قربانی ساخته میشود.
Blob URL چیست و چرا تشخیص حمله را دشوار میکند؟
Blob URL یک آدرس موقت است که مرورگر برای دسترسی به دادههای ذخیرهشده در حافظه یا فضای محلی ایجاد میکند. بنابراین، بهجای اینکه صفحه فیشینگ از یک دامنه مشخص روی اینترنت بارگذاری شود، بخش اصلی محتوای آن میتواند مستقیماً در محیط مرورگر قربانی تولید و نمایش داده شود.
این تکنیک یک مزیت مهم برای مهاجمان دارد: بسیاری از ابزارهای امنیتی و سامانههای تشخیص فیشینگ به بررسی URL، دامنه و مقصد لینکها متکی هستند. اما در اینجا، صفحه نهایی فیشینگ ممکن است اصلاً از یک وبسایت مشکوک بارگذاری نشده باشد.
حمله با یک ایمیل جعلی DocuSign آغاز میشود
زنجیره حمله با یک ایمیل که ظاهراً از طرف DocuSign ارسال شده آغاز میشود. این ایمیل حاوی یک دعوتنامه تقویم بهعنوان فایل پیوست است.
با این حال، فایل دعوتنامه خودش محتوای مخرب اصلی نیست. هدف آن این است که ایمیل کاملاً شبیه یک درخواست معمول برای شرکت در جلسه یا رویداد به نظر برسد.
نکته مهمتر این است که لینک موجود در این زنجیره مستقیماً به یک زیرساخت مشکوک اشاره نمیکند. مهاجمان از یک Microsoft OAuth endpoint واقعی استفاده میکنند تا اعتماد قربانی را جلب کرده و احتمال شناسایی حمله را کاهش دهند.
Microsoft Teams به بخشی از زنجیره فیشینگ تبدیل میشود
پس از کلیک قربانی، یک پارامتر Redirect دستکاریشده او را به Microsoft Teams هدایت میکند.
Teams نیز یک منبع را از دامنه خارجی cdn.bloom[.]io بارگذاری میکند. در ادامه این زنجیره، صفحه فیشینگ نهایی بهجای اینکه مستقیماً از یک وبسایت روی اینترنت دریافت شود، با استفاده از یک Blob URL روی سیستم خود قربانی ساخته و نمایش داده میشود.
به این ترتیب، مهاجمان از چند سرویس و زیرساخت معتبر برای عبور از مراحل اولیه حمله استفاده میکنند و در نهایت محتوای فیشینگ را داخل مرورگر قربانی قرار میدهند.
Service Worker و iframe؛ اجزای مهم حمله
پس از بارگذاری صفحه، کد مخرب یک Service Worker ثبت میکند و بخشی از منطق خود را نیز داخل یک iframe sandboxed اجرا میکند.
این دو مؤلفه به مهاجمان اجازه میدهند ارتباط پویاتری با صفحه فیشینگ برقرار کنند. برای مثال، سرور مهاجم میتواند از طریق پیامرسانی مرورگر، دستورهای جدیدی را به صفحه ارسال کند.
در نتیجه، محتوای صفحه لزوماً به یک سناریوی از پیش تعیینشده محدود نیست و مهاجمان میتوانند بدون تکیه بر Redirectهای ثابت، آنچه قربانی مشاهده میکند را تغییر دهند.
یک پلتفرم فیشینگ مدیریتشده
پژوهشگران Barracuda میگویند وجود تنظیمات مخفی مربوط به Command and Control (C2) نشان میدهد این حمله احتمالاً یک صفحه فیشینگ مستقل نیست.
در عوض، ساختار آن بیشتر شبیه یک پلتفرم فیشینگ متمرکز است که مهاجمان میتوانند از طریق آن صفحات را برای تعداد زیادی قربانی بهصورت همزمان مدیریت، بهروزرسانی و هدایت کنند.
این ویژگی باعث میشود زیرساخت حمله انعطافپذیرتر باشد و مهاجمان بتوانند رفتار صفحه را متناسب با شرایط تغییر دهند.
چرا این نوع فیشینگ خطرناکتر است؟
در حملات فیشینگ سنتی، تیمهای امنیتی معمولاً به نشانههایی مانند دامنه جعلی، URL مشکوک یا وبسایت مشابه سرویس اصلی توجه میکنند.
اما در این کمپین، مهاجمان تلاش کردهاند همین نشانههای شناختهشده را حذف کنند. قربانی ابتدا با Microsoft OAuth و Microsoft Teams واقعی مواجه میشود و صفحه جعلی نهایی نیز در قالب یک Blob URL داخل مرورگر ایجاد میشود.
در نتیجه، صرف مسدود کردن دامنههای شناختهشده فیشینگ دیگر برای مقابله با چنین حملاتی کافی نیست.
توصیه Barracuda برای مقابله با حملات جدید
Barracuda به سازمانها توصیه کرده است جریانهای OAuth و زنجیره Redirectها را با دقت بیشتری بررسی کنند؛ بهخصوص زمانی که مقصد نهایی با چیزی که کاربر انتظار دارد مطابقت ندارد.
بررسی فعالیتهای مرتبط با Blob URL در فرایندهای ورود و احراز هویت و همچنین شناسایی Service Workerهایی که با محتوای خارجی ارتباط دارند نیز میتواند به تشخیص این نوع حملات کمک کند.
این شرکت همچنین استفاده از روشهای MFA مقاوم در برابر فیشینگ مانند کلیدهای FIDO2 و Passkey را توصیه کرده است.
از سوی دیگر، ابزارهای امنیت ایمیل باید کل مسیر یک لینک را بررسی کنند، نه اینکه فقط اولین مقصد آن را ارزیابی کنند. آموزش کارکنان نیز اهمیت زیادی دارد؛ بهویژه اینکه کاربران باید حتی درخواستهای مربوط به امضای اسناد را، اگر از طریق زیرساختهای معتبر مایکروسافت انجام میشوند، بدون بررسی نپذیرند.
فیشینگ دیگر فقط یک وبسایت جعلی نیست
به گفته تحلیلگران Barracuda، این کمپین نشان میدهد فیشینگ در حال فاصله گرفتن از الگوی قدیمی «یک وبسایت جعلی با دامنه مشکوک» است.
مهاجمان اکنون میتوانند از زیرساختهای قانونی، OAuth، Redirectهای چندمرحلهای، Blob URL، Service Worker و iframe در کنار یکدیگر استفاده کنند تا بسیاری از شاخصهایی که تیمهای امنیتی سالها برای شناسایی فیشینگ به آنها تکیه کردهاند، از بین برود.
به همین دلیل، سازمانها باید بهجای تمرکز صرف بر مسدود کردن URLهای شناختهشده، روی تشخیص رفتارهای مخرب و تقویت کنترلهای مبتنی بر هویت تمرکز کنند.