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

В случае, если у нас десятки и сотни серверов, генерирующих события, лучше всего использовать специализированные решения SIEM (Security information and event management), предназначенные для управления событиями безопасности. Помимо централизованного хранения событий ИБ, SIEM также может анализировать приходящие события на соответствие правилам корреляции для выявления инцидентов, и вот об этом мы и будем говорить в данной статье. В качестве примеров логов будут рассматриваться как журналы событий ОС Windows, так и Linux.

Что такое инцидент

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

Этапы развития атаки

Для того, чтобы представить основные действия, которые может предпринять хакер для реализации атаки воспользуемся матрицей MITRE. Матрица MITRE ATT&CK описывает тактики и техники, которыми злоумышленники пользуются в своих атаках на корпоративную инфраструктуру. На рисунке ниже тактики указаны по горизонтали: Reconnaissance, Resource Development, Initial Access и так далее. А соответствующие каждой тактике техники идут по вертикали.

Выявляем разведку

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

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

Например systeminfo. Запуск этой команды позволяет узнать основную информацию об используемой ОС.

systeminfo | findstr /B /C:"Название ОС" /C:"Версия ОС"

Аналогично команды hostname и whoami вряд ли потребуются обычному пользователю слишком часто, разве что при общении с техподдержкой.

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

net users

net user имя_пользователя

Если машина входит в домен, то команда set поможет злоумышленнику узнать многое о системных настройках и взаимодействии с AD.

В общем, не лишним будет настроить корреляции в вашем SIEM на выявление запуска данных команд как минимум на пользовательских машинах.

Получение доступа

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

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

Также для выявления Initial Access стоит уделять внимание различным сообщениям о ошибках в логах самих приложений. Так попытка выполнить переполнение буфера может привести к появлению логах сообщений о сбоях в работе приложений, например об обращении к запрещенной странице памяти.

Здесь стоит отметить, что такие сообщения, если говорить о логах Windows обычно появляются не в разделе Security, а в Application и, возможно в System. Соответственно, безопасникам при подключении источников к SIEM не стоит забывать о существовании других логов, кроме Security.

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

Этап Execution

На шаге Execution злоумышленнику необходимо выполнить различные скрипты и команды, подгрузить необходимые библиотеки для того, чтобы начать подготовку к закреплению в системе. Здесь особое внимание стоит уделить событиям Windows 4103 и 4104, связанным с запуском скриптов.

Также, не лишним здесь будет обратить внимание на запуск различных протоколов, предназначенных для загрузки файлов, например SMB или FTP.

Под Linux в качестве транспорта обычно используют SSH (SCP) так что активация SSH на машине, которая не предполагает удаленный доступ по данному протоколу это тоже очень подозрительная активность.

Закрепление и поднятие привилегий

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

Если говорить про Linux, то здесь причиной успешного поднятия привилегий может стать неаккуратная раздача прав sudo, или выставления SUID битов.

Так в примере ниже наличие прав sudo на команду find позволило получить сессию root.

В Windows также возможна неаккуратная настройка прав политик ИБ. Но также не стоит забывать и о банальных уязвимостях. Так в примере ниже в логах зафиксировано выполнение команды systeminfo с правами SYSTEM. Причиной этого стала реализация старой доброй Ettrenalblue на уязвимую машину Win 7SP1.

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

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

Заключение

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

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

В заключение напомню о ближайших уроках по SIEM:

• 6 ноября, «Настройка аудита безопасности в Windows для интеграции с SIEM». В результате урока вы научитесь работать с журналами аудита и настраивать другие средства мониторинга. Запись по ссылке

• 20 ноября, «Применение SIEM для расследования инцидентов». Обсудим, как эффективно использовать логи для быстрого выявления инцидентов безопасности и проведения детального расследования кибератак. Запись по ссылке