Введение

В первой части статьи мы дали краткое описание механизма encrypted SNI (eSNI). Показали каким образом на его основе можно уклоняться от детектирования современными DPI-системами (на примере билайновского DPI и запрещенного РКН рутрекера), а также исследовали новый вариант домен-фронтинга на основе данного механизма.

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

Мы постараемся применить механизм домен-фронтинга для современных инструментов RedTeam, например, таких как Cobalt Strike, Empire и т.д., и дать им дополнительные возможности по мимикрированию и уклонению от современных систем фильтрации контента.

Введение

Современные корпоративные системы фильтрации контента, от таких именитых производителей как Cisco, BlueCoat, FireEye имеют довольно много общего с более мощными их собратьями — DPI системами, которые усиленно внедряются на национальном уровне. Суть работы и тех и других в том, чтобы производить досмотр входящего и исходящего интернет трафика и, на основании черных/белых списков, принимать решение о запрете интернет-соединения. А так как и те, и другие в основах своей работы полагаются на схожие принципы, то и способы их обхода также будут иметь много общего.

Одной из технологий, позволяющей достаточно эффективно обходить как DPI, так и корпоративные системы, является технология домен-фронтинга. Ее суть состоит в том, что мы идем на заблокированный ресурс, прикрываясь другим, публичным доменом, с хорошей репутацией, который заведомо не будет блокирован ни одной системой, например google.com.

О данной технологии было написано уже достаточно много статей и приведено много примеров. Однако популярные и обсуждаемые в последнее время технологии DNS-over-HTTPS и encrypted-SNI, а также новая версия протокола TLS 1.3 дают возможность рассмотреть еще один вариант домен-фронтинга.

Ни для кого не секрет, что корпоративные IPS становятся все умнее и умнее. Сейчас уже никого не удивишь IPS с SSL-митмом на периметре сети или даже внутри корпоративной сети между сегментами. В то же время, помимо всем известных IPS, стали появляться и распространяться различные EDR-решения, которые уже непосредственно на хостах смотрят за устанавливаемыми соединениями. В связи с этим порядочному RedTeam специалисту с каждым днем все труднее и труднее скрываться от вездесущего взгляда BlueTeam. Приходится становиться все изобретательнее в своей нелегкой работе.

Одним из решений для маскировки наших «более полезных деструктивных действий»(с) внутри корпоративных сетей может послужить использование протоколов SMB или RDP. Можно спрятаться внутри них и замаскироваться под легитимный трафик. В этом ничего особо нового нет и техника маскировки внутри SMB используется со времен знаменитых APT-компаний Duqu и Sauron. Там ребята также с большим успехом использовали SMB протокол для передачи управляющих команд своим агентам. После этого данную технику переняли разработчики Metasploit и Cobalt Strike.

В данной статье мы рассмотрим варианты использования протокола SMB для пивотинга, а RDP уже оставим на потом.

Публикуем статью по следам нашего выступления на Fast Track OFFZONE-2019 с докладом «Дела ажурные – как Microsoft Azure помогает в проведении фишинговой атаки».

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

При проведении RedTeam мы стараемся использовать легальные средства, которые используют пользователи. Например, наличие в компании VPN-сервиса помогает нам попадать в компанию с пользовательскими правами и при этом вызывать минимум подозрений (или не вызывать совсем).

Возникла идея посмотреть, а чем нам может помочь Microsoft. Посмотрели какие средства защиты предоставляет Microsoft и решили посмотреть, что за зверь такой Azure Information Protection.

История об исследовании и разработке в 3-х частях. Часть 3 — практическая.
Буков много — пользы еще больше

Предыдущие статьи из цикла можно найти тут и здесь =)

Проверка боем

Давайте теперь проверим работу нашего скрипта на практике. Для этого попробуем выбросить обратный туннель с виртуалки (Windows 7 .net 4.7) до линуксовой VPS на Digital Ocean и затем, воспользовавшись им, зайдем обратно на Win7. В данном случае мы имитируем ситуацию, когда Windows 7 — машина Заказчика, Linux VPS — наш сервер.

История об исследовании и разработке в 3-х частях. Часть 2 — разработческая.
Буков много — пользы еще больше.

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

Прежде всего, нам необходимо понять, в каком режиме будет работать наш модуль. Очевидно, что для прима-передачи данных нам необходимо будет использовать механизм windows сокетов и предоставляемые .Net возможности по потоковому чтению-записи в сокеты. Но, с другой стороны, т.к. наш модуль должен обслуживать несколько yamux-стримов одновременно, то все операции ввода-вывода не должны полностью блокировать выполнение нашей программы. Отсюда напрашивается вывод о том, что наш модуль должен использовать программную многопоточность и выполнять операции чтения-записи с yamux-сервером, а так же операции чтения-записи к серверам назначения в разных программных потоках. Ну и само собой необходимо предусмотреть механизм взаимодействия между нашими параллельными потоками. Благо, powershell предоставляет широкие возможности по запуску и управлению программными потоками.

История об исследовании и разработке в 3-х частях. Часть 1 — исследовательская.
Буков много — пользы еще больше.

Постановка задачи

В ходе проведения пентестов и RedTeam кампаний не всегда удается воспользоваться штатными средствами Заказчиков, такими как VPN, RDP, Citrix и т.д. в качестве закрепления для захода во внутреннюю сеть. Где-то штатный VPN работает по MFA и в качестве второго фактора используется железный токен, где-то он жестоко мониторится и наш вход по VPN сразу же становится виден, как говорится — со всеми вытекающими, а где-то таких средств попросту нет.

В подобных случаях постоянно приходится делать так называемые «обратные туннели» — соединения из внутренней сети к внешнему ресурсу или контролируемому нами серверу. Внутри такого туннеля мы уже можем работать с внутренними ресурсами Заказчиков.

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

Конечно же, со своей стороны разработчики защитных решений не стоят в стороне и активно детектируют подобные действия.

К примеру, MSF-сессии успешно детектируются современными IPS от Cisco или Positive Tech, а обратный SSH- туннель можно задетектить практически любым мало-мальским нормальным файерволлом.

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

Давайте попробуем найти или изобрести нечто подобное.

В дополнение к нашей прошлой статье про расшифровку DPAPI-блобов расскажем еще о двух случаях, с которыми нам пришлось столкнуться. Речь пойдет о сохраненных паролях в браузерах MS IE11 и Edge.

Стратегия остается прежней – будем все расшифровывать в режиме offline. Для этого необходимо забрать нужные файлы.

В зависимости от операционной системы (Windows 7 или выше) сохраненные пароли следует искать в двух местах:

В случае Windows 7 это ветка реестра

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

В случае Windows 8 и выше — хранилище Windows Vault.

Так же следует отметить что на Windows 7 пароли http basic авторизации так же хранятся в Windows Vault, так что забрать его не помешает в любом случае.

Ну и по старой доброй традиции — все это конечно же шифруется через DPAPI-механизмы.

Теперь рассмотрим алгоритм расшифровки более подробно.

Вторая статья по итогам выступления нашей команды на OFFZONE-2018. На этот раз рассмотрим доклад с MainTrack “Windows DPAPI “Sekretiki” or DPAPI for pentesters”.

Внимание! Очень много буков!

При проведении RedTeam кампаний хочется давать меньше поводов для реакции BlueTeam, но их может быть много. Например, запуск mimikatz для получения пользовательских паролей или сертификатов. Даже если мы сумели «отмазать» его от Касперского, у BlueTeam есть возможность отслеживания с помощью специализированных средств, таких как Sysmon, Microsoft ATA и т.д. В тоже время хотелось бы получить максимум информации со скомпрометированной машины пользователя. В ходе неоднократно проведенных RedTeam кампаний с противодействием настоящим BlueTeam командам мы пришли к выводам, что необходимо в максимально избегать действий, которые могу служить индикаторами компрометации системы. Достигнуть эту цель возможно с помощью использования легальных механизмов и действий, предусмотренных операционной системой для пользователя.

Одним из таких легальных инструментов является механизм DPAPI (Windows Data Protection API), который используется операционной системой и различными приложениями для шифрования чувствительных данных пользователя (прежде всего паролей, криптографических ключей и т.д.) Для конечного пользователя и его приложений DPAPI выглядит предельно просто: есть всего 2 функции – «зашифровать данные» и «расшифровать данные». В данной статье хотелось бы рассмотреть, насколько такой механизм полезен пентестерам при проведении RedTeam кампаний.

Не прошло и месяца, как мы решили, что пора написать статьи по итогу наших выступлений на OFFZONE-2018. Первая статья будет исполнена по мотивам доклада с FastTrack «MS Exchange Relay attack without sms and registration».

При проведении RedTeam использование фишинга является обязательным – можно построить великолепную защиту на периметре, но какой-нибудь пользователь поведется на фишинг и даст злоумышленнику возможность оказаться сразу внутри сети. Все прекрасно знают, что в основном для фишинга используют ссылки на сторонние сайты, по которым пользователю нужно перейти или документ с макросом. Службы безопасности под угрозой санкций «дрессируют» пользователей, говоря, что ни в коем случае нельзя нажимать на кнопочку «включить содержимое». И в принципе успех есть – пользователи на такого рода рассылки ведутся все реже. Но злоумышленники тоже не стоят на месте – фишинг становится все более интересным. От нас Заказчики также требуют каких-то интересных фишинговых рассылок. Да и мы сами заинтересованы в том, чтобы сотрудники Заказчика повелись на фишинг, и мы смогли им объяснить, на что следует обращать внимание при получении письма.

В области информационной безопасности постоянно что-то происходит — она развивается, появляются новые средства защиты, которые, если верить их описанию, умеют все. Ни один хакер не сможет прорваться сквозь них в вашу информационную систему и сделать свои темные хакерские делишки. Когда читаешь про современные SIEM и anti-apt решения, прямо гордость берет за то, как стало все просто в мире информационной безопасности – поставь себе железок и софта на несколько миллионов, и будет тебе счастье, найми парочку сотрудников, чтобы следить за этим «зоопарком», — и вообще идеально. Примерно так и думает большинство руководителей компаний, администраторов безопасности и менеджеров по продажам этих самых новомодных решений.

И в принципе сказка-то почти реальна. Машинное обучение, интеграция с облаком, постоянное пополнение сигнатур случившимися инцидентами – все это хорошо помогает в разработке средств защиты. Но, отдавая за это огромные деньги, компании забывают, что такие решения нужно настраивать под конкретную информационную систему, что дефолтные настройки не спасут во время атаки, что информационная система функционирует не в вакууме.
Другие компании выбирают более бюджетные варианты средств защиты — раз в жизни закажут услугу по анализу защищенности и считают, что теперь-то у них точно все в порядке. И очень негодуют, когда что-то случается! Ведь действительно — все было сделано, чтобы обезопасить компанию. Что же пошло не так?

Цель данной статьи – порассуждать на тему безопасности компании, а также разобраться, нужны ли вообще такие услуги, как тестирование на проникновение, и почему ИБ – это дорого.