Атака ближайшего соседа: как российская APT использовала соседние сети Wi-Fi для скрытого доступа

КЛЮЧЕВЫЕ ВОПРОСЫ

• Российская APT-группа GruesomeLarch применила новую технику атаки, используя сети Wi-Fi в непосредственной близости от целевого объекта.

• Активно использовались методы, основанные на принципе «living-off-the-land».

• Для получения дополнительных привилегий была задействована уязвимость 0-day.

• Атаки были направлены на проекты, связанные с Украиной, незадолго до начала вооруженного конфликта.

В начале февраля 2022 года, незадолго до вооруженного конфликта России и Украины, специалисты компании Volexity обнаружили проблему. Впоследствии она привела к одному из самых сложных расследований инцидента в её практике. Расследование началось с сигнала от специальной системы обнаружения, установленной на объекте заказчика («Организация A»). Система зафиксировала компрометацию сервера в сети организации.

По мере анализа инцидента возникало больше вопросов, чем ответов, из-за активности высокомотивированного и опытного противника — группы APT, использовавшей ранее неизвестный вектор атаки. В конечном итоге Volexity связала данный инцидент с российской группировкой GruesomeLarch (также известной как APT28, Forest Blizzard, Sofacy, Fancy Bear и другими именами). Было установлено, что целью было получение данных, связанных с Украиной.

Расследование, длившееся полтора месяца, показало, что злоумышленникам удалось проникнуть в сеть Организации A через корпоративную Wi-Fi-сеть. Для этого они использовали цепочку компрометаций нескольких организаций, расположенных рядом с целью. При этом сами атакующие находились за тысячи километров от цели, по другую сторону океана. Такую технику Volexity назвала Атакой ближайшего соседа (Nearest Neighbor Attack), поскольку ранее такого подходящего термина не встречалось.

Атака ближайшего соседа

Учитывая значительное физическое расстояние, возникает вопрос: каким образом злоумышленники смогли аутентифицироваться в корпоративной Wi-Fi-сети Организации A?

Первым шагом было получение действительных учетных данных. Это было достигнуто с помощью атак типа «password spray» на публичный сервис сети Организации A. Однако, несмотря на возможность проверки учетных данных, их использование против публичных сервисов организации оказалось невозможным из-за включенной многофакторной аутентификации (MFA).

Корпоративная Wi-Fi-сеть, напротив, не требовала MFA и допускала аутентификацию только с использованием имени пользователя и пароля. Однако возможности физического подключиться к Wi-Fi не было из-за огромного расстояния от цели.

Чтобы обойти это ограничение, атакующие взяли под контроль соседние организации, расположенные в зданиях неподалеку от офиса Организации A. Их стратегия заключалась в следующем:

1. Провести атаку на соседнюю организацию.

2. Найти в её сети устройства с двойным подключением (как к проводной, так и к беспроводной сети).

После успешной компрометации устройства, подключенного через Ethernet, APT использовала его Wi-Fi-адаптер. Таким образом, они подключались к SSID корпоративной Wi-Fi-сети Организации A и аутентифицировались, получая доступ к её внутренней сети.

На рисунке ниже представлена анатомия Атаки ближайшего соседа.

На данном этапе можно предположить, что описанный сценарий выглядит маловероятным. Однако специалисты Volexity обнаружили, что группе GruesomeLarch удалось скомпрометировать более одной организации, расположенной в непосредственной близости от Организации A. Взломав одно из таких соседних учреждений, группа GruesomeLarch нашла и получила доступ к системе с двойным подключением (dual-homed), что позволило ей использовать этот доступ для подключения к корпоративной Wi-Fi-сети Организации A.

Volexity считает, что эта техника представляет новый класс атак, ранее не описанный. В данном случае осуществляется сначала взлом одной организации, а затем через Wi-Fi-сети проводятся атаки типа «credential stuffing», чтобы получить доступ к другим организациям, находящимся в непосредственной близости к цели. Стоит отметить, что компрометация учетных данных сама по себе не предоставляла доступ к среде клиента, так как для всех интернет-ориентированных ресурсов требовалась многофакторная аутентификация (MFA). Однако Wi-Fi-сеть не была защищена MFA, и для подключения к ней требовалось только находиться в зоне действия сети и иметь действительные учетные данные.

Цель данной публикации — пролить свет на тактики, техники и процедуры (TTPs), которые Volexity наблюдала во время расследования инцидента, а также подробно объяснить механику Атаки ближайшего соседа и предложить способы защиты от подобных угроз.

«Мелькание призрака»

История начинается 4 февраля 2022 года, когда специалисты Volexity зафиксировали подозрительную активность в сети одного из своих клиентов — Организации A. Обнаружение стало возможным благодаря срабатыванию сигнатуры, специально разработанной для выявления файлов, записанных и выполняемых в корневом каталоге директории C:\ProgramData. В ходе расследования было установлено, что произошла следующая активность:

1. Был создан и выполнен файл C:\ProgramData\servtask.bat.

2. Файл servtask.bat вызывал утилиту командной строки Microsoft для работы с реестром и PowerShell для выполнения следующих команд:

• reg save hklm\sam C:\ProgramData\sam.save

• reg save hklm\security C:\ProgramData\security.save

• reg save hklm\system C:\ProgramData\system.save

PowerShell -c «Get-ChildItem C:\ProgramData\sam.save, C:\ProgramData\security.save, C:\ProgramData\system.save ^| Compress-Archive -DestinationPath C:\ProgramData\out.zip»

Эти действия сразу вызвали тревогу у команды Volexity Threat Detection & Response, так как стало очевидным, что неизвестные экспортировали конфиденциальные данные из ключевых разделов реестра и упаковывали их в архив ZIP.

Следующие шаги расследования были очевидны: команда начала углубленный анализ событий в системе с использованием истории EDR и сбором содержимого оперативной памяти и ключевых артефактов с диска.

Анализ журналов EDR дал интересную информацию о действиях, которые предшествовали и следовали сразу за обнаруженной активностью:

• На сервере произошел вход с использованием учетной записи с ограниченными правами через RDP.

• В каталоге этого пользователя появился архив DefragmentSrv.zip, который был распакован с помощью графической версии программы WinRAR, установленной на системе.

• Были созданы и выполнены файлы DefragmentSrv.exe и DefragmentSrv.bat, что в итоге привело к созданию и выполнению файла servtask.bat.

• Файл с именем wayzgoose52.dll был записан в фиктивный каталог C:\ProgramData\Adobe\v3.80.15456.

Первая проблема заключалась в том, что во время сбора данных из памяти система была отключена. Это привело к потере временных данных, которые могли бы оказаться полезными для расследования. Например, некоторые компоненты файлов могли остаться в памяти, что позволило бы их восстановить и проанализировать.

Второй проблемой оказалось то, что были стерты все файлы и каталоги, которые были идентифицированы ранее. Более того, Volexity обнаружила, что атакующий использовал встроенную утилиту Microsoft Cipher.exe для надежного удаления файлов и сокрытия следов. Хотя специалисты уже сталкивались с применением средств антифоренсики, это был первый случай использования утилиты Cipher.exe для таких целей.

Расследование зашло в тупик

После первоначального инцидента группа GruesomeLarch на некоторое время прекратила активность. В это время специалисты Volexity продолжали расследование, анализируя различные собранные артефакты. Однако они столкнулись с рядом новых сложностей:

Во-первых, был идентифицирован IP-адрес, подключавшийся к серверу жертвы, однако его принадлежность к атаке оставалась неясной, так как адрес более не использовался.

Во-вторых, в офисе Organization A был развернут сетевой сенсор безопасности, однако он практически не содержал записей, указывающих на активность атакующего.

Обычные шаги, которые зачастую быстро проясняют ситуацию и помогают определить дальнейшие действия в расследовании, на этот раз не дали результатов.

Расследование зашло в тупик, пока не возобновилась враждебная активность. Это дало Volexity новые данные:

• Было установлено, что атакующие использовали сегмент IP-адресов, относящихся к корпоративной Wi-Fi сети Organization A.

• Один из контроллеров домена в сети жертвы функционировал как DHCP-сервер.

Однако, несмотря на проверку DHCP-логов, специалисты не обнаружили записей об IP-адресах, связанных с атакующими. Этот возможный источник информации также оказался тупиковым.

Разгадка через беспроводную сеть

На более позднем этапе расследования выяснилось, что организация использовала контроллер для управления своей беспроводной сетью, точками доступа и связанной инфраструктурой. Этот контроллер хранил подробные журналы, включая данные о силе сигнала, подключенных устройствах и учетных записях пользователей, прошедших аутентификацию. Получив доступ к этому контроллеру, специалисты сделали первый значительный успех в расследовании.

Через контроллер беспроводной сети удалось определить IP-адрес неизвестного, а также связать его с доменной учетной записью и MAC-адресом устройства.

Расширение поисков

После анализ логов RADIUS сервера организации, выявив события аутентификации, связанные с этим MAC-адресом и учетной записью. Выяснилось следующее:

• Этот же MAC-адрес и учетная запись фигурировали в старых журналах, связанных с первоначальным проникновением.

• В логах также обнаружились события аутентификации с тем же MAC-адресом, но под другой учетной записью, начиная с конца января 2022 года.

В ходе расследования Volexity узнала, что пароль учетной записи, использовавшейся в январе, истек, и пользователь сменил его. Это временно заблокировало атакующего, но в начале февраля ему удалось восстановить доступ с использованием новой учетной записи, обнаруженной через контроллер беспроводной сети.

Новые данные расширяют расследование

Полученная информация побудила специалистов проверить журналы систем в Organization A, предоставлявших веб-сервисы с выходом в Интернет и поддерживавших аутентификацию. Эти сервисы были защищены многофакторной аутентификацией (MFA), но позволяли проверять корректность введенных учетных данных. В логах за январь и февраль Volexity обнаружила атаки с подбором паролей (password-spraying), в результате которых были успешно скомпрометированы три учетные записи. Две из них совпадали с теми, которые ранее были выявлены через журналы контроллера беспроводной сети и RADIUS. Третья учетная запись пока не использовалась.

Выяснение механизма атаки

Неизвестные подключалисься к сети, используя учетные данные для беспроводной сети, которые были скомпрометированы через подбор пароля на сервисе с выходом в Интернет. Однако оставался открытым вопрос: где физически находился атакующий, чтобы подключиться к корпоративной Wi-Fi-сети?

Дополнительный анализ данных контроллера беспроводной сети показал, к каким именно точкам доступа он подключался. Эти точки доступа были нанесены на карту, где был указан план здания и расположение этажей. Volexity выявила, что он подключался к трем точкам доступа, находившимся в конференц-зале на дальнем конце здания, рядом с окнами, выходящими на улицу.

Первые выводы о местоположении атакующего

Эти данные стали первым доказательством, что атака могла происходить извне здания. Возникло предположение, что атакующий мог находиться на улице, проводя операцию с близкого расстояния.

Не доверяй никому, особенно своему соседу

В ходе расследования Organization A предприняла несколько шагов по устранению уязвимостей, внедрению контрмер и улучшению тех областей, где логирования сетевой активности было недостаточно. Это позволило сделать значительный прорыв в расследовании и понять, что именно произошло.

Несмотря на сброс различных учетных данных, включая три учетные записи, скомпрометированные в ходе атак с подбором паролей, злоумышленник все равно сохранял рабочие доменные учетные данные. Он снова получил доступ к корпоративной Wi-Fi сети Organization A. Теперь исследователи могли захватывать полные пакеты сетевых данных, связанных с Wi-Fi подключениями в сети Organization A, независимо от того, где они подключались.

Обнаружение местоположения неизвестного

Анализ захваченных пакетов показал, что система атакующего отправляла запросы NetBIOS Name Service (NBNS). Они раскрывали имя его компьютера и домен Active Directory, с которым у него было соединение. Этот домен точно указал, откуда подключался неизвестный — из организации (далее Organization B), расположенной прямо напротив.

Исследователи связались с Organization B и совместно с ней продолжили расследование. В ходе этого расследования они раскрыли, как именно работал атакующий и как осуществлялась атака Nearest Neighbor. В координации с Organization B, удалось найти систему, которая подключалась к Wi-Fi сети Organization A. Анализ этой системы показал, что она была скомпрометирована после того, как атакующий использовал привилегированные учетные данные для подключения через RDP к этой системе с другого устройства в сети Organization B. Эта система была «двухдоменной», то есть подключалась к Интернету через проводное Ethernet-соединение, но также имела адаптер Wi-Fi, который использовался совместно. Неизвестный нашел эту систему и использовал кастомный PowerShell-скрипт для анализа доступных сетей в радиусе действия беспроводного адаптера, после чего подключился к Wi-Fi сети Organization A, используя скомпрометированные учетные данные.

Отредактированную копию C# кода, встроенного в кастомный PowerShell-скрипт, можно найти тут https://github.com/volexity/threat-intel/blob/main/2024/2024-11-22%20GruesomeLarch/wifi_ps1_redacted.cs .

Дополнительный анализ систем в Organization B выявил два способа доступа к их сети. Первый способ — использование учетных данных, которые позволяли ему подключаться к VPN, не защищенному многофакторной аутентификацией (MFA). Также обнаружилось, что атакующий подключался к Wi-Fi сети Organization B с другой сети, принадлежащей соседней организации (“Organization C”). Неизвестный приложил значительные усилия, чтобы взломать несколько организаций, чтобы в конечном итоге цепочкой соединений через Wi-Fi и/или VPN добраться до сети Organization A. Команда исследователей была поражена, но в то же время облегченно вздохнула, так как теперь у нее было объяснение и доказательства того, как происходила эта атака.

Исследователи определили, что за организация была Organization C, на основе анализа MAC-адресов и SSID информации, и связалась с ними. Однако Organization C отказалась предоставить доступ к ключевым данным, необходимым для дальнейшего расследования. Тем не менее, все эти находки дали полное понимание действий атакующего и позволили команде уверенно порекомендовать дополнительные меры защиты и инструкции по устранению уязвимостей для Organization A. На данный момент доступ атакующего к корпоративной Wi-Fi сети Organization A был заблокирован.

Заметки о методах работы

Группа GruesomeLarch в основном использовала подход «living-off-the-land» (использование существующих инструментов и протоколов) во время своей атаки, полагаясь на стандартные протоколы Microsoft и осуществляя дальнейшее перемещение по сети. В следующих разделах приведены некоторые наблюдения, которые могут быть использованы для обнаружения действий группы GruesomeLarch или других, использующих аналогичные методы или техники.

Использование Cipher.exe

Во время вторжения атакующий удалил файлы, которые он создал, используя встроенный инструмент Windows — Cipher.exe, который поставляется с каждой современной версией Windows:

Следующая команда была использована для перезаписи удаленных данных в конкретной папке:

cmd.exe /c cipher /W:C

Документация Microsoft описывает это следующим образом:

Эффект заключается в том, что атакующие могут безопасно удалить свои инструменты, используя встроенную функциональность Windows, без необходимости загружать новые инструменты или писать собственный код. Это делает восстановление инструментов злоумышленников более сложным для судебных экспертов.

Каждый записанный на диск файл, позже был удален с помощью данного инструмента. Стоит отметить, что в рамках многочисленных расследований инцидентов исследователи ранее не сталкивались с использованием этой техники для очистки следов.

Еще одной замеченной тактикой была попытка кражи базы данных Active Directory путем создания теневого снимка тома. Это распространенная техника. Рабочий процесс хорошо задокументирован в открытых источниках и включает следующие ключевые компоненты, которые были замечены в этом инциденте:

1) Создание теневого снимка тома, например, с помощью команды:

vssadmin create shadow /for C: /quiet

2) Извлечение копии файла ntds.dit и реестровой базы данных SYSTEM из теневого снимка тома:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\NTDS\NTDS.dit [dest]

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy1\Windows\System32\config\SYSTEM [dest]

3) Загрузка скопированных файлов. Для скачивания файлов (которые были довольно большими) злоумышленник сжимает их с помощью команды PowerShell:

powershell -c "& { Add-Type -Assembly 'System.IO.Compression.FileSystem'; [IO.Compression.ZipFile]::CreateFromDirectory($path1', '$path2');}" > C:\Windows\Temp\b2rMBPL.tmp 2>&1

Антивирусы и системы защиты конечных точек (EDR) могут естественным образом обнаружить это поведение как потенциально вредоносное. Однако для дополнительных возможностей обнаружения организации могут создать кастомные EDR-сигнатуры для поиска привилегированного аккаунта, который проявляет следующие признаки:

• Любое использование vssadmin.exe

• Копирование или перемещение файлов из каталогов VolumeShadowCopy

• Команды PowerShell, указывающие на сжатие файлов в реальном времени

Основная часть данных с этого инцидента была скопирована на систему атакующего, которая была подключена к Wi-Fi. Однако в некоторых случаях наблюдалось, как неизвестные подготавливали данные для эксфильтрации в каталогах на общедоступном веб-сервере. Эти файлы затем были эксфильтрованы через внешние загрузки.

Это распространенная техника, которая встречается у злоумышленников в различных случаях. Отслеживать такую активность может быть трудно, но есть возможности для обнаружения такого поведения, если организации могут мониторить неожиданные файлы на веб-серверах или передачи больших файлов, которые выходят за рамки обычного. В любом случае, обеспечение функционирования веб-логов и их сохранение может помочь в расследованиях на более поздних этапах.

Изначально исследователи не смогли приписать этот инцидент известной группировке. Атакующий использовал методы «living-off-the-land» (использование уже существующих инструментов и средств системы), и инструменты или IP-адреса, которые он использовал, затрудняли установление возможного виновника. Однако, как только удалось определить, что именно было внутри организации, они сразу заподозрили, что это могла быть активность российских групп, но какой именно?

Затем, в апреле 2024 года, Microsoft опубликовала исследование о Forest Blizzard, в котором был описан инструмент после компрометации под названием GooseEgg, используемый группой GruesomeLarch. Этот инструмент использовался для эксплуатации уязвимости повышения привилегий CVE-2022-38028 в службе печати Microsoft Windows. В своем отчете Microsoft подробно указала несколько ключевых имен файлов, путей и команд, используемых этим фреймворком, в том числе следующие:

• Servtask.bat

• Wayzgoose52.dll

• DefragmentSrv.exe

• C:\ProgramData[var]\v%u.%02u.%04u

Эти же имена файлов и пути были зафиксированы в исследованном инциденте. Отчет Microsoft также показал, какие команды использовались в файле servtask.bat, которые полностью совпадают с теми, что наблюдались, когда реестровые хайвы были сохранены и сжаты в файл с именем out.zip в начале атаки.

Microsoft в своем отчете указала, что GooseEgg использовался как минимум с июня 2020 года, возможно, начиная с апреля 2019 года. Эксплуатация уязвимости CVE-2022-38028 также объясняет, как была вероятно скомпрометирована первоначальная жертва.

Заключение

Расследование подчеркивает инновационный и ресурсоемкий подход атакующего, стремящегося достичь своих целей. Атака ближайшего соседа продемонстрировала, как операция, требующая физического доступа, может быть выполнена без непосредственной близости, что устраняет риски идентификации или задержания. Эта техника позволяет получить все преимущества физического нахождения рядом с целью, при этом оператор может находиться на расстоянии тысяч миль, что подчеркивает растущую сложность современных киберугроз.

Организациям необходимо пересмотреть риски, которые могут исходить от Wi-Fi сетей для операционной безопасности. В то время как много внимания было уделено защите интернет-услуг, особенно с использованием многофакторной аутентификации (MFA), Wi-Fi сети часто не получали такого же уровня внимания. Важно, чтобы доступ к корпоративным Wi-Fi сетям был защищен так же тщательно, как и другие методы удаленного доступа, например, VPN.

Эта атака была возможна из-за слабых средств защиты на Wi-Fi сетях по сравнению с другими ресурсами, такими как электронная почта или VPN. Ход атаки был следующим:

1. Компрометация сети соседней организации.

2. Поиск двухсетевых систем, подключенных как по Ethernet, так и по Wi-Fi.

3. Сканирование доступных Wi-Fi сетей и брутфорс учетных данных.

4. Аутентификация в соседних Wi-Fi сетях с использованием полученных учетных данных.

Объединяя эти сети, группа GruesomeLarch переходила от одной организации к другой, не используя вредоносное ПО, а лишь действуя с помощью действующих учетных данных для получения доступа. Она также применяла методику использования стандартных инструментов, таких как netsh и Cipher.exe, чтобы скрыть свои действия и избежать обнаружения.

Для предотвращения или выявления подобных атак рекомендуются следующие меры:

• Мониторить или настроить оповещения о подозрительном использовании netsh и Cipher.exe в вашей среде.

• Создать правила обнаружения для необычного выполнения файлов из нестандартных местоположений (например, корень C:\ProgramData).

• Следить за попытками эксфильтрации данных.

• Разделять сетевые среды для Wi-Fi и Ethernet-сетей, особенно в случае, если Ethernet предоставляет доступ к важным ресурсам.

• Внедрять MFA или решения на основе сертификатов для аутентификации в Wi-Fi сетях.

• Мониторить сетевой трафик SMB для выявления признаков эксфильтрации данных, таких как учетные данные, файлы ntds.dit и реестровые хабы.

Применение этих профилактических мер поможет организациям снизить риски от подобных сложных методов атак.

Life-Hack — Жизнь-Взлом