رفتن به محتوا
IROSG.
EN
تازه‌ها

گزارش Microsoft از وجه مشترک آسیب‌پذیری‌های بهره‌برداری‌شده؛ چرا مسیر حمله مهم‌تر از فهرست CVE است؟

گزارش رسمی Microsoft Security نشان می‌دهد از حدود ۳۸۳ هزار CVE افشاشده تا سپتامبر ۲۰۲۶، فقط ۲٬۰۵۶ مورد با بهره‌برداری واقعی مرتبط بوده‌اند؛ اما همین گروه کوچک عمدتاً ضعف‌هایی را دربرمی‌گیرد که کنترل سامانه، هویت ممتاز و مسیر گسترش حمله را در اختیار مهاجم می‌گذارند.

اینفوگرافیک Microsoft درباره ۲٬۰۵۶ CVE بهره‌برداری‌شده در دنیای واقعی؛ اجرای کد از راه دور سمت سرور مهم‌ترین اثر و Windows پرتکرارترین سکوی آسیب‌پذیر است.

خبر در یک نگاه

گزارش پژوهشی Microsoft Security که در ۲ نوامبر ۲۰۲۶ منتشر شده، نشان می‌دهد فراوانی یک CVE به‌تنهایی نمی‌گوید کدام ضعف در خط مقدم تهدید است. تیم Microsoft Security Research با بررسی کاتالوگ آسیب‌پذیری‌های ردیابی‌شده تا پایان سپتامبر ۲۰۲۶، از حدود ۳۸۳ هزار آسیب‌پذیری افشاشده به مجموعه‌ای کوچک‌تر رسیده است: فقط ۲٬۰۵۶ CVE با بهره‌برداری واقعی مرتبط شده‌اند؛ کمتر از یک مورد از هر ۲۰۰ آسیب‌پذیری منتشرشده.

پیام اصلی گزارش، نادیده گرفتن وصله‌ها نیست؛ پیشنهاد می‌کند منابع محدود بر ترکیب «اثر بهره‌برداری» و «میزان در معرض‌بودن دارایی» متمرکز شوند. ضعف‌هایی که کنترل سامانه را می‌دهند، به‌ویژه RCE سمت سرور، ارتقای امتیاز محلی و دورزدن احراز هویت، در داده‌های واقعی سهمی بزرگ‌تر از کل CVEها دارند. این یافته برای تیم‌هایی مهم است که فهرست وصله را فقط با شدت اعلام‌شده یا CVSS مرتب می‌کنند.

روش خواندن داده‌های Microsoft

گزارش هر CVE را در دو بُعد دسته‌بندی کرده است: پیامد امنیتی و سکوی آسیب‌پذیر. در بُعد پیامد، هر CVE بر اساس مهم‌ترین نتیجه‌ای که مستقیماً ممکن می‌کند یک‌بار طبقه‌بندی شده است. اگر ضعفی دورزدن احراز هویت و از همان مسیر RCE را ممکن کند، در طبقه RCE قرار می‌گیرد. این روش، نوع فنی ضعف را از سطح کنترلی که مهاجم می‌تواند بگیرد جدا می‌کند.

طبقه‌های بررسی‌شده شامل اجرای کد از راه دور سمت سرور یا کاربر، اجرای کد محلی، ارتقای امتیاز تا SYSTEM یا root، دورزدن احراز هویت یا کنترل امنیتی، افشای اطلاعات، دست‌کاری، منع خدمت، XSS، دسترسی دلخواه به فایل و جعل یا تغییر مسیر است. در تحلیل سکو نیز Windows، Linux/Unix، موبایل، تجهیزات شبکه، IoT/OT، میزبان‌های مجازی‌سازی و بسته‌های توسعه‌دهنده دیده شده‌اند. یک CVE می‌تواند در چند سکو قرار گیرد؛ اما در تحلیل اثر، هر مورد یک‌بار محاسبه شده است.

شکاف میان کل بازار و آسیب‌پذیری‌های واقعاً استفاده‌شده

در کل جمعیت منتشرشده، حدود ۷۷ درصد CVEها به کد کاربردی و ۲۳ درصد به کد سیستم‌عامل یا سیستم مربوط‌اند. در میان ۲٬۰۵۶ CVE بهره‌برداری‌شده، سهم کد سیستم‌عامل به ۴۱ درصد می‌رسد و سهم برنامه‌ها ۵۹ درصد است. مهاجم الزاماً پرشمارترین دسته را انتخاب نمی‌کند؛ دسته‌ای را انتخاب می‌کند که کنترل قابل‌استفاده‌تر یا مسیر حساس‌تری می‌دهد.

در سطح اثر، اجرای کد از راه دور سمت سرور از ۲۰ درصد در کل CVEهای منتشرشده به ۳۷ درصد در CVEهای بهره‌برداری‌شده افزایش می‌یابد. ارتقای امتیاز محلی از ۱۱ به ۱۸ درصد و اجرای کد از راه دور سمت کاربر از ۴ به ۱۳ درصد می‌رسد. در جهت عکس، XSS از ۱۵ به ۴ درصد و منع خدمت از ۱۶ به ۷ درصد کاهش می‌یابد. این مقایسه نمی‌گوید XSS یا DoS بی‌اهمیت‌اند؛ می‌گوید در نمونه بهره‌برداری واقعی، نسبت آن‌ها از سهمشان در کل جامعه CVE کمتر است.

از این داده‌ها یک قاعده عملی به دست می‌آید: تیمی که فهرست بزرگی از ضعف‌ها دارد، باید بپرسد «پس از موفقیت، مهاجم چه چیزی به دست می‌آورد؟» نه فقط «نمره شدت چقدر است؟» RCE سمت سرور، دورزدن احراز هویت و ارتقای امتیاز محلی می‌توانند پایگاه و مسیر گسترش بسازند. Microsoft می‌گوید این سه طبقه در مجموع ۷۸ درصد آسیب‌پذیری‌های بهره‌برداری‌شده واقعی را تشکیل می‌دهند؛ در این گروه ۱٬۲۳۹ CVE بر اساس سکو و لایه کد تفکیک شده‌اند.

چرا نوع دارایی از نوع CVE مهم‌تر می‌شود

یک CVE در یک لپ‌تاپ جدا از شبکه با همان CVE روی یک درگاه اینترنتی، ریسک عملی یکسانی ندارد. گزارش «اثر» را نتیجه موفقیت و «در معرض‌بودن» را جایگاه دارایی در محیط و فرصت‌هایی می‌داند که برای گام بعدی ایجاد می‌کند. این فرصت‌ها به هویت‌ها، امتیازها، اتصال‌های شبکه و منابع قابل‌دسترسی از همان دارایی وابسته‌اند. از همین رو، دارایی آسیب‌پذیر باید در متن معماری دیده شود، نه به شکل یک ردیف مستقل در جدول اسکن.

سرورها نمونه روشن این مسئله‌اند. آن‌ها ممکن است با حساب سرویس، هویت برنامه یا هویت مدیریت‌شده ابری کار کنند؛ هویتی که گاهی بیشتر از نیاز عملیاتی مجوز دارد. تسخیر چنین سروری می‌تواند راهی به داده حساس، منبع دیگر، امتیاز مدیریتی یا مسیر مورد اعتماد شبکه باز کند. «انفجار اثر» نتیجه همین پیوند است: RCE روی سامانه متصل به هویت ممتاز با RCE روی میزبان کم‌دسترسی پیامد یکسان ندارد.

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

زمان اصلاح در برابر زمان مسلح‌شدن

گزارش درباره سرعت اصلاح بین سکوها تفاوت معناداری نشان می‌دهد. بر اساس داده Microsoft Security Exposure Management در سال ۲۰۲۶، میانه اصلاح در ایستگاه‌های کاری Windows حدود دو هفته و در Windows Server بیش از یک ماه است. برای Linux Server و برنامه‌های macOS بیش از ۱۰ هفته و برای تجهیزات شبکه بیش از یک سال گزارش شده است. این اعداد میانه‌اند، اما شکاف را روشن می‌کنند: دارایی‌های حیاتی‌تر معمولاً کندتر تغییر می‌کنند.

در سوی مقابل، بهره‌برداری می‌تواند در چند روز آماده شود یا هم‌زمان با افشا شکل بگیرد. گزارش به VulnCheck ارجاع می‌دهد که ۲۹ درصد exploitهای سال ۲۰۲۵ در فاصله یک روز از انتشار CVE راه‌اندازی شده‌اند. با استناد به CISA، میانگین فاصله انتشار CVE تا ورود به KEV از ۸۹ روز در ۲۰۲۴ به ۵۷ روز در ۲۰۲۵ کاهش یافته است. داده‌های ۲۰۲۶ تا سپتامبر، میانگین ۲۰ روز و میانه سه روز را نشان می‌دهند. این اعداد «زمان تا ثبت در KEV» هستند، نه زمان قطعی شروع همه حمله‌ها.

نتیجه مدیریتی روشن است: سیاست «ابتدا وصله، سپس هر کار دیگر» برای سامانه‌ای که هفته‌ها یا ماه‌ها در صف تغییر می‌ماند کافی نیست. تیم باید هم‌زمان کنترل موقت داشته باشد: حذف exposure غیرضروری، محدود کردن دسترسی ورودی، جداسازی سرویس، کاهش امتیاز هویت و نظارت بر نشانه‌های سوءاستفاده. وصله درمان اصلی است، اما کوتاه کردن پنجره دسترسی نیز بخشی از پاسخ اضطراری است.

نقد اتکای تک‌معیاری به CVSS

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

گزارش پیشنهاد می‌کند سیگنال تهدید و exploitability، احتمال نقض، exposure اینترنتی و اهمیت دارایی کنار هم قرار گیرند. این به معنای کنار گذاشتن CVSS نیست؛ CVSS یک ورودی است، نه حکم نهایی. مدل اولویت‌بندی باید پرسش‌های «آیا در محیط ما reachable است؟»، «آیا exploit مشاهده شده؟»، «هویت این پردازش چیست؟»، «به کدام داده یا مسیر اعتماد وصل است؟» و «در صورت تسخیر، چه چیزی بعد از آن در دسترس قرار می‌گیرد؟» را پاسخ دهد.

برای اجرایی کردن این مدل، صف فوری را به ضعف بهره‌برداری‌شده روی دارایی اینترنتی یا هویت ممتاز اختصاص دهید؛ سپس takeover روی دارایی حیاتی، سرویس غیرضروری قابل‌حذف و مواردی را که کنترل جبرانی دارند جدا کنید. هر صف باید مالک، مهلت، شواهد تصمیم و مسیر استثنا داشته باشد؛ وگرنه دوباره به فهرست بلندبالای بدون مسئول تبدیل می‌شود.

موجودی؛ پیش‌شرط هر اولویت‌بندی

هیچ اولویت‌بندی‌ای بدون موجودی قابل‌اعتماد دوام نمی‌آورد. سازمان باید بداند چه دارایی‌هایی دارد، کدام اینترنتی‌اند، چه نسخه‌ای اجرا می‌کنند، مالکشان کیست، با چه هویتی اجرا می‌شوند و از کجا قابل‌دسترسی‌اند. این موجودی باید سرور، ابر، endpoint، تجهیزات شبکه، OT/IoT، برنامه وب و وابستگی توسعه‌دهنده را پوشش دهد.

تفاوت «دارایی ثبت‌شده» و «دارایی مشاهده‌شده» را جدی بگیرید. گزارش بر کشف زیرساخت‌های اینترنتی، دارایی‌های ناشناخته یا پایش‌نشده، shadow IT و وابستگی‌های شخص ثالث تأکید می‌کند. هر چیزی که در CMDB نیست لزوماً کم‌ریسک نیست؛ گاهی به‌دلیل نبود مالک و پایش، مسیر ساده‌تری برای مهاجم است. خروجی موجودی باید به تیم شبکه، مالک سرویس و تیم هویت برسد.

مدل‌سازی تهدید و مسیر حمله

اسکن آسیب‌پذیری می‌گوید کدام نسخه مشکل دارد؛ مدل‌سازی تهدید می‌پرسد مهاجم پس از آن چه می‌کند. برای هر finding مهم، نقطه ورود، هویت، امتیاز، مسیر شبکه، اسرار قابل‌خواندن و دارایی نهایی را ترسیم کنید و مسیر را تا داده حساس یا سرویس حیاتی ادامه دهید.

Attack Path Analysis در گزارش برای همین پیوند معرفی شده است: اتصال دارایی‌ها و تکنیک‌های مهاجم در مسیری از نقطه ورود تا دارایی حساس. در محیط‌های endpoint، ابر و hybrid، ترکیب زمینه آسیب‌پذیری، داده endpoint و اطلاعات دارایی ابری می‌تواند نشان دهد کدام ضعف راهی به مرحله بعد می‌سازد. در ابر، exposure اینترنتی، اتصال شبکه، هویت و مجوز در Azure، AWS و Google Cloud به تحلیل اضافه می‌شود.

این مدل به جای وصله‌کردن کورکورانه، محل شکستن مسیر را نشان می‌دهد. ممکن است وصله سرویس قدیمی زمان‌بر باشد، اما برداشتن مجوز خواندن مخزن اسرار، حذف دسترسی عمومی یا جدا کردن subnet فوراً ارزش مسیر را کم کند. کنترل جبرانی نباید جای وصله دائمی جا زده شود؛ باید صاحب و تاریخ بازبینی داشته باشد.

کنترل‌های پیشگیرانه پیشنهادی

اول، سطح حمله بیرونی را مستمر کشف کنید و هر سرویس را به مالک و هدف کسب‌وکاری متصل کنید. دوم، برای سرویس‌های اینترنتی احراز هویت قوی، محدودیت مبدأ، تفکیک شبکه و حداقل exposure را اعمال کنید. سوم، حساب‌های سرویس و هویت‌های مدیریت‌شده را با اصل کمترین امتیاز بازبینی کنید؛ مجوز غیرضروری مسیر حرکت جانبی را بزرگ می‌کند.

چهارم، وصله را بر اساس exploitation، exposure و criticality زمان‌بندی کنید و برای سامانه‌های کند، کنترل موقت از پیش آماده داشته باشید. پنجم، telemetry لازم برای تشخیص سوءاستفاده را نگه دارید: دسترسی غیرعادی، اجرای فرایند ناشناخته، تغییر هویت، حرکت بین میزبان‌ها و خواندن غیرمنتظره داده. ششم، وابستگی‌های شخص ثالث و بسته‌های توسعه‌دهنده را بخشی از دارایی سازمان بدانید.

هفتم، backup و بازیابی را در کنار دارایی‌های حیاتی از نظر دسترس‌پذیری آزمایش کنید؛ منع خدمت برای محیطی که uptime مأموریتی است می‌تواند پایان‌دهنده مأموریت باشد. هشتم، افشای credential و secret را کم‌اهمیت تلقی نکنید؛ افشای محدود اگر به مسیر هویت ممتاز وصل شود، مقدمه دسترسی گسترده‌تر است.

چک‌لیست اجرایی برای تیم دفاع

  • در ۲۴ ساعت نخست، فهرست CVEهای بهره‌برداری‌شده را با inventory واقعی تطبیق دهید.
  • برای هر مورد، اینترنتی‌بودن، سرویس شنوا، مالک، هویت اجراکننده، امتیاز، اتصال شبکه و داده مقصد را ثبت کنید.
  • RCE سمت سرور، دورزدن احراز هویت و ارتقای امتیاز محلی را در صف takeover قرار دهید، نه در صفی که فقط با CVSS ساخته شده است.
  • دارایی‌های ناشناخته، shadow IT و وابستگی‌های شخص ثالث را از discovery خارج نگذارید.
  • برای وصله‌های دیرهنگام، exposure ورودی را کم و کنترل جبرانی را با تاریخ انقضا ثبت کنید.
  • مسیر حمله تا دارایی حساس و نخستین نقطه قابل‌شکست با کاهش مجوز، segment یا حذف سرویس را مشخص کنید.
  • پس از اصلاح، نسخه نصب‌شده، بسته‌بودن مسیر، وضعیت هویت و نبود نشانه سوءاستفاده را جداگانه راستی‌آزمایی کنید.
  • زمان کشف تا مالک، زمان افشا تا کاهش exposure، زمان اصلاح بر حسب سکو و تعداد مسیرهای باز تا دارایی حیاتی را با مسئول مشخص گزارش کنید.

جمع‌بندی

گزارش دوم نوامبر Microsoft دو ساعت متفاوت را کنار هم می‌گذارد: ساعت دفاع که در برخی سکوها هفته‌ها یا بیش از یک سال طول می‌کشد، و ساعت مهاجم که برای بخشی از exploitها به یک روز یا کمتر از چند روز رسیده است. در چنین محیطی، شمارش CVE کافی نیست. ۲٬۰۵۶ مورد بهره‌برداری‌شده از میان حدود ۳۸۳ هزار مورد نشان می‌دهد جامعه تهدید کوچک‌تر است، اما تمرکز آن روی ضعف‌هایی است که کنترل و دسترسی واقعی می‌سازند.

راهکار عملی، ترکیب سه کار است: موجودی دقیق برای دانستن آنچه در معرض است، اولویت‌بندی مبتنی بر اثر و exposure برای انتخاب نبرد درست، و کنترل‌های پیشگیرانه و جبرانی برای کوتاه کردن مسیر پیش از تکمیل وصله. سازمانی که فقط patch dashboard را مرتب می‌کند، ممکن است نداند کدام درِ باز به هویت ممتاز یا داده حیاتی می‌رسد. سازمانی که exploit، سرویس exposed، identity و attack path را یک‌جا می‌بیند، سرمایه محدود اصلاح را همان جایی خرج می‌کند که جلوی گسترش حمله را می‌گیرد.

TRACEABLE KNOWLEDGE

منابع و مطالعهٔ بیشتر

01
Microsoft Security Research — What exploited vulnerabilities have in commonhttps://www.microsoft.com/en-us/security/blog/2026/11/02/exploited-vulnerabilities-common-data-driven-analysis-real-world-attacks/
02
Microsoft Learn — Microsoft Defender Vulnerability Management Exposure Scorehttps://learn.microsoft.com/defender-vulnerability-management/tvm-exposure-score
IROSG / EDITORIAL

خبرها و معرفی مشاهیر با نگارش مستقل و ذکر منبع تهیه شده‌اند. اعتبار و مجوز تصاویر در بخش منابع همین صفحه نگه‌داری می‌شود تا متن زیر عکس‌ها شلوغ نشود. داده‌های مرجع CVE با اعتباردهی به منابع اصلی ارائه می‌شوند.

سیاست تألیف و حقوق تصاویر ↗

ادامهٔ کشف.

تازه‌ها ↗