- PVSM.RU - https://www.pvsm.ru -
Статью «Один квартал из жизни SOC. Три инцидента без купюр» весьма активно плюсовали, так что мы решили рассказать о еще одной интересной атаке, расследованием которой мы недавно занимались.
Существует мнение, что международные корпорации и крупные компании, идущие в ногу со временем в оказании услуг своим клиентам, так же четко выстраивают процессы во всех областях своей деятельности, в том числе в информационной безопасности. К сожалению, это не всегда так.
Некоторое время назад крупная компания с развитой инфраструктурой обратилась к нам за помощью. Проблема заключалась в странных событиях в инфраструктуре компании:
Для разбора ситуации мы подключили основные инфраструктурные источники к 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 Этап
II Этап
III Этап
Общая схема заражения выглядит следующим образом:
Для реализации атаки в рамках исследуемых образов рабочих станций и серверов использовались следующие компоненты вредоносного ПО:
Имя компонента |
Назначение компонента |
Malware_dll.dll |
Кейлоггер (32-битная версия) |
Malware_dll64.dll |
Кейлоггер (64-битная версия) |
Bach.dll |
Переименованная оригинальная библиотека System_dll.dll, которая является службой SystemService |
System_dll.dll |
Библиотека, которая при запуске службы System_Service подкачивается в svchost.exe. System_dll.dll поддерживает те же вызовы, что и system_dll2.dll, путём перенаправления всех этих функций в system_dll2.dll. Подтягивает _________.dll. Является 32-разрядной версией |
System_dll.dll_ |
64-разрядная версия System_dll.dll |
_________.dll |
BackDoor, 32-разрядная версия |
_________.dll_ver2 |
64-разрядная версия _________.dll |
S64 |
Аналог System_dll.dll для х64 архитектуры |
P64 |
Аналог _________.dll для х64 архитектуры |
It_helpdesk.exe |
Переименованный PsExesvc.exe (компонент PSExec, который создается и запускается на удаленной машине с целью выполнения заданных действий |
Users.exe |
BackDoor. Функционал аналогичен _________.dll, но маскируется под jusched.exe – «Java Update Scheduler» |
Всё общение сервера с клиентом шифруется. Ключ шифрования: 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, количество скомпрометированных учетных записей потенциально возросло до общего количества сотрудников компании, так как одна из скомпрометированных машин являлась контроллером домена.
На втором этапе для исследования были выбраны еще несколько машин для поиска дополнительных индикаторов компрометации. Образы, дампы были сняты, и можно было приступать к процессу «перезаливки» скомпрометированных хостов.
В случае обнаружения такого массового, длительного и глубокого заражения процесс вычищения «хвостов» очень труден и долог. Последовательность действий выглядела следующим образом:
Общая длительность данного этапа составила около двух недель, в первую очередь, из-за технологических учетных записей.
Злоумышленники всегда резервируют свои доступы в инфраструктуру, поэтому параллельно осуществлялся полноценный мониторинг инцидентов и профилирование всех активностей.
С последним была отдельная сложность, так как, собрав профиль за две недели, нельзя с полной уверенностью назвать его легитимным, ведь злоумышленники все еще могли быть в инфраструктуре. Поэтому необходима была процедура согласования всех собранных активностей с компанией и уже в дальнейшем – фиксация собранных профилей. Общие рекомендации по выявлению резервных доступов выглядели следующим образом:
Одновременно Solar JSOC осуществлял мониторинг активности на критичных серверах и рабочих станциях по следующим направлениям:
После принятия оперативных мер по блокированию угрозы появилось время для сведения полного отчета о произошедшем инциденте:
В качестве заключительной мысли хочется отметить, что обнаружение аналогичных инцидентов – это задача Security Operations Center, но и без него кое-что можно сделать, если правильно организовать работу с рядовыми сотрудниками компании и постоянно повышать их Security Awareness.
Злоумышленники часто пытаются скрыть свою активность от службы информационной безопасности и ИТ-администраторов, поскольку именно эти категории сотрудников компетентны в области информационной безопасности и понимают, что различные аномалии могут быть вызваны внешними воздействиями. При этом хакеры часто пренебрегают сокрытием своих действий от рядовых пользователей. Повышенная нагрузка на компьютер, странные действия на системе, внезапно открывшиеся или закрывшиеся приложения, появление новых файлов, иконок, установленных приложений, которые замечает пользователь, могут служить индикатором компрометации системы. Поэтому безопасникам необходимо внимательно относиться к входящим запросам, жалобам со стороны персонала компании и мотивировать сотрудников на информирование ответственных по отмеченным аномалиям.
Автор: avpavlov
Источник [2]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/269916
Ссылки в тексте:
[1] www.gf8ealht9d22________________.com: http://www.gf8ealht9d22________________.com
[2] Источник: https://habrahabr.ru/post/343668/
Нажмите здесь для печати.