DNS-туннель, PsExec, кейлоггер: разбираем схему и технические инструменты атаки

Статью «Один квартал из жизни SOC. Три инцидента без купюр» весьма активно плюсовали, так что мы решили рассказать о еще одной интересной атаке, расследованием которой мы недавно занимались.

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

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

1. Рабочие станции и серверы внезапно уходили на перезагрузку и выводились из домена.
2. Пользователи обнаруживали, что их учетная запись заблокирована.
3. Компьютеры некоторых сотрудников стали «тормозить» без видимой причины.

Для разбора ситуации мы подключили основные инфраструктурные источники к SIEM-системе, находящейся в облаке Solar JSOC. Для этого мы разместили сервер-коллектор для сбора логов на площадке заказчика и построили site-to-site между площадками. Параллельно компании были высланы инструкции по настройке необходимого уровня аудита, а также подробное описание подготовительных работ для подключения источника.

На первом этапе мы подключили межсетевые экраны и прокси, антивирус, логи контроллеров домена и DNS. Уже к вечеру следующего дня у нас были логи всех необходимых систем.

Первое, что удалось детектировать, – обращение с 12 рабочих станций к серверам управления Corkow/Metel. Оказалось, что в течение более чем двух лет клиентские части одной из модификаций вируса Win32/Corkow оставались никем незамеченными в инфраструктуре компании, несмотря на наличие антивирусного ПО. Вредоносы отправляли телеметрию на давно выключенные серверы управления (доменные имена серверов были названы в честь двух великих русских художников и широко известны аналитикам ИБ). Антивирусный вендор, ПО которого использовалось в компании, так и не добавил известные сигнатуры в свои базы, поэтому не мог детектировать вирус.

Но дело оказалось не в этом хоть и нашумевшем, но более не опасном вирусе. Буквально через несколько часов мониторинга, впервые в реальной практике Solar JSOC, был выявлен полноценный, не тестовый, DNS-туннель, отправляющий информацию с нескольких хостов инфраструктуры компании.

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

Но опасность DNS-туннелей кроется не только в том, что с их помощью можно незаметно похитить данные из инфраструктуры. DNS-туннели позволяют строить reverse shell с конечным хостом, что позволяет контролировать его действия удаленно.

Несмотря на то, что DNS-туннели – тема очень старая, и все решения класса IPS и NGFW должны их детектировать, на практике это далеко не так. Малейшее изменение параметров (например, передача payload в поле key или другом поле стандартного формата DNS, либо за пределами стандартных полей DNS-запроса) позволяет легко обойти стандартные сигнатуры.

Первым делом были приняты меры по блокированию внешних адресов на всех пограничных сетевых устройствах.

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

При подключении хостов специалисты Solar JSOC столкнулись с первой сложностью – Security Log был пуст на всех машинах. Параллельно исследовался образ, и тут возникла вторая сложность – USN (Update Sequence Number) и MFT (Master File Table) не содержали хоть сколько-нибудь значимой информации из-за частой плановой дефрагментации дисков.

Первую существенную информацию удалось обнаружить в логах контроллеров домена – там был выявлен доступ к хостам под учетной записью доменного администратора. Вход осуществлялся с logon type 3 – сетевой вход к «админ. шаре» C$.

Далее, анализируя на всех потенциально скомпрометированных хостах System Log, который не был очищен, мы обнаружили установку службы it_helpdesk. После анализа MD5-суммы стало понятно, что это переименованная утилита PsExec. ИТ-подразделение компании подтвердило, что данное ПО не является корпоративным стандартом администрирования и не используется сотрудниками.

PsExec входит в состав PsTools – пакета бесплатных утилит, разработанных компанией Sysinternals и затем приобретённых Microsoft. Они предназначены для упрощения администрирования операционных систем Microsoft Windows. Сама утилита PsExec позволяет удаленно выполнять процессы.

PsExec позволяет перенаправлять входные и выходные данные удаленно запущенной исполняемой программы посредством использования SMB и скрытого ресурса общего доступа $ADMIN на удаленной системе. С помощью этого ресурса PsExec использует интерфейс программирования диспетчера управления Windows Service control Manager API для запуска службы PsExecsvc на удаленной системе, которая создает именованный канал (named pipe), по которому работает PsExec.

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

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

I Этап

• Переименование оригинальной библиотеки system_dll.dll в system_dll2 и создание вредоносного объекта system_dll.dll. При этом system_dll.dll обращается к system_dll2 за функциями, которые не определены в его коде. system_dll.dll представляет собой вредоносный объект типа PE, который служит для загрузки библиотеки _________.dll.
• Создание _________.dll — представляет собой вредоносный объект типа PE, который служит для установления связи с произвольными серверами по протоколу DNS и выполнения различных команд. Данная библиотека загружается вредоносным объектом system_dll.dll.
• При последнем запуске it-helpdesk на машине предположительно осуществляется запуск объекта C:Windowssystem32shutdown.exe с целью инициации перезагрузки операционной системы. Данная перезагрузка необходима, чтобы служба System Service подгрузила в свое адресное пространство вредоносную библиотеку System_dll.dll.

II Этап

• После перезагрузки операционной системы появляются события ошибок резолва домена random symbols.xxxxx.su, что может свидетельствовать о функционировании скрытого канала передачи данных с использованием протокола DNS (произвольные данные передаются в доменном имени 3-го уровня).
• Создание библиотеки Windows/System32/malware_dll.dll, которая представляет собой вредоносный объект типа PE, служащий для перехвата введенных с клавиатуры данных. Хранение данных, которые были перехвачены осуществляется в файле %USER%/AppData/LocalLow/NTUSER.DAT. Данные в файле закодированы с использованием побайтового кодирования с вычитанием байта 10H.
• Создание на атакуемом хосте вредоносного объекта jusched.exe, который служит для перезагрузки библиотеки malware_dll.dll. При этом объект jusched.exe прописывается в автозагрузке (ветка реестра HKLMSoftwareMicrosoftWindowsCurrentVersionRun), это означает, что система будет загружать данный объект при старте сеанса от любого пользователя.

III Этап

• При последующем создании сеанса пользователя, подгружается его профиль, запускается кейлоггер, создается файл LocalLow/NTUSER.DAT и осуществляется запись в него результатов работы кейлоггера в рамках всего сеанса пользователя.
• Также на данном этапе выполняется запуск архиватора из командной строки rar.exe с целью создания архива C:ProgrammData.0. Данный архив содержит в себе теневую копию файла SAM и ветку реестра HKLMSYSTEM. Данная связка файлов может использоваться для извлечения хешей учетных записей из файла SAM.
• В некоторых случаях данный этап сопровождается множественными перезагрузками операционной системы, выполнением команд wevtutil, gpscript, nslookup, cmdkey и др., а также очисткой журнала Application.
• На одной из исследуемых машин были зафиксированы создание и множественные запуски объекта tvnserver.exe с одновременным появлением на машине вредоносного объекта users.exe и записи в ветку реестра HKLMSoftwareCorporation ключей 000 и 001 с конфигурацией вредоноса.

Общая схема заражения выглядит следующим образом:

Описание инструментов, используемых для реализации атаки

Для реализации атаки в рамках исследуемых образов рабочих станций и серверов использовались следующие компоненты вредоносного ПО:

Активность вредоносных компонентов

1. Malware_dll.dll:
   • Создание файла «%APPDATA%LocalLowNTUSER.DAT».
   • Создание мьютекса «mbowefvncwiomcowermg32».
   • Устанавливает перехват нажатий клавиш на клавиатуре.
   • Шифрование полученных данных и последующая запись в файл из первого пункта.

2. System_dll.dll:
   • Автозапуск посредством службы System Service.
   • Загрузка _________.dll.

3. _________.dll и users.exe:
   • Отправка на резолв DNS-адресов:
     — www.gf8ealht9d22________________.com
     — 832v1hda31sqfcl5bh81lmqk74z.xxxxxxxxx.com
     — 13bmvqdr1ju64dqm6n8877hbo0z.xxxxxxxxx.com
   • Отправка DNS-пакетов на управляющий сервер (xxxxx.su).
   • Исполнение команд, полученных от управляющего сервера.
   • Возможно создание ключей реестра для хранения данных между перезапусками процесса в ветках HKLM или HKCU:
     — SoftwareCorporation00
     — SoftwareCorporation01
     — SoftwareCorporation02

Общение клиента с сервером

Всё общение сервера с клиентом шифруется. Ключ шифрования: 25 d9 01 4c 21 c9 ed 89 86 14 8d 05 _________

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

На сервер отправляются пакеты вида <27 symbols>.xxxxx.su. Последовательность может быть и более 27 символов, но минимальный пакет в 27 символов. Последовательность из 27 символов – это закодированные после шифрования данные, которые клиент передаёт серверу. Данный пакет не несёт в себе никакой информации, кроме псевдорандомных чисел и хеш-суммы пакета. Псевдорандомные числа нужны, чтобы после всех преобразований пакеты не были похожи друг на друга. Пакет из 27 символов говорит серверу, что он готов принять команду на обработку. Пример такого пакета:

В ответ приходит команда в виде 6 адресов ipv4 – 24 байта данных. Данные адреса записываются последовательно и сортируются по младшему октету. Отбросив младшие октеты, получим последовательность из 18 байт.

Первый байт – количество не используемых данных (n = 1-3).
Последние n байт – псевдорандомные и не используются в дальнейшем.
Оставшиеся байты – зашифрованные данные с ключом выше.
Первые три байта – псевдорандомное число и хеш-сумма пакета, что делает одну и туже команду от сервера визуально различающуюся, из-за чего ip-адреса кажутся рандомными. Остальное – команда.

Дальнейшие шаги и ликвидация последствий

На первом этапе поиска индикаторов анализировались образы четырех рабочих станций, с которых фиксировались активные DNS-туннели.

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

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

Поиск осуществлялся как силами специалистов Solar JSOC, так и сотрудниками компании. Всего на на поиск ушло 3 дня. Скоуп зараженных систем вырос до 64, количество скомпрометированных учетных записей потенциально возросло до общего количества сотрудников компании, так как одна из скомпрометированных машин являлась контроллером домена.

На втором этапе для исследования были выбраны еще несколько машин для поиска дополнительных индикаторов компрометации. Образы, дампы были сняты, и можно было приступать к процессу «перезаливки» скомпрометированных хостов.

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

1. Работа с учетными записями:
   • Смена паролей для всех указанных скомпрометированных учетных записей, включая учетные записи от бизнес-приложений.
   • Привилегии сервисных учетных записей были ограничены, введен запрет на использование учетных записей с правами доменного администратора для работы служб.

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

2. На время работ с учетными записями был введен мораторий на использование удаленного доступа сотрудников за исключением ИТ-администраторов. Параллельно для них был запущен второй фактор аутентификации.
3. Закрыты типовые бреши организаций с развитой инфраструктурой:
   • Прямые доступы в интернет в обход прокси.
   • Удалено ПО, классифицируемое как not-a-virus и активно использующее интернет.
   • Собран профиль открытых портов на периметре, верифицировано и закрыто лишнее «на горячую», благо, произошедший инцидент позволял это сделать.
4. Администраторы прикладных систем усилили контроль за действиями и транзакциями, выполняемыми в критичных бизнес-приложениях, особенно связанных с финансовыми транзакциями, транзакциями в рамках бонусных программ и программ лояльности, доступом к клиентской и партнерской базе и т.п.
5. Для ИТ-администраторов был введен полный запрет на работу с критичными бизнес-приложениями из-под локальных учетных записей на своих АРМах. Все было переведено на доменные учетные записи с ограниченными привилегиями, находящиеся под контролем системы мониторинга.

Основные рекомендации и меры по мониторингу

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

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

1. Провести аудит установленного на рабочих станциях и серверах софта с целью выявления инструментов удаленного управления и нелегитимного ПО.
2. Обеспечить контроль запуска программ на критичных компьютерах и серверах компании, ввести «белые списки» разрешенного программного обеспечения, особенно в отношении средств удаленного управления.

Одновременно Solar JSOC осуществлял мониторинг активности на критичных серверах и рабочих станциях по следующим направлениям:

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

Основные выводы и результаты расследования инцидента

После принятия оперативных мер по блокированию угрозы появилось время для сведения полного отчета о произошедшем инциденте:

• Каналом попадания вредоносного ПО на зараженные машины являлась уже скомпрометированная на момент заражения учетная запись с правами администратора домена, которую использовали с нескольких машин в ЛВС компании.
• Для передачи вредоносных файлов на машину, выполнения команд удаленного управления и завершения заражения машин кейлоггером использовался инструмент PsExec.
• На исследуемых зараженных машинах обнаружены следы другого ПО для удалённого управления, которое попало туда несколько лет назад. Среди RAT были TIghtVNC, WinVNC, Pointdev.
• В результате работы кейлоггера, как правило, были скомпрометированы учетные данные пользователя от ОС и ряда бизнес-приложений, его почтовая переписка, критичные файлы с парольной информацией от серверов ключевых бизнес-приложений, паспортные данные сотрудников.
• Каналом последующего удаленного управления и передачи информации злоумышленникам являлся DNS-туннель.

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

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

Автор: avpavlov

Источник