یک کیت فیشینگ حساب Google از اتصال‌های WebSocket زنده استفاده می‌کند تا قربانیان را در صفحات ورود جعلی هدایت کند، درخواست‌های احراز هویت را در لحظه منتقل کند و نشست‌های احرازشده را سرقت کند.
این کارزار نشان می‌دهد مهاجمان می‌توانند با فوروارد کردن گام‌های ورود به‌صورت بلادرنگ از MFA عبور کنند، بی‌آن‌که خودِ کنترل‌های امنیتی را بشکنند.
این عملیات افرادی را که به سازمان‌های پژوهشی در تایوان مرتبط هستند هدف قرار می‌دهد. ایمیل‌ها خود را دعوت‌نامه رویدادهای دانشگاهی و سیاست‌گذاری جا می‌زنند و با استفاده از جزئیات واقعی رویداد، هویت‌های جعلیِ فرستنده و پیوندهای ثبت‌نام پنهان، تلاش برای سرقت اعتبارنامه را شبیه یک مکاتبه حرفه‌ای معمول جلوه می‌دهند.
پژوهشگران شرکت Cisco Talos در اواسط 2026 این کارزار را شناسایی کردند و آن را با شناسه UAT-11985 رصد نمودند. آنان کیت فیشینگ آن را در یک گزارش پژوهشی درباره تهدید در ماه اکتبر که در 8 اکتبر منتشر شد، با جزئیات تشریح کردند.
این تحلیل، سامانه‌ای هدایت‌شونده توسط اپراتور را توصیف می‌کند که با ترکیب درخواست‌های HTTP و به‌روزرسانی‌های WebSocket، فرآیند احراز هویت Google را بازتاب می‌دهد.
کیت فیشینگ AitM گوگل
ایمیل‌ها خود را به‌جای مرکز Taiwan European Union Centre، مؤسسه NCCU Institute of International Relations و مؤسسه Taiwan Research Institute جا زدند.
وقتی گیرنده‌ها نزد آن نهادها وضعیت فرستندگان ادعایی را استعلام کردند، هیچ‌کدام نتوانستند تأیید کنند که آن افراد کارمند یا نماینده هستند. اطلاعات دقیق رویداد به مهاجمان کمک کرد پیرامون هویت‌های ساختگی اعتماد ایجاد کنند.
هر پیام الگوی مشابهی داشت: آغاز با مضمون سیاست‌گذاری، تعریف و تمجید متناسب با گیرنده، و دستورالعمل‌های ثبت‌نام.
این رویکرد قربانیان را به همان خطر سرقت نشست سوق می‌دهد که در حملات فیشینگ Tycoon 2FA دیده شده است؛ جایی که یک صفحه ورود متقاعدکننده میان کاربر و سرویس احراز هویت واقعی قرار می‌گیرد.
شرکت Talos نشانه‌هایی از نگارش با کمک هوش مصنوعی مشاهده کرد؛ از جمله الگوهای تکراری جملات، تعریف‌های کلی و تغییرات سریع برای موضوع‌ها و گیرندگان مختلف.
بااین‌حال، پژوهشگران نتوانستند اثبات کنند که یک مدل زبانی بزرگ کل ایمیل‌ها را نوشته است. این یافته از کمک‌گیری محتمل از هوش مصنوعی پشتیبانی می‌کند و تولید محتوای کاملاً خودکار را تأیید نمی‌کند.
مهاجمان پوسترهای رویداد معتبر را نیز کپی کردند و کدهای QR آنها را با کدهای مخرب جایگزین کردند. به گفته واحد Talos، نسخه‌های چاپی این پوسترها می‌توانستند افرادی را در معرض این تله قرار دهند که هرگز ایمیل اولیه را دریافت نکرده بودند. در نتیجه، آشنابودن طراحی هیچ تضمینی نمی‌داد که کد ثبت‌نام به مقصدی امن هدایت می‌کند.
سازوکار رله WebSocket برای MFA چگونه کار می‌کند؟
قربانیان ابتدا با یک Google Form جعلی روبه‌رو می‌شوند که آنها را به یک صفحه ورودِ کپی‌شده متعلق به Google هدایت می‌کند. برخلاف یک فرم ساده جمع‌آوری گذرواژه، این کیت به اپراتور اجازه می‌دهد هر مرحله احراز هویت را کنترل کند.
تکنیک‌های فیشینگ WebSocket در چارچوب JWR نشان می‌دهند اتصال‌های پایدار چگونه می‌توانند از تعامل زنده پشتیبانی کنند، هرچند آن چارچوب بانکداری و اطلاعات پرداخت را هدف قرار می‌دهد.
این کیت بارگذاری داده را از به‌روزرسانی‌های صفحه جدا می‌کند. درخواست‌های HTTP POST جزئیات مرورگر، شناسه‌های حساب، گذرواژه‌ها و پاسخ‌های چالش را به زیرساخت تحت‌کنترل مهاجم ارسال می‌کنند.
یک اتصال WebSocket پایدار دستورالعمل‌ها را به صفحه بازمی‌گرداند و به آن می‌گوید در مرحله بعد کدام صفحه احراز هویت را نمایش دهد. این تفکیک باعث می‌شود بارگذاری‌ها جدا بمانند و در عین حال امکان تغییرات سریع حین ورود فراهم شود.
اولین درخواست با نام google_login_start تنظیمات زبان، اطلاعات user-agent، ابعاد صفحه و وضعیت دستگاه همراه را جمع‌آوری می‌کند. پس از ایجاد یک نشست، اسکریپت اتصال WebSocket خود را باز می‌کند.
رویداد google_input_identifier سپس نشانی ایمیل یا شماره تلفن قربانی را برای بررسی در برابر سرویس احراز هویت واقعی Google ارسال می‌کند.
هنگامی که گذرواژه وارد می‌شود، رویداد google_login_check آن را به‌همراه شناسه حساب و اطلاعات مرورگر ارسال می‌کند. اگر Google گام تأیید دیگری بخواهد، مهاجم رابط جعلی را از طریق پیام‌های WebSocket به‌روزرسانی می‌کند.
به گزارش واحد Talos، این رله هماهنگ سرقت توکن‌های نشست احرازشده را ممکن می‌کند و پس از آنکه قربانی بررسی‌های خواسته‌شده را کامل کرد، تصاحب حساب را امکان‌پذیر می‌سازد.
این صفحه JavaScript خود را با استفاده از رشته‌های Base64 و چرخش تکراری آرایه‌ها پنهان می‌کند. رابط آن از زبان‌های چینی ساده‌شده، چینی سنتی و انگلیسی پشتیبانی می‌کند.
پژوهشگران Talos با اطمینان متوسط ارزیابی کردند که زبان اصلی کاری توسعه‌دهنده «چینی ساده‌شده» بوده است؛ این یافته به‌تنهایی ملیت یا حمایت دولتی را اثبات نمی‌کند.
تفاوت مهم این است که تکمیل درخواست MFA، امنیت نشست را تضمین نمی‌کند. همان‌گونه که در Mirage2FA session cookie theft مستند شده است، مهاجمان می‌توانند داده‌های احراز هویتِ به‌دست‌آمده در جریان ورود رله‌شده را مجدداً استفاده کنند.
توصیه می‌شود سازمان‌ها احراز هویتِ مقاوم در برابر فیشینگ را برگزینند، دعوت‌نامه‌های غیرمنتظره را به‌صورت مستقل راستی‌آزمایی کنند، و در صورت ظن به سرقت نشست آن را بررسی کنند؛ تکیه صرف بر تعویض گذرواژه کافی نیست.
شاخص‌های نفوذ (IoC)
| نوع | شاخص منتشرشده توسط منبع |
|---|---|
| URL | https[:]//google.morelessty[.]com |
| URL | https[:]//jmlh.morelessty[.]com/ |
| URL | https[:]//google.centerhoti[.]com/ |
| URL | https[:]//google.natrlyi[.]com/ |
| URL | https[:]//accounts.natrlyi[.]com/ |
hoangthikieuanh254@gmail[.]com |
|
chenzhengyu1989@gmail[.]com |
|
tonn9127@gmail[.]com |
پژوهشگران Talos پوشش‌های تشخیصی زیر را نیز فهرست کرده‌اند. این‌ها امضاها و قوانین دفاعی هستند، نه شاخص‌های زیرساختیِ اضافی.
| سامانه تشخیص | امضا یا قانون |
|---|---|
| ClamAV | Html.Phishing.UAT11985-10060614-0 |
| Snort 2 | 1:67198 |
| Snort 3 | 7:31 |
یادداشت: برای جلوگیری از تفکیک نام یا لینک‌شدن ناخواسته، آدرس‌های IP و دامنه‌ها عمداً غیرفعال‌سازی شده‌اند (برای نمونه، [.]). آنها را تنها در پلتفرم‌های کنترل‌شده اطلاعات تهدید مانند پلتفرم MISP، سرویس VirusTotal یا سامانه SIEM خود به حالت عادی برگردانید.
