Есть ложь, большая ложь, а есть… обещания, которые вы читаете в бесчисленных рекламных материалах. Наша команда Endpoint Security решила доказать делом, что не просто дает красивые обещания, а готова пройти через стресс-тест настоящих хакеров.

Меня зовут Валерий, я работаю в экспертном центре безопасности Positive Technologies и в этой статье расскажу, как мы провели Endpoint Hack Zone, где я был модератором, как развернули MaxPatrol Endpoint Security и предложили хакерам выполнить ряд сценариев на защищённых хостах. 

Endpoint Hack Zone – это специализированное интерактивное пространство, развернутое в рамках нашего главного ежегодного события в сфере практической информационной безопасности – кибербитвы Standoff. В течение нескольких дней подряд 6 независимых команд белых хакеров непрерывно пытались взломать и обойти защиту системы MaxPatrol Endpoint Security v9.1, которая на тот момент являлась самой актуальной версией нашего ИБ-продукта. Мы рассчитывали привлечь команды разного уровня и разной направленности, что в принципе получилось.

Раньше подобных конкурсов никто не проводил, либо я про них просто не слышал. Вместо стандартных синтетических тестов исследователям были предложены реалистичные сценарии атак. Белые хакеры пытались реализовать техники скрытого закрепления в системе, симулировали действия продвинутых APT-группировок, тестировали методы отключения компонентов защиты «изнутри» и проверяли устойчивость продукта к атакам нулевого дня (т.н. 0-day). 

Это был открытый стресс-тест под прицелом красных команд из Standoff-комьюнити.  Максимально прозрачно: все сценарии были приближены к жизни (ведь, оказавшись на конечном устройстве, хакеру необходимо выполнять свою задачу в обход защиты).

В список на участие попали шесть команд.

Вот какие предлагались сценарии:

Для всех сценариев, кроме ВМ#3 давалась учетка администратора (на Windows) / root (на Linux), ограничение по времени составляло 3,5 часа.

Я отметил те сценарии, которые удалось воспроизвести за отведённое время.

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

• антишифровальщик,

• самозащита,

• поведенческий движок,

• антивирус,

• антируткит и

• контроль устройств. 

Далее идёт описание того, как именно хакерам удалось осуществить критические события.

Руткит

В этом сценарии мы хотели обкатать наш PoC модуля для защиты от руткитов на Linux. К сожалению, продовой реализации данного модуля пока нет (но если статья наберёт 1000 лайков… ? ). Антируткит представляет собой LKM, который защищает от различных типов Linux руткитов: LD_PRELOAD, eBPF, LKM.

Наш модуль нашли в списке загруженных модулей, разреверсили и отправили через команду ioctl на отключение. Мы никак не валидировали клиента, себя не прятали, так что всё удалось. Ну а дальше с root-учёткой, которую мы любезно выдали атакующим, можно было грузить что угодно.

Мы подправили наш PoC «на лету», и следующие команды уже его не находили.

Контроль устройств

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

Кстати, почитать наши рекомендации по тому, как защитить данные на физическом уровне, можно здесь.

Загрузка с другого устройства

На предоставленном ноутбуке был разрешён вход в BIOS без пароля, поэтому можно было загрузиться с другого устройства и унести целевой файл. Тут мы ничего поделать не можем, кроме как порекомендовать защищать вход в BIOS паролем (что мы и сделали).

Использование окна между стартом системы и стартом агента

Пару релизов назад у сервиса агента была зависимость от TCP/IP Protocol Driver, из-за чего агент запускался не сразу. Эта особенность могла быть использована для обхода защиты: времени оказалось достаточно, чтобы положить целевой файл на съёмный USB-носитель.

На мероприятии использовался агент от EDR 9.1, т.к. на момент подготовки «десятка» находилась в тестировании и активно обновлялась.

Использование окна между подключением устройства и его блокировкой

При подключении нового устройства ребята заметили, что мелькает окошко проводника, и сделали правильный вывод ? 

Небольшой powershell-скрипт позволил «унести» целевой файл с хоста на флешку до того, как она заблокировалась.

Много, конечно, не унесёшь, но недочёт обидный. Исправлено в 10.1.

Телефон в режиме передачи фото

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

Исправлено в 10.1.

Зависимость от незащищаемой библиотеки

В первый же день было обнаружено, что агент использует рантайм msvc, который находится в незащищённой директории. Как я упоминал ранее, участникам выдавалась УЗ администратора, которой хватало прав для его удаления.

Для того чтобы остальным командам было интереснее, мы занесли все нужные зависимости в защищённую папку агента. Исправлено в 10.1.

AntiRansom

Сценарий с шифрованием директории был реализован из-за ошибки в эвристиках, связанной с некорректным определением веса сработок. Данный недочёт уже исправлен.

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

Подробности про эвристики приводить не буду, думаю, мы напишем об этом отдельную статью.

Самозащита агента

Пожалуй, самый опасный сценарий, который удалось реализовать только одной команде.

Уже два года мы продолжаем работать над собственной безопасностью агента – функциональностью, которая не позволяет отключить решение на устройстве. Регулярно анализируются статьи из различных источников, проводятся собственные исследования. В работе принимают участие эксперты, команда продукта, команда низкоуровневой разработки и багхатеры площадки Standoff Bug Bounty. Именно поэтому данный сценарий был для нас особенно интересным.

В реестре Windows есть ветка, которая содержит ряд настроек управления памятью. Модификация администратором одного из значений позволяла после перезагрузки удалить исполняемый файл агента.

После этого можно было создавать файлы в директории агента, выполнять dll-hijacking, и т. д. За эту находку отдельное спасибо команде, уяза закрыта. 

«А как же BYOVD?», – спросите вы

Да, действительно, техника Bring Your Own Vulnerable Driver – одна из самых эффективных для отключения средств защиты, т.к. позволяет выполнять код из ядра Windows.

Для защиты от этой техники на машинах ВМ#1 и ВМ#2 мы использовали средства самой винды, а именно – политики Code Integrity. 

На ноутбуке с Device Control такие политики не были применены, и одна из команд успешно использовала EDR-Killer, который легко можно найти в открытых источниках. 

На тему BYOVD можно много философствовать, но кажется всё сведётся к следующему:

• Microsoft ведёт список уязвимых драйверов, стоит убедиться, что их блокировка включена в настройках безопасности Windows.

• Загрузка драйвера не остаётся незамеченной для мониторинга SIEM и EDR. Сразу после загрузки драйвера агент теряет связь с сервером – отличный повод для SOC начать расследование.

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

Заключение

И напоследок, пара слов про организацию

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

Не скрою, было немного волнительно, что что-то пойдёт не так и за отведённое время ничего не получится или, наоборот, всё очень быстро переломают. На мой взгляд получилось хорошо, хоть ввиду отсутствия опыта организации подобных мероприятий все параметры (время, количество участников, количество сценариев и т.д.) придумывались без оглядки на пример похожих активностей.

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

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

Очень хочется сделать Hack Zone регулярным мероприятием, таким же как Standoff. Лично мне было интересно – а вам? 

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

На этом всё!