خانه » اخبار » از تماس جعلی «پشتیبانی IT» در Teams تا گواهی مدیر دامنه؛ مایکروسافت دو نفوذ با سوءاستفاده از AD CS را تشریح کرد

از تماس جعلی «پشتیبانی IT» در Teams تا گواهی مدیر دامنه؛ مایکروسافت دو نفوذ با سوءاستفاده از AD CS را تشریح کرد

از تماس جعلی «پشتیبانی IT» در Teams تا گواهی مدیر دامنه؛ مایکروسافت دو نفوذ با سوءاستفاده از AD CS را تشریح کرد

نوشتهٔ

در

·

تیم اطلاعات تهدید مایکروسافت روز جمعه ۳۰ اکتبر گزارش دو نفوذ واقعی را منتشر کرد که هر دو با یک پیام یا تماس ساده در Microsoft Teams شروع شدند: کسی خود را «پشتیبانی IT» معرفی کرد و از کارمند خواست برای رفع یک مشکل، ابزار Quick Assist را باز کند. چند ساعت بعد، مهاجم در یکی از سازمان‌ها گواهی دیجیتال ۱۱ حساب ممتاز را در دست داشت، روی کنترلر دامنه بود و داده‌ها را به بیرون می‌برد. نکتهٔ مهم این است که هیچ آسیب‌پذیری‌ای در Teams در کار نبود؛ راه ورود، فریب کاربر بود و راه ارتقا، قالب‌های ناامن گواهی در Active Directory Certificate Services (AD CS).

🚨 مهاجم چطور وارد شد؟

  • تماس از بیرون سازمان: مهاجم از تِنَنت‌های بیرونی با نام‌های شبیه سازمان و نام نمایشی «پشتیبانی» در Teams پیام می‌داد یا تماس می‌گرفت.
  • کنترل از راه دور با رضایت کاربر: کاربر Quick Assist را باز می‌کرد و کد اتصال را برای «پشتیبان» می‌خواند؛ از این لحظه کنترل کامل دستگاه در دست مهاجم بود.
  • اجرای اسکریپت بدون بدافزار شناخته‌شده: یک فایل فشرده در پوشهٔ Downloads باز می‌شد، داخل پوشه‌ای با نامی شبیه به‌روزرسانی ویندوز (شروع با KB) قرار می‌گرفت و با نسخهٔ قابل‌حمل Python، Bun یا Java اجرا می‌شد؛ روشی که امضاهای معمول ضدبدافزار را دور می‌زند.

🔍 نفوذ اول: قالب ESC1 و ۱۱ حساب ممتاز

در سازمان اول یک قالب گواهی با ضعف معروف به ESC1 وجود داشت: درخواست‌دهندهٔ کم‌دسترسی می‌توانست خودش تعیین کند گواهی به نام چه کسی صادر شود. مهاجم در موج اول از سه کاربر و یک ایستگاه کاری، گواهی سه حساب بسیار ممتاز را گرفت. سامانهٔ خودکار مایکروسافت دیفندر این هویت‌ها را مسدود کرد، به جز یک حساب ممتاز که از پاسخ خودکار مستثنا شده بود.

  • موج دوم، حدود ۹۰ دقیقه بعد: این بار ۱۶ کاربر هدف قرار گرفتند، ایستگاه کاری دوم آلوده شد و گواهی هشت حساب ممتاز دیگر صادر شد.
  • کنترلر دامنه در چند ثانیه: مهاجم چند ثانیه پس از گرفتن گواهی، روی کنترلر دامنه احراز هویت کرد و DCSync را برای برداشتن داده‌های اعتبارنامه اجرا کرد.
  • خروج داده: با همان حساب مستثنا، به سرور فایل رفت و با نسخهٔ تغییرنام‌یافتهٔ Rclone (با نام SearchApp.exe) پوشه‌های اشتراکی را به یک سرور SFTP بیرونی کپی کرد. بیش از ۱۰۰۰ تلاش بعدی برای دسترسی مسدود شد.

⚠️ نفوذ دوم: PetitPotam و رله به سرویس ثبت‌نام وب (ESC8)

سازمان دوم قالب ESC1 نداشت، پس مهاجم مسیر دیگری رفت. با تکنیک PetitPotam کنترلر دامنه را وادار کرد به دستگاه مهاجم احراز هویت کند و این احراز هویت NTLM را به صفحهٔ ثبت‌نام وب AD CS رله کرد (ضعف ESC8). مرجع صدور گواهی، گواهی حساب ماشینی خودِ کنترلر دامنه را صادر کرد و مهاجم با آن از طریق Kerberos PKINIT بلیت TGT گرفت. هشدار ESC8 در دیفندر به موقع بالا آمد، ایستگاه کاری ایزوله شد و فعالیت دیگری دیده نشد.

60%

بنا بر گزارش بررسی رخنه‌های داده Verizon در سال ۲۰۲۵، در حدود ۶۰ درصد رخنه‌ها عامل انسانی نقش داشته است؛ از فریب و مهندسی اجتماعی تا خطای کاربر. تماس جعلی پشتیبانی دقیقاً همین نقطه را هدف می‌گیرد.

🧩 چرا گواهی از رمز عبور خطرناک‌تر است؟

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

  • تغییر رمز گواهیِ صادرشده را باطل نمی‌کند.
  • نصب دوبارهٔ ویندوز روی دستگاه اول هم گواهی را از دست مهاجم بیرون نمی‌آورد.
  • ابطال گواهی بلیت‌های Kerberos ازپیش‌صادرشده را باطل نمی‌کند؛ این‌ها کارهای جدا هستند.
  • مهار ناقص هنوز یک راه ممتاز باز می‌گذارد؛ همان حساب مستثنا، مسیر خروج داده شد.

🛠️ همین امروز چه کنیم؟

  1. درخواست پشتیبانی را از کانال دوم تأیید کنید: هر تماس ناخواسته را با شمارهٔ داخلی شناخته‌شده تأیید کنید و فقط ابزارهای کنترل از راه دور مجاز را بپذیرید. دسترسی تِنَنت‌های بیرونی در Teams را محدود کنید.
  2. قالب‌های گواهی را ممیزی کنید: قالبی که به درخواست‌دهنده اجازهٔ تعیین نام صاحب گواهی می‌دهد یا حق ثبت‌نام بیش از حد گسترده دارد، حذف یا محدود شود. ارزیابی مداوم ریسک هویت این قالب‌ها را پیش از مهاجم نشان می‌دهد.
  3. ثبت‌نام وب را ببندید یا امن کنید: اگر لازم نیست، حذفش کنید؛ وگرنه فقط HTTPS، فعال‌سازی Extended Protection for Authentication و غیرفعال‌کردن NTLM تا جای ممکن، طبق راهنمای KB5005413.
  4. گواهی‌ها را پایش کنید: رخدادهای صدور گواهی را فعال کنید و صدور گواهی برای حساب‌های ممتاز را به یک سامانهٔ متمرکز پایش رویداد بفرستید تا هشدار بدهد.
  5. استثناها را بازبینی کنید: هر حسابی که از پاسخ خودکار مستثناست باید آگاهانه باشد و برایش یک اقدام دستی تعریف شود. حساب‌های ممتاز را در یک سامانهٔ مدیریت دسترسی ممتاز نگه دارید.

🧭 درس این ماجرا

زیرساخت کلید عمومی داخلی (PKI) در بسیاری از سازمان‌ها سال‌ها پیش نصب شده و کسی سراغ قالب‌هایش نرفته است. یکی از همکاران ما در یک ارزیابی دید که قالب «کاربر» با امکان تعیین نام دلخواه، برای همهٔ کاربران دامنه باز بود؛ یعنی هر کارمندی می‌توانست گواهی مدیر دامنه بگیرد. ممیزی قالب‌ها، نگه‌داری کلید مرجع صدور در ماژول امنیتی سخت‌افزاری و احراز هویت چندعاملی مقاوم در برابر فیشینگ، کار مهاجم را بسیار سخت‌تر می‌کند. راهنمای کامل‌تر را در مقالهٔ امنیت PKI داخلی و کلیدهای امضای کد بخوانید و برای بازبینی معماری هویت و PKI با کارشناسان ما در تماس باشید.

💬 سؤال از شما:آخرین بار کی قالب‌های گواهی AD CS سازمان‌تان را ممیزی کردید؟ آیا کارکنان می‌دانند تماس «پشتیبانی IT» را چطور تأیید کنند؟
#هشدار_امنیتی#اکتیو_دایرکتوری#مهندسی_اجتماعی#امنیت_هویت#سکیورلند#MicrosoftTeams#ADCS#ActiveDirectory#SocialEngineering#SecurityLand

راهکار مناسب سازمانتان را می‌خواهید؟ با چند سؤال ساده نسخه و لایسنس مناسب را پیدا کنید، یا نیازتان را بگویید تا کارشناسان ما بی‌طرفانه پیشنهاد و قیمت روز را اعلام کنند.

مشاور انتخاب لایسنسدرخواست مشاوره و استعلام قیمت

دیدگاه‌ها

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *