Павел Топорков, независимый эксперт: Не может быть два одинаковых редтим-проекта и двух одинаковых команд

Павел Топорков (Paul Axe), независимый эксперт, специалист в области анализа защищенности, рассказал Cyber Media об особенностях редтим-проектов и личном опыте участия в них, а также о новых трендах в сфере анализа защищенности.

Cyber Media: Если говорить о новых трендах и практиках, какие изменения в сфере анализа защищенности вы считаете наиболее интересными или важными?

Павел Топорков: Один из трендов последнего времени — переход компаний на облачную инфраструктуру. Раньше для создания основной инфраструктуры требовались домены, виртуалки, физические сервера с гипервизорами. Сегодня все по-другому. Молодые компании и стартапы, не готовые сразу нанимать себе сетевых инженеров и брать стойки в дата-центрах, арендуют нужные мощности у облачных провайдеров и там строят свою инфраструктуру. Конечно, такой тренд требует и специфического подхода к обеспечению безопасности облачных структур от проникновения и других инцидентов. Сами провайдеры занимаются этим. Например, у Amazon есть огромный список best practice — правил грамотного построения безопасной облачной инфраструктуры, и ее мониторинга. Но не все компании следуют им.

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

И последний интересный тренд — переход компаний на беспарольную аутентификацию или на использование хардварных токенов в качестве второго фактора аутентификации. Причем часто в качестве токенов используются токены Yubikey. У них есть два важных преимущества. Во-первых, такие токены можно аттестовать, то есть понять, что мы общаемся действительно с Yubikey, а не каким-то токеном непонятного происхождения. Во-вторых, эти токены требуют физического присутствия пользователя — нажать на сенсорную кнопку, чтобы ключ начал работать. Без этого токен не будет подписывать никакие запросы. Это важно с точки зрения обеспечения защиты — злоумышленники не смогут использовать токен, который уже вставлен в USB-порт без того, чтобы пользователь его коснулся.

Cyber Media: Насколько отличается инструментарий пентестера в рамках редтим-проекта и стандартного пентеста? Чем обусловлена разница?

Павел Топорков: Принципиальной разницы нет, подходы в целом одинаковые и какой-то набор утилит может быть почти одинаковым. Но технически разница огромная. Она обусловлена тем, что в редтим-проекте нельзя использовать любую утилиту, например, самую популярную и скачанную с Гитхаба, потому что у команды противодействия детекты с высокой вероятностью будут настроены именно на эти популярные утилиты. Redteam нужно искать свои подходы, избегать фингерпринтов, «рейт-лимитить» и т. д. Фактически мы используем те же самые техники. Но имплементация для редтим требует переработки или «допиливания» существующих утилит.

Также хочется отметить разные требования к туннелям в редтим-проекте и пентесте. Red team нужно больше заморачиваться с разными видами туннелирования и маскировки трафика для эксфильтрации или инфильтрации. В пентесте, как правило, такой задачи нет.

Cyber Media: Исходя из вашего опыта, какие системы защиты доставляют red team наибольшее количество проблем, сложностей?

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

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

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

Но в целом есть несколько сценариев развития событий:

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

Cyber Media: Есть ли какие-то истории из практики проведения redteam-проектов, которые вы считаете наиболее интересными?

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

На первом этапе получили логин, пароль и коннект с VPN. В этой компании использовали внешний SSO-провайдер авторизации и Yubikey в качестве второго фактора. Когда используется хардварный токен, то часто оставляют какой-то fallback-механизм на случай, если токен использовать не получается. В данном кейсе для этой цели использовали OTP-приложение для телефона от этого же провайдера аутентификации. То есть пользователь мог использовать OTP на своём телефоне как второй фактор, если забыл Yubikey токен дома.

Обычно вход выглядел так: в окошке браузера пользователь вводит логин и пароль, а затем использовал Yubikey как второй фактор. Если по каким-то причинам Yubikey невозможно использовать, то осуществляется fallback на ОТР-приложение. Мы этим и воспользовались. Начали редтим с социалки — на фишинговой странице отрисовали окошко браузера, где запрашивали логин и пароль пользователя. Естественно, дальше писали, что Yubikey не поддерживался, и просили ввести ОТР, которое потом проксировали в VPN endpoint компании.

Второй этап начался после долгого скана, когда мы обнаружили внутренний npm-репозиторий Verdaccio для разработчиков. По умолчанию эта имплементация разрешает запись всем куда угодно. Поэтому мы подменили один npm-пакет, чтобы внедрить свою полезную нагрузку в postinstall script одного из существующих npm-пакетов. После этого нужно было только дождаться, пока разработчик обновит пакет либо оно установится на какой-нибудь CI/CD системе.

На третьем этапе мы получили RCE на компьютере разработчика и увидели, что компания использует свой мессенджер, написанный на Electron. После нескольких дней изучения мне удалось найти zero-click RCE в этом мессенджере, которое отработает на любом клиенте, которому я смогу отправить сообщение. Дальше было дело техники — найти интересных для нас людей в адресной книге компании, выбрать подходящее время и отправить полезную нагрузку. И все — RCE уже у них на устройстве.