История одной атаки

Авторы:           Д. Моисеев, сервис-менеджер направления Solar JSOC компании Solar Security,
А. Павлов, эксперт направления Solar JSOC компании Solar Security.

История одной атаки

Одной из самых ярких частей конференции PHDays , на наш взгляд, является «Противостояние». Оно дает возможность проверить свои навыки в борьбе против таких же профессионалов информационной безопасности. Но аналитикам Solar JSOC часто приходится участвовать в подобных противоборствах и в реальной жизни, а отчеты специалистов по форензике иногда напоминают детектив. Сегодня хотелось бы рассказать об одном таком случае.

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

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

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

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

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

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

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

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

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

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

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

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

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

sExec. ИТ-подразделение компании подтвердило, что данное ПО не является корпоративным стандартом администрирования и не используется сотрудниками.

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:\Windows\system32\shutdown.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 прописывается в автозагрузке (ветка реестра HKLM\Software\Microsoft\Windows\CurrentVersion\Run), это означает, что система будет загружать данный объект при старте сеанса от любого пользователя.

III Этап

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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