Нужен ли SOC? Решать вам!
Совсем недавно я участвовал в расследовании инцидента в одной компании. Этот инцидент мне понравился своей наглядностью. Предлагаю свое видение ситуации: первичное обследование и выводы.
Вкратце – на одном из компьютеров специалиста ИТ–отдела стали происходить странные вещи с буфером обмена. Периодически, при работе с буфером из него вставлялись то куски документов, то команды, которые, по его словам, он никогда не вводил. В наш SOC для расследования компания обратилась только спустя месяц после обнаружения такого поведения.
ПРЕДЫСТОРИЯ
До данного инцидента АМТ-ГРУП уже работала с этим заказчиком. Некоторое время назад был реализован проект, в рамках которого мы внедряли, в том числе, пограничный NGFW. Также на АРМ работников и Windows-серверах было установлено антивирусное ПО – вот и все, что было из технических средств защиты в данной компании. Выделенного отдела ИБ тоже нет, часть задач возложена на ИТ-отдел, который периодически смотрит логи упомянутого NGFW. Следует отметить, что еще во время проекта по интеграции мы предлагали подключить услугу экспертного мониторинга SOC или помочь с разработкой собственного, но, из-за недостаточного финансирования направления ИБ, заказчик отказался.
ОБСЛЕДОВАНИЕ
Услышав описание инцидента, к заказчику я ехал, честно говоря, без особой надежды на успех расследования. По симптомам это, с большой вероятностью, могло быть либо плохо написанное шпионское ПО, либо так совпали звезды, что пользователю это просто показалось (поскольку документальных подтверждений инцидента не было). К тому же прошло около месяца с появления симптомов, а компьютер продолжал использоваться. Шпионское ПО могло уже удалиться, особенно в случае присутствия внутреннего злоумышленника. А косвенные признаки - кэши, физически не удаленные файлы и т.д., которые могли остаться, - уже бы перезаписались. После стандартных процедур снятия дампа памяти и копии диска, я решил просто бегло осмотреть систему. Вскоре на компьютере были обнаружены интересные артефакты, которые и натолкнули меня на мысль написать статью:
- На АРМ обновления не ставились уже два года! Т.е. в компании был настроен WSUS, но по непонятным причинам, уже два года был сбой установки. В логах обновления - «отказ» и невнятная ошибка.
- Логирование событий остановлено и все файлы логов удалены. Служба логирования не перезапускается, выдается ошибка.
- Последняя запись журнала антивируса – логи удалены пользователем несколько дней назад. Больше ничего. Пользователь говорит, что ничего не удалял.
- В Windows директории был найден сервис PsExec для удаленного доступа к системе. Как выяснилось, пользователь когда-то сам изучал утилиты из Sysinternals пакета, но, разумеется, он его ставил или злоумышленник - непонятно.
- IP-адреса DNS-серверов в сетевом подключении подменены на внешние, зарегистрированные в Америке IP-адреса.
- На АРМ присутствуют учетные записи, назначение которых пользователь не знает.
В принципе, такой букет сюрпризов уже крайне подозрителен. Стоит отметить, что при внедрении SOC даже в минимальном наборе «SIEM + инженер мониторинга» в компании обо всех этих событиях можно было бы узнать через несколько минут, а не лет!
Дальнейшее расследование - тема отдельной статьи, ниже давайте на основе приведенного случая разберем каждый найденный артефакт в срезе того, как можно было бы ускорить и повысить эффективность расследования, если бы был внедрен SOC. Основная идея тут в важности наличия процесса мониторинга и журналирования событий, позволяющих, по аналогии с традиционным расследованием преступления, сохранять улики и доказательства до того, как они будут затоптаны ногами, смыты дождем, сожжены пожаром и т. д.
Начнем с остановки журналирования. Любой провайдер SOC первым делом настраивает правила, позволяющие выявить сбой службы журналирования. Это можно сделать как сбором некоторых типов событий о неудачной записи в журнал, так и установки таймеров на приемниках событий, которые срабатывают, если от узла не получены события за определенный промежуток времени. Также можно через групповые политики разослать разработанные задачи, отправляющие в журнал события через определенный промежуток времени.
Сбор событий со средств антивирусной защиты (помимо других источников) также является обязательным, как и отслеживание запуска и остановки самого процесса антивируса.
Ошибки обновления компонентов обязательно должны журналироваться и SIEM должна оперативно оповещать об этом инженера мониторинга. Также собираются события об успешно установленных обновлениях, так что, в экстренном случае, например, при эпидемии вируса, использующего незакрытые патчами уязвимости, можно быстро узнать, на каких компьютерах определенный патч отсутствует. Кроме того, при услуге управления уязвимостями выполняется периодическое сканирование внутренней сети на предмет уязвимостей и не установленных обновлений.
Все легитимные средства удаленного управления и другие утилиты, которые могут быть использованы хакерами, но при этом проходить проверку антивирусом, обязательно должны отслеживаться. Их использование можно обнаруживать как по имени файла, обращению на известный пул адресов, так и с помощью поведенческого анализа по категории запускаемого средства, если на хостах используется HIPS (например, есть в АВ Касперского - KES). При установке агентов на хост возможности журналирования также расширяются. Если пользователю необходимо использование подобных утилит - настраиваются исключения, но логирование по-прежнему выполняется, и инциденты для инженера мониторинга уже не создаются. К примеру, запуск tcpdump для бухгалтера является инцидентом, а для сетевого инженера нет.
Смену DNS-сервера можно обнаружить по обращению на DNS-порты внешних IP-адресов из внутреннего сегмента сети. Кстати, в данном конкретном случае в смене DNS виноват поставленный для альтернативной проверки антивирус Comodo с опцией по умолчанию Comodo Secure DNS. Но, во-первых, сменой DNS часто промышляет вредоносное ПО, а во-вторых, для некоторых государственных структур такой инцидент фактически отслеживания DNS запросов уже является серьезным нарушением политики безопасности.
Ну и, разумеется, отслеживание изменения списка или прав пользователей – базовая задача любого SOC.
ПОЧЕМУ МОГ ПРОИЗОЙТИ ИНЦИДЕНТ
Чем же плоха описанная ИБ-система и как мог произойти инцидент? Пограничные NGFW решения не видят внутрисетевого трафика, да и от целенаправленных APT атак не спасут. Для того, чтобы убедиться, что обойти такие средства можно без специальных навыков, достаточно ввести в поисковике название вашего средства защиты + bypass, и вы найдете различные способы, вплоть до использования стандартных msf утилит, чтобы обойти блокировку. Обход современных антивирусов с эвристикой сложнее, но способы также существуют. К примеру, еще недавно вредоносные powershell скрипты не определялись ни одним антивирусом, да и сейчас не все антивирусы это отслеживают. На профильных форумах всегда можно увидеть свежие обсуждения обхода антивирусных движков, не говоря уже о закрытых обсуждениях, которые мы не можем увидеть. К тому же около двух третей всех инцидентов ИБ происходят со стороны внутреннего злоумышленника. Реальное расследование невозможно без проактивного мониторинга и полноценного журналирования.
Часто можно услышать слова: «Ну вы же специалисты, разбирайтесь, найдите что-нибудь». И не всегда ИТ или ИБ-специалистам компании удается объяснить руководителям, не знакомым со спецификой форензики, что, чтобы было в чем разбираться, нужно заранее об этом позаботиться. Специалисты по форензике не волшебники, и доказательства не появляются из ниоткуда. Если нет инструмента, собирающего эти самые доказательства, а злоумышленник постарается и почистит за собой следы, то расследование только затянется, очень дорого обойдется, но не всегда приведет к результату. Кто-то это понимает и объясняет важность развития ИБ в своей компании, кто-то нет. Ждать первого инцидента внутри компании для того, чтобы получить толчок к созданию своего SOC, или позаботиться об этом заранее - решать вам.