Реальный кейс от компании RuSIEM: расследование SSRF-атаки

Заказчик обратился с просьбой провести расследование инцидента: произошла утечка почтовой переписки. С момент инцидента до обращения прошло более трех недель. После появления в сети базы почтового сервера администраторы заказчика в срочном порядке удалили роль Exchange с сервера и ввели в строй новый.

Ошибка 1 «Бес паники»: при реагировании на инциденты предпринимаются панические необдуманные действия, которые мало помогут как в расследовании, так и при минимизации последовательности атаки. Особенно это касается действий, когда что-то срочно удаляется. Обычно у злоумышленников есть способ вернуться обратно, если они уже закрепились в сети. Вторая причина в том, что они, возможно, специально «наводят шум» с целью побудить администраторов выполнить какие-либо действия, например, залогиниться под учетной записью администратора домена для перехвата хеша пароля. Это поможет им проникнуть еще глубже и закрепиться там.

Если информация появилась в открытом доступе, это может означать то, что:

• Они не могут проникнуть глубже

• У них есть 100% способ вернуться и получить более актуальную информацию

• Они хотят, чтобы служба IT запаниковала и совершила ошибку.

Ошибка 2: отсутствие регламента реагирования на инциденты. Регламент необходим, чтобы все службы могли оперативно отреагировать на происходящие инциденты по заранее определенному и продуманному плану, а также оперативно его расследовать.

Для того чтобы не паниковать, необходимо:

• Смоделировать последовательность действий в случае инцидента

• Описать их в регламенте и внедрить его в практику

Ошибка 3: инстинктивная реакция. Любая реакция из набора «бей, замри или беги» является неверной, потому что она инстинктивная:

• Пытаемся обнаружить вектор утечки своими силами при отсутствии необходимых навыков (бей)

• Ждем какое-то время (замри)

• Обращаемся к специалистам (беги)

• Реагировать надо быстро, принимать решения – осознанно.

В рамках первичного аудита был получен доступ к коммутационному оборудованию, файловым хранилищам, базам данных из-за слабых паролей. Никаких доказательств проникновения злоумышленника по этим векторам получено не было. В связи с этим сделали вывод, что либо злоумышленник не получал доступа во внутреннюю сеть, либо действовал инсайдер.

Ошибка 4: Поспешное лечение симптомов без анализа причин: сервер Exchange выведен из строя, роль Exchange c сервера удалена, журналы событий успели перезаписаться. Это сильно усложнило расcледование инцидента.

По информации от службы IT заказчика, все обновления на сервер устанавливались и сервер был в актуальном состоянии. Однако по информации из базы данных Shodan веб-версия OWA на этом IP-адресе имела множество уязвимостей.

Ошибка 5: не устанавливать обновления.

Изучение обновлений на сервере, где был Exchange показало, что обновлений действительно не было. Дамп почтовой переписки показал, что доступа непосредственно к базе не было, а имела место SSRF-атака. Сервер Exchange находился за сервером nginx, изучение его логов дало ip-адрес атакующего, который принадлежал компании, предоставляющей услуги по анонимизации. Дальнейшее исследование артефактов и логов доступа позволило выйти на конкретный скрипт, который использовался для атаки: написанный на python и выложенный на github.

Нормальное расследование инцидентов доступно не всем, поэтому лучше привлекать специалистов. Прежде чем работать с инцидентами, их необходимо фиксировать. Это то, что можно сделать в любой компании. Это максимум полезного, что может сделать большинство компаний.

Эффективное взаимодействие SOAR и SIEM-систем

Сейчас SOC-центры испытывают огромную нагрузку, регистрируя миллионы инцидентов, их количество постоянно растет. Для выявления инцидентов используются SIEM-системы, которые с помощью правил корреляции вычленяют из потока данных какие-то события или инциденты, однако даже после этого их остается все еще очень много. Как правило, среднестатистический сотрудник SOC-центра не справляется с обработкой и закрытием всех инцидентов, т.к. есть много ложноположительных срабатываний (по статистике их около 80%), но на них в любом случае требуется реагировать.

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

Одним из базовых каналов взаимодействия SIEM и SOAR является тикетинг: в SIEM генерируются события на основе правил корреляции, но как правило в SIEM нет полноценного механизма по управлению и закрытию этих инцидентов, по управлению этими процессами, и когда инцидент появляется в SIEM, для его разрешения создается аналогичный в какой-то внешней системе.

Внутри SOAR-платформы Security Vision есть полноценный движок по управлению инцидентами, где их можно удобно просматривать, закрывать, отслеживать связанные события.

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

Отправка удаленных команд на внешние системы осуществляется на основе интеграций с помощью различных коннекторов. Коннекторы можно создавать вручную, практически без написания какого-либо кода. Это существенно упрощает и ускоряет процесс, до 15 минут.

Security Vision поддерживает все транспортные протоколы: ssh, RDP, HTTP,… за счет чего можно создать практически любую интеграцию в дополнение к более 80 уже готовым.

В зависимости от типа инцидента, автоматизация позволяет сократить время реагирования в 8 и более раз (на примере заражения вредоносным ПО – с 80 до 10 минут).

Есть еще неочевидные способы взаимодействия SOAR и SIEM:

• проверка эффективности (эмуляция паттернов атак, проверка текущего уровня логирования);

• data lake для инцидентов (построение статистики на основе данных из SIEM, возможность обращаться к SIEM как к data lake);

• поиск инцидентов в реальном времени: на основе анализа аномалий определять возможные инциденты в реальном времени даже при отсутствии настроенных правил корреляции.

Можно ли заменить функционал Security Vision OpenSource-решениями? Можно, если для этого есть ресурсы и хорошие специалисты.

У SOC есть одна очень серьезная проблема – отсутствие каналов получения контекста о той организации, данные которой анализируются. Из-за этого сотрудники SOC зачастую не знают, как корректно интерпретировать приходящие события. Пример: отдел переезжает физически с одного этажа на другой и меняет свое расположение в сети (другой VLAN). В SOC об этом не знают, и нет стандартизированного способа сообщить им об этом, вследствие чего начинают генерироваться события безопасности, которые превращаются в требующие анализа инциденты.

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

SOAR-система должна быть в состоянии эту проблему решать, чтобы не искажать картину событий.

Ошибка 6: неправильное выстраивание угроз и правил корреляции. Проблема, достаточно распространенная и в больших, и мелких компаниях. Инцидент ли это вообще? Как это соотносится с моделью угроз? Как правило, это приводит к игнорированию события в дальнейшем и пропуску реального инцидента.

Ошибка 7: неверная (или отсутствующая) настройка средств обнаружения. Все средства обнаружения и автоматизации никогда не работают просто «из коробки», их надо настраивать для корректной работы в той среде, где они внедряются. Если этого не делать, системы будут генерировать множество событий, которые не будут нести никакой информации и система в целом будет бесполезна. Настройку можно проводить путем симуляции атак и настройки реакции системы на происходящие события. Эта работа может происходить около года.

Ошибка 8: некорректная работа с данными. Как правило, на начальных этапах внедрения все стараются подключить как можно больше источников для того, чтобы все логи загружались в систему обнаружения (SIEM, например). Это существенно увеличивает нагрузку, ведет к повышению стоимости владения системой (если лицензирование производится по EPS), и вынуждает систему генерировать огромное число событий. Более правильным представляется подход, когда данные сначала загружаются предварительно в хранилище (GrayLog, например), там очищаются и потом уже в SIEM уже передается только то, что необходимо для корреляции.

Ошибка 9: несогласованность действий ИБ, IT и бизнеса. При наступлении инцидента оказывается, что приоритеты у этих групп совершенно разные (например, с точки зрения бизнеса наиболее важно – прекратить инцидент и восстановить работу; с точи зрения ИБ – поймать нарушителя и расследовать), что добавляет напряженности в ситуацию и отвлекает ресурсы на поиск виноватых вместо продуктивного и своевременного реагирования.

Ошибка 10: Незнание внутреннего контекста, бизнес-процессов и инфраструктуры. Без этого знания адекватно реагировать и предотвращать инциденты не получится.