کارزار EvilTokens با فیشینگ device code حساب‌ها را می‌دزدد

کارزار فیشینگ «EvilTokens» از فوریه 2026 ظاهر شد و در مدت کوتاهی به یکی از رایج‌ترین پلتفرم‌های phishing-as-a-service بدل شد که با تکیه بر قابلیت‌های هوش مصنوعی، سناریوهای فریب متنی متناسب با هدف تولید می‌کرد و با تحلیل خودکار صندوق‌های ایمیلِ در معرض خطر، قربانیان باارزش را شناسایی می‌کرد. این پلتفرم مجرمانه با محوریت هوش مصنوعی، کمپین‌های پیشرفته business email compromise را تسهیل کرد و به نفوذ به بیش از 12,000 صندوق ایمیل در بیش از 10,000 سازمان در سراسر جهان انجامید. EvilTokens با سوءاستفاده از جریان احراز هویت device code، ربایش توکن و دسترسی در مقیاس سازمانی را ممکن کرد و با خودکارسازی چندین بخش از زنجیره حمله، سرعت و بازده عملگران تهدید را به‌طرز محسوسی افزایش داد.

در مرکز عملیات EvilTokens، بسته‌ای از قالب‌های فیشینگ و صفحات فرود از پیش‌ساخته همراه با یک دستیار مبتنی بر هوش مصنوعی عرضه می‌شد که به کاربر مخرب در چینش ایمیل‌های هدف‌محور یاری می‌رساند. توکن‌های سرقت‌شده برای استخراج ایمیل و ماندگاری در حساب‌های قربانی به کار می‌رفتند؛ ماندگاری اغلب از طریق ساخت قوانین مخرب در صندوق ایمیل که ارتباطات را پنهان می‌کنند برقرار می‌شد. در برخی موارد، از همین توکن‌ها برای اعطای دسترسی به دستگاه‌های جدید به صندوق قربانی استفاده می‌شد که روشی ماندگارتر برای حفظ حضور مخرب است. عامل تهدیدی که توسعه و پشتیبانی کیت فیشینگ EvilTokens را بر عهده داشت با نام ⁦Storm-2992⁩ رهگیری می‌شود.

پس از نفوذ اولیه، EvilTokens به عملگران تهدید امکان می‌داد با اتکا به دستیارهای هوش مصنوعی محتوای صندوق‌های ایمیل قربانی را غربال و بر اساس محتوای دردسترس، متن فیشینگ مهندسی‌شده تولید کنند. همچنین، انجام شناسایی با Microsoft Graph برای ترسیم ساختار سازمانی و مجوزها تسهیل می‌شد تا تا زمانی که توکن معتبر است، دسترسی ادامه یابد و حرکت جانبی محتمل شود. در حالی که فیشینگ متمرکز بر توکن پدیده‌ای تازه نیست، طی سال‌های اخیر هم‌زمان با فراگیری راهکارهای 인증 چندمرحله‌ای، بسامد و صنعتی‌سازی آن افزایش چشمگیری پیدا کرده است.

برای گریز از تشخیص، EvilTokens از یک زنجیره تحویل چندمرحله‌ای استفاده می‌کرد تا از درگاه‌های ایمیل سنتی و امنیت سمت کاربر عبور کند. اهداف با ایمیل‌های فریبنده‌ای با 44 تم متفاوت، از جمله «صورتحساب»، «درخواست پیشنهاد» (RFP)، یا «فایل اشتراکی»، جذب می‌شدند. این ایمیل‌ها حاوی URLهای مخرب، فایل‌های PDF و فایل‌های HTML بودند. قربانیان در صنایع گوناگون شامل پخش عمده، ساخت‌وساز، خدمات مالی، املاک و مستغلات، آموزش عالی و سلامت، هدف قرار گرفتند و بیشترین تراکم فعالیت مشاهده‌شده در ایالات متحده، کانادا، بریتانیا، استرالیا، هند و فرانسه بود. در هماهنگی با شرکا، واحد جرایم دیجیتال شرکت Microsoft موسوم به DCU اختلال هماهنگ‌شده‌ای در بخشی از زیرساخت مورد استفاده برای راهبری سرویس EvilTokens ایجاد کرد.

فیشینگ device code چیست

یکی از قابلیت‌های محوری EvilTokens سوءاستفاده از «device code authentication» است؛ این یک جریان مشروع OAuth برای دستگاه‌هایی با رابط محدود است، مانند تلویزیون‌های هوشمند، پرینترها، دستگاه‌های Teams و تجهیزات کنفرانس که امکان ورود تعاملی استاندارد ندارند. در این مدل، کاربر کدی کوتاه را روی دستگاهی که می‌کوشد از آن وارد شود می‌بیند و دستور می‌گیرد آن کد را در مرورگرِ دستگاهی دیگر وارد کند تا احراز هویت تکمیل شود.

این جریان برای چنین سناریوهایی سودمند است اما مصالحه امنیتی به همراه دارد. از آنجا که احراز هویت روی دستگاهی جداگانه تکمیل می‌شود، نشست آغازکننده درخواست، به‌صورت قوی به زمینه اصلی کاربر متصل نیست. عملگران تهدید از همین ویژگی برای دور زدن حفاظت‌های سنتی MFA سوءاستفاده کرده‌اند؛ به این معنا که احراز هویت را از نشست مبدأ جدا می‌کنند و در لفافه فریب‌های مهندسی اجتماعی، درخواست تأیید جریان device code را به‌عنوان نیازی دیگر جا می‌زنند.

در فیشینگ device code، عملگر تهدید خود را در میانه این فرایند وارد می‌کند. به جای آن‌که دستگاهی مشروع درخواست دسترسی بدهد، عملگر تهدید جریان را آغاز می‌کند و کد را از طریق فریب فیشینگی به کاربر می‌دهد. وقتی کاربر کد را وارد می‌کند، ناآگاهانه نشست عملگر تهدید را تأیید می‌کند و بدون آشکار کردن گذرواژه، دسترسی به حساب اعطا می‌شود. توصیه می‌شود جریان device code هرجا ممکن است مسدود شود. اگر سازمان به‌دلیل وجود دستگاه‌های Teams به آن نیاز دارد، استثنا را به حساب‌های منبع همان دستگاه‌های Teams محدود و «Device Registration Service» را در سیاست Conditional Access از استثنا خارج کند.

در آوریل 2026، یک کمپین فیشینگ هم‌راستا با EvilTokens رصد شد که با استفاده از پلتفرم‌های خودکارسازی، هزاران گره polling یکتا و کوتاه‌عمر برپا می‌کرد. این رویکرد به عملگران تهدید اجازه داد منطق پشتی (Node.js) پیچیده‌ای به کار گیرند که از شناسایی مبتنی بر امضا یا الگو عبور کند. این زیرساخت در سراسر حمله، از تولید پویا برای device code تا فعالیت‌های پس از نفوذ، مورد بهره‌برداری قرار گرفت.

پلتفرم و عملیات EvilTokens

توزیع و پشتیبانی همکاران

فروش و پشتیبانی سرویس‌های EvilTokens توسط عامل تهدیدی با نام ⁦Storm-2992⁩ در کانال‌های Telegram انجام می‌شد. مجرمان سایبری به‌طور فزاینده به پیام‌رسان‌هایی مانند Telegram گرایش پیدا می‌کنند، زیرا ناشناس‌بودن، دسترسی چندسکویی، اشتراک فایل و امکان اطلاع‌رسانی یک‌به‌انبوه را در قالب کانال‌ها فراهم می‌کند. این عامل تهدید از Telegram برای تبلیغ کیت فیشینگ، اعلام به‌روزرسانی‌ها، هماهنگی با مشترکان و ارائه پشتیبانی مشتری استفاده می‌کرد.

کیت‌های فیشینگ EvilTokens با قیمت اولیه 1,500 دلار آمریکا فروخته می‌شد و برای دسترسی مستمر به کیت و پنل کنترلی، اشتراک ماهانه 500 دلاری مطالبه می‌شد. بسته علاوه بر هسته کیت، محصولات افزوده‌ای نیز ارائه می‌کرد که شامل Antibot redirector، B2B Sender، Office 365 Capture Link و Simple Mail Transfer Protocol (SMTP) Sender بود. هر یک از این محصولات، هزینه جداگانه برای دسترسی 30 روزه داشتند. سازوکار فروش و راهبری از طریق ربات‌های فروش و پشتیبانی در Telegram انجام می‌گرفت.

پنل مشتری و پیکربندی کمپین

پنل EvilTokens مولفه‌های اصلی لازم برای پشتیبانی کمپین‌های فیشینگ را یکجا در دسترس مشترکان می‌گذاشت؛ از جمله قالب‌های پیش‌ساخته، فایل‌های پیوست برای قالب‌های رایج فریب، پیکربندی دامنه و میزبانی، منطق بازگردانی (redirect) و رهگیری قربانی. پس از ورود، مشترک با یک داشبورد و گزینه‌های متعدد مواجه می‌شد. نخست باید روش استقرار را برمی‌گزید: «Cloudflare Workers/Bunny» یا «PHP Hosting». سپس فهرستی از گزینه‌های استقرار ارائه می‌شد که شامل Capture Mode، Layout & Template، Code Display Style، Page Language، CAPTCHA، AI Mode و Captured Text بود. این گزینه‌ها امکان سفارشی‌سازی عمیق نحوه استقرار را فراهم می‌کردند.

در کنار این، مجموعه‌ای از تنظیمات و راهنمایی‌های تکمیلی برای مدیریت توکن‌های به‌دست‌آمده در پنل تعبیه شده بود. به‌محض ربایش توکن‌ها، مشترک به دسترسی کامل به حساب ایمیل قربانی دست می‌یافت و قابلیت‌هایی مانند تشخیص مدیر (admin detection)، نوسازی خودکار توکن (token auto-refresh) و پویش خودکار صندوق ورودی بر مبنای کلیدواژه‌ها با اعلان در Telegram فعال می‌شد. بخش Essential Tools نیز اطلاعات محصولات افزوده، لینک دریافت یا خرید آنها و ویدئوهای آموزشی را ارائه می‌کرد. برنامه ارجاع با پاداش رمزارزی برای معرفی مشتریان جدید نیز در پنل پیش‌بینی شده بود.

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

ایمیل‌های فیشینگ و زنجیره حمله EvilTokens

EvilTokens با اتکا به هوش مصنوعی، فریب‌هایی شخصی‌سازی‌شده تولید می‌کرد که با نقش کاربر هدف هم‌راستا بود. تم‌های به‌کاررفته شامل سرویس‌های امضای اسناد، سرویس‌های ابری Microsoft، خدمات ثالث مانند cloud identity، میزبانی فایل و پرداخت/صورتحساب، و نیز سرویس‌های متفرقه مانند voicemail و eFax بود. همچنین در نمونه‌های مشاهده‌شده، متن‌هایی مانند «پیشنهادهای مناقصه ساخت‌وساز»، «توافق‌های مشارکت تجاری»، «مزایا و جبران خدمات کارکنان» و «اعلان انقضای گذرواژه» در ایمیل‌های EvilTokens به چشم می‌خورد.

زنجیره حمله با تعامل کاربر با پیوست یا URL مخربِ نهفته در یک فریب پرفشار آغاز می‌شد، برای نمونه «Action Required: Password Expiration». با کلیک کاربر روی لینک یا پیوست، او به صفحه‌ای هدایت می‌شد که اسکریپت خودکاری در پس‌زمینه اجرا می‌کرد. این اسکریپت در زمان واقعی با ارائه‌دهنده هویت Microsoft تعامل برقرار می‌کرد تا یک device code زنده تولید کند. کد روی صفحه کاربر نمایش داده می‌شد؛ در کنار آن دکمه «Copy Code» و نیز دکمه‌ای مانند «Continue» یا «Continue with Microsoft» قرار داشت که با کلیک آن، کاربر به پورتال رسمی microsoft.com/devicelogin منتقل می‌شد.

پس از ارائه کد و گشودن URL مشروع microsoft.com/devicelogin، اسکریپت وارد وضعیت polling می‌شد و با تابع checkStatus() پنجره 15 دقیقه‌ای مجاز را در زمان واقعی پایش می‌کرد. هر 3 تا 5 ثانیه با setInterval، اسکریپت به نقطه انتهایی /state متعلق به عملگر تهدید پینگ می‌زد و شناسه محرمانه نشست را برای اعتبارسنجی اینکه آیا کاربر احراز هویت را تکمیل کرده است یا نه، ارسال می‌کرد. در حالی که کاربر هدف در وب‌سایت واقعی Microsoft کد را وارد می‌کرد، چرخه وضعیت «pending» برمی‌گرداند.

برای کاستن از زحمت کاربر و افزایش نرخ موفقیت، اسکریپت عملگر معمولاً device code تولیدشده را به‌طور خودکار در کلیپ‌بورد کپی می‌کرد. وقتی کاربر به صفحه رسمی ورود می‌رسید، کد را جای‌گذاری می‌کرد. اگر نشست فعالی نداشت، از او گذرواژه و سپس MFA مطالبه می‌شد. اگر از پیش وارد شده بود، صرفاً جای‌گذاری کد و تأیید درخواست، نشست عملگر را در پشت‌صحنه و بلافاصله احراز هویت می‌کرد.

مرحله پایانی بسته به هدف‌های مشخص هر عملگر متفاوت بود. در برخی موارد، ظرف 10 دقیقه پس از نفوذ، دستگاه‌های جدیدی ثبت شد تا «Primary Refresh Token (PRT)» برای ماندگاری بلندمدت تولید شود. در سناریوهای دیگر، مهاجم چند ساعت منتظر می‌ماند و سپس قوانین مخرب صندوق ایمیل می‌ساخت یا داده‌های حساس ایمیل را استخراج می‌کرد تا از کشف فوری بگریزد. در عمل، EvilTokens عملگر را قادر می‌کرد فراتر از توانمندی‌های معمول خود فیشینگ کند و اقدامات پسینی را انجام دهد؛ از جمله فیشینگ انبوه کاربران و اجرای عملیات در زمان دلخواه.

تکنیک‌های دورزدن دفاع

EvilTokens از خط لوله تحویل چندمرحله‌ای برای عبور از درگاه‌های ایمیل و امنیت نقطه پایانی بهره می‌برد. صفحات فیشینگ ارائه‌شده به کاربر از حیث پیچیدگی و تکنیک‌های گریز متفاوت بود و لایه‌ای از سفارشی‌سازی بسته به اپراتور و ابزارهای مورد استفاده او به آن افزوده می‌شد. تکنیک‌های متداول عبارت بود از لینک‌های تصویری (تصاویری که به URL متصل می‌شوند)، طرحواره‌های بازگردانی چندمرحله‌ای، و پیوست‌هایی که تحویل چندمرحله‌ای دارند. در صفحات فرود نیز شگردهایی مانند CAPTCHA جعلی یا سرویس‌های «تأیید» که از کاربر تعامل می‌طلبیدند پیش از آن‌که محتوای فیشینگ نمایش داده شود، به کار گرفته می‌شد.

برای گریز بیشتر از اسکنرهای خودکار URL و sandboxها، مهاجمان گاهی به صفحه فیشینگ نهایی پیوند مستقیم نمی‌دادند و به‌جای آن، از سلسله‌ای از بازگردانی‌ها در دامنه‌های مشروعِ نقب‌زده‌شده و پلتفرم‌های «serverless» با اعتبار دامنه بالا استفاده می‌کردند. اتکا به سوءاستفاده از Vercel (.vercel.app)، Cloudflare Workers (.workers.dev) و AWS Lambda برای میزبانی منطق بازگردانی به‌طور برجسته مشاهده شد. با استفاده از این دامنه‌ها، ترافیک فیشینگ در میان ترافیک ابر سازمانی مشروع محو می‌شود و از محرک‌های ساده فهرست‌سیاه دامنه می‌گریزد.

دسترسی پس از نفوذ و سوءاستفاده از حساب

پس از به‌دست‌آوردن توکن‌های احراز هویت، تمرکز مهاجم به فعالیت‌های پس‌ازنفوذ معطوف می‌شد؛ اقداماتی برای حفظ و گسترش دسترسی و بیرون‌بردن داده. این دسترسی می‌تواند برای ارسال ایمیل‌های بیشتر به‌صورت داخلی و به مخاطبان بیرونی به‌کار رود و امکان می‌دهد که فیشینگ از جانب تماس‌های به‌ظاهر مورد اعتماد انجام شود. در یک رخداد مشاهده‌شده، حمله به استخراج ایمیل و ماندگاری حساب از طریق قوانین inbox ساخته‌شده با Microsoft Office پیش رفت. روال شامل پالایش کاربران نقب‌زده و گزینش اهداف بود:

• شناسایی هدف‌های باارزش. با تکیه بر قابلیت AI در EvilTokens، مهاجم کاربران در نقش‌های مالی، مدیریتی یا اداری را از میان مجموعه کاربران نقب‌زده‌شده برگزید.
• شتاب‌دهی به شناسایی. بلافاصله پس از دسترسی به Microsoft Graph برای شناسایی، ساختارهای داخلی سازمانی و مجوزهای حساس به‌صورت برنامه‌پذیر ترسیم شد.
• استخراج مالی هدفمند. تهاجمی‌ترین فعالیت‌ها برای کاربرانی با اختیار مالی ذخیره شده بود. در این پروفایل‌ها، مهاجم با واکاوی عمیق مکاتبات ایمیل، به‌دنبال هدف‌های باارزش و اطلاعات حساسی مانند جزئیات حواله‌ها، صورتحساب‌های در انتظار پرداخت و مکاتبات مدیران می‌گشت.

کِی‌ها، کجاها و چه کسانی هدف بودند

کمپین‌های مبتنی بر EvilTokens صنایع متعددی را تحت تأثیر قرار داد: پخش عمده، ساخت‌وساز، خدمات مالی، املاک و مستغلات، آموزش عالی و سلامت. از منظر جغرافیایی، بیشترین تراکم فعالیت قربانیان در ایالات متحده، کانادا، بریتانیا، استرالیا، هند و فرانسه مشاهده شد. آمار کلان نشان داد که بیش از 12,000 صندوق ایمیل در بیش از 10,000 سازمان در سراسر جهان نقب زده شدند.

راهنمای کاهش ریسک و محافظت

دفاع مؤثر در برابر EvilTokens و تهدیدهای فیشینگ adversary-in-the-middle مشابه، به رویکردی چندلایه متکی است که کنترل‌های فنی را با آگاهی کاربران ترکیب می‌کند. اقدامات زیر برای سخت‌سازی دفاع توصیه می‌شود:

• جریان device code را فقط در مواقع ضرورت مجاز کنید. در حالت پیش‌فرض، این جریان را مسدود کنید. در صورت نیاز، استثنا را صرفاً برای حساب‌های منبع دستگاه‌های Teams تعریف و «Device Registration Service» را از استثنا در سیاست Conditional Access کنار بگذارید.
• کاربران را درباره تکنیک‌های رایج فیشینگ آموزش دهید. اعلان‌های ورود باید برنامه‌ای را که کاربر واقعاً قصد ورود به آن را دارد، به‌صراحت نشان دهند. تعاملات Azure سال‌ها است از کاربر می‌خواهد تأیید کند که در حال ورود به همان برنامه مورد انتظار است؛ این نشانه در صفحات فیشینگ غالباً غایب است.
• به پیام‌هایی با برچسب «[EXTERNAL]» که حاوی لینک‌های مشکوک هستند با تردید بنگرید. از ورود به سرویس‌هایی که فرستنده آنها برای شما آشنا نیست پرهیز کنید.
• سیاست‌های ضد فیشینگ را پیکربندی کنید. این سیاست‌ها با کشف فرستنده‌های جعل‌شده، تلاش‌های تقلید و دیگر تکنیک‌های فریبنده، محافظت می‌کنند.
• در Defender for Office 365، قابلیت Safe Links را فعال کنید. اسکن Safe Links از سازمان در برابر لینک‌های مخربِ به‌کاررفته در فیشینگ و سایر حملات محافظت می‌کند و می‌تواند هشدارهای پر‌اطمینان فیشینگ device code تولید کند.
• در صورت شناسایی مظنون به فیشینگ device code، راهنمای «واکنش به حساب ایمیل نقب‌زده» را دنبال کنید؛ توکن‌های refresh کاربر را با فراخوانی revokeSign-inSessions ابطال کنید و با سیاست Conditional Access، کاربر را مجبور به احراز هویت مجدد کنید. با توجه به این‌که ابطال نشست به‌صورت پیش‌فرض معمولاً فقط refresh token را باطل می‌کند و access token موجود تا حدود یک ساعت معتبر می‌ماند، برای جلوگیری فوری از سوءاستفاده از این پنجره، حسابِ نقب‌زده را موقتاً غیرفعال کنید.
• آستانه Advanced Phishing Threshold را به مقدار 2 یا 3 افزایش دهید.
• قابلیت Zero-hour auto purge (ZAP) را در Microsoft Defender for Office 365 فعال کنید تا ایمیل‌های ارسالی در پاسخ به اطلاعات تهدید تازه قرنطینه شوند و پیام‌های مخرب که پیش‌تر تحویل شده‌اند، به‌صورت بازگشتی خنثی شوند.
• کاربران را به استفاده از Microsoft Edge و مرورگرهایی که Microsoft Defender SmartScreen را پشتیبانی می‌کنند ترغیب کنید تا وب‌سایت‌های مخرب شامل سایت‌های فیشینگ و میزبان malware مسدود شوند.
• برای ساختن هشدار، ایجاد قوانین مشکوک inbox را پایش کنید تا شواهد BEC و کمپین‌های فیشینگ سریع‌تر شناسایی و رسیدگی شوند.

علاوه بر این اقدام‌ها، به‌کارگیری بهترین رویه‌های زیر برای تقویت دفاع سازمان در برابر فیشینگ و سرقت اعتبارنامه توصیه می‌شود:

• سیاست sign-in risk را پیاده‌سازی کنید تا پاسخ به ورودهای پرخطر خودکار شود. بر پایه سطح ریسک (high/medium/low)، دسترسی را مسدود یا MFA را اجباری کنید. در ریسک بالا و ارزیابی فعال Conditional Access، دسترسی کاربر فوراً لغو و او مجبور به احراز هویت مجدد می‌شود. برای پایش منظم، از گزارش‌های Risky sign-in استفاده کنید.
• MFA را الزامی کنید و از روش‌های مقاوم در برابر فیشینگ مانند FIDO Tokens یا Microsoft Authenticator با passkey استفاده کنید. روش‌های مبتنی بر تلفن را به‌دلیل ریسک SIM-jacking به‌کار نبرید.
• با استفاده از Conditional Access در Microsoft Entra، احراز هویت legacy را مسدود کنید؛ این پروتکل‌ها قابلیت اجبار MFA ندارند و در معرض سوءاستفاده‌اند.
• مدیریت هویت سازمان را متمرکز کنید. در محیط‌های ترکیبی، دایرکتوری‌های on-premises را با دایرکتوری‌های ابری یکپارچه کنید. اگر از مدیریت هویت ثالث استفاده می‌کنید، اطمینان حاصل کنید که داده‌ها در SIEM لاگ می‌شوند یا به Microsoft Entra متصل‌اند تا پایش مرکزی دسترسی‌های مخرب هویت ممکن شود. مزیت دیگر، تسهیل SSO و تغذیه مدل‌های یادگیری ماشین Entra ID با همه داده‌های هویتی برای تفکیک سریع‌تر میان دسترسی مشروع و مخرب است. توصیه می‌شود به‌هنگام همگام‌سازی، همه حساب‌ها به‌جز حساب‌های مدیریتی و بسیار ممتاز همگام شوند تا مرزی میان محیط on-premises و ابر حفظ شود.
• اگر نشانه‌هایی مانند هشدارها دال بر به‌خطر افتادن refresh token کاربر وجود دارد، دستگاه را غیرفعال و همه refresh tokenهای موجود را باطل کنید. غیرفعال‌سازی دستگاه، PRT را بی‌اثر و ابطال refresh tokenها همه توکن‌های صادرشده با استفاده از PRT را بی‌اعتبار می‌کند. برای رسیدگی به هشدارهای مرتبط با هویت‌های نقب‌زده، گام‌های playbook «token theft» را دنبال کنید.
• حساب‌ها را با «بهداشت اعتبارنامه» ایمن کنید: اصل حداقل امتیاز را اعمال و فعالیت حساب‌های ممتاز را در محیط Entra ID ممیزی کنید تا سرعت و دامنه مهاجم کاسته شود.
• Network protection و web protection را فعال کنید تا برنامه‌ها یا کاربران به دامنه‌ها و محتوای مخرب در اینترنت دسترسی نیابند.

پوشش و تشخیص‌های Microsoft Defender

سامانه‌های Microsoft Defender، کشف، پیشگیری، تحقیق و پاسخ را در دستگاه‌ها، هویت، ایمیل و برنامه‌ها هماهنگ می‌کنند تا در برابر حملاتی مانند تهدید حاضر محافظت یکپارچه فراهم کنند. استفاده از Safe Links و Microsoft Entra ID Protection هشدارهای پر‌اطمینان فیشینگ device code را در Defender تقویت می‌کند. جدول زیر تاکتیک‌ها، فعالیت‌های مشاهده‌شده و پوشش متناظر در Microsoft Defender را خلاصه می‌کند.

تاکتیک	فعالیت مشاهده‌شده	پوشش در Microsoft Defender
Initial access	Device code authentication	Microsoft Defender for Identity – Anomalous OAuth device code authentication activity
Credential access	Token theft following device code authentication	Microsoft Defender for Identity – Anomalous token exchange following device code authentication؛ Microsoft Defender XDR – User account compromise via OAuth device code phishing – Suspicious Azure authentication through possible device code phishing
Persistence	Device registration following anomalous device code authentication	Microsoft Defender for Identity – Suspicious Entra device join or registration؛ Microsoft Defender XDR – Device registration after potential device code phishing
Discovery	Anomalous volume of Microsoft Graph API requests following device code flow authentication	Microsoft Defender XDR – Anomalous Microsoft Graph API activity after potential device code phishing – Anomalous Microsoft Graph API POST activity after potential device code phishing
Defense evasion	Malicious inbox rule created after anomalous device code authentication	Microsoft Defender XDR – Suspicious inbox rule created after potential device code phishing sign-in

Microsoft Security Copilot و عامل‌های مبتنی بر هوش مصنوعی

محصول Microsoft Security Copilot که در Microsoft Defender تعبیه شده است، قابلیت‌های هوش مصنوعی برای تیم‌های امنیتی فراهم می‌آورد تا رخدادها را خلاصه، فایل‌ها و اسکریپت‌ها را تحلیل و هویت‌ها را جمع‌بندی کنند؛ همچنین پاسخ‌های هدایت‌شده، خلاصه‌های دستگاه، کوئری‌های شکار و گزارش رخداد تولید کنند. افزون بر این، امکان استقرار عامل‌های هوش مصنوعی برای اجرای وظایف امنیتی به‌شکل کارآمد وجود دارد؛ از جمله:

• Threat Intelligence Briefing agent.
• Phishing Triage agent.
• Threat Hunting agent.
• Dynamic Threat Detection agent.

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

کوئری‌های شکار تهدید در Microsoft Defender XDR

مشتریان Microsoft Defender XDR می‌توانند از کوئری‌های زیر برای کشف تلاش‌های فیشینگ بهره ببرند. برای بررسی داده خام تا 30 روز و یافتن نشانگرهای بالقوه مرتبط با EvilTokens، به Advanced hunting > Query بروید و بازه را روی «Last 30 days» تنظیم کنید. اگر کوئری، بینش‌های ارزشمند درباره رفتار مخرب یا غیرعادی ارائه داد، می‌توانید از همان کوئری، «custom detection rule» بسازید تا این بینش‌ها به‌صورت هشدارهای سفارشی سطح‌بندی شود. برای این کار کوئری را اجرا و «Create detection rule» را انتخاب کنید.

Suspicious URL clicked

این کوئری سیگنال‌های Microsoft Defender for Office 365 را با داده‌های هویت Microsoft Entra ID هم‌بست می‌کند و رویداد مرتبط با باز شدن مرورگر برای URL مخرب را در Microsoft Defender XDR می‌یابد.

AlertInfo | where ServiceSource =~ "Microsoft Defender for Office 365" | join ( AlertEvidence | where EntityType =="Url" | project AlertId, RemoteUrl ) on AlertId | join ( AlertEvidence | where EntityType =="MailMessage" | project AlertId, NetworkMessageId ) on AlertId // Get the unique NetworkMessageId for the email containing the Url | distinct RemoteUrl, NetworkMessageId | join EmailEvents on NetworkMessageId // Get the email RecipientEmailAddress and ObjectId from the email | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId | join kind = inner IdentityInfo on $left.RecipientObjectId == $right.AccountObjectId | distinct RemoteUrl, NetworkMessageId, RecipientEmailAddress , RecipientObjectId, OnPremSid // Get the Url click event on the recipient device. | join kind = inner (DeviceEvents | where ActionType == "BrowserLaunchedToOpenUrl"| where isnotempty(RemoteUrl) | project UrlDeviceClickTime = Timestamp , UrlClickedByUserSid = RemoteUrl, InitiatingProcessAccountSid, DeviceName, DeviceId, InitiatingProcessFileName ) on $left.OnPremSid == $right.InitiatingProcessAccountSid and $left.RemoteUrl == $right.UrlClickedByUserSid | distinct UrlDeviceClickTime, RemoteUrl, NetworkMessageId, RecipientEmailAddress, RecipientObjectId, OnPremSid, UrlClickedByUserSid, DeviceName, DeviceId, InitiatingProcessFileName | sort by UrlDeviceClickTime desc

Determine successfully delivered phishing emails to Inbox/Junk folder

این کوئری تهدیدهایی را که با موفقیت به پوشه Inbox یا Junk تحویل شده‌اند شناسایی می‌کند.

EmailEvents | where isnotempty(ThreatTypes) and DeliveryLocation in~ ("Inbox/folder","Junk folder") | extend Name = tostring(split(SenderFromAddress, '@', 0)[0]), UPNSuffix = tostring(split(SenderFromAddress, '@', 1)[0]) | extend Account_0_Name = Name | extend Account_0_UPNSuffix = UPNSuffix | extend IP_0_Address = SenderIPv4 | extend MailBox_0_MailboxPrimaryAddress = RecipientEmailAddress

Microsoft Sentinel

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

جزئیات فنی تکمیلی درباره سازوکار EvilTokens

معماری EvilTokens بر مبنای خودکارسازی در سمت کاربر و زیرساخت پویا در سمت مهاجم استوار بود. اسکریپت سمت کاربر پس از کلیک، device code زنده تولید و بلافاصله رابطِ هدایت به microsoft.com/devicelogin را مهیا می‌کرد تا کاربر احساس طبیعی‌بودن فرایند را از دست ندهد. شیوه poll کردن با checkStatus() و فواصل 3 تا 5 ثانیه‌ای از طریق setInterval، به سرویس پشت‌صحنه مهاجم این امکان را می‌داد که احراز هویت کاربر را بی‌درنگ تشخیص دهد و توکن‌ها را بازیابی کند. شناسه محرمانه نشست که در هر نمونه کد درج می‌شد، ردیابی هر جلسه را برای مهاجم امکان‌پذیر می‌کرد.

در بسیاری از موارد، پس از دریافت توکن‌های دسترسی و refresh، مهاجم اقدام به راه‌اندازی sessionهای برنامه‌ای و اجرای درخواست‌های Microsoft Graph با حجم غیرمعمول می‌کرد تا نمودار سازمانی، گروه‌ها، نقش‌ها و مجوزها را استخراج کند. این شناسایی شتاب‌یافته، انتخاب اهداف دومرحله‌ای، مانند دستیاران مدیران، مالی و IT را تسهیل می‌کرد تا هم ماندگاری طولانی‌مدت از طریق PRT و ثبت دستگاه و هم بهره‌برداری مالی هدفمند از طریق BEC محقق شود.

قوانین مخرب inbox غالباً به‌صورت پنهان‌ساز طراحی می‌شدند؛ برای نمونه، انتقال خودکار ایمیل‌های ارسالی از دامنه‌های خاص به پوشه‌ای که کمتر دیده می‌شود، یا حذف پیام‌ها پس از خواندن. این قوانین می‌توانستند به‌گونه‌ای پیکربندی شوند که کلمات کلیدی مرتبط با صورتحساب‌ها یا واژگان مالی را شکار کنند تا مهاجم رویدادهای پرداخت را در لحظه متوجه شود.

زیرساخت بازگردانی و استتار ترافیک

برای استتار ترافیک و عبور از فهرست‌های مسدودسازی ساده، مهاجمان از زنجیره‌های بازگردانی چندگامی استفاده می‌کردند که شامل دامنه‌های مشروعِ به‌خطر افتاده و پلتفرم‌های serverless با اعتبار بالا بود. استفاده از .vercel.app برای میزبانی رابط‌های ظریف جاوااسکریپت، .workers.dev برای منطق بازگردانی edge و AWS Lambda برای اجرای کد بدون سرور، با بسامد بالا مشاهده شد. این الگوی میزبانیِ خوش‌اعتبار باعث می‌شد هرگونه پایش مبتنی بر دامنه، ترافیک را به‌عنوان الگوی عادی کسب‌وکار تلقی کند.

پیکربندی و گزینه‌های منعطف در پنل EvilTokens

انعطاف‌پذیری پنل مشتری EvilTokens از چند جهت برای مهاجم مزیت آفرید. گزینه Capture Mode تعیین می‌کرد کدام نشانه‌ها و داده‌ها (مانند device code، نشانی ایمیل واردشده، یا tokenهای بازگشتی) ثبت شوند. Layout & Template ظاهر صفحه و همخوانی با برندهای مرسوم را تنظیم می‌کرد. Code Display Style نحو نمایش device code را کنترل می‌نمود تا با صفحات ورود مشروع همگون باشد. Page Language و انتخاب CAPTCHA سدهای روانی و فنی را برای کاربر می‌کاست. AI Mode تولید متن‌های جدید و پویا را برای سناریوهای فریب تسهیل می‌کرد و Captured Text امکان ذخیره گزیده‌هایی از صندوق ورودی را برای بهره‌برداری‌های بعدی فراهم می‌ساخت.

گزینه‌های مدیریت توکن نیز شامل تشخیص ورود مدیران، نوسازی خودکار توکن‌های نزدیک به انقضا و اسکن برخط صندوق ورودی با محرک‌های کلیدواژه‌ای بود که اعلان‌های Telegram به عملگر ارسال می‌کرد. تجمیع این قابلیت‌ها در یک پنلِ قابل استقرار روی Cloudflare Workers/Bunny یا‌هاست‌های PHP، ورودی فنی برای مهاجم را به‌شدت پایین می‌آورد.

نشانه‌های احتمالی آلودگی و رفتارهای قابل پایش

• ورودهای غیرمعمول از طریق جریان device code، به‌ویژه در زمان‌هایی که کاربر ادعای اقدام ندارد.
• افزایش ناگهانی درخواست‌های Microsoft Graph پس از احراز هویت با device code.
• ساخته‌شدن قوانین inbox غیرمعمول، به‌ویژه قوانین حذف یا انتقال پیام‌های شامل کلیدواژه‌های مالی.
• ثبت یا join شدن دستگاه‌های جدید در Entra در فاصله کوتاهی پس از رخدادهای ورود مشکوک.
• ایمیل‌های خروجی غیرمعمول از حساب‌های داخلی به تماس‌های بیرونی با لحن مالی، درخواست به‌روزرسانی اطلاعات بانکی یا تغییر مسیر پرداخت.

اختلال در زیرساخت سرویس و وضعیت فعلی

با همکاری شرکا، واحد DCU در شرکت Microsoft اقداماتی هماهنگ برای اخلال در زیرساخت به‌کاررفته برای راهبری سرویس EvilTokens انجام داد. این اقدام‌ها سطح حمله مهاجمان و دسترس‌پذیری زیرساخت آنها را محدود کرد، هرچند با توجه به ماهیت منعطف و توزیع‌شده پلتفرم‌های serverless و میزبانی ابر، ضرورت دفاع در عمق در سمت سازمان‌ها همچنان پابرجاست. مهاجمان توان بازیابی سریع روش‌های بازگردانی و میزبانی را دارند؛ ازاین‌رو، انسداد جریان device code در صورت عدم نیاز و پایش نشانه‌های رفتاری، سنگ بنای دفاع است.

چه کسانی در معرض خطر هستند

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

یادآوری درباره آموزش کاربر و سیاست‌گذاری ایمیل

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

مروری دوباره بر اعداد و دامنه تهدید

نفوذ به بیش از 12,000 صندوق ایمیل در بیش از 10,000 سازمان، نشان‌دهنده صنعتی‌شدن فیشینگ متمرکز بر توکن و تزریق هوش مصنوعی به زنجیره حمله است. 44 تم فیشینگ، گزینه‌های متعدد استقرار و پیکربندی، و زیرساخت پویا برای تولید device code زنده، تصویری از یک «زنجیره تأمین جرم سایبری» را آشکار می‌کند که در آن عملگر تهدید با حداقل مهارت، حداکثر کارآمدی را به‌دست می‌آورد. به‌کارگیری Node.js در backend و راهبرد گره‌های polling کوتاه‌عمر نیز بر قابلیت پنهان‌کاری و فرار از شناسایی افزوده است.

References

برای زمینه فنی بیشتر درباره سوءاستفاده از زیرساخت‌های PaaS در حملات توکن Microsoft 365، می‌توان به گزارشی با عنوان «Riding the Rails: Threat Actors Abuse Railway.com PaaS as Microsoft 365 Token Attack Infrastructure» و نیز یادداشت‌های پژوهشگران Huntress درباره تم‌ها و متون فریب در ایمیل‌های EvilTokens رجوع کرد.

جمع‌بندی

EvilTokens تصویری روشن از آینده فیشینگ را نشان داد: پلتفرمی با اتکا به هوش مصنوعی که تولید فریب، نقشه‌برداری از سازمان، ربایش توکن و ماندگاری را خودکارسازی می‌کند و با بهره‌برداری از مصالحه‌های ناگزیر در جریان‌های احراز هویتِ برای دستگاه‌های کم‌واسط، لایه‌های دفاعی مبتنی بر MFA را دور می‌زند. واکنش درخور این تهدید، ترکیبی از تصمیم‌های معماری (مسدودسازی device code مگر در موارد ناگزیر)، سیاست‌های دقیق دسترسی مشروط، هوشیاری کاربر، و پایش رفتاریِ مداوم در سطح هویت، ایمیل و دستگاه است. با چنین رویکردی، امکان می‌یابیم پنجره فرصت مهاجم را تنگ، دامنه نفوذ را محدود و پیامدهای مالی و اعتباری حملات BEC را کاهش دهیم.