از آغاز سال جدید میلادی، خبرهای زیادی در خصوص هک کمپانی های بزرگ میاد از جمله ی اونا میشه به هک مایکروسافت ، AnyDesk و حالا هم که کلودفلر .
روز شکرگزاری ، 23 نوامبر ، کلودفلر فعالیت یه بازیگر تهدید رو در سرور Atlassian خودش شناسایی کرد. تیم امنیتی وارد کار شده و دسترسی بازیگر تهدید رو قطع کرده. روز 26 نوامبر، تیم فارنزیک CrowdStrike برای تحقیقات و بررسی مستقل وارد کار میشه.
در نهایت بعد از تکمیل فرایند فارنزیک توسط CrowdStrike ، کلودفلر جزییاتی از این رخداد امنیتی رو منتشر کرده که در این پست بررسیش میکنیم.
کلودفلر اعلام کرده که، داده یا سیستمی از مشتریاش، تحت تاثیر این رخداد امنیتی نبوده. استفاده از رولهای فایروال ، کنترل دسترسی و کلید های امنیتی که توسط ابزارهای Zero Trust اشون اعمال میشه، توانایی حرکت جانبی توسط بازیگر تهدید رو محدود کرده. هیچ سرویس یا سیستم یا پیکربندی تحت تاثیر این رخداد امنیتی قرار نگرفته. این ضمانت یه معماری Zero Trust هست ،که مانند دیوارهای یه کشتی عمل میکنه و با محدود کردن سیستمی که تحت تاثیر قرار گرفته ، از به خطر افتادن کل سازمان، جلوگیری میکنه.
از 14 تا 17 نوامبر، بازیگر تهدید فرایند ریکان رو انجام داده و بعدش تونسته به ویکی داخلی کلودفلر که روی Atlassian Confluence بوده و دیتابیس باگ هاشون که روی Atlassian Jira بوده ، دسترسی پیدا کنه.
20 و 21 نوامبر ، شاهد یسری دسترسی دیگه بودن که احتمالا نشون دهنده اینه که بازیگر تهدید برگشته تا بررسی کنه که آیا دسترسی هاشون همچنان در دسترسه یا نه.
22 نوامبر بازیگر تهدید برگشته و با استفاده از پلاگین ScriptRunner for Jira ، روی سرور Atlassian پرسیست کرده ، در ادامه به سیستم مدیریت سورس کدشون که روی Atlassian Bitbucket بوده، دسترسی پیدا کرده. در ادامه تلاش کردن تا به یه سرور کنسول که به دیتاسنتری در سائوپائولو برزیل دسترسی داشته و کلودفلر هنوز اونو تکمیل نکرده، دسترسی پیدا کنن، که این کارشون ناموفق بوده. سرور کنسول دستگاهیه که در مدیریت شبکه استفاده میشه که دسترسی ایمن به پورت های کنسول سایر تجهیزات شبکه مانند روترها، سوئیچ ها، سرورها و سایر دستگاه های شبکه رو فراهم میکنه. این پورتهای کنسول به ادمینها اجازه میده تا مستقیماً دستگاههای متصل رو پیکربندی، نظارت و عیب یابی کنن، مخصوصاً در شرایطی که دستگاه‌ها از طریق شبکه در دسترس نباشه.
بازیگر تهدید این حمله رو با استفاده از یه Access token و سه اعتبارنامه اکانت سرویس که از حمله سایبری به Okta در اکتبر 2023 لو رفته بوده، انجام داده و متاسفانه کلودفلر بعد از اطلاع از این رخداد امنیتی، این اکانتها رو تغییر یا بروزرسانی نکرده بوده.
تمام دسترسی ها ی بازیگر تهدید در 24 نوامبر قطع شده و تیم فارنزیک CrowdStrike تایید کرده که آخرین شواهد فعالیت بازیگر تهدید برای 24 نوامبر، ساعت 10:44 هستش.
کلودفلر اعلام کرده اگرچه تاثیر عملیاتی این حادثه خیلی کم بوده، اما اونو جدی گرفتن، چون بازیگر تهدید از اعتبارنامه های سرقت شده برای دسترسی به سرور Atlassian اشون استفاده کرده، به برخی اسناد و سورس های کدشونم دسترسی داشته. کلودفلر گفته بدلیل همکاریشون با دولت و صنعت ، این حمله توسط یه بازیگر تهدید دولتی انجام شده که هدفشون رسیدن به دسترسی پایدار و گسترده به Cloudflare global network بوده.
با توجه به اینکه این هک تحت تاثیر هک Okta بوده، اول یه نگاهی به این هک میندازیم.
هک Okta :
Okta که قبلا با نام Saasure شناخته میشد، یه شرکت مدیریت شناسه و دسترسی هست که در سانفرانسیسکو آمریکا قرار داره. یه برنامه ابری داره که به سازمانها و شرکتها کمک میکنه تا احرازهویت کاربراشون رو در برنامه ها مدیریت و امن کنن. همچنین توسعه دهندگان از این سرویس ها برای کنترل شناسه ها در برنامه ها و سرویس های وب و دستگاههاشون استفاده میکنن.
Okta در 20 اکتبر اعلام کرد که مهاجمین به فایلهای حاوی کوکی و توکن های جلسه ی آپلود شده توسط برخی از مشتریاشون در سیستم مدیریت پشتیبانیشون دسترسی پیدا کردن . این شرکت گفت، به اکانتهایی که تحت تاثیر این حمله بود، اطلاعرسانی کردن تا موارد امنیتی رو اعمال کنن.
Okta اعلام کرده بود که مهاجمان از اواخر سپتامبر 2023/اوایل مهر 1402 به اکانت 134 تا از مشتریاشون (1% از کل مشتریاشون) و نام و آدرس ایمیل همه کاربران سیستم پیشتبانیشون دسترسی داشتن. در بیانیه ای که این شرکت منتشر کرده بود، همه ی مشتریان Okta Workforce Identity Cloud (WIC) و Customer Identity Solution (CIS) به غیر از مشتریانی که در محیط FedRamp High and DoD IL4 بودن تحت تاثیر این حمله بودن. خود شرکت 17 اکتبر/25 مهر 1402 متوجه این حمله شده بود.
سیستم مدیریت پشتیبانی این شرکت، برای ذخیره ی فایلهای HTTP Archive (HAR) هم استفاده میشه که برای بازتولید خطاهای کاربر یا ادمین برای عیب یابی مشکلات مختلف گزارش شده توسط کاربران استفاده میشه. فرمت HTTP Archive یا HAR یه فرمت فایل آرشیو با فرمت JSON ،برای ثبت تعامل مرورگر وب با یه سایته و پسوند رایجش har. هست.
این فایلها حاوی اطلاعات حساسی مانند کوکی ها یا توکن های جلسه، صفحات بازدید شده، هدرها و … هستن، که مهاجمین از اونا میتونن برای جعل و دسترسی به اکانتهای کاربران استفاده کنن.
بعد از این رخداد، Okta همه ی توکن های موجود در این فایلها رو باطل و اعلام کرد که قبل از ارسال، اونارو بررسی کنن تا شامل اطلاعات حساس نباشن.
یکی از شرکتهایی که تحت تاثیر نقض Okta قرار گرفت، کمپانی BeyondTrust بود. این شرکت در زمینه مدیریت دسترسی، شناسه و آسیب پذیری فعالیت میکنه. تیم امنیتی این شرکت، 2 اکتبر تلاش برای ورود به یه اکانت داخلی Okta از یه کوکی دزدیده شده از سیستم پشتیبانی Okta رو مشاهده و مسدود کرد و در ادامه به Okta گزارش داده. 19 اکتبر Okta در پاسخ گفته که خودشون هک شدن و اینجوری متوجه شدن که یکی از قربانیان هک Okta هستن.
دومین شرکتی که اعلام کرد تحت تاثیر این حمله بوده کلودفلر بود. این شرکت 18 اکتبر شواهدی مبنی بر ورود به سیستمهاش از طریق اطلاعات نقض شده از سیستم مدیریت پشتیبانی Okta گزارش کرد. این حمله توسط تیم SIRT کلودفلر خنثی شده و در ادامه این رخداد رو به Okta گزارش کردن و متوجه شدن که Okta هک شده بوده.
علاوه بر این دو شرکت، 1Password و Caesar’s Entertainment و MGM Resorts هم تحت تاثیر این نقض Okta قرار گرفتن.
در ادامه کلودفلر دوباره ، 23 نوامبر/2 آذر 1402 یه فعالیت مشکوک رو شناسایی میکنه که در این پست بهش اشاره کردیم.
پروژه Code Red :
24 نوامبر که دسترسی بازیگر تهدید رو قطع کردن، تیم امنیتی کلودفلر همه افراد مورد نیازش در سراسر شبکه رو جذب کرده تا نفوذ رو بررسی کنن. هدف از این کار هم دو مورد بود:
- مطمئن بشن که همه ی دسترسی های بازیگر تهدید به سیستمهاشون قطع شده.
- مطمئن بشن هر چیزی که بازیگر تهدید بهش دسترسی داشته یا میخواسته دسترسی داشته باشه رو میدونن.
بنابراین 27 نوامبر اومدن همه ی افراد فنی رو برای کار روی یه پروژه بنام Code Red جمع کردن. تمرکز این پروژه روی تقویت، اعتبارسنجی و اصلاح هر کنترلی در محیطشون بوده تا مطمئن بشن در برابر نفوذهای آتی ایمن هستن و بتونن تایید کنن که بازیگر تهدید نمیتونه به محیطشون دسترسی داشته باشه. همچنین همه سیستم ها، اکانتها و لاگ هارو بررسی کردن تا تایید کنن که بازیگر تهدید خودش پرسیست نکرده و متوجه بشن که بازیگر تهدید به کدوم سیستم ها دسترسی داشته و میخواسته به کدوم سیستمها دسترسی داشته باشه.
تیم CrowdStrike هم یه ارزیابی مستقل از دامنه و گستره فعالیتهای بازیگر تهدید انجام داده از جمله جستجو برای شواهدی مبنی بر حضور بازیگر تهدید در سیستمهاشون. تحقیقات CrowdStrike باعث تایید و پشتیبانی تحقیقات تیم امنیتی کلودفلر بوده و تقریبا چیزی گزارش ندادن که تیم امنیتی کلودفلر پیداشون نکرده باشه.
تنها سیستم تولیدی که بازیگر تهدید با استفاده از اعتبارنامه های سرقت شده، تونسته بهش دسترسی پیدا کنه، محیط Atlassian اشون بوده. با بررسی صفحات ویکی که اونا بهش دسترسی داشتن و دیتابیس باگ ها و مخازن سورس کدشون، به نظر میرسه اونا دنبال اطلاعاتی در خصوص معماری و امنیت و مدیریت Cloudflare global network بودن تا بتونن جای پای خودشون رو محکم کنن. برا همین ، کلودفر تصمیم گرفته که تلاش زیادی برای سختتر کردن پروتکل‌های امنیتیشون بکنه تا در صورتی که چیزی از فایلهای لاگ از قلم افتاده باشه، بازیگر تهدید نتونه اون جایگاه رو دوباره بدست بیاره.
یکی از اهدافی که کلودفلر در پاسخ به این رخداد داشته این بوده که مهاجم با استفاده از اطلاعات فنی در خصوص شبکه اشون، نتونه دوباره بگرده. با وجود اینکه کلودفلر معتقد بوده و بعدا تایید کرده که مهاجم دسترسی محدودی داشته اما همه ی اعتبارنامه های بخش تولید که بیش از 5000 ها مورد بوده رو تغییر و بروزرسانی کرده، سیستم های بخش تست و مرحله بندی ( مرحله بندی شبیه محیط تسته اما معمولا برای شبیه سازی بیشتر از محیط تولید استفاده میکنن. اغلب شامل داده های تولید و پیکربندی ها هستن تا مطمئن بشن هر بروزرسانی یا تغییری قبل از استقرار نرم افزار، تست شده) رو اومدن بصورت فیزیکی جدا و جایگزین کردن (سخت افزار جایگزین کردن)، فرایند فارنزیک رو روی 4,893 سیستم انجام دادن ، هر ماشینی که در Cloudflare global network بوده از جمله مواردی که مهاجم بهشون دسترسی داشته و همه ی محصولات Atlassian (Jira, Confluence, and Bitbucket) رو پاک کردن و دوباره سیستم عامل روشون نصب کردن و بالا آوردن.
بازیگر تهدید همچنین خواسته به سرور کنسول در دیتاسنتر جدیدی در سائوپائولو برزیل که هنوز بالا نیومده، دسترسی پیدا کنه ،با اینکه تو این کار هم موفق نبوده، کلودفلر برای اطمینان 100درصد از امنیتش، اومده همه ی سیستم ها و تجهیزات این دیتاسنتر رو به سازندگانشون برگردونده. تیم‌های فارنزیک سازندگان همه سیستمها رو بررسی کردن تا مطمئن بشن که هیچ دسترسی به دست نیومده . چیزی پیدا نکردن ، اما کلودفلر سخت افزار رو تعویض کرده.
در ادامه اومدن همه بسته های نرم افزاری که بروزرسانی نشدن، اکانتهایی که ممکنه ایجاد شده باشن، اکانتهای کارمندانی که دیگه استفاده نمیشن، اطلاعات حساسی که در تیکتهای Jira یا سورس کدها بودن، همه ی فایلهای HAR آپلود شده در ویکی که حاوی توکن بودن، رو جستجو کردن. به هر چیزی که شک میکردن، بدترین سناریو رو براش در نظر گرفتن، بنابراین تغییراتی ایجاد کردن تا مطمئن بشن اگه مهاجم به اون دسترسی پیدا کنه، نتونه ازش استفاده کنه و یه چیز ارزشمند براش نباشه.
اعضای تیم روی جاهایی که ممکنه عامل تهدید بهشون دسترسی داشته باشه، تمرکز کردن، بنابراین فایلهای لاگ رو بررسی کنن و تونستن میزان دسترسی بازیگر تهدید رو مشخص کنن. کلودفلر گفته که هدفشون از استفاده از افراد زیاد در این فرایند این بوده که دنبال شواهدی مبنی بر دسترسی یا تغییراتی که باید برای بهبود امنیت انجام بدن، بودن و خلاصه اینکه سنگ تموم بزارن.
این تلاشها که با عنوان Code Red انجام شد، درنهایت در 5 ژانویه به پایان رسید،اما کار در سراسر شرکت روی مدیریت اعتبارنامه ها، مدیریت آسیب پذیری ها ، امن سازی نرم افزار، اعلان هشدارهای اضافی و … ادامه داره. ( از 27 نوامبر تا 5 ژانویه – 6 آذر تا 15 دی فقط فرایند Code Red بوده)
جدول زمانی حمله :
حمله در ماه اکتبر بعد از هک Okta شروع شده اما بازیگر تهدید اواسط نوامبر شروع به هدف قرار دادن سیستم های کلودفلر با استفاده از اعتبارنامه های بدست اومده از هک Okta کرده.
در زیر جدول زمانی رویدادهای مهم رو بررسی میکنیم:
18 اکتبر/26 مهر – هک Okta :
این دومین باری بوده که کلودفلر ، قربانی هک Okta بوده. بازیگر تهدید با بدست آوردن یسری اعتبارنامه ، تونسته به کلودفلر نفوذ کنه. این اعتبارنامه ها باید تغییر و بروزرسانی میشد ، اما کلودفلر سهل انگاری کرده و یه شناسه سرویس و سه اعتبارنامه ی اکانت سرویس رو از هزاران موردی که در جریان هک Okta لیک شده بود رو تغییر یا بروزرسانی نکرده.
برخلاف اکانتهای کاربری استاندارد، که انسانها به اونا دسترسی دارن، اکانتهای سرویس بیشتر برای خودکار کردن عملکردهای ماشین به ماشین، مانند انجام پشتیبان‌گیری از داده ها یا اسکن آنتی ویروس هر شب در یه زمان خاص، رزرو میشن. به همین دلیل، نمیشه اونارو را با احراز هویت چند عاملی امنشون کرد.
یکیشون شناسه سرویس Moveworks بود که به سیستم Atlassian اشون دسترسی راه دور میداد. یکی از اعتبارنامه ها مربوط به اکانت سرویسی بود که توسط برنامه ی Smartsheet که مبتنی بر SaaS هست، دسترسی مدیریتی به سیستم Atlassian Jira اشون داشته. اعتبارنامه ی بعدی مربوط به اکانت سرویس Bitbucket بوده که برای دسترسی به سیستم مدیریت سورس کدشون استفاده میشده و در نهایت آخرین اکانت مربوط به AWS بود که دسترسی به Global Network ، داده های حساس یا مشتریان نداشته.
دلیل این سهل انگاری هم این بوده که فک میکردن این اکانتها استفاده نمیشن. قسمت جالب هم اینجاست که کلودفلر گفته این خطایی از سمت Atlassian, AWS, Moveworks یا Smartsheet نبوده و بلکه اشتباه از جانب ما بوده که این اکانتها رو تغییر یا بروزرسانی نکردیم.
14 نوامبر/23 آبان ساعت 09:22:49 – بازیگر تهدید شروع به بررسی میکنه
لاگ ها نشون میدن که بازیگر تهدید از 14 نوامبر ، شروع به ریکان و پیدا کردن سیستمهایی بوده که بتونه از اعتبارنامه ایی که در دست داره، واردشون بشه. سعی کردن به Okta و Cloudflare Dashboard وارد بشن، اما نتونستن.
بازیگر تهدید به یه AWS دسترسی پیدا کرده که برای مارکت Cloudflare Apps هست و روش نه داده حساسیه نه داده مشتری و نه دسترسی به Global Network داره. اکانت سرویسی که برای دسترسی به این محیط استفاده شده، کلا باطل و یکپارچگی محیط رو هم تایید کردن.
15 نوامبر/24 آبان ساعت 16:28:38 – بازیگر تهدید به سرویس های Atlassian دسترسی پیدا کرده.
مهاجم با موفقیت در 15 نوامبر با استفاده از توکن سرویس Moveworks تونسته به Atlassian Jira و Confluence دسترسی پیدا کنه و بعدش از اکانت سرویس Smartsheet ،برای دسترسی به محیط Atlassian استفاده کرده. روز بعدش شروع به جستجوی اطلاعاتی در خصوص پیکربندی و مدیریت Cloudflare global network کردن و به تیکتهای مختلف Jira دسترسی پیدا کردن.
مهاجم در ویکی دنبال مواردی مانند اجرای کد از راه دور ، اطلاعات حساس، client-secret ، openconnect ، cloudflared و توکن بوده. از مجموع 2,059,357 تیکت Jira به 36 تیکت و از 194,100 صفحه ویکی به 202 صفحه دسترسی داشته.
تیکتهایی که مهاجم بهشون دسترسی داشته در خصوص مدیریت آسیب پذیری ، تغییر و بروزرسانی اطلاعات حساس، دور زدن MFA ، دسترسی شبکه و حتی پاسخ به حوادث کلودفلر به Okta بوده.
با توجه به جستجوهایی که مهاجم در صفحات ویکی انجام داده، نشون میده که مهاجم بیشتر علاقه به همه جنبه های دسترسی به سیستم های کلودفلر داشته : بازیابی پسورد، دسترسی از راه دور، پیکربندی، استفاده کلودفلر از Salt ، اما داده ها یا پیکربندی های مشتریان رو هدف قرار نداده.
16 نوامبر/25 آبان ساعت 14:36:37 – مهاجم یه اکانت کاربر Atlassian ایجاد کرد
مهاجم از اعتبارنامه Smartsheet برای ایجاد یه اکانت کاربری Atlassian استفاده کرده که شبیه یه کاربر معمولی Cloudflare بود. اونا این کاربر رو به تعدادی از گروه‌های داخلی Atlassian اضافه کردن تا اگه اکانت سرویس Smartsheet حذف شد، دسترسی به محیط Atlassian رو همچنان داشته باشن.
17 نوامبر/26 آبان ساعت 14:33:52 تا 20 نوامبر/29 آبان 09:26:53 – استراحت
تو این بازه ی مهاجم رفته برای استراحت و فقط هر از گاهی چک میکرده ببینه دسترسی برقراره یا نه.
22 نوامبر/1 آذر ساعت 14:18:22 – مهاجم پرسیست میکنه
از اونجایی که اکانت سرویس Smartsheet به Atlassian Jira دسترسی مدیریتی داشته، مهاجم تونسته Sliver Adversary Emulation Framework رو ، که یه ابزار و فریمورک کاربردی برای تیم‌های قرمز و مهاجمان برای فعال کردن C2 هست، برای دسترسی پایدار و مخفیانه به سیستمها نصب کنه . Sliver با استفاده از پلاگین ScriptRunner for Jira نصب شده.
اینکار دسترسی پایدار به سرور Atlassian رو در اختیار مهاجمین قرار داده و مهاجم میتونسته فرایند حرکت جانبی رو هم انجام بده. با این دسترسی مهاجم خواسته به سرور کنسول یه دیتاسنتر در برزیل هم دسترسی بگیره که این کار موفقیت آمیز نبوده.
روز بعدش مهاجم تونسته به 120 مخزن کد از 11,904 مخزن دسترسی داشته باشه. از این 120 مورد، مهاجم با استفاده از ویژگی Atlassian Bitbucket git archive تونسته 76 مورد رو روی سرور Atlassian دانلود کنه. کلودفلر گفته اگرچه ما نتونستیم تایید کنیم که این مخازن استخراج شدن یا نه، اما اونا رو بعنوان یه مخزن استخراج شده در نظر گرفتیم.
این 76 مخزن کد تقریباً همه اشون مربوط به نحوه کار پشتیبان گیری، نحوه پیکربندی و مدیریت Cloudflare global network، نحوه کارکرد شناسه در Cloudflare، دسترسی از راه دور و استفاده کلودفلر از Terraform و Kubernetes بودن. تعداد کمی از مخازن حاوی اطلاعات حساس رمزگذاری شده بودن که با وجود اینکه خودشون به شدت رمزگذاری شده بودن، فوراً تغییر و بروزرسانی شدن.
کلودفلر روی این 76 مخزن کد تمرکز کرده و دنبال اطلاعات حساس جاسازی شده، آسیب پذیری ها و راه هایی که مهاجم میتونه از اونا برای حمله بعدی استفاده کنه، بوده . این کار بعنوان یه اولویت توسط تیم های مهندسی در سراسر شرکت به عنوان بخشی از “Code Red” انجام شده.
کلودفلر بعنوان یه شرکت SaaS، این باور داره که سورس کدهاش به اندازه سورس کدهای شرکتهای نرم‌افزاری که نرم‌افزارشون رو بین کاربران نهایی توزیع میکنن، ارزشمند نیست. مقدار زیادی از سورس کدهاشون رو منبع باز کردن و از طریق وبلاگشون در مورد الگوریتم ها و تکنیک هایی که استفاده می کنیم، آشکارا صحبت کردن. بنابراین تمرکزشون روی دسترسی به سورس کد نبوده، بلکه رو این بوده که آیا این سورس کد حاوی اطلاعات حساس جاسازی شده (مانند کلید یا توکن) و آسیب‌پذیری هست یا نه.
23 نوامبر/2 آذر – کشف و خاتمه دسترسی بازیگر تهدید
تیم امنیتی ساعت 16 ، متوجه این نفوذ شده و 35 دقیقه بعد اکانت سرویس Smartsheet رو بسته. 48 دقیقه بعد اکانت ایجاد شده توسط مهاجم کشف و غیرفعال کرده. در زیر، جدول زمانی از اقداماتی که بعد از اولین هشدار گرفتن رو مشاهده میکنید :
- 15:58 – مهاجم اکانت سرویس Smartsheet رو به یه گروه مدیریتی اضافه کرد.
- 16:00 – هشدار اولیه در خصوص تغییرات 15:58 به تیم امنیتی ارسال شده.
- 16:12 – تیم Cloudflare SOC شروع به بررسی هشدار میکنه.
- 16:35 – اکانت سرویس Smartsheet توسط تیم Cloudflare SOC غیرفعال میشه.
- 17:23 – اکانت کاربر Atlassian ایجاد شده توسط مهاجم کشف و غیرفعال میشه.
- 17:43 – اعلان رخداد امنیتی داخلی در کلودفلر
- 21:31 – تنظیم رولهای فایروال برای مسدود کردن IP مرتبط با مهاجم
24 نوامبر/3 آذر – حذف Sliver و پایان دسترسی مهاجم
- 10:44 – آخرین فعالیت مهاجم شناسایی میشه.
- 11:59 – فریمورک Sliver حذف میشه.
در طول این جدول زمانی، مهاجم سعی کرده به تعداد بیشماری از سیستمهای دیگه در کلودفلر دسترسی پیدا کنه اما بدلیل کنترلهای دسترسی، رولهای فایروال و استفاده از کلیدهای امنیتی که با استفاده از ابزار Zero Trust خودشون اعمال کردن، موفقیت نشده.
کلودفلر گفته که نتونستن شواهدی مبنی بر دسترسی مهاجم به Cloudflare global network ، دیتاسنتر، کلیدهای SSL، اطلاعات پیکربندی و دیتابیس مشتریان، Cloudflare Workerهایی که توسط خودشون یا مشتریاشون ایجاد شده، مدلهای هوش مصنوعی ، زیرساخت شبکه یا دیتاهای مرتبط با Workers KV ، R2 ، Quicksilver پیدا کنن. فقط دسترسی محدود به محیط Atlassian و سروری که Atlassian روش در حال اجرا بوده، داشتن.
بخش بزرگی از “Code Red” این بوده که بفهمن مهاجم به چه چیزی دسترسی داشته و سعی کرده به چه چیزی دسترسی داشته باشه. با بررسی لاگها، کلودفلر تونسته تلاش برای دسترسی به معیارهای داخلی، پیکربندی شبکه، سیستم ساخت، سیستمهای هشدار و سیستم مدیریت release رو رهگیری کنه. بر اساس بررسیشون، هیچ یک از تلاش های مهاجم برای دسترسی به این سیستم ها موفقیت آمیز نبوده.
CrowdStrike بطور مستقل ارزیابی از دامنه و میزان فعالیت مهاجم انجام داده، که با تحقیقات تیم امنیتی کلودفلر همپوشانی داشته ،در نهایت به این نتیجه رسیدن که آخرین شواهد از فعالیت تهدید در ۲۴ نوامبر در ساعت ۱۰:۴۴ بوده. کلودفلر مطمئنه که با توجه به تحقیقات خودشون و CrowdStrike، اقدامات مهاجم رو کاملاً فهمیدن و فعالیتشون محدود به سیستم هایی بوده که اینا کشف کردن.
در نهایت کلودفلر از همه کسانی که در این رخداد امنیتی کمکشون کرده تشکر کرده.
IOCهای گزارش :
| Indicator | Indicator Type | SHA256 | Description |
|---|---|---|---|
| 193.142.58[.]126 | IPv4 | N/A | Primary threat actor Infrastructure, owned by M247 Europe SRL (Bucharest, Romania) |
| 198.244.174[.]214 | IPv4 | N/A | Sliver C2 server, owned by OVH SAS (London, England) |
| idowall[.]com | Domain | N/A | Infrastructure serving Sliver payload |
| jvm-agent | Filename | bdd1a085d651082ad567b03e5186d1d4 6d822bb7794157ab8cce95d850a3caaf |
Sliver payload |
منابع :