مایکروسافت روز ۱ اکتبر گزارش دفاع دیجیتال ۲۰۲۶ را منتشر کرد. بیشتر خبرها درباره حمله‌هایی بود که هوش مصنوعی اجرایشان می‌کند و باج‌افزار. ولی بخشی که برای مسئول ایمیل سازمان مهم‌تر است بی‌سروصداتر است و در صفحه‌های ۳۳ و ۴۵ فایل PDF آمده: فیشینگ دوباره به یکی از راه‌های اصلی نفوذ برگشته و صفحه فیشینگ معمولی دیگر یک فرم ورود جعلی نیست که فقط رمز را بدزدد.
در این نوشته یافته‌های مربوط به ایمیل را بیرون کشیده‌ایم، توضیح داده‌ایم در عمل یعنی چه، و صادقانه گفته‌ایم یک سرویس ایمیل (از جمله محصول خود ما) چه کاری از دستش برمی‌آید و چه کاری نه.
گزارش دقیقاً درباره فیشینگ چه می‌گوید
بازه گزارش از ژوئیه ۲۰۲۵ تا ژوئن ۲۰۲۶ است. در پرونده‌های پاسخ به حادثه مایکروسافت، فیشینگ راه ورود اولیه در ۲۳ درصد نفوذها بوده، در حالی که سال قبل ۷ درصد بود. در همین مدت سهم پرونده‌هایی که راه ورودشان شناسایی نشد از ۲۵ به ۱۴ درصد رسید؛ پس بخشی از این جهش شاید به دید بهتر برگردد، ولی جهت روند روشن است.
تغییر بزرگ‌تر در نوع فیشینگ است. کیت‌های «مهاجم در میانه» (AiTM) حالا ۴۴٫۶ درصد روش‌های فیشینگ شناسایی‌شده را تشکیل می‌دهند؛ در برابر ۳۳٫۶ درصد برای لینک فیشینگ معمولی و ۱۲٫۹ درصد برای پیوست. صفحه AiTM یک پراکسی معکوس است. قربانی صفحه ورود واقعی را می‌بیند، رمز واقعی را می‌زند، درخواست تأیید دومرحله‌ای واقعی را هم تأیید می‌کند و پراکسی کوکی نشستی را که برمی‌گردد نگه می‌دارد. مایکروسافت در همان صفحه می‌گوید در ۸۷٫۷ درصد نفوذهای فیشینگ، اطلاعات ورود یا نشست کاربر جمع‌آوری شده است.
و مهاجم وقتی یک حساب سالم به دست آورد، دنبال حساب‌های بیشتر می‌رود. در نفوذهایی که با حساب معتبر شروع شدند، ۵۲٫۲ درصد به سرقت اطلاعات ورود بیشتر ادامه پیدا کردند.
چرا کد شش‌رقمی دیگر نجاتتان نمی‌دهد
بخش ناخوشایند ماجرا اینجاست. کد پیامکی، کد اپلیکیشن احراز هویت و تأیید push همه جلوی حمله قدیمی را می‌گیرند؛ یعنی کسی که رمز لو رفته را می‌خرد و از جای دیگری وارد می‌شود. هیچ‌کدام جلوی AiTM را نمی‌گیرند. پراکسی هر چیزی را که کاربر تایپ می‌کند، از جمله همان کد، همان لحظه به سرور واقعی می‌فرستد. کاربر همه کار را درست انجام داده و باز هم یک نشست زنده را تحویل داده است.
چیزی که جلویش را می‌گیرد احراز هویتی است که به نشانی سایت گره خورده: کلیدهای امنیتی FIDO2 و passkey. مرورگر برای دامنه‌ای که فقط شبیه دامنه اصلی است چیزی امضا نمی‌کند، پس چیز به‌دردبخوری برای جابه‌جا کردن به دست پراکسی نمی‌رسد. توصیه خود مایکروسافت در گزارش هم همین است: از MFA سنتی فراتر بروید و روش‌های مقاوم در برابر فیشینگ را در اولویت بگذارید.
به نظر ما حرف درستی است و درباره خود ما هم صدق می‌کند. FanMail ورود با رمز یک‌بار مصرف پیامکی و کد اپلیکیشن احراز هویت (TOTP) را به‌عنوان عامل دوم دارد. این‌ها نسبت به رمز تنها پیشرفت بزرگی‌اند و در خیلی از سازمان‌ها تنها عامل دومی‌اند که کاربران واقعاً فعالش می‌کنند. اما در برابر فیشینگ مقاوم نیستند و ترجیح می‌دهیم همین‌جا بگوییم تا اینکه مشتری آن را از گزارش یک حادثه بفهمد.
ترفندهایی که از فیلترها رد می‌شوند
نیمه دیگر کار رساندن قربانی به صفحه پراکسی است و گزارش نشان می‌دهد مهاجمان قالب‌ها را سریع‌تر از سازگار شدن فیلترها عوض می‌کنند:
- کد QR داخل PDF. Microsoft Defender for Office 365 بیش از ۱۴۵ میلیون حمله فیشینگ با کد QR شناسایی کرده و تا آوریل ۲۰۲۶، ۷۹ درصد آن‌ها در فایل PDF بوده‌اند. کاربر PDF را روی لپ‌تاپ اداری باز می‌کند و کد را با گوشی شخصی‌اش اسکن می‌کند؛ گوشی‌ای که بیرون از همه کنترل‌های سازمان است.
- دروازه CAPTCHA. در همان صفحه آمده که بیش از ۱۰۰ میلیون حمله فیشینگ یک CAPTCHA جلوی صفحه سرقت رمز گذاشته‌اند تا اسکنرهای خودکار هیچ‌وقت آن را نبینند.
- فیشینگ با کد دستگاه. طعمه کاربر را به صفحه واقعی ورود دستگاه مایکروسافت می‌فرستد و مهاجم بعد از آن توکن‌های OAuth را جمع می‌کند. اصلاً صفحه جعلی‌ای در کار نیست که بشود با نشانی‌اش مسدودش کرد.
- پشتیبانی جعلی. اول سیلی از ایمیل بی‌ارزش، بعد پیام چت از یک حساب تازه که خود را پشتیبانی IT جا می‌زند و پیشنهاد رفع مشکل می‌دهد. هدف این یکی اعتماد کارکنان به تیم پشتیبانی خودشان است.
پیش‌تر درباره اینکه یک PDF چطور می‌تواند اسکریپت را وارد هلپ‌دسک یا فضای فایل کند، در یادداشت مقاوم‌سازی دانلود پیوست‌های PDF نوشته بودیم. روند QR داخل PDF حمله دیگری است از همان در: قالب فایلی که همه آن را بی‌خطر می‌دانند.
پنج کار برای همین فصل
- passkey یا کلید FIDO2 را از حساب‌های حساس شروع کنید. مدیران سیستم، مالی، منابع انسانی و هر کسی که پرداخت تأیید می‌کند. لازم نیست روز اول کل سازمان را پوشش دهید.
- نشست‌ها را کوتاه‌تر کنید و زیر نظر بگیرید. AiTM نشست را می‌دزدد نه رمز را؛ پس نشست‌های طولانی و تمدید بی‌صدای توکن است که این حمله را سودآور می‌کند. اگر همان نشست از شبکه تازه‌ای دیده شد، هشدار بدهید.
- کد QR داخل پیوست را مثل لینک ببینید. اگر فیلتر ایمیلتان نمی‌تواند QR داخل PDF را بخواند، فرض کنید کاربر آن را با گوشی بی‌محافظ اسکن می‌کند.
- به کارکنان بگویید پشتیبانی واقعی چطور با آن‌ها تماس می‌گیرد. یک جمله در آموزش ورود، و تکرارش هر چند ماه: پشتیبانی هیچ‌وقت از شما نمی‌خواهد از طریق پیام چت ابزار کنترل از راه دور نصب کنید.
- SPF و DKIM و DMARC دامنه‌های خودتان را سخت‌گیرانه نگه دارید. جلوی دامنه‌های شبیه را نمی‌گیرد، ولی ارزان‌ترین نسخه حمله، یعنی جعل دقیق نشانی خودتان، را می‌بندد.
FanMail کجا به کار می‌آید و کجا نه
FanMail سرویس ایمیل سازمانی قابل نصب روی سرور خودتان است که روی Stalwart Mail Server ساخته شده. در بخشی از فهرست بالا کمک می‌کند: ایمیل خروجی با DKIM امضا و با SPF و DMARC بررسی می‌شود، نمایشگر پیام HTML را پاک‌سازی می‌کند و می‌تواند تصاویر خارجی را مسدود کند، و کاربران می‌توانند ورود دومرحله‌ای با پیامک یا اپلیکیشن احراز هویت را روشن کنند. چون روی سرور خود سازمان اجرا می‌شود، لاگ‌های سرور در اختیار خودتان است و هر وقت خواستید می‌توانید ببینید یک نشست از کجا استفاده شده.
کاری که نمی‌کند این است که کد پیامکی یا TOTP را در برابر فیشینگ مقاوم کند؛ هیچ سرور ایمیلی نمی‌تواند. اگر نگرانی اصلی‌تان AiTM است، فارغ از اینکه از چه محصول ایمیلی استفاده می‌کنید، احراز هویت مقاوم در برابر فیشینگ را جلوی ایمیل بگذارید. برای اینکه چرا اصلاً ورود پیامکی را ساختیم، یادداشت ما درباره OTP پیامکی را ببینید و اگر گزینه‌های میزبانی‌شده را مقایسه می‌کنید، مقایسه FanMail با Google Workspace و Zoho Mail کنترل داده و هزینه را پوشش می‌دهد.
