تحلیل فنی دفاعی و منبع‌محور: Storm-3168 و حملات ابری مبتنی بر عامل با سرویس‌پرینسیپال‌های در معرض…

مفاهیم و زمینه‌سازی: حمله‌های ابری مبتنی بر عامل (Agentic) و سرویس‌پرینسیپال‌های در معرض خطر

در حوزه امنیت سایبری، سرویس‌پرینسیپال‌ها (Service Principals) به عنوان هویت‌های برنامه‌محور در سرویس‌های ابری مانند Microsoft Azure عمل می‌کنند. این هویت‌ها برای دسترسی برنامه‌ها به منابع ابری ایجاد می‌شوند و اغلب دارای مجوزهای گسترده‌ای هستند. حملات مبتنی بر عامل (Agentic) به عملیات‌هایی گفته می‌شود که در آن‌ها از هوش مصنوعی یا سیستم‌های خودمختار برای هماهنگی و اجرای مراحل مختلف یک حمله استفاده می‌شود. این رویکرد نوین، به مهاجمان امکان می‌دهد تا عملیات پیچیده‌ای مانند شناسایی، تخریب و جمع‌آوری اطلاعات را با سرعت و مقیاسی فراتر از روش‌های سنتی انجام دهند.

بر اساس گزارش‌های منتشرشده توسط Microsoft Threat Intelligence، گروه تهدیدی با شناسه Storm-3168 (که با نام JADEPUFFER نیز شناخته می‌شود) به عنوان اولین عملیات باج‌افزاری مستند مبتنی بر عامل شناخته شده است. این گروه در جولای ۲۰۲۶ توسط Sysdig شناسایی شد و تحقیقات مایکروسافت نشان داد که فعالیت‌های آن فراتر از باج‌افزاری سنتی، شامل تخریب گسترده منابع در محیط Azure است. این یافته‌ها نشان‌دهنده تکامل عملیات ابری این مهاجم و ارائه اولین نمای دقیق از فعالیت‌های آن در Azure است.

در این حمله، مهاجمان با به خطر انداختن دو سرویس‌پرینسیپال متعلق به یک مستأجر (tenant) خاص، عملیات تخریبی گسترده‌ای را انجام دادند. یکی از این سرویس‌پرینسیپال‌ها برای شناسایی و کشف منابع و دیگری برای انجام عملیات تخریبی و جمع‌آوری اعتبارنامه‌ها استفاده شد. این فعالیت‌ها شامل حذف انبوه Storage Accounts، پایگاه‌های داده SQL، Key Vaultها، Function Appها، قفل‌های محافظت از بازیابی، ماشین‌های مجازی و App Serviceها بود. این نمونه بارز استفاده از هویت‌های ابری در معرض خطر برای انجام حملات مخرب در مقیاس بزرگ است.

• سرویس‌پرینسیپال‌ها هویت‌های برنامه‌محور در Azure هستند که برای دسترسی برنامه‌ها به منابع استفاده می‌شوند.
• حملات مبتنی بر عامل از هوش مصنوعی برای هماهنگی عملیات پیچیده استفاده می‌کنند.
• Storm-3168 (JADEPUFFER) اولین عملیات باج‌افزاری مستند مبتنی بر عامل است.
• فعالیت‌های تخریبی این گروه در Azure شامل حذف Storage Accounts، SQL databases، Key Vaults و سایر منابع است.

شواهد و تله‌متری: جزئیات فنی فعالیت‌های شناسایی و تخریب

بر اساس گزارش منتشرشده توسط مایکروسافت، در یک مستأجر (tenant) در معرض خطر، دو سرویس‌پرینسیپال (service principal) در معرض خطر قرار گرفته بودند که هر دو به زیرساخت مرتبط با Storm-3168 متصل بودند. اولین سرویس‌پرینسیپال عمدتاً به فعالیت‌های شناسایی پرداخته و به مدت تقریبی ۱۵ ساعت و ۳۰ دقیقه، با بیش از ۳۰۰ عملیات خواندن موفق، به شمارش و شناسایی ماشین‌های مجازی، اشتراک‌ها، گروه‌های منابع و سایر منابع در محیط آژور پرداخته بود. این فعالیت گسترده، دید وسیعی از محیط ابری سازمان در اختیار مهاجم قرار می‌دهد.

دومین سرویس‌پرینسیپال نیز فعالیت‌های شناسایی مشابهی را در مدت زمان بسیار کوتاه‌تری (حدود پنج ثانیه) بر روی ماشین‌های مجازی و گروه‌های منابع در دو اشتراک انجام داده بود. هر دو سرویس‌پرینسیپال از همان اثر انگشت شبکه و عامل کاربری یکسان «python-requests/2.34.2» استفاده می‌کردند. پس از حدود ۱۶ ساعت، دومین سرویس‌پرینسیپال اقدام به شمارش پیکربندی سرویس‌های برنامه (App Service) نمود و به طور ناموفق نیز سعی در یافتن منابع OpenSearch داشت. سپس عملیات‌های تخریبی آغاز شد.

توالی تخریبی که حدود ۷ دقیقه به طول انجامید، شامل بیش از ۱۰۰ تلاش برای حذف حساب‌های ذخیره‌سازی (Storage Accounts) بود که اکثر آنها موفق بودند. این عملیات تخریبی در ادامه به SQL databases، Key Vaults، Function Apps، Virtual Machines و App Services نیز گسترش یافت. مجموعاً، این سرویس‌پرینسیپال در یک بازه ۳۵ دقیقه‌ای، بیش از ۱۵۰ عملیات تخریبی یا مرتبط با جمع‌آوری اعتبارنامه انجام داد. با این حال، وجود قفل‌های منابع (resource locks) و محافظت حذف در سطح حساب ذخیره‌سازی، از حذف برخی منابع جلوگیری کرد.

این رصد نشان می‌دهد که مهاجم از ترکیب دو سرویس‌پرینسیپال برای جداسازی وظایف شناسایی و تخریب استفاده کرده است. فاصله کوتاه بین عملیات شناسایی و تخریب (کمتر از یک ثانیه پس از آخرین عملیات ناموفق ListKey) نشان‌دهنده خودکار بودن این عملیات است. این الگو، هماهنگی مبتنی بر عامل (agentic coordination) را تأیید می‌کند که در آن، یک عامل تصمیم‌گیرنده، اقدامات تخریبی را پس از تکمیل شناسایی آغاز می‌کند. برای تحلیل‌گران دفاعی، بررسی تله‌متری ورود به سیستم و رویدادهای مدیریتی در این بازه‌های زمانی کوتاه می‌تواند به شناسایی زودهنگام این الگو کمک کند.

• زمان‌بندی: شناسایی اولیه ۱۵ ساعت و ۳۰ دقیقه با بیش از ۳۰۰ عملیات خواندن موفق.
• سرویس‌پرینسیپال دوم: شمارش منابع در دو اشتراک در پنج ثانیه.
• شروع تخریب: کمتر از یک ثانیه پس از آخرین عملیات ناموفق ListKey.
• مدت تخریب: حدود ۷ دقیقه با بیش از ۱۰۰ تلاش برای حذف حساب ذخیره‌سازی.
• مجموع عملیات تخریبی و جمع‌آوری اعتبارنامه: بیش از ۱۵۰ عملیات در ۳۵ دقیقه.
• منابع هدف‌گیری‌شده: Storage Accounts، SQL databases، Key Vaults، Function Apps، Virtual Machines، App Services.

گردش کار حمله: از شناسایی تا تخریب و جمع‌آوری اعتبارنامه

بر اساس مستندات منتشرشده توسط مایکروسافت، فعالیت مخرب مرتبط با Storm-3168 در یک محیط اجاره‌ای (tenant) در Azure از طریق دو سرویس‌پرینسیپال به خطر افتاده انجام شده است. نخستین سرویس‌پرینسیپال در اوایل ژوئن ۲۰۲۶ حدود ۱۵ ساعت و نیم به شمارش ماشین‌های مجازی، اشتراک‌ها، گروه‌های منابع و منابع پرداخت و بیش از ۳۰۰ عملیات خواندن موفق انجام داد. این مرحله از شناسایی، دید گسترده‌ای از محیط ابری را برای مهاجم فراهم کرد. حدود ۹۰ دقیقه پس از شروع این شمارش، دومین سرویس‌پرینسیپال، شمارش ماشین‌های مجازی و گروه‌های منابع را در دو اشتراک در تنها پنج ثانیه انجام داد. هر دو سرویس‌پرینسیپال از زیرساخت مرتبط با Storm-3168، همان اثر انگشت شبکه و عامل کاربری python-requests/2.34.2 استفاده می‌کردند.

شانزده ساعت بعد، دومین سرویس‌پرینسیپال با موفقیت پیکربندی‌های App Service را شمارش کرد و احتمالاً به دنبال اعتبارنامه‌های در معرض دید بود. همچنین تلاش ناموفقی برای یافتن منابع OpenSearch انجام داد. هفتاد ثانیه پس از این عملیات فهرست‌برداری نهایی، همان سرویس‌پرینسیپال عملیات ListKey را علیه یک حساب ذخیره‌سازی ناموجود امتحان کرد. این توالی زمانی نشان می‌دهد که مهاجم پیش از اقدام مخرب، به دنبال یافتن منابع ارزشمند و اعتبارنامه‌های قابل استفاده بوده است. در این مرحله، هیچ نشانه‌ای از دسترسی به منابع OpenSearch وجود ندارد و به نظر می‌رسد تلاش برای یافتن چنین منابعی ناموفق بوده است.

کمتر از یک ثانیه پس از عملیات ListKey ناموفق، توالی تخریبی آغاز شد. در مدت زمان حدود هفت دقیقه، سرویس‌پرینسیپال دوم بیش از ۱۰۰ تلاش برای حذف حساب‌های ذخیره‌سازی انجام داد که بیشتر آن‌ها موفق بودند. در مجموع، طی ۳۵ دقیقه بیش از ۱۵۰ عملیات تخریبی یا جمع‌آوری اعتبارنامه ثبت شد. با این حال، برخی از تلاش‌های حذف به دلیل وجود قفل‌های منابع (resource locks) و محافظت از حذف در سطح حساب ذخیره‌سازی ناکام ماندند. این مشاهدات نشان می‌دهد که مهاجم به دنبال تخریب گسترده منابع و جمع‌آوری اعتبارنامه برای استفاده‌های بعدی بوده است.

1. شناسایی اولیه
2. شناسایی سریع
3. جستجوی اعتبارنامه
4. عملیات تخریب

راهنمای تریاژ: شناسایی و اولویت‌بندی هشدارهای مرتبط با سرویس‌پرینسیپال‌های در معرض خطر

در تحلیل رویدادهای مرتبط با Storm-3168، تریاژ مؤثر نیازمند توجه به نشانه‌های رفتاری خاصی است که در مستندات مایکروسافت به آن‌ها اشاره شده است. بر اساس شواهد موجود، دو سرویس‌پرینسیپال در معرض خطر در یک مستأجر (tenant) مشاهده شده‌اند که یکی به شناسایی منابع و دیگری به عملیات مخرب و جمع‌آوری اعتبارنامه پرداخته است. برای اولویت‌بندی هشدارها، ابتدا باید الگوهای زمانی غیرعادی مانند توالی سریع عملیات (مثلاً شمارش ماشین‌های مجازی و گروه‌های منابع در چند ثانیه) و حجم بالای عملیات خواندن (بیش از ۳۰۰ عملیات موفق در مدت کوتاه) را در نظر گرفت. این الگوها می‌توانند نشانه‌ای از فعالیت خودکار (agentic) باشند که نیاز به بررسی فوری دارند.

معیار مهم دیگر، استفاده از user agent خاص «python-requests/2.34.2» و زیرساخت مرتبط با Storm-3168 است. در تریاژ، هر رویدادی که این مشخصات را داشته باشد باید به‌عنوان پرخطر طبقه‌بندی شود، به‌ویژه اگر با عملیات حذف یا تلاش برای دسترسی به کلیدهای ذخیره‌سازی همراه باشد. همچنین توجه به توالی زمانی اهمیت دارد: در حمله مشاهده‌شده، عملیات مخرب حدود ۷ دقیقه طول کشیده و شامل بیش از ۱۰۰ تلاش برای حذف حساب ذخیره‌سازی بوده است. بنابراین، هشدارهایی که نشان‌دهنده تلاش‌های مکرر برای حذف منابع (مانند Storage Accounts، SQL databases، Key Vaults) هستند، باید در بالاترین اولویت تریاژ قرار گیرند.

برای تمایز بین مثبت کاذب و فعالیت واقعی، پیشنهاد می‌شود که تحلیلگران به دنبال ترکیب چند نشانه باشند: استفاده از user agent غیرمعمول، آدرس‌های IP مرتبط با زیرساخت شناخته‌شده Storm-3168، و الگوی زمانی که در آن عملیات شناسایی (reconnaissance) بلافاصله قبل از عملیات مخرب انجام می‌شود. به‌عنوان مثال، در این حمله، حدود ۹۰ دقیقه پس از شروع شمارش توسط سرویس‌پرینسیپال اول، سرویس‌پرینسیپال دوم شمارش سریع را انجام داد و سپس ۱۶ ساعت بعد عملیات مخرب آغاز شد. این توالی می‌تواند به عنوان یک معیار کمکی برای تأیید استفاده شود. لازم به ذکر است که این معیارها صرفاً بر اساس شواهد موجود است و ممکن است در محیط‌های دیگر متفاوت باشد؛ بنابراین توصیه می‌شود که تحلیلگران از قضاوت حرفه‌ای خود استفاده کنند.

• اولویت‌بندی هشدارها بر اساس ترکیب user agent خاص (python-requests/2.34.2) و زیرساخت مرتبط با Storm-3168.
• توجه به توالی سریع عملیات (مانند شمارش منابع در چند ثانیه) به عنوان نشانه فعالیت خودکار.
• بررسی تلاش‌های مکرر برای حذف منابع حیاتی (Storage Accounts، Key Vaults، SQL databases) به عنوان سیگنال پرخطر.
• استفاده از الگوی زمانی: فاصله کوتاه بین شناسایی و عملیات مخرب (مثلاً ۹۰ دقیقه یا ۱۶ ساعت) برای تأیید.

1. مرحله ۱: جمع‌آوری لاگ‌های ورود و فعالیت سرویس‌پرینسیپال‌ها در Microsoft Entra و Azure Activity Log.
2. مرحله ۲: فیلتر کردن رویدادها بر اساس user agent «python-requests/2.34.2» و آدرس‌های IP مرتبط با Storm-3168.
3. مرحله ۳: شناسایی الگوهای زمانی غیرعادی مانند شمارش سریع منابع یا توالی سریع عملیات حذف.
4. مرحله ۴: اولویت‌بندی هشدارهایی که شامل عملیات حذف (Delete) یا ListKey بر روی منابع حساس هستند.
5. مرحله ۵: بررسی وجود قفل‌های منابع (resource locks) و محافظت از حذف در سطح حساب ذخیره‌سازی به عنوان اقدامات کاهشی.

مثبت‌های کاذب: چالش‌های تشخیص فعالیت‌های مخرب در برابر عملیات عادی

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

نکته مهم این است که در این حمله، سرویس‌پرینسیپال‌های در معرض خطر از همان زیرساخت شبکه و عامل کاربری (python-requests/2.34.2) استفاده کرده‌اند که ممکن است با ابزارهای مدیریتی رایج در سازمان‌ها یکسان باشد. این اشتراک در شاخص‌های فنی، تشخیص را پیچیده‌تر می‌کند. به عنوان مثال، عملیات شمارش ماشین‌های مجازی و گروه‌های منابع که در مدت زمان کوتاهی انجام شده، می‌تواند با اسکریپت‌های خودکار پایش یا پشتیبان‌گیری اشتباه گرفته شود. همچنین تلاش برای دسترسی به کلیدهای ذخیره‌سازی (ListKey) ممکن است در نگاه اول به عنوان یک خطای پیکربندی یا تست نفوذ مجاز تفسیر شود.

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

• شباهت رفتارهای مخرب به عملیات مدیریتی مجاز، تشخیص را دشوار می‌کند.
• استفاده از شاخص‌های مشترک مانند عامل کاربری و زیرساخت شبکه، نیاز به تحلیل ترکیبی دارد.
• بررسی توالی زمانی و حجم عملیات می‌تواند به کاهش هشدارهای اشتباه کمک کند.

محدودیت‌ها: شکاف‌های اطلاعاتی و عدم قطعیت‌ها در تحلیل

تحلیل حاضر مبتنی بر گزارش عمومی مایکروسافت درباره فعالیت‌های مخرب Storm-3168 است و بنابراین با محدودیت‌های ذاتی داده‌های منبع مواجه است. مهم‌ترین شکاف اطلاعاتی، عدم وجود جزئیات در مورد نحوه به خطر افتادن سرویس‌پرینسیپال‌ها است. گزارش مایکروسافت اشاره می‌کند که دو سرویس‌پرینسیپال در یک مستأجر (tenant) به خطر افتاده‌اند، اما روش نفوذ اولیه (مانند فیشینگ، افشای اعتبارنامه، یا سوءاستفاده از آسیب‌پذیری) مشخص نیست. این ابهام، ارزیابی دقیق سطح ریسک و ارائه توصیه‌های پیشگیرانه متناسب با بردار حمله اولیه را دشوار می‌سازد.

دومین محدودیت، عدم شفافیت در مورد برخی عملیات ناموفق است. به عنوان مثال، گزارش به تلاش ناموفق برای جستجوی منابع OpenSearch و همچنین عملیات ListKey روی یک حساب ذخیره‌سازی غیرموجود اشاره دارد. این رویدادها نشان‌دهنده عدم آگاهی کامل مهاجم از محیط هدف است، اما جزئیات فنی بیشتری درباره دلیل این تلاش‌ها یا پیامدهای احتمالی آن‌ها در دسترس نیست. همچنین مشخص نیست که آیا این تلاش‌های ناموفق صرفاً خطا بوده یا بخشی از یک فرآیند شناسایی سیستماتیک برای کشف منابع حساس بوده‌اند.

علاوه بر این، گزارش مایکروسافت عمدتاً بر روی فعالیت‌های مخرب موفق و توالی زمانی آن‌ها تمرکز دارد و اطلاعات محدودی در مورد اقدامات دفاعی که توسط سازمان قربانی انجام شده یا تأثیرات نهایی بر روی داده‌ها و سرویس‌ها ارائه می‌دهد. به عنوان مثال، اشاره شده که برخی حذف‌ها توسط قفل‌های منبع (resource locks) مسدود شده‌اند، اما مشخص نیست که این قفل‌ها به طور پیش‌فرض فعال بوده‌اند یا در واکنش به حمله اعمال شده‌اند. این ابهامات، قضاوت در مورد اثربخشی کنترل‌های امنیتی موجود را محدود می‌کند.

در نهایت، تحلیل حاضر صرفاً بر اساس یک منبع واحد (گزارش مایکروسافت) انجام شده است و داده‌های مستقلی از محیط‌های آسیب‌دیده در دسترس نیست. بنابراین، هرگونه نتیجه‌گیری در مورد انگیزه‌های مهاجم، اهداف نهایی، یا ارتباط با سایر کمپین‌ها باید به عنوان فرضیه در نظر گرفته شود. توصیه‌های ارائه شده در این تحلیل نیز بر اساس الگوهای مشاهده شده و بهترین شیوه‌های عمومی امنیت ابری است و باید با توجه به شرایط خاص هر سازمان سفارشی‌سازی شود.

• عدم وجود جزئیات در مورد روش نفوذ اولیه به سرویس‌پرینسیپال‌ها
• عدم شفافیت در مورد عملیات ناموفق مانند جستجوی OpenSearch و ListKey روی حساب غیرموجود
• فقدان اطلاعات در مورد اقدامات دفاعی سازمان قربانی و اثربخشی آن‌ها
• تکیه صرف بر یک منبع واحد و عدم دسترسی به داده‌های مستقل

شاخص‌های اندازه‌گیری: معیارهای کمی برای ارزیابی پاسخ به تهدید

در تحلیل رویداد Storm-3168، تعریف معیارهای کمی برای سنجش اثربخشی اقدامات دفاعی ضروری است. بر اساس داده‌های موجود در گزارش، می‌توان سه شاخص اصلی را استخراج کرد: تعداد عملیات تخریبی مسدودشده، زمان بین تشخیص تا پاسخ، و تعداد منابع محافظت‌شده. این معیارها باید به‌صورت دوره‌ای و در قالب داشبوردهای عملیاتی پایش شوند تا تیم‌های امنیتی بتوانند روند بهبود یا افت آمادگی خود را مشاهده کنند. به‌ویژه در حملاتی که از هویت‌های سرویس‌محور بهره می‌برند، سرعت واکنش به تغییرات رفتاری غیرعادی، نقشی تعیین‌کننده در کاهش دامنه خسارت دارد.

معیار نخست، «تعداد عملیات تخریبی مسدودشده» است. در این رویداد، مهاجم در یک بازه زمانی کوتاه (حدود ۷ دقیقه) بیش از ۱۰۰ تلاش برای حذف حساب‌های ذخیره‌سازی انجام داد. بنابراین، هر سامانه دفاعی باید بتواند تعداد این تلاش‌ها را که توسط قفل‌های منبع یا سیاست‌های حفاظتی متوقف شده‌اند، شمارش و گزارش کند. این عدد به‌طور مستقیم نشان‌دهنده اثربخشی کنترل‌های پیشگیرانه است. به‌عنوان مثال، اگر در یک سازمان ۵۰ تلاش حذف رخ دهد و ۴۵ مورد آن مسدود شود، نرخ موفقیت دفاعی ۹۰ درصد خواهد بود. این شاخص باید به‌همراه جزئیات نوع منبع (ذخیره‌سازی، پایگاه داده، Key Vault و غیره) ثبت شود.

معیار دوم، «زمان تشخیص تا پاسخ» است. در گزارش، فاصله بین شروع شناسایی توسط اولین سرویس‌اصلی در معرض خطر و شروع عملیات تخریبی حدود ۱۶ ساعت بوده است. این بازه زمانی، فرصتی حیاتی برای مداخله فراهم می‌کند. بنابراین، سازمان‌ها باید زمان سپری‌شده از اولین هشدار رفتاری (مانند شمارش غیرعادی منابع) تا اعمال اقدامات مهارکننده (مانند غیرفعال‌سازی اعتبارنامه یا اعمال قفل) را اندازه‌گیری کنند. هدف باید کاهش این زمان به کمتر از ۳۰ دقیقه باشد. معیار سوم، «تعداد منابع محافظت‌شده» است؛ یعنی تعداد حساب‌های ذخیره‌سازی، ماشین‌های مجازی، و سایر منابعی که به‌واسطه قفل‌های حذف یا سیاست‌های دسترسی حداقلی از تخریب مصون مانده‌اند. این عدد باید نسبت به کل منابع موجود در محیط محاسبه شود.

توجه: این معیارها صرفاً بر اساس داده‌های موجود در گزارش استخراج شده‌اند و برای تعمیم به سایر محیط‌ها نیاز به بومی‌سازی دارند. همچنین، پیشنهاد می‌شود که این شاخص‌ها به‌صورت خودکار از طریق ابزارهای SIEM و Defender for Cloud جمع‌آوری شده و در گزارش‌های ماهانه امنیتی منعکس شوند. هرگونه بهبود در این معیارها باید مستند و با اقدامات اصلاحی همراه باشد.

• تعداد عملیات تخریبی مسدودشده: شمارش تلاش‌های ناموفق برای حذف منابع (مانند Storage Accounts) که توسط قفل‌ها یا سیاست‌های حفاظتی متوقف شده‌اند.
• زمان تشخیص تا پاسخ: فاصله زمانی بین اولین فعالیت مشکوک (مانند شمارش منابع) و اعمال اقدامات مهارکننده (مانند چرخش کلید یا غیرفعال‌سازی سرویس‌اصلی).
• تعداد منابع محافظت‌شده: تعداد منابعی که به‌واسطه قفل‌های حذف، محافظت از حذف در سطح حساب ذخیره‌سازی، یا دسترسی حداقلی از تخریب در امان مانده‌اند.

1. استخراج لاگ‌های مربوط به عملیات حذف و شمارش تعداد تلاش‌های مسدودشده با استفاده از Microsoft Defender for Cloud.
2. اندازه‌گیری زمان بین اولین هشدار رفتاری و زمان اعمال پاسخ خودکار یا دستی.
3. تهیه فهرست دوره‌ای از منابع دارای قفل حذف و مقایسه آن با فهرست منابعی که در معرض خطر بوده‌اند.

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

بر اساس یافته‌های منتشرشده توسط Microsoft Threat Intelligence درباره فعالیت‌های مخرب Storm-3168، سازمان‌ها باید اقدامات مشخصی را برای کاهش سطح ریسک در محیط‌های ابری خود اجرا کنند. این اقدامات صرفاً مبتنی بر توصیه‌های ارائه‌شده در متن اصلی است و هرگونه توصیه اضافی خارج از چارچوب مذکور، به‌عنوان استنتاج شخصی تلقی می‌شود. تمرکز اصلی بر محافظت از هویت‌های کاری و اسرار، اعمال حداقل دسترسی، محافظت از منابع بازیابی و فعال‌سازی Microsoft Defender for Cloud است.

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

دومین اقدام، اعمال اصل حداقل دسترسی (Least Privilege) است. سرویس‌پرینسیپال‌ها باید تنها به منابع و عملیات ضروری برای عملکرد خود دسترسی داشته باشند. این اصل به‌ویژه برای سرویس‌پرینسیپال‌هایی که وظایف مدیریتی یا خودکارسازی را انجام می‌دهند، حیاتی است. در حمله مشاهده‌شده، سرویس‌پرینسیپال‌های در معرض خطر قادر به انجام عملیات مخرب گسترده‌ای مانند حذف Storage Accountها و دسترسی به Key Vaultها بودند که نشان‌دهنده وجود دسترسی‌های بیش از حد لازم است.

سومین اقدام، محافظت از منابع بازیابی (Recovery Resources) است. در این حمله، قفل‌های منابع (Resource Locks) و محافظت از حذف در سطح Storage Account، تا حدی مانع تخریب کامل شدند. سازمان‌ها باید از این مکانیزم‌ها برای منابع حیاتی خود استفاده کنند و اطمینان حاصل کنند که قفل‌ها به‌درستی پیکربندی شده‌اند تا از حذف تصادفی یا عمدی جلوگیری شود. همچنین باید فرآیندهای بازیابی و پشتیبان‌گیری را در برابر حملات مخرب مقاوم‌سازی کنند.

در نهایت، فعال‌سازی Microsoft Defender for Cloud به‌عنوان یک اقدام پیشگیرانه و واکنشی توصیه شده است. این سرویس می‌تواند به شناسایی فعالیت‌های غیرعادی، مانند شمارش گسترده منابع یا تلاش‌های حذف انبوه، کمک کند. سازمان‌ها باید تنظیمات این سرویس را به‌گونه‌ای پیکربندی کنند که هشدارهای مرتبط با دسترسی‌های غیرمجاز به سرویس‌پرینسیپال‌ها و عملیات مخرب را به تیم امنیتی اطلاع دهد. این اقدامات، اگرچه جامع نیستند، اما پایه‌ای برای کاهش ریسک در برابر تهدیداتی مانند Storm-3168 فراهم می‌کنند.

• محافظت از هویت‌های کاری و اسرار: جلوگیری از ذخیره‌سازی اعتبارنامه در مکان‌های ناامن، چرخش دوره‌ای و ابطال سریع اعتبارنامه‌های افشاشده.
• اعمال حداقل دسترسی: محدود کردن دسترسی سرویس‌پرینسیپال‌ها به منابع و عملیات ضروری.
• محافظت از منابع بازیابی: استفاده از قفل‌های منابع و محافظت از حذف برای منابع حیاتی.
• فعال‌سازی Microsoft Defender for Cloud: برای شناسایی و پاسخ به فعالیت‌های غیرعادی.

1. مرحله ۱: ممیزی کامل از تمام سرویس‌پرینسیپال‌ها و مجوزهای آن‌ها انجام دهید و دسترسی‌های غیرضروری را حذف کنید.
2. مرحله ۲: برای تمام اعتبارنامه‌های ذخیره‌شده، فرآیند چرخش دوره‌ای تنظیم کنید و در صورت مشاهده هرگونه افشا، بلافاصله آن‌ها را باطل کنید.
3. مرحله ۳: بر روی تمام Storage Accountها و منابع حیاتی، قفل‌های حذف (Delete Locks) فعال کنید و محافظت از حذف را در سطح Storage Account اعمال کنید.
4. مرحله ۴: Microsoft Defender for Cloud را فعال کرده و هشدارهای مرتبط با دسترسی به سرویس‌پرینسیپال‌ها و عملیات حذف انبوه را پیکربندی کنید.