Привет, Хабр! Меня зовут Александр, я работаю в Региональном центре кибербезопасности ХМАО-Югры на базе АУ «Югорский НИИ информационных технологий», проще говоря – SOC. Мы занимаемся обеспечением информационной безопасности в органах государственной власти, органах местного самоуправления, медицинских организациях на территории ХМАО-Югры. В качестве первой статьи я выбрал кейс ИБ, который не так давно произошел в ИТ-инфраструктуре нашего Абонента (статья публикуется с согласия Абонента). Моя история о том, как инструменты с ИИ могут стать причиной выхода из строя ИТ-инфраструктуры. Надеюсь, наш опыт поможет другим избежать таких ситуаций в будущем.

Что произошло?

От начала рабочего дня сотрудников Абонента прошло 40 минут. В это время нам поступает алерт в систему мониторинга событий ИБ о аварийной остановке службы Netlogon на контроллерах домена Абонента. Доводим эту информацию до Абонента, на что получаем ответ: «Наблюдаем жалобы от пользователей о невозможности войти в компьютер». Наше обнаружение подтверждает Абонент, служба действительно не запускается. Решить проблему быстро не получается, поэтому чтобы ускорить процесс восстановления службы AD, было принято решение восстановить контроллеры домена из резервной копии, а выведенные из строя контроллеры отключить от сети и оставить в стороне для установки причин сбоя. Мы также не исключали вероятности хакерской атаки, поэтому продолжили работы по расследованию. Резервные копии мы совместно с Абонентом также проверили на предмет ранней компрометации с помощью песочницы. Нелегитимных действий мы не зафиксировали, поэтому дали отмашку для развертывания новых контроллеров домена из копий. С момента аварии и до восстановления контроллеров домена из резервной копии прошло около часа.

Расследование инцидента

Пока часть нашей команды продолжила поиск следов компрометации системы, мы с коллегами решили поискать причину остановки службы. Наш поиск начался с того, что мы отфильтровали события по названию службы Netlogon. Сразу же обнаруживаем событие с типом AMSI-проверка, где как раз фигурирует служба Netlogon.

На скриншоте видно часть исполняемого кода, похожего на PowerShell скрипт. По коду мы видим обращение к разделу ветки реестра «HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters», который хранит конфигурационные параметры для службы Netlogon. Также мы видим, что код создает параметр «DBFlag» со значением «0x2080FFFF», после чего принудительно перезапускает службу Netlogon.

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

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

(Данный скрипт, в определенных версиях ОС Windows, может нарушить работу ОС. Его демонстрация проводится исключительно в ознакомительных целях. Автор статьи не несет никакой ответственности за его использование.)

Прошу обратить внимание на процесс, который инициировал это действие, а именно исполняемый файл wsmprovhost.exe – хост процесс Windows, запускающийся при удаленном подключении к рабочей станции по протоколу WS-Management.

Это говорит нам о том, что код на контроллерах домена запускался удаленно с другого устройства. Учетная запись пользователя, из-под которой был запущен процесс, оказалась с правами администратора домена, именная, поэтому мы легко определили сотрудника из сетевого отдела Абонента. Учетная запись была сразу же заблокирована в домене, всем администраторам домена принудительно изменены пароли. Также отфильтровав запущенные процессы от этой ��четной записи, мы нашли запуск PowerShell_ISE, который был зафиксирован за 20 секунд до выполнения кода на одном из контроллере домена.

При интервьюировании сотрудника удалось выяснить, что с соседнего сервера запускался PowerShell скрипт по поиску заблокированных учетных записей в Active Directory.

Тут нужно пояснить. У коллег частый кейс с поиском причин блокировок учетных записей пользователей, очень много факторов оказывают влияние. Особенно большой парк наложенных средств защиты, который также дает трудности с поиском первопричин блокировок. Именно из-за этой проблемы коллеги и решили внедрить скрипт, автоматизирующий поиск этих причин. Если скрипт не выявляет проблем, то как правило коллеги обращаются к нам за дополнительным анализом средств защиты (например, средств защиты от несанкционированного доступа).

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

Какие выводы можно сделать из этой истории:

1. Использовать ИИ при написании кода можно, но стоит подходить к этому процессу ответственно, с полным пониманием каждой его строчки.

2. Перед использованием самописного ПО в продуктовой среде обязательно проводить его тестирование.

3. Помнить о важности резервных копий критических систем.

4. Дружить со службой ИБ и заранее уведомлять о проведении работ на критических системах.

На этом у меня все. Благодарю за внимание!