Хабрахабр

Solar JSOC Forensics: дело о майнинге на 32-х несуществующих гипервизорах

Последний год можно считать расцветом массового майнинга криптовалют. Ровно год назад этот хайп достиг пика, и цены на видеокарты в магазинах взлетели. Затем алгоритмы майнинга портировали в браузеры, и появился знаменитый сервис Сoinhive. Даже недавнее падение курса основных криптовалют не сильно затормозило процесс. Естественно, злоумышленники не только следили за этим явлением, но принимали в нем активное участие.

Мы фиксировали и расследовали множество инцидентов, когда внешние нарушители распространяют майнеры в нагрузку к основному модулю вредоносного ПО, скрывают его под именами системных процессов (например, C:\Windows\Sys\taskmgr.exe), а иногда бывали случаи, когда распространение шло за счет сетевых эксплойтов, Psexec-ов и их аналогов, и разумеется, вредоносного Javascript. Можно по-разному относиться к самим криптовалютам и токенам, однако каждый безопасник негативно относится к майнингу, когда он производится несанкционированно и на оборудовании предприятия.

И чаще всего он хорошо знает, что делает и как скрыть следы так, чтобы остаться безнаказанным. Но, кроме нарушителя внешнего, бывает нарушитель внутренний. Один такой случай нас попросили расследовать.

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

Сотрудник сделал это осознанно, так как файл распакован на рабочий стол. Гипотеза 0. Вероятность того, что это сделало вредоносное ПО, минимальна.

Наверняка это же правило ранее срабатывало на архиве, лежащем в папке \Downloads. Проверить такую гипотезу очень просто – достаточно посмотреть в журнал антивируса на рабочем месте пользователя.

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

К делу

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

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

Отработали штатно, и вроде бы все хорошо, и можно идти дальше. Аналитик со стороны Solar JSOC сообщил клиенту о «потенциально нежелательной активности», и тот заблокировал обращения на межсетевом экране и прокси-сервере. Мы немедленно сообщили об этом заказчику, который попросил провести детальное расследования инцидента. Но при этом аналитик также обратил внимание на то, что майнинг производился с 32 разных IP-адресов, которые по документам являются гипервизорами (а мощности на них немалые).

Как только дело передали в JSOC CERT, мы сразу начали сбор цифровых доказательств (копия жесткого диска, RAM и прочее), и тут на пути расследования встали два неприятных обстоятельства:

  1. Сегмент сети, в котором осуществлялась майнинговая активность, не был подключен к SIEM (ввиду ограничения охвата инфраструктуры).
  2. У клиента не было удаленного доступа к гипервизорам, потому что по документам их списали в утиль 2 месяца назад.

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

Злоумышленником мог быть кто-то из своих. Гипотеза № 1.

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

Сотрудники ЦОД причастны к инциденту. Гипотеза № 2.

В итоге имеем неприятную ситуацию, когда целевых серверов нет, журналы их контроллера домена перетерлись (напомним, этот сегмент не подключен к SIEM), выход в Интернет из сегмента не проксируется, никаких netflow и в помине нет… В такие моменты следует сделать шаг назад и вспомнить, что у нас есть. А были у нас только журналы DNS-серверов…

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

  • Кто-то использует Event Log Explorer.
  • Кто-то экспортирует все в Elastic/Kibana.
  • Кто-то экспортирует в csv и затем sort-ит и grep-ает прямиком в командной строке.

Мы используем все вышеперечисленное и даже больше, но в данном случае нагляднее всего был статистический анализ, сделанный в старом добром Excel, а именно сводные (pivot) таблицы, которые в пару кликов превращают миллион вот таких записей:


Пример выгрузки из HPE ArcSight

в такую таблицу:


Количество DNS-запросов в день (по вертикали) от конкретного IP-адреса (по горизонтали)

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


Сводная таблица с наглядным форматированием

Большая часть инцидентов начинается с одинакового паттерна:

  1. Сначала серверы отсылают DNS-запросы, характерные для Windows-системы (запросы к NTP-серверам и телеметрия вроде telecommand.telemetry.microsoft[.]com).
  2. Активность прекращается на неделю, день, а иногда не прекращается вообще.
  3. Серверы начинают слать запросы, характерные для Ubuntu (ntp.ubuntu[.]com, security.ubuntu[.]com, us.archive.ubuntu[.]com и так далее).

Гипотеза № 3. Злоумышленник поднял виртуальную машину Ubuntu с тем же IP, который ранее был у гипервизора.

После чего каждый из этих хостов по два-три раза запросил обратную DNS-запись для одного и того же хоста из другого сегмента сети: Прямо перед началом майнинга больше половины хостов обратились к google[.]com, а затем сразу к download.minergate[.]com.

После создания виртуальной машины злоумышленник открыл на ней браузер, зашел в Google, нашел страницу загрузки майнера, загрузил его, и затем зашел на “узловую точку” – неизвестный ранее сервер, откуда скачал конфигурационный файл майнера.
Обратные DNS-запросы о узловой точке

Гипотеза № 4.

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


Ошибки злоумышленника при обращении к узловой точке

К счастью, ближайший к узловой точке доменный контроллер был подключен к SIEM, что позволило узнать, кто и с какой учетной записью туда заходил:

Единственная учетная запись по понятным причинам затерта. Количество попыток аутентификации всех учетных записей на узловой точке.

Итого:

Гипотеза

Статус проверки

1.

Злоумышленником мог быть кто-то из своих.

Подтверждено

2.

Сотрудники ЦОД причастны к инциденту.

Опровергнуто

3.

Злоумышленник поднял виртуальную машину Ubuntu с тем же IP, который ранее был у гипервизора.

Подтверждено

4.

После создания виртуальной машины злоумышленник открыл на ней браузер, зашел в Google, нашел страницу загрузки майнера, загрузил его, и затем зашел на “узловую точку” – неизвестный ранее сервер, откуда скачал конфигурационный файл майнера.

Подтверждено

Заключение

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть