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

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

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

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


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



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

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

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

    К делу


    В рамках предоставления услуг 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, который ранее был у гипервизора.

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


    Обратные DNS-запросы о узловой точке

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

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


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

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



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

    Итого:

    Гипотеза
    Статус проверки
    1.
    Злоумышленником мог быть кто-то из своих.
    Подтверждено
    2.
    Сотрудники ЦОД причастны к инциденту.
    Опровергнуто
    3.
    Злоумышленник поднял виртуальную машину Ubuntu с тем же IP, который ранее был у гипервизора.
    Подтверждено
    4.
    После создания виртуальной машины злоумышленник открыл на ней браузер, зашел в Google, нашел страницу загрузки майнера, загрузил его, и затем зашел на “узловую точку” – неизвестный ранее сервер, откуда скачал конфигурационный файл майнера.
    Подтверждено

    Заключение


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

    Ростелеком-Solar

    167,83

    Безопасность по имени Солнце

    Поделиться публикацией
    Комментарии 3
      +1
      Роскомнадзора на них не хватает. Те бы в два счёта всю подсеть положили, и дело закрыто!
        0
        Итак, на момент начала расследования у нас не было почти ничего. Все диски размагничены, журналы перетерты, злоумышленник узнал о том, что его раскрыли, и зачистил следы.

        Кто-то из ваших?

          0
          После статьи будут осторожнее

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое