Представьте, что все, у кого дома есть умная колонка Amazon Echo (Яндекс Алиса, Маруся – подставить подходящее), узнали бы, что на протяжении последних 6 месяцев она отпирала их дом и впускала воров внутрь. Как теперь чувствовать себя в безопасности, если злоумышленники могли сделать копии ваших ключей, документов, носителей информации или, например, отравить систему водоснабжения?
В таком положении сейчас находятся тысячи организаций, пострадавших от взлома цепочки поставок программного обеспечения компании SolarWinds при помощи вредоносного приложения Sunburst. Пострадавшие компании отчаянно ищут признаки компрометации, проводят внеочередной аудит безопасности инфраструктуры, а некоторые могут даже приостановить ряд сервисов до окончания расследования.
8 декабря компания FireEye сообщила, что была взломана, и начала расследование с привлечением правительства США и компании Microsoft.
13 декабря FireEye выпустила подробный отчет о компрометации, где описан принцип распространения вредоносного кода через ПО Orion от компании SolarWinds.
17 декабря Агентство по Кибербезопасности и Безопасности Инфраструктуры (CISA) выпустило экстренное сообщение, в котором опросило все компании, использующие ПО SolarWinds, обновить или даже отключить компонент SolarWinds Orion от сети (в Шаге 2 вышеупомянутого сообщения). С тех пор служба расследований инцидентов безопасности Varonis заметила всплеск криминалистических расследований, связанных с этой кампанией, и выявила несколько активных атак.
Хотя большая часть материала на сегодняшний день сосредоточена на устранении последствий от скомпрометированных версий решения SolarWinds Orion, согласно CISA, есть свидетельства дополнительных векторов вторжений, связанных с этой кампанией.
От атак через цепочки поставок сложно защититься
При атаке через цепочку поставок злоумышленник выбирает своей целью доверенного поставщика или доверенный продукт вместо того, чтобы атаковать свои цели напрямую. В данном случае злоумышленники внедрили заранее заготовленный бэкдор («потайной ход») в доверенный программный продукт (SolarWinds Orion), который затем был автоматически разослан тысячам клиентов, замаскированный под обычное обновление.
На этом плохие новости не заканчиваются — злоумышленники оказались достаточно изощренными, чтобы месяцами оставаться незамеченными. У них было время оставить дополнительные бэкдоры и получить доступ к множеству систем и данных. В настоящее время организации, получившие вредоносное обновление, вынуждены изучать абсолютно всё: начиная с систем и учетных записей, которые напрямую связаны с SolarWinds, и продолжая расследование далее по цепочке.
Первичное выявление
Независимо от того, являетесь ли вы клиентом Varonis или нет, первый шаг — проверить наличие уязвимой версии ПО SolarWinds. Компания SolarWinds определила уязвимые версии, и, по состоянию на 16 декабря 2020 года, выпустила обновления и исправления для замены скомпрометированных компонентов.
Если ваша версия уязвима, вот какие шаги вам следует предпринять:
- Проверьте подключения к avsvmcloud [.] com и к другим доменам, связанным с атакой
Проверьте подключения DNS и прокси на предмет активности в доменах avsvmcloud [.] com, а также в других доменах, связанных с системой управления и контроля (C2) эксплойта SolarWinds Sunburst.
Клиенты Varonis могут легко искать оповещения и события, связанные с активностью в этих доменах, с помощью панели управления Varonis Edge и предустановленных поисковых запросов для поиска угроз.
- Проверьте необычную активность учетных записей и систем, связанных с ПО SolarWinds
Клиенты Varonis обнаружили необычную активность учетных записей служб, связанных с SolarWinds, в том числе аномальную активность на общих сетевых файловых ресурсах и странные подключения к рабочим станциям пользователей. Любые необычные соединения, события безопасности из Active Directory, или активность на сетевых файловых ресурсах от учетных записей служб SolarWinds должны быть исследованы, особенно в отношении конфиденциальных данных или систем.
Вот пример уведомления Varonis о необычном поведении сервисной учетной записи SolarWinds – аномальная активность на общем сетевом ресурсе:
- Проверьте необычные обращения и изменения ресурсов, сделанные другими учетными записями служб (не только теми, которые связаны с ПО SolarWinds)
Просматривайте уведомления (алерты) и логи по необычным аутентификациям и доступу, уделяя особое внимание уведомлениям и действиям учетных записей служб и объектам, к которым они обращаются в гибридных средах (Azure Active Directory).
Если вам нужна помощь нашего отдела расследований, свяжитесь с нашими представителями, также здесь можно запросить сессию для настройки продукта Varonis DatAlert.
Что мы знаем об этой APT-кампании (технический анализ)
Эта атака была проведена без использования уязвимости нулевого дня (по крайней мере — такой уязвимости, о которой мы знаем на данный момент). Преобладающая теория, еще не подтвержденная компанией SolarWinds, заключается в том, что злоумышленники использовали открытые учетные данные FTP-сервера, обнаруженные на GitHub в 2018 году, для получения доступа к инфраструктуре обновления программного обеспечения компании.
Злоумышленник смог изменить пакет обновления программного обеспечения и добавить вредоносный бэкдор в одну из библиотек подключаемых модулей (DLL) программы SolarWinds Orion под названием SolarWinds.Orion.Core.BusinessLayer.dll.
Злоумышленники подписали свою вредоносную версию DLL закрытым ключом компании SolarWinds. Сертификат был выдан компанией Symantec.
Мы предполагаем, что злоумышленник смог подписать DLL одним из двух способов:
- Злоумышленник вклинился в процесс разработки, добавил бэкдор и позволил SolarWinds подписать его в рамках легитимного процесса создания и развертывания ПО.
- Злоумышленник украл закрытый ключ сертификата, подписал сами DLL и заменил официальную DLL своей вредоносной версией. Это менее вероятно.
Любая организация, которая использует ПО производства компании SolarWinds и получает обновления с их серверов, загрузила и запустила вредоносную DLL. Поскольку DLL была подписана и доставлена через официальные серверы обновлений SolarWinds, было чрезвычайно сложно обнаружить вредоносное содержимое.
Анализ бэкдора SolarWinds SUNBURST (BusinessLayer.dll)
Когда мы заглядываем внутрь вредоносной DLL, мы видим, что злоумышленники сделал ставку на скрытность. Они приложили немало усилий, чтобы написать код, который гармонировал бы с остальной частью исходного кода Orion, используя хорошо написанные аргументы и общие, не вызывающие подозрений имена классов и методов, такие как «Initialize» или «Job».
Бэкдор SolarWinds Sunburst действует в несколько этапов:
- Бомба замедленного действия
Бэкдор ждет 12-14 дней перед отправкой своего первого сигнала на управляющий сервер (C2). Это значительно усложняет обнаружение и сопоставление атаки с вредоносным обновлением.
- Сбор информации
Бэкдор отправляет некоторую базовую информацию обратно на сервер C2 (имя пользователя, IP-адрес, версия ОС, установленные обновления), чтобы определить, стоит ли развивать атаку на данной машине. - Связь
Бэкдор использует свой собственный алгоритм генерации домена (DGA) для поиска активного IP-адреса сервера управления и контроля (C2). При взаимодействии с сервером C2 бэкдор имитирует легитимный канал связи для улучшения ПО — SolarWinds OIP (Orion Improvement Program).
- Сокрытие
Код сканирует машину на наличие антивирусов и других инструментов безопасности, которые могли бы обнаружить его присутствие.
- Развитие атаки
Если злоумышленник считает, что сеть стоит исследовать, он использует бэкдор для загрузки небольшого дроппера (загрузчика), известного как TEARDROP, который затем загрузит дополнительные инструменты для выполнения дальнейших действий после вторжения.
Алгоритм действий бэкдора
При первом сеансе связи бэкдор отправляет информацию об устройстве и его окружении, зашифрованную в DNS-пакетах.
Необычным является факт, что IP адрес в ответном DNS-пакете определяет следующий шаг бэкдора. В зависимости от того в каком диапазоне находится IP-адрес, процесс SUNBURST завершает работу или активирует дополнительный функционал, например, отключение антивируса или скачивание и запуск новых вредоносов.
Давайте более подробно рассмотрим начало коммуникации бэкдора с C2
- После загрузки DLL SUNBURST выполняет ряд проверок, чтобы убедиться, что она работает в корпоративной сети, а не на изолированной машине.
- Злоумышленники использовали то, что наши исследователи называют «алгоритмом генерации субдоменов». Его принцип заключается в создании уникального субдомена для каждой жертвы. Алгоритм собирает информацию о локальном устройстве и кодирует ее в небольшую текстовую строку.
- Затем генерируется часть FQDN сервера C2, к которому будет обращаться бэкдор. Алгоритм генерации использует две жестко заданные строки (domain1 и domain2) + а третья строка выбирается из четырех возможных значений, хранящихся в массиве строк (domain3):
Расшифрованные значения:
Domain1 = ‘avsvmcloud[.]com’
Domain2 = ‘appsync-api’
Domain3 = [‘eu-west-1’, ‘us-west-2’, ‘us-east-1’, ‘us-east-2’]
Функция GetStatus генерирует итоговую строку:
- Далее бэкдор добавляет информацию о жертве (п. 2) к полученному домену (п. 3) и отправляет DNS запрос на получившийся адрес. Соответственно, DNS запрос достигнет сервера, контролируемого злоумышленником.
Для сбора и передачи информации о жертве используется 4 функции:
«GetCurrentString» и «GetPreviousString» используются для получения уникального идентификатора GUID и имени хоста/домена устройства.
«GetNextString» и «GetNextStringEx» используются для получения списка запущенных процессов и их статуса вместе с идентификатором GUID.
Отправляя эту информацию через DNS-запросы, серверу C2 предоставляется возможность принимать обоснованные решения о том, как отвечать.
Вот несколько примеров доменных имен, запрошенных SUNBURST:
Аналитики из Prevasio расшифровали некоторые из субдоменов, обнаруженных в журналах DNS, для идентификации жертв.
- Как упоминалось выше, IP-адрес в DNS-ответе определяет дальнейшие действия SUNBURST. Класс «IPAddressHelper» содержит жестко заданные диапазоны IP-адресов, одному из которых будет соответствовать IP-адрес, полученный в DNS-ответе:
В зависимости от того, какой IP-адрес возвращается злоумышленником, SUNBURST будет выполнять методы для получения списка текущих процессов текущих процессов, вызывать свой бэкдор HTTP и многое другое.
- Вместо ответа с IP-адресом DNS-сервер может перенаправить жертву на вторичный C2, отправив соответствующий CNAME. Пример таких доменов, опубликованных в общем доступе:
- Чтобы избежать обнаружения, SUNBURST выполняет DNS-запросы с низкой интенсивностью, используя случайную задержку между запросами для каждой жертвы / домена, в некоторых случаях ожидая до 120 минут между запросами.
- SUNBURST также отправляет HTTP-запросы к домену C2 используя псевдослучайный и безвредный на вид URL-адрес для вызова команд, передавая полезную нагрузку в теле HTTP в формате JSON.
Пример URI:
hxxps://3mu76044hgf7shjf[.]appsync-api[.]eu-west-[.]avsvmcloud[.]com /swip/upd/Orion[.]Wireless[.]xml
Ответ может запускать несколько команд, поддерживаемых бэкдором SUNBURST, таких как чтение/запись файлов, перезапуск устройства и т. д.:
Обнаружение вредоносной DLL
К сожалению, SolarWinds советует клиентам исключать свое программное обеспечение из антивирусного сканирования и из сканирования средствами обнаружения и реакции на вторжения (EDR), чтобы избежать ложных срабатываний. Многие службы безопасности применяют эти типы исключений самостоятельно, чтобы снизить уровень «шума» от ложных срабатываний.
Как только бэкдор SolarWinds Sunburst установлен, злоумышленник использует дроппер TEARDROP, который считывает поддельный файл изображения с именем «gracious_truth.jpg» для декодирования встроенной в него полезной нагрузки Cobalt Strike Beacon, причем полезная нагрузка уже «настроена» злоумышленником под конкретную жертву.
Затем выполняются дальнейшие действия после проникновения — распространение, повышение привилегий, кража данных и обеспечение дальнейшего присутствия.
Компания FireEye и агентство CISA проделали фантастическую работу, документируя индикаторы компрометации (IOC), выявленные после вторжения. Мы не можем утверждать, что паттерн развития атаки каждой жертвы будет выглядеть одинаково. Фактически, можно с уверенностью сказать, что злоумышленники с большей вероятностью будут использовать тщательно настроенные кампании, управляемые человеком, для кражи специфической информации у каждой жертвы — например, инструменты, используемые тестировщиками на проникновение («красной командой») компании FireEye.
Подобные атаки на цепочку поставок являются убедительным аргументом в пользу принятия модели «нулевого доверия» и обнаружения угроз на основе поведенческого анализа. Злоумышленники смогли сделать свою вредоносную версию DLL программы SolarWinds Orion похожей на обычную версию программного обеспечения. Обнаружить это было практически невозможно, потому что все выглядело легитимно и официально. Тем не менее, как только злоумышленники начинают перемещаться по сети после проникновения, они получают доступ к новым учетным записям и обращаются к данным. Какими бы изощренными ни были действия атакующих, они не знают, как точно сымитировать нормальное поведение всех пользователей и устройств, с которыми они работают, что открывает новое окно возможностей для обнаружения.
Агентство CASA подчеркивает важность анализа поведенческих моделей в оповещении, посвященном рассмотренной угрозе:
«При вроде бы легитимном, но на самом деле несанкционированном использовании обычных учетных записей, выявление такой активности требует определенной зрелости системы защиты, чтобы отличить действия, совершаемые за пределами повседневной работы. Например, сложно себе представить, чтобы учетной записи сотрудника отдела кадров вдруг требовалось бы обращаться к базе данных о расследованиях киберугроз».
