С 21 по 24 ноября 2023 года прошел Standoff 12 — международные киберучения по информационной безопасности, на которых команды «красных» (атакующих белых хакеров) исследуют защищенность IT-инфраструктуры виртуального Государства F . Синие же команды (защитники) фиксируют эти атаки, а иногда даже отражают. Атакующие пытались перехватить управление спутником , украсть данные клиентов банка или скомпрометировать систему управления дорожным движением; в общей сложности можно было воплотить в жизнь 137 атак и недопустимых событий. Всего было развернуто семь отраслевых сегментов: шесть офисов Государства F и один офис со сборочной инфраструктурой Positive Technologies.
Офис Positive Technologies состоял из трех сборочных конвейеров, разбитых по сложности взлома почти как в Quake III Arena: base, hard и nightmare. Конвейер base не предполагал какого-либо реагирования, hard предполагал ручное реагирование командой глобального SOC, а nightmare — автоматизированное реагирование СЗИ. Внедрение закладки в код собираемого продукта на конвейере nightmare сулило «красным» 5 млн рублей, которые остались нетронутыми, хотя попытки были. Еще не вечер — возможность показать высший класс у команд будет на следующих мероприятиях.
За каждой из отраслей Государства F была закреплена команда защитников, осуществлявшая мониторинг и расследование произошедших инцидентов. Задача синих команд — оперативно выявлять все атаки, детально расследовать их и формировать подробные отчеты о действиях хакеров. Красным командам для победы нужно было набрать наибольшее количество очков за реализованные недопустимые события и успешно сдать отчет с описанием каждого шага атаки.
Наша роль
Standoff — традиционно важное событие для команды экспертного центра безопасности Positive Technologies — PT Expert Security Center (PT ESC). Каждая прошедшая кибербитва запомнилась нам по-своему: на Standoff 9, например, мы впервые организовали участие наших стажеров в качестве команды защитников (что впоследствии стало доброй традицией!), а на Standoff 11 выполняли ответственную роль менторов сразу нескольких синих команд.
Но особенно значимым стал осенний Standoff 12, где мы выступали главными арбитрами кибербитвы. Наша судейская задача состояла в оперативной проверке отчетов (которые, конечно, должны были быть корректными и полными) атакующих и защитников. Справиться с этим в отсутствие полной картины происходящего в инфраструктуре было бы невозможно, поэтому наш инструментарий включал в себя несколько решений Positive Technologies из линейки продуктов для мониторинга и реагирования: MaxPatrol SIEM , MaxPatrol EDR , PT Network Attack Discovery (PT NAD) , PT Application Firewall , PT Sandbox , PT Industrial Security Incident Manager (PT ISIM) . Кроме того, для построения цепочек атак и работы с инцидентами был развернут Anthill IRP (Incident Response Platform) — наша внутренняя разработка, которую мы показали на SOC-Forum 2023 . И, разумеется, у нас были мы сами — команда глобального SOC. Поэтому в целом на Standoff в роли жюри мы выходили с твердой уверенностью в своих силах и возможностях. Тем не менее предстоящие киберучения обещали стать «задачей со звездочкой»: нас ждали абсолютно новые отраслевые сегменты и недопустимые события, часть реальной инфраструктуры Positive Technologies с режимом автоматического реагирования и многое другое.
Всего в ноябрьском Standoff участвовало 15 красных команд и 6 синих. Эти числа могут показаться скромными, но надо учитывать, что в одной команде могло быть до 10 участников, работающих параллельно. Примерно так наша команда чувствовала себя на мероприятии (осознано избежали типичной картинки с блондинкой, окруженной заботой):
Подготовка
Как известно, правильная подготовка — это уже половина успеха. И на Standoff это справедливо не только для участников противостояния, но и для команды жюри. Скоуп подготовительных задач был разноплановый, и мы разбили его на следующие шаги.
Шаг 1. Проверка средств защиты информации
После того как все продукты были развернуты для дальнейшей эксплуатации, необходимо было убедиться в правильности их настройки. Мы проверяли все: от сетевого доступа к средствам защиты и наличия у каждого специалиста необходимых учетных данных до подключения источников событий и трафика из всех сегментов. В этом нам помогала команда инфраструктуры Standoff. Ребята, вы крутые!
Кроме того, полностью на наших плечах лежала установка и настройка собственного IRP-решения Anthill IRP. На Standoff мы использовали Anthill IRP впервые, реализовав дополнительные функции специально для кибербитвы.
Средства защиты проверены — идем дальше, а именно — занимаемся правильной подготовкой активов.
Шаг 2. Идентификация активов
MaxPatrol SIEM умеет автоматизированно работать с активами; для их идентификации необходимо провести сканирование. Это позволяет автоматически получить не только перечень активов текущей инфраструктуры, но и заполненные табличные списки типа AssetGrid (динамически формируемые на основе PDQL-запроса к активам), позволяющие повысить точность срабатываний корреляционных правил.
Чтобы упростить работу по разбору инцидентов, мы заранее сгруппировали активы в MaxPatrol SIEM в соответствии со схемами офисов и дополнительно разметили те, на которых была предусмотрена реализация недопустимых событий. Именно поэтому первый офис — банковская сфера — был разбит на четыре группы, каждая из которых представляет инфраструктуру отдельного банка. Для всех размеченных активов был установлен высокий уровень важности, а также добавлено описание связанного недопустимого события и название информационной системы.
Более того, мы подготовили специальное правило для MaxPatrol SIEM, которое автоматически обогащало события информацией о связях узла-источника с недопустимыми событиями, чтобы гарантированно «засечь» атакующих еще на подступах к реализации. Для построения цепочек процессов на критически важных активах под управлением Linux мы также заполнили табличный список Critical_Linux_Hosts_for_Process_Chains и настроили профилирование доступа к активам .
С целью поиска и верификации атак, а также ретроспективного анализа трафика на периметре и внутри сети началась подготовка PT NAD. Мы распределили по группам подсети, отвечающие за тот или иной сервис или сегмент. Все это упростило работу по анализу инцидентов и дало возможность увидеть, в каком именно офисе произошло срабатывание того или иного правила. Это же позволило отфильтровать, например, только те узлы, которые закреплены за администраторами. Кроме того, немаловажной задачей было отфильтровать срабатывания чекеров, ведь даже их действия генерировали предупреждения. Очередное напоминание о том, что если сетевой трафик заведен в систему корректно, то все, что происходит в сети, видно как на ладони.
Шаг 3. Вайтлистинг
Объемный пласт работ был направлен на то, чтобы максимально избавить нас от ложноположительных срабатываний правил и не отвлекаться на их разбор в ходе Standoff. Процесс фильтрации false positive едва ли можно назвать увлекательным, но во многом именно он является основой эффективного мониторинга. В конечном итоге именно тщательная и заблаговременная (а не по принципу «в ночь перед экзаменом») подготовка к Standoff дала свои плоды.
Шаг 4. Разработка контента для недопустимых событий
В наши задачи также входила разработка правил MaxPatrol SIEM для обнаружения критических инцидентов и недопустимых событий, где это возможно. Подобные правила крайне редко можно создать для реальной инфраструктуры, но на Standoff это позволяло нам повысить оперативность проверки отчетов. Где-то мы написали отдельные правила, например на обращения к файлам на целевых АРМ, где-то просто дополнили табличный список Windows_Hacktools для выявления запуска учебного шифровальщика. Это дало возможность быстрее выявлять компрометацию и проверять прилетающие отчеты, которых было довольно много.
Мониторинг
Еще до старта кибербитвы мы разделили роли и зоны ответственности между собой. Рассредоточиться мы решили и вертикально, и горизонтально. В глобальном SOC, следуя традициям, было выделено три линии мониторинга, а за каждым специалистом закреплены свои офисы Государства F. Специалисты первой линии отслеживали и валидировали инциденты в своих офисах в Anthill IRP.
Задачи второй линии были несколько шире: необходимо было разбирать подтвержденную активность атакующих и выстраивать цепочки атак. Проще говоря, специалист должен был анализировать инциденты на предмет связанности или схожести и по этому принципу объединять их в системе Anthill IRP, фиксируя хронологию атаки.
Так разрозненные срабатывания потихоньку выстраивались в полные цепочки атак. Собственно, эта работа была призвана облегчить жизнь третьей линии, ответственной за верификацию отчетов атакующих и защитников. И вот мы плавно подошли к самому интересному — отчетам участников кибербитвы. Начнем с того, что формат проверки отчетов команд защитников и атакующих различался: если атакующих оценивали три независимых лица — автор задания, аналитик и специалист SOC, — то защитники находились исключительно в ведении глобального SOC. Логика обработки, соответственно, также варьировалась. При проверке отчетов красных команд требовалось пошагово верифицировать все описанные атакующими действия, которые привели к реализации недопустимого события. Воркфлоу был незамысловатый: специалисты третьей линии сопоставляли шаги из отчета с подтвержденными инцидентами в Anthill IRP, а при отсутствии таковых — искали необходимые события в средствах мониторинга. Именно здесь сыграла свою роль работа второй линии по сбору цепочек, результаты которой использовались как справочник.
С защитниками дела обстояли любопытнее. Синие команды могли сдавать разные типы отчетов: отчеты об атомарных инцидентах, отчеты о расследованиях реализации недопустимых событий и отчеты о реагировании. Львиную долю, конечно, составляли первые. В отчетах об инцидентах мы оценивали полноту и логичность, корректность трактовки описываемой активности. Отметим, что мы всегда были предельно лояльны ко всем командам и давали возможность доработать неточные или неполные отчеты, попутно направляя и давая свои рекомендации. Ведь главная цель участия защитников в Standoff — отточить свои навыки и научиться новому. Отчеты о реагировании обрабатывались по схожему принципу: предложенные меры по реагированию через MaxPatrol EDR должны были быть целесообразными и допустимыми в рамках конкретного инцидента. Таких отчетов было сравнительно немного, поскольку только одна команда, защищавшая транспортную компанию Heavy Logistics, работала в режиме предотвращения атак. Наиболее трудоемкой была проверка отчетов о расследованиях реализации недопустимых событий. В идеале, конечно, такие отчеты защитников должны быть зеркальны соответствующим отчетам атакующих о реализации недопустимых событий. Поэтому при верификации расследований мы опирались на описанные атакующими шаги, при необходимости сверяясь с собранными в Anthill IRP хронологиями и журналами в средствах мониторинга.
На Standoff 12 мы стали быстрее обрабатывать поток отчетов благодаря новой версии портала с унифицированными отчетами от команд защитников и атакующих, которые разбивались по kill chain. Для каждого шага указывался временной интервал, источник атаки и цель, текстовое описание и результат атаки. Можно было прикладывать скриншоты, что здорово упрощало проверку. Были моменты, когда такая функциональность подводила, но ребята из разработки Standoff прикладывали все силы, чтобы быстро вернуть ее в строй. Встроенный чатик с командой позволял оперативно уточнять непонятные моменты.
Чаще всего ошибки в отчетах были связаны со временем шага атаки, которое команды указывали не всегда точно. На следующем месте была чрезвычайная краткость описания шага, например: «Проэксплуатировано remote code execution (RCE)» — и все. Не обошлось и без нарушения правил мероприятия. Так, в инфраструктуре присутствовали узлы, компрометация которых не допускалась при реализации инцидента, например сборщики логов (log collectors). Отчеты хакеров, которые включали данные узлы, отклонялись.
Важной вспомогательной активностью, которой глобальный SOC не пренебрегал в процессе мониторинга, был сбор индикаторов компрометации (IoC) атакующих. Мы отслеживали и фиксировали IP-адреса, домены, хеши ВПО и другие данные, позволяющие провести атрибуцию разных команд атакующих. Все это помогало нам обнаруживать «красных» на этапах продвижения к реализации очередного недопустимого события и соотносить атомарные активности между собой.
Мероприятие закончилось, а мы продолжаем работать, работать и еще раз работать...
Помимо валидации отчетов, мы также смотрели и на срабатывания правил в наших продуктах с точки зрения полноты видимости действий «красных». Несмотря на то что MaxPatrol SIEM является агрегатором срабатываний других систем защиты, мы также пользовались PT NAD, PT Sandbox, PT Application Firewall для валидации срабатываний и расширения контекста. Сегодня поговорим о продуктах MaxPatrol SIEM, PT NAD и MaxPatrol EDR.
MaxPatrol SIEM
За время проведения мероприятия была заведена 51 задача на доработку контента в MaxPatrol SIEM. Оставшийся после мероприятия массив журналов мы будем продолжать использовать, пока не получим из него максимум полезной информации не только для совершенствования текущего контента, но и при создании будущего.
Первое, о чем бы хотелось поговорить, — это, конечно, исключение легитимной активности (false positive). Очевидно, что этот процесс непрерывный, и мы продолжаем делать наш контент более адаптированным для типовых корпоративных инфраструктур. Делаем это мы максимально осторожно, дабы не исключить нелегитимную активность.
Кроме того, мы смотрели наличие пропусков детектов (false negative). Делать это несложно благодаря наличию отчетов от атакующих, в которых они описывают свои шаги и используемые инструменты. Смотрим описание, проверяем наличие необходимых срабатываний. Это гораздо более сложная задача, чем исправление false positive. Например, согласно отчету, «красные» просто взяли и повысили привилегии на узле под управлением Windows c использованием, например, GodPotato. Но если начать рассматривать срабатывания до этого, то можно обнаружить неудачные попытки использовать другие инструменты, которые отличаются по событиям тем, что процесс с повышенными привилегиями (пользователь System) не был порожден. Каждый такой случай надо проверять.
Следующее, о чем важно рассказать, — это описание срабатываний правил: локализация, которая понятна любому русскоязычному и англоязычному пользователю; описание правила, которое должно говорить о том, что за активность выявляется и чем она может грозить инфраструктуре. Нам с этим сильно помогает команда наших технических писателей, спасибо им за это
Четвертое — гранулярность, а именно ее повышение. Дело в том, что одна нелегитимная активность может приводить к срабатыванию группы generic-правил, которые требуют от аналитика некоторой умственной работы, чтобы собрать этот пазл и понять, что именно произошло. Например, при фишинговой атаке с использованием макроса, который запускает загрузчик Certutil в виде закодированного PowerShell-скрипта, можно увидеть срабатывания следующих правил:
Malicious_Office_Document, Dangerous_Command_Usage Download_via_encoded_Powershell, Execute_Encoded_Powershell
Но если бы было одно срабатывание, которое говорило бы о том, что произошел запуск фишингового документа от такого-то пользователя на таком-то узле, то это ощутимо облегчило жизнь аналитику SOC.
PT NAD
За время проведения мероприятия мы убедились, что хакерам не чуждо использование как уже зарекомендовавших себя хакерских инструментов, так и совершенно новых, только появившихся в открытом доступе. Кроме того, мы видели и следы самописного софта. Первые доработки и улучшения наших сетевых детектов случились практически в самом начале мероприятия. В современных реалиях шифрованным TLS-трафиком уже никого не удивить, поэтому нам необходимо уметь обнаруживать и взаимодействие хакерских утилит по такому каналу. Одной из них является Ligolo, предназначенная для создания реверс-туннелей. Несмотря на то что мы уже умели обнаруживать ее, при использовании одной из команд «красных» срабатывания не было. Мы оперативно доработали детект и впоследствии уже не сталкивались с подобными false negative. Это лишь один из кейсов, с которыми нам пришлось столкнуться, но он показателен тем, что всегда есть возможность совершенствовать экспертизу, и такие мероприятия предоставляют нам данные, способствующие этому.
Другим несомненно важным элементом, как и в случае с MaxPatrol SIEM, являются наши описания правил и рекомендации, которые позволяют операторам оценить, с чем связано предупреждение и как на него стоит реагировать. В то время, когда постоянно происходят атаки, аналитикам SOC нужно уметь быстро анализировать ситуацию, и мы стараемся помочь им с этим; они же, в свою очередь, могут поделиться с нами тем, что мы могли бы еще улучшить в будущем.
MaxPatrol EDR
Особенностью Standoff 12 стало то, что команде Your Shell Not Pass, защитникам офиса Heavy Logistics, было предложено использовать MaxPatrol EDR для противодействия атакующим. Мы наблюдали за тем, как активно ребята использовали модули реагирования: для примера, DNS-синкхолинг доменов использовали более 1000 раз за 4 дня. Это позволяло отрезать запущенное в инфраструктуре ВПО от центров управления. В топе также оказались операции по блокировке доступа к IP-адресам, принудительное завершение процессов и частичная изоляция устройств от сети.
Согласно правилам игры, защитники должны были снимать блокировки через некоторое время. За этим внимательно следили организаторы и в отдельных случаях снимали запреты принудительно. К тому же свои баллы защитники получали за сдачу отчетов, поэтому превращать инфраструктуру в неприступный бастион было бессмысленно. Напоминаем, что все действия команда защитников выполняла в ручном режиме, автоматизация реагирования использовалась только в офисе со сборочной инфраструктурой Positive Technologies на конвейере nightmare.
Забавные случаи
На Standoff 12 произошло множество забавных и курьезных случаев — такие часто бывают и в реальных кибератаках. При появлении подозрительных ссылок в сработавших корреляциях у начинающих аналитиков появляется непреодолимый соблазн сразу перейти по ним для проверки легитимности. Атакующие, очевидно, ожидают такого поведения. Если в реальной жизни для них это является индикатором обнаружения их действий, что можно понять по заголовку User Agent, то на Standoff «красные» решили повеселить аналитиков перенаправлением на google.com с запросом «how to be an asshole while working at cybersecurity». Мы оценили.
Нам (как, думаю, и нашим друзьям-соорганизаторам) было просто приятно получать такие вот «приветы» от атакующих:
Иногда кажется, что по одному только запуску исполняемого файла невозможно определить его назначение путем анализа событий с конечной точки, но на Standoff возможно все. Так, на рисунке ниже не только хорошо видно то, что хакеры запускают эксплойт, но и не составляет труда установить, для эксплуатации какой именно уязвимости он необходим.
Хакеры, конечно, не машины, чтобы всю необходимую информацию держать в голове. Поэтому если какие-то параметры эксплойта или утилиты забыл, то можно посмотреть их прямо на жертве, почему бы и нет. На рисунке приведены наиболее популярные примеры, которые мы встречали.
Успевали повеселить глобальный SOC и защитники. Если бы мы учредили приз за самые креативные рекомендации по реагированию, то он бы точно ушел отчету на рисунке ниже. Доподлинно неизвестно, что это было: трудности перевода, следы «помощи» искусственного интеллекта или новое слово в security awareness. Но на всякий случай: безопасники, используйте «методы подводной охоты»!
Заключение
Итак, неполные четыре дня глобальный SOC провел за проверкой отчетов и расследованиями многочисленных атак красных команд, направленных на Государство F. Далее около месяца мы разбирали задачи по улучшению наших детектов на основе результатов кибербитвы. Суммарно за время мероприятия нами было зафиксировано 20 500 инцидентов информационной безопасности, проверено более 200 отчетов атакующих и около 450 отчетов защитников. Конечно, было бы лукавством утверждать, что Standoff прошел для нас гладко и безмятежно. За время кибербитвы было все: лавины инцидентов, потоки отчетов, недосып, недоедание, хаос и разруха. Тут, пожалуй, остается только поблагодарить нашу замечательную команду и выразить ей огромный респект. Коллеги, вы в очередной раз доказали свой исключительный профессионализм, успешно преодолели все возникшие трудности и показали высочайший уровень стрессоустойчивости и экспертизы в отнюдь непростых условиях. Спасибо, вы лучшие!
Авторы:
