Последний год можно считать расцветом массового майнинга криптовалют. Ровно год назад этот хайп достиг пика, и цены на видеокарты в магазинах взлетели. Затем алгоритмы майнинга портировали в браузеры, и появился знаменитый сервис С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. Злоумышленником мог быть кто-то из своих.
Едем в ЦОД, чтобы снять данные на месте. Там нам показывают пустые стойки и сваленные в кучу размагниченные жесткие диски. Сотрудники ЦОД тоже отработали штатно: в целях информационной безопасности при демонтаже гипервизоров диски должны быть размагничены, что собственно и было сделано 2 месяца назад – это подтверждали даже документы с печатью.
Гипотеза № 2. Сотрудники ЦОД причастны к инциденту.
В итоге имеем неприятную ситуацию, когда целевых серверов нет, журналы их контроллера домена перетерлись (напомним, этот сегмент не подключен к SIEM), выход в Интернет из сегмента не проксируется, никаких netflow и в помине нет… В такие моменты следует сделать шаг назад и вспомнить, что у нас есть. А были у нас только журналы DNS-серверов…
В тех случаях, когда нужно проанализировать очень большой лог, каждый специалист по реагированию на инциденты использует «свои» утилиты:
Мы используем все вышеперечисленное и даже больше, но в данном случае нагляднее всего был статистический анализ, сделанный в старом добром Excel, а именно сводные (pivot) таблицы, которые в пару кликов превращают миллион вот таких записей:
Пример выгрузки из HPE ArcSight
в такую таблицу:
Количество DNS-запросов в день (по вертикали) от конкретного IP-адреса (по горизонтали)
Затем можно выделить цветом ячейки, в которых наблюдалась какая-либо активность, выставить фильтры на доменные имена майнингового пула, убрав явные шумы, добавить форматирование к некоторым другим интересным доменам, и в результате мы получим наглядную таблицу, из которой можно выделить несколько паттернов, которые подсказывают, как действовал злоумышленник:
Сводная таблица с наглядным форматированием
Большая часть инцидентов начинается с одинакового паттерна:
Гипотеза № 3. Злоумышленник поднял виртуальную машину Ubuntu с тем же IP, который ранее был у гипервизора.
Прямо перед началом майнинга больше половины хостов обратились к google[.]com, а затем сразу к download.minergate[.]com. После чего каждый из этих хостов по два-три раза запросил обратную DNS-запись для одного и того же хоста из другого сегмента сети:
Обратные DNS-запросы о узловой точке
Гипотеза № 4. После создания виртуальной машины злоумышленник открыл на ней браузер, зашел в Google, нашел страницу загрузки майнера, загрузил его, и затем зашел на “узловую точку” – неизвестный ранее сервер, откуда скачал конфигурационный файл майнера.
Одним из подтверждений данной гипотезы служит тот факт, что часть серверов также запрашивали доменные имена, похожие на IP-адреса, но с ошибкой: как будто злоумышленник случайно перепутал запятую и точку:
Ошибки злоумышленника при обращении к узловой точке
К счастью, ближайший к узловой точке доменный контроллер был подключен к SIEM, что позволило узнать, кто и с какой учетной записью туда заходил:
Количество попыток аутентификации всех учетных записей на узловой точке. Единственная учетная запись по понятным причинам затерта.
Итого:
Итак, на момент начала расследования у нас не было почти ничего. Все диски размагничены, журналы перетерты, злоумышленник узнал о том, что его раскрыли, и зачистил следы. Однако, как видите, отсутствие источников информации не всегда означает, что дело гиблое. Достаточно лишь хорошо понимать, как работает система, и постараться взглянуть на входные данные нетривиальным образом – поиграться, покрутить информацию, поискать варианты интерпретации. И тогда расследование можно будет успешно провести и без дорогих forensic-инструментов и APT-сканеров, используя буквально лишь стандартный офисный пакет. И вот в этом, на наш взгляд, суть форензики: не столь важно, какие инструменты ты умеешь применять для расследования инцидента ИБ, главное – глубокое понимание принципов работы системы и внимание к деталям.
Можно по-разному относиться к самим криптовалютам и токенам, однако каждый безопасник негативно относится к майнингу, когда он производится несанкционированно и на оборудовании предприятия. Мы фиксировали и расследовали множество инцидентов, когда внешние нарушители распространяют майнеры в нагрузку к основному модулю вредоносного ПО, скрывают его под именами системных процессов (например, 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 и прочее), и тут на пути расследования встали два неприятных обстоятельства:
- Сегмент сети, в котором осуществлялась майнинговая активность, не был подключен к SIEM (ввиду ограничения охвата инфраструктуры).
- У клиента не было удаленного доступа к гипервизорам, потому что по документам их списали в утиль 2 месяца назад.
Сначала мы предложили отключить блокировку доменных имен майнингового пула, чтобы поймать злоумышленника «на живца», но после отключения блокировки активность не возобновилась. По всей видимости, злоумышленник понял, что о его деятельности узнали, и выключил майнеры.
Гипотеза № 1. Злоумышленником мог быть кто-то из своих.
Едем в ЦОД, чтобы снять данные на месте. Там нам показывают пустые стойки и сваленные в кучу размагниченные жесткие диски. Сотрудники ЦОД тоже отработали штатно: в целях информационной безопасности при демонтаже гипервизоров диски должны быть размагничены, что собственно и было сделано 2 месяца назад – это подтверждали даже документы с печатью.
Гипотеза № 2. Сотрудники ЦОД причастны к инциденту.
В итоге имеем неприятную ситуацию, когда целевых серверов нет, журналы их контроллера домена перетерлись (напомним, этот сегмент не подключен к SIEM), выход в Интернет из сегмента не проксируется, никаких netflow и в помине нет… В такие моменты следует сделать шаг назад и вспомнить, что у нас есть. А были у нас только журналы DNS-серверов…
В тех случаях, когда нужно проанализировать очень большой лог, каждый специалист по реагированию на инциденты использует «свои» утилиты:
- Кто-то использует Event Log Explorer.
- Кто-то экспортирует все в Elastic/Kibana.
- Кто-то экспортирует в csv и затем sort-ит и grep-ает прямиком в командной строке.
Мы используем все вышеперечисленное и даже больше, но в данном случае нагляднее всего был статистический анализ, сделанный в старом добром Excel, а именно сводные (pivot) таблицы, которые в пару кликов превращают миллион вот таких записей:
Пример выгрузки из HPE ArcSight
в такую таблицу:
Количество DNS-запросов в день (по вертикали) от конкретного IP-адреса (по горизонтали)
Затем можно выделить цветом ячейки, в которых наблюдалась какая-либо активность, выставить фильтры на доменные имена майнингового пула, убрав явные шумы, добавить форматирование к некоторым другим интересным доменам, и в результате мы получим наглядную таблицу, из которой можно выделить несколько паттернов, которые подсказывают, как действовал злоумышленник:
Сводная таблица с наглядным форматированием
Большая часть инцидентов начинается с одинакового паттерна:
- Сначала серверы отсылают DNS-запросы, характерные для Windows-системы (запросы к NTP-серверам и телеметрия вроде telecommand.telemetry.microsoft[.]com).
- Активность прекращается на неделю, день, а иногда не прекращается вообще.
- Серверы начинают слать запросы, характерные для 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-сканеров, используя буквально лишь стандартный офисный пакет. И вот в этом, на наш взгляд, суть форензики: не столь важно, какие инструменты ты умеешь применять для расследования инцидента ИБ, главное – глубокое понимание принципов работы системы и внимание к деталям.
