هنر هکرهای روسی در حمله ی Nearest Neighbor

زمان مطالعه: 15 دقیقه

اوایل فوریه 2022، درست قبل از حمله ی نظامی روسیه به اوکراین، محققای Volexity موردی رو کشف کردن که به گفته ی خودشون، جذابترین و پیچیده ترین رخداد امنیتی بوده که تا به حالا بررسیش کردن.

تحقیقات زمانی شروع شد که یک هشدار از یک امضای تشخیص سفارشی که Volexity در سایت مشتری (“سازمان A”) مستقر کرده بود، نشون داد که یک بازیگر تهدید یک سرور رو در شبکه مشتری به خطر انداخته.

در حالیکه Volexity به سرعت فعالیت تهدید رو بررسی کرد، سؤالات بیشتری نسبت به پاسخها مطرح شد، چون با یک APT بسیار با انگیزه و ماهر روبرو شده بود که از یک بردار حمله جدید استفاده میکرد که Volexity قبلاً با اون مواجه نشده بود.

در پایان تحقیقات، Volexity این نفوذ رو به یک بازیگر تهدید روسی با عنوان GruesomeLarch (بطور عمومی با عناوین APT28، Forest Blizzard، Sofacy، Fancy Bear و … شناخته میشه) نسبت داده. Volexity همچنین مشخص کرد که GruesomeLarch بطور فعال سازمان A رو برای جمع‌آوری داده‌ها از افراد متخصص و پروژه‌های فعال درگیر اوکراین، هدف قرار داده.

تحقیقات یک ماه و نیمه، نشون داد که GruesomeLarch تونسته با اتصال به شبکه Wi-Fi سازمانی سازمان A، در نهایت به شبکه سازمان A نفوذ کنه. بازیگر تهدید با زنجیره ای کردن رویکرد خود برای به خطر انداختن چندین سازمان در نزدیکی هدف مورد نظر خود، یعنی سازمان A، به این کار دست یافته. این کار توسط یک بازیگر تهدید انجام شد که هزاران مایل دورتر از قربانی بود. Volexity از هیچ اصطلاحی برای توصیف این سبک حمله آگاه نیست و اونرو حمله همسایه نزدیک ( Nearest Neighbor Attack) نامیده.

 

حمله ی Nearest Neighbor :

با توجه به فاصله فیزیکی فرضی، ممکن است تعجب کنید که چگونه این بازیگر تهدید دقیقاً تونسته به شبکه Wi-Fi سازمانی سازمان A احراز هویت کنه.

اولین و واضحترین چیزی که نیاز داشتن، اعتبارنامه‌های معتبر بوده. این کار رو از طریق حملات اسپری رمز عبور (Password-Spray Attacks) علیه یک سرویس عمومی در شبکه سازمان A برای تأیید اعتبارنامه‌ها انجام دادن. در حالیکه میشه اعتبارنامه‌ها رو تأیید کرد، اما به دلیل اجرای احراز هویت چند عاملی (MFA)، نمیشه از اونا علیه سرویسهای عمومی سازمان A استفاده کرد. بنابراین این طرح شکست خورده.

با این حال، شبکه Wi-Fi سازمانی، نیازی به MFA نداشته و فقط به نام کاربری و رمز عبور دامنه معتبر کاربر برای احراز هویت نیاز داشته. اما مشکلی که وجود داره اینه که بازیگر تهدید اون سر دنیا بوده و نمیتونسته واقعاً به شبکه Wi-Fi سازمانی A متصل بشه. برای حل این مشکل، بازیگر تهدید تلاش کرده تا سازمانهای دیگه رو به خطر بندازه، که در ساختمانهایی در نزدیکی دفتر سازمان A قرار داشتن. استراتژی اونا، نفوذ به سازمان دیگه و سپس حرکت جانبی در داخل اون سازمانها، برای یافتن سیستمهایی بود که به هکرها امکان دسترسی از طریق دو نوع اتصال رو میداد. (یعنی سیستمهایی که دارای اتصال شبکه سیمی و بی‌سیم بودن). [دلیلش این بوده که به یک سیستم دسترسی سیمی داشته باشن و با اون بصورت بی سیم به شبکه A وصل بشن.]

پس از موفقیت در یافتن سیستمی که از طریق یک اتصال اترنت سیمی به شبکه متصل بود، بازیگر تهدید به سیستم دسترسی پیدا میکنه و از آداپتور Wi-Fi اون استفاده میکنه. در این مرحله، اونا به SSID شبکه Wi-Fi سازمانی سازمان A وصل و احراز هویت میکنه. در نتیجه تونستن به شبکه سازمان A دسترسی پیدا کنن.

شکل زیر آناتومی حمله ی همسایه نزدیک یا Nearest Neighbor Attack رو نشون میده.

 

 

در این مرحله، قابل درکه اگه فکر کنید این کمی دور از ذهن به نظر میرسه. با این حال، Volexity کشف کرد که GruesomeLarch موفق به نفوذ به بیش از یک سازمان در نزدیکی سازمان A شده. اونا تونستن یک سیستم با شرایط بالا رو در یک سازمان مجاور پیدا کرده و به خطر بندازن، و به اونا اجازه داده تا از طریق اون سیستم به شبکه Wi-Fi سازمانی سازمان A متصل بشن.

Volexity معتقده که این نشون دهنده یک کلاس جدید از حمله است که قبلاً توصیف نشده، که در اون یک بازیگر تهدید یک سازمان رو به خطر میندازه و حملات پر کردن اعتبارنامه (Credential-Stuffing Attack) رو برای به خطر انداختن سازمانهای دیگه در نزدیکی فیزیکی اون، از طریق شبکه‌های Wi-Fi اونا انجام میده. برای یادآوری، به خطر انداختن این اعتبارنامه‌ها به تنهایی منجر به دسترسی به محیط مشتری نشد، چون همه منابع رو به اینترنت نیاز به استفاده از احراز هویت چند عاملی (MFA) داشتن. با این حال، شبکه Wi-Fi توسط MFA محافظت نمیشد، به این معنی که نزدیکی به شبکه هدف و اعتبارنامه‌ های معتبر تنها الزامات برای اتصال بودن.

این پست با هدف روشن کردن تاکتیک‌ها، تکنیک‌ها و روش‌های (TTPs) مشاهده شده توسط Volexity در طول تحقیقات رخداد و ارائه یک نگاه دقیق به نحوه عملکرد حمله همسایه نزدیک و اقدامات کاهشی علیه اون هستش.

 

 

نگاهی اجمالی به یک روح:

این داستان در 4 فوریه 2022 آغاز میشه، زمانیکه Volexity فعالیت مشکوکی رو در شبکه مشتری خودش، سازمان A، تشخیص داد. این تشخیص پس از فعال شدن یک هشدار از یک امضای سفارشی که Volexity برای جستجوی فایلهایی که در ریشه دایرکتوری C:\ProgramData نوشته و اجرا میشن، رخ داد. Volexity متوجه شد که فعالیت زیر رخ داده:

• یک فایل با نام C:\ProgramData\servtask.bat نوشته و اجرا شد.
• فایل servtask.bat از ابزار خط فرمان رجیستری مایکروسافت (reg) و PowerShell برای اجرای دستورات زیر استفاده کرده:

 

 

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

اکنون مراحل بعدی تحقیقات مشخص بود: تیم به سرعت بررسی عمیق‌تر خودش رو در تاریخچه‌ی رویدادهای EDR سیستم آغاز کرد و یک پکیج برای استقرار Volexity Surge Collect Pro، برای جمع‌آوری حافظه‌ی سیستم (RAM) و مصنوعات کلیدی دیسک آماده کرد.

بررسی لاگ های EDR اطلاعات جالبی در مورد فعالیتهایی که بلافاصله قبل و بعد از کشف اولیه رخ داده بود، ارائه کرد. Volexity موارد زیر رو در سیستم، درست پیش از فعالیت ذکر شده در بالا، پیدا کرد:

• ورود به سیستم با یک حساب کاربری با سطح دسترسی پایین (غیرمدیر) بر روی سرور از طریق RDP رخ داده بود.
• فایلی به نام DefragmentSrv.zip در سیستم، در دایرکتوری کاربر، ایجاد و با استفاده از نسخه‌ی گرافیکی نرم‌افزار WinRAR که روی سیستم بود، از حالت فشرده خارج شده بود.
• دو فایل دیگه، DefragmentSrv.exe و DefragmentSrv.bat، هم نوشته و اجرا شدن. این زنجیره در نهایت منجر به نوشتن و اجرای servtask.bat شد.
• فایلی به نام wayzgoose52.dll هم در یک دایرکتوری جعلی در C:\ProgramData\Adobe\v3.80.15456 نوشته شده بود.

محققای Volexity علاقمند بودن که همه ی این فایلهارو بعنوان بخشی از تحقیقات جمع آوری کنن، اما به دو دلیل این کار انجام نشده.

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

مشکل دوم این بود که Volexity متوجه شد مهاجم تمام فایلها و پوشه‌هایی رو که شناسایی شده بودن رو، حذف کرده. نه تنها فایلها از بین رفته بودن، بلکه Volexity کشف کرد که مهاجم از یک ابزار بومی مایکروسافت به نام Cipher.exe برای این کار استفاده کرده بود که با پاک کردن ایمن فایلها، رد خودش رو بپوشونن. اگرچه این اولین باری نیست که Volexity با مهاجمی مواجه شده که رد خودش رو با روشهای ضد فارنزیک پوشونده، اما اولین باری است که Volexity این کار رو با ابزار Cipher.exe دیده.

 

بن بست های تحقیق:

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

اولاً، Volexity تونست یک آدرس IP رو شناسایی کنه که به سرور قربانی متصل شده بود، اما در اون لحظه مشخص نبود که به چه چیزی مربوطه و دیگه آنلاین نبود. علاوه بر این، Volexity یک سنسور امنیتی شبکه رو در دفتر سازمان A مستقر کرده بود، اما تقریباً هیچ سندی از مهاجم روی اون وجود نداشت. چندین قدمی که اغلب بلافاصله شفافیت و گامهای بعدی رو در یک تحقیق فراهم میکرد، بطور ناامیدکننده‌ای خالی از نتیجه بودن.

تحقیقات برای مدتی سرد شد تا اینکه مهاجم دوباره ظاهر شد. زمانیکه مهاجم بازگشت، Volexity تونست به برخی پاسخها برسه. Volexity متوجه شد که بخشی از آدرس IP که مهاجم از اون میاد، با شبکه‌ی WiFi سازمانی سازمان A مرتبط هستش و یکی از کنترل‌کننده‌های دامنه در شبکه به عنوان سرور DHCP عمل میکنه. با این حال، پس از بررسی لاگهای DHCP، هیچ سندی از آدرسهای IP که Volexity به مهاجم مرتبط کرده بود، وجود نداشت. سرنخ احتمالی دیگه هم یک بن‌بست دیگه بود.

 

استرداد بی سیم:

کمی بعد در تحقیقات، Volexity متوجه شد که سازمان دارای یک کنترل‌کننده بی‌سیم است که برای مدیریت شبکه بی‌سیم، نقاط دسترسی و تمام زیرساخت‌های مرتبط استفاده میشه. این کنترل‌کننده همچنین لاگهای مفصلی در مورد قدرت سیگنال، دستگاههای متصل، حساب‌های کاربری تأیید شده و غیره رو ذخیره میکنه. Volexity به کنترل‌کننده بی‌سیم دسترسی پیدا کرد و اولین شانس بزرگ خودش در تحقیقات رو داشت. مدت کوتاهی پس از دسترسی به کنترل‌کننده بی‌سیم، Volexity تونست آدرس IP مهاجم رو پیدا کنه و اونرو به یک کاربر دامنه تأیید شده و یک آدرس MAC مرتبط کنه.

با استفاده از این اطلاعات جدید، Volexity تونست لاگهای RADIUS سازمان A رو بررسی کنه و رویدادهای احراز هویت مرتبط با کاربر و آدرس MAC که تازه کشف شده بود رو پیدا کنه.

همین آدرس MAC و حساب کاربری در لاگ‌های قدیمی‌تر که با نفوذ اولیه همپوشانی داشتن، ظاهر شد. با این حال، Volexity رویدادهای احراز هویت دیگه ای با همون آدرس MAC و نام کاربری متفاوت رو پیدا کرد که به اواخر ژانویه 2022 برمی‌گشت.

Volexity متوجه شد که رمز عبور حساب مشاهده شده از ژانویه منقضی شده و توسط کاربر بروز شده. این ظاهراً مانع دسترسی مهاجم به اون اکانت میشده. اما اونا تونستن در اوایل فوریه با حسابی که از کنترل‌کننده بی‌سیم مشاهده شده بود، دوباره برگردن.

این اطلاعات جدید باعث شد Volexity لاگهای سیستمی رو در سازمان A که سرویسهای وب، رو به اینترنت ارائه میکرد و می‌تونست احراز هویت بشه رو بررسی کنه. خود سرویس با MFA محافظت می شد، اما می‌تونست برای تأیید اعتبار یا عدم اعتبار اعتبارنامه‌ها استفاده بشه. پس از بررسی این لاگ‌ها، Volexity دریافت که در ژانویه و فوریه، حملات اسپری رمز عبور علیه این سرویس انجام شده و سه حساب توسط یک مهاجم با موفقیت به خطر افتاده بود. دو تا از سه حساب شناسایی شده، همان حسابهایی بودن که Volexity از کنترل‌کننده بی‌سیم و لاگ‌های RADIUS شناسایی کرده بود. حساب سوم هنوز استفاده نشده بود.

تا اینجای کار Volexity متوجه شده بود که مهاجم از طریق اعتبارنامه‌های بی‌سیم که با brute-force یک سرویس رو به اینترنت بدست آورده بود، به شبکه متصل شده.

با این حال، مشخص نبود که مهاجم از نظر فیزیکی کجا بود که به او اجازه میداد در ابتدا به Wi-Fi سازمانی متصل بشه. تجزیه و تحلیل بیشتر داده‌های موجود از کنترل‌کننده بی‌سیم سازمان A نشون داد که مهاجم به کدام نقاط دسترسی بی‌سیم خاص، متصل شده و اونارو روی نقشه ای که طرحی از ساختمان و طبقات خاص داشت، همپوشانی داد.

Volexity می‌تونست ببینه که مهاجم به همون سه نقطه دسترسی بی‌سیم متصل شده بود که در یک اتاق کنفرانس در انتهای ساختمان نزدیک پنجره‌ها در امتداد خیابان قرار داشتن. این اولین مدرک رو به Volexity داد که “تماس از داخل ساختمان نبوده”. آیا این میتونه یک مهاجم باشه که یک عملیات دسترسی نزدیک (close access operation) رو از خیابان بیرون انجام میده؟ هیچ چیز رد نشد، اما Volexity خیلی دور از کشف پاسخ واقعی نبود.

 

به هیچکس، بخصوص به همسایه ی خودتون اعتماد نکنید:

در طول این تحقیق، Volexity با سازمان A همکاری کرد تا اقدامات مختلف اصلاحی رو انجام بده، اقدامات تدافعی رو اجرا کنه و بهبودهایی رو در زمینه‌های مختلفی که ورود به سیستم و دید شبکه در اونا بهینه نبود، انجام بده. انجام این کار در نهایت به Volexity اجازه داد تا یک پیشرفت بزرگ در تحقیقات داشته باشه و دقیقاً بفهمه چه اتفاقی در حال رخ دادن هستش.

با وجود تنظیم مجدد اعتبارنامه‌های مختلف، از جمله سه حساب شناسایی‌ شده از حملات اسپری رمز عبور، مهاجم همچنان دارای اعتبارنامه‌های دامنه فعال بود. مهاجم یک بار دیگه به Wi-Fi سازمانی سازمان A دسترسی پیدا کرد، اما با توجه به اینکه حالا قابلیت مشاهده و لاگین آماده بود، Volexity به سرعت وارد عمل شد. Volexity اکنون میتونست ضبط کامل پکتهارو از تمام فعالیتهای مربوط به سیستمهای متصل به Wi-Fi در شبکه سازمان A، صرف نظر از اینکه از کجا متصل شده بودن، دریافت کنه. تجزیه و تحلیل این پکت های ضبط شده، نشون داد که سیستم مهاجم کوئریهای NetBIOS Name Service (NBNS) رو ارسال کرده، که نام رایانه و دامنه‌ی اکتیودایرکتوری که عضو اون بود رو نشون میداد. این دامنه اکتیودایرکتوری دقیقاً نشون میداد که مهاجم از کجا متصل شده، که معلوم شد سازمانی (“سازمان B”) واقع در اون طرف خیابان هستش.

Volexity تونسته با سازمان B تماس بگیره و تا با اونا برای بررسی بیشتر این موضوع همکاری کنن. در اینجا بود که Volexity در نهایت نحوه‌ی عملکرد مهاجم و نحوه‌ی عملکرد حمله همسایه نزدیک رو کشف کرد.

در هماهنگی با سازمان B، محققین تونستن سیستمی رو پیدا کنن که به Wi-Fi سازمان A متصل شده بود. آنالیز این سیستم نشون داد که مهاجم از اعتبارنامه‌هایی با امتیاز بالا، برای اتصال به اون سیستم از طریق RDP، از سیستم دیگه ای که در شبکه سازمان B، به خطر افتاده بود، استفاده کرده بود. این سیستم دو نوع اتصال رو پشتیبانی میکرد. از طریق اترنت سیمی به اینترنت متصل بود، اما همچنین دارای یک آداپتور شبکه Wi-Fi بود که میتونست همزمان استفاده بشه. مهاجم این سیستم رو پیدا و از یک اسکریپت PowerShell خاص برای بررسی شبکه‌های موجود در محدوده‌ی بی‌سیم اون استفاده کرده و بعدش با استفاده از اعتبارنامه‌هایی که به خطر انداخته بود، به Wi-Fi سازمانی سازمان A متصل شده بود. یک نسخه ویرایش شده از کد سی شارپ تعبیه شده در اسکریپت PowerShell سفارشی، اینجا موجود هستش.

تحلیل بیشتر سیستمهای سازمان B نشون داد که مهاجم دو حالت دسترسی به شبکه اونا داشته. اولین مورد با استفاده از اعتبارنامه‌هایی بود که به اونا اجازه میداد تا به VPN شون متصل بشن که با MFA محافظت نمیشد.

Volexity همچنین شواهدی یافت که نشون میداد، مهاجم از شبکه‌ی دیگه ای متعلق به سازمان دیگه ای (“سازمان C”) که در نزدیکی Wi-Fi سازمان B بود، متصل شده بود. مهاجم برای نفوذ به چندین سازمان تلاش زیادی کرده بود تا بتونه اتصالات Wi-Fi و/یا VPN رو زنجیره‌ کنه و در نهایت به شبکه‌ی سازمان A برسه. تیم Volexity شگفت‌زده شد اما همچنین نفس راحتی کشید که اکنون توضیح و مدرکی در مورد نحوه‌ی وقوع این حمله داشت.

Volexity تونست بر اساس تجزیه و تحلیل آدرسهای MAC و اطلاعات SSID، سازمان C رو شناسایی کنه و با اونا تماس بگیره. با این حال، سازمان C تصمیم گرفت دسترسی به داده‌های کلیدی مورد نیاز برای پیشبرد تحقیقات رو به Volexity نده.

در هر صورت، تمام این یافته‌ها به Volexity درک کاملی از عملیات مهاجم رو داد و به تیم اجازه داد تا با اطمینان، توصیه‌های بیشتری رو برای کاهش خطر و دستورالعمل‌های اصلاحی، به سازمان A ارائه بده. در این مرحله، دسترسی مهاجم از Wi-Fi سازمانی سازمان A قطع شد و از اون زمان به بعد مشاهده نشده که به این شبکه متصل بشه.

 

تلاش نهایی : WiFi مهمان

بیش از یک ماه پس از آخرین فعالیت مشاهده‌ شده‌ی بازیگر تهدید، و پس از انجام مراحل مختلف اصلاحی، Volexity هشدار دیگه ای مبنی بر فعالیت مشکوک در شبکه‌ی مشتری خود، سازمان A، دریافت کرد. پس از بررسی این فعالیت، Volexity کشف کرد که همون بازیگر تهدید موفق شده به شبکه برگرده و از طریق چندین سیستم داخلی، پروکسی میکرد. خوشبختانه، Volexity تونست به سرعت این حادثه رو بررسی کنه و اون رو از طریق چندین سیستم به مبدا اون بازگردونه: سیستمی در شبکه‌ی WIFI مهمان (Guest Wi-Fi network) در سازمان A. (معمولا شرکتهای بزرگ، دو نوع اتصال Wifi ایجاد میکنن. یکی سازمانی که مختص کارهای خود سازمان هستش و سیستمها و داده های مهم از طریق این Wifi قابل دسترسی و انتقال هستن. یک WiFi دیگه هم با عنوان شبکه WiFi مهمان راه اندازی میکنن برای کارهای دمه دستی.)

در حالیکه اعتقاد بر این بود که شبکه‌ی WiFi مهمان کاملاً از شبکه‌ی سیمی سازمانی، که داده‌های با ارزش در اون قرار داشت، جدا شده، یک سیستم وجود داشت که از هر دو شبکه‌ی WiFi و شبکه‌ی سیمی سازمانی قابل دسترس بود. مهاجم با استفاده از اعتبارنامه‌های حسابی که ریست نشده بود و این واقعیت که شبکه‌ی WiFi کاملاً جدا نبود، تونست به شبکه‌ی سیمی سازمانی برگرده و در نهایت به داده‌های با ارزش هدف دسترسی پیدا کنه.

برای دستیابی به این مورد، مهاجم از ابزار netsh ویندوز برای راه‌اندازی یک سری port-forward استفاده کرده، که به اونا اجازه میداد به سیستمهای هدف دسترسی پیدا کنن. مثالهایی از دستورات استفاده‌ شده برای این کار در زیر ارائه شدن:

 

 

با تجزیه و تحلیل ترافیک شبکه و لاگهای کنترلر بی‌سیم سازمان A، تونستن سیستمی که این فعالیت رو آغاز کرده بود رو، یکبار دیگه تعیین کنن. Volexity دریافت که مهاجم این بار از سازمان C متصل شده بود. Volexity دوباره با سازمان C تماس گرفت و همچنین با سازمان A همکاری کرد تا اقدامات اصلاحی جدیدی، برای حل این نفوذ جدید انجام بدن.

از آنجاییکه این فعالیت نهایی مربوط به شبکه‌ی WiFi مهمان بود، هیچ فعالیت مشاهده‌ شده‌ای وجود نداره که Volexity بتونه اون رو به مهاجمی که از حمله‌ی همسایه نزدیک استفاده کرده، مرتبط کنه.

 

نکاتی از ترفندهای جاسوسی:

GruesomeLarch در طول نفوذ خود عمدتاً رویکردی مبتنی بر استفاده از ابزارهای موجود در سیستم (Living-Off-The-Land) رو اتخاذ و از پروتکلهای استاندارد مایکروسافت و حرکت جانبی استفاده کرده.

بخشهای زیر برخی از مشاهدات از حادثه رو تشریح میکنن که میشه از اونا برای تشخیص بالقوه GruesomeLarch یا سایر بازیگران تهدیدی که از رفتارها یا تکنیکهای مشابه استفاده میکنن، استفاده کرد.

 

استفاده از Cipher.exe:

در طول نفوذ، مهاجم فایلهایی رو که ایجاد کرده بود، با استفاده از یک ابزار داخلی ویندوز به نام Cipher.exe که در هر نسخه مدرن ویندوز وجود داره، حذف کرده بود:

 

 

عملکرد زیر برای بازنویسی داده‌های حذف‌ شده در یک پوشه خاص استفاده شده:

 

 

طبق مستندات مایکروسافت :

برای بازنویسی داده‌های حذف‌ شده روی یک volume با استفاده از Cipher.exe، از سوئیچ /w با دستور cipher استفاده کنید:

• تمام برنامه‌ها رو ببندید.
• روی Start > Run کلیک کنید، cmd رو تایپ و بعدش Enter کنید.
• <cipher /w:<directory رو تایپ و بعدش Enter کنید. <directory> هر فولدری در volume ای است که میخواید پاک کنید. به عنوان مثال، دستور cipher /w:C باعث میشه که تمام فضای آزاد شده در درایو C بازنویسی بشه. اگه <directory> یک mount point باشه یا به یک فولدر در volume دیگه ای اشاره کنه، تمام فضای آزاد شده در اون volume رو هم پاک میکنه.

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

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

 

دامپ کردن Ntds.dit با استفاده از VSSAdmin :

تکنتیک مشاهده‌ شده دیگه، تلاش برای سرقت دیتابیس اکتیودایرکتوری با ایجاد یک volume shadow copy بود. این یک تکنیک رایج است و Volexity چندین ساله که اونو مشاهده میکنه. این تکنیک به خوبی در سطح عمومی مستند شده و از اجزای کلیدی زیر تشکیل شده که در این حادثه هم مشاهده شده:

• ایجاد یک volume shadow copy ، مثلا با دستور زیر:

 

 

• یک کپی از ntds.dit و SYSTEM registry hive رو از volume shadow copy گرفته شده، بازیابی کنید:

 

 

• فایلهارو دانلود کنید. با توجه به اینکه، سایز فایلها زیاد بودن، مهاجم اونارو با دستور پاورشل زیر، فشرده کرده بود:

 

 

محصولات آنتی‌ویروس و EDR ممکنه بطور طبیعی این رفتار رو بعنوان بالقوه مخرب تشخیص بدن. با این حال، برای فرصتهای تشخیص بیشتر، سازمانها میتونن امضاهای EDR سفارشی ایجاد کنن تا به دنبال، یک حساب با امتیاز بالا باشن که موارد زیر رو انجام داده:

• هرگونه استفاده از vssadmin.exe
• کپی یا انتقال فایلها از دایرکتوری‌های VolumeShadowCopy
• دستورات PowerShell که نشون‌ دهنده فشرده‌سازی درون خطی فایلها هستن.

 

استخراج داده ها:

بیشتر داده‌های این حادثه به سیستم مهاجم که به WiFi متصل بود، کپی شدن. با این حال، در چند مورد، Volexity مشاهده کرد که مهاجم داده‌ها رو در دایرکتوریهای یک وب‌ سرور عمومی قرار میداده و بعدش این فایلهارو برای استخراج، دانلود میکرده.

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

 

انتساب:

در ابتدا، Volexity قادر به نسبت دادن این نفوذ به یک بازیگر تهدید شناخته‌شده نبود. مهاجم عمدتاً از تکنیکهای living-off-the-land استفاده میکرد و هر ابزاری یا آدرس IP که استفاده میکرد، برای Volexity دشوار بود تا روی یک مظنون احتمالی متمرکز بشه. با این حال، هنگامی که Volexity تونست تعیین کنه چه کسی و چه چیزی بعنوان تارگت قرار گرفته، بلافاصله مشکوک شد که این، فعالیت یک بازیگر تهدید روسی است، اما کدوم یک؟

در آوریل 2024، مایکروسافت تحقیقاتی رو در مورد Forest Blizzard منتشر کرد که Volexity اونو با عنوان GruesomeLarch ردیابی میکنه. در این گزارش مایکروسافت جزئیاتی از ابزار پس از نفوذ به نام GooseEgg، که بازیگر تهدید ازش استفاده کرده بود رو، ارائه کرد. از این ابزار برای اکسپلویت زیرودی CVE-2022-38028، یک آسیب‌پذیری افزایش امتیاز در سرویس Print Spooler مایکروسافت ویندوز، استفاده شده بود. در این گزارش، مایکروسافت چندین نام فایل کلیدی، مسیرهای فولدرها و دستورات استفاده‌ شده توسط این فریمورک رو تشریح کرده بود، از جمله موارد زیر:

Servtask.bat
Wayzgoose52.dll
DefragmentSrv.exe
C:\ProgramData\[var]\v%u.%02u.%04u

در این حادثه که توسط Volexity مورد بررسی قرار گرفت، دقیقاً همین نامها و مسیرهای فایل مشاهده شد. گزارش مایکروسافت همچنین دستورات موجود در فایل servtask.bat رو نشون داد که با اونچه Volexity دیده بود، جایی که Hiveهای رجیستری در یک فایل به نام out.zip از فعالیت نفوذ اولیه ذخیره و فشرده شده بودن، یکسان بود. با این حال، همانطور که در بخش نکاتی از ترفندهای جاسوسی این پست اومده، این فایها با استفاده از ابزار Cipher.exe بطور ایمن حذف شدن.

پست مایکروسافت بیان کرد که GooseEgg از “حداقل ژوئن 2020 و احتمالاً از آوریل 2019” در حال استفاده از این ابزار بوده. Volexity میتونه تأیید کنه که این ابزار بطور قطعی در فوریه 2022 استفاده شده. اکسپلویت CVE-2022-38028 ، همچنین توضیحی در مورد چگونگی به خطر افتادن سیستم قربانی اولیه ارائه میده. بر اساس استفاده از این ابزار، که مایکروسافت نشون میده منحصر به این بازیگر تهدید هستش، Volexity با اطمینان بالایی ارزیابی میکنه که فعالیت توصیف شده در این پست رو میشه به GruesomeLarch نسبت داد.

 

اقدامات کاهشی:

برای جلوگیری یا تشخیص عمومی حملاتی مشابه آنچه در این پست مورد بحث قرار گرفت، Volexity توصیه‌های زیر رو ارائه میده:

• نظارت و هشداردهی بر استفاده غیرعادی از ابزارهای netsh و Cipher.exe در محیط خودتون.
• ایجاد قوانین تشخیص سفارشی برای جستجوی فایلهایی که از مکانهای غیر استاندارد مختلف، مانند C:\ProgramData اجرا میشن.
• تشخیص و شناسایی استخراج داده‌ها از سرویسهای رو به اینترنت که در محیط شما اجرا میشن.
• ایجاد محیطهای شبکه‌ای جداگانه برای شبکه‌های Wi-Fi و اترنت، بویژه در مواردی که شبکه‌های مبتنی بر اترنت امکان دسترسی به منابع حساس رو فراهم میکنن.
• هاردنینگ الزامات دسترسی به شبکه‌های Wi-Fi، مانند اعمال الزامات MFA برای احراز هویت یا راهکارهای مبتنی بر گواهینامه.
• نظارت بر ترافیک شبکه بین دستگاهها برای شناسایی فایلهایی که از طریق SMB منتقل میشن و حاوی داده‌ هایی هستن که معمولا استخراج میشن. مانند اعتبارنامه، ntds.dit، رجیستری و … .

 

منبع