Недавно я участвовал в интересном пентесте масштабной инфраструктуры. После успешного завершения проекта хочу поделиться с вами обнаруженным вектором атаки и опытом применения на практике некоторых техник.
В статье мы рассмотрим важные аспекты — подготовку C2-инфраструктуры, закрепление, схему пивотинга и другие.
Сразу оговорюсь: хотя в пентесте предполагалось противодействие SOC, мы не будем подробно рассматривать техники уклонения.
Надеюсь, чтение этой статьи будет для вас таким же увлекательным, каким для меня был сам проект.
Сбор информации
Практически любой пентест начинается с разведки и этот не стал исключением. Скоуп был большим, что внушало надежду на пробитие через веб-приложения или другие внешние сервисы. После сбора информации и сканирования внешнего периметра так называемых 'low-hanging fruits' с RCE обнаружено не было.
Однако, на Github были обнаружены доменные учётные данные одного пользователя. Также в ходе разведки был обнаружен OWA (Outlook Web Access). Совмещение этих двух находок чаще всего позволяет получить очень важную информацию - доменные логины и email’ы пользователей. Они извлекаются из так называемой GAL(Global Address List).
Global Address List - это адресная книга, в которой содержатся все объекты организации, которые имеют почтовый адрес.
Для успешного извлечения GAL необходимо, чтобы был доступен MAPI у OWA. Чаще всего он доступен и наш случай не стал исключением.
Для выгрузки GAL мы использовали утилиту ruler.
./ruler --email user@domain.com abk dump --output GAL.txtТеперь на руках у нас был огромный список учёток и почтовых адресов. А это значит, что можно провести атаку password spraying! Но есть загвоздка: слишком интенсивные действия пресекаются со стороны SOC, а password spraying на значительное количество учёток в короткий промежуток времени, через один сервис (в нашем случае OWA) и с одного адреса очевидно вызовут подозрения. Какие же здесь есть пути решения?
Ротация IP-адресов
Снижение рейта атаки
Поиск других конечных точек для доменной аутентификации и распараллеливание password spraying
Самым привлекательным вариантом был как раз последний, поскольку эндпоинты с доменной аутентификацией (в частности NTLM) имелись в избытке. Однако, мы решили использовать комбинацию из подходов, и в результате получили более 100 рабочих учеток.
В почтовых ящиках не нашлось содержимого, которое могло привести во внутреннюю сеть (VPN-конфигов, например). А на внешнем периметре обнаруживалось всё, кроме уязвимостей, приводящих к исполнению кода на серверах, имеющих связность с внутренней инфраструктурой, или любых других, которые могли привести к пробиву внешнего периметра. Было решено готовить фишинговую атаку.
Подготовка к фишинговой атаке
Для успешного фишинга необходимо решить несколько типовых для пентестера задач:
Определение целей фишинговой рассылки
Раззработка сценария (или легенды) фишинговой атаки
Организация C2-инфраструктуры
Подготовка полезной нагрузки, которая обеспечит доступ и закрепление внутри
Обход антиспам фильтра и антивирусного ПО
Поскольку у нас был очень длинный список почтовых адресов и дополнительная информация о владельцах emal’ов из GAL, выбрать цели не составило труда. Мы просто исключили контрагентов целевой Компании (они точно не обладали доступом к нужному нам сегменту) и убрали сотрудников ИБ из рассылки, так как мы не хотели намерено раньше времени раскрывать атаку. После согласования списка целей с заказчиком мы отправились решать оставшиеся задачи.
Легенда рассылки не самая замысловатая - просьба со стороны технической поддержки запустить ПО для диагностики доступности узлов сети. При переходе по ссылке пользователю показывалась форма аутентификации, скопированная с корпоративной. После ввода любых учетных данных ПО становилось доступно для загрузки.
Давайте рассмотрим технические аспекты подготовки атаки более детально.
C2-инфраструктура
В качестве полезной нагрузки мы выбрали ligolo-ng. На это было несколько причин:
В первую очередь нам нужен был сетевой доступ во внутреннюю инфраструктуру близкий к полноценному(например, VPN), так как с ним удобнее всего работать. Ещё нужно было учитывать, что ПО будут запускать низкопривилегированные пользователи.
Нам была нужна надежная имплементация каналов связи.
Возможность легко и эффективно обфусцировать имплант для уклонения от антивирусного ПО.
Неогромный размер импланта, особенно с учётом того, что ligolo-ng написан на Go.
Открытый, а главное понятный и незапутанный код.
Чтобы обеспечить себе удобный и эргономичный способ управления множеством сессий и выполнения через эти сессии различных операций, стоит выбрать C2-фреймворк. Есть очень хорошая Google-таблица с информацией обо всех известных(и не очень) C2.
Ligolo-ng является утилитой для туннелирования трафика с возможностью управления множеством обратных подключений. Самым приятным здесь было то, что на стороне сервера создаётся отдельный сетевой интерфейс, что очень сильно упрощает задачу перенаправления трафика. На стороне же клиента не требуются никакие дополнительные привилегии, а тем более привилегии локального администратора. И это не считая таких возможностей, как автороутинг, мультиплатформенность и автоматическая генерация сертов. Всё это вместе со сравнительно небольшим размером агента (~ 6 Мб).
Также всё это позволяет развернуть на сервере любой VPN (в нашем случае OpenVPN) и иметь тот тип доступа, о котором мы говорили ранее. В дальнейшем это позволит избежать проблем с применением многих инструментов. Схема организации доступа в инфраструктуру выглядит следующим образом.
При помощи iptables был настроен форвардинг между интерфейсом tun0, который создал ligolo-ng сервер, и интерфейсом tun1, который принадлежал OpenVPN серверу. Для атакующей машины всё выглядит так, будто у неё есть классический доступ в офисную сеть через VPN. Для такой конфигурации можно применить следующие правила для iptables(для простоты приведём сразу команды)
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i tun0 -o tun1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i tun1 -o tun0 -j ACCEPTТакже не забудьте настроить форвардинг на стороне OS.
echo 1 > /proc/sys/net/ipv4/ip_forwardК сожалению, из коробки ligolo-ng не имеет никаких встроенных OpSec-механизмов. При блокировке трафика к серверу доступы, как ни странно, просто пропадут. Также не стоит забывать, что сканы нашего сервера со стороны могут сильно испортить логи или положить сервер, не говоря о возможности подключения к нам evil-агента. Ещё хотелось иметь возможность исполнения команд на клиентской машине. Здесь очень сильно помогло то, что утилита написана на Go (и я его немного знаю) и что её код хорошо читается.
В агент была добавлена логика переключения между серверами при условии отсутствия ответа в течение определенного промежутка времени. Затем была добавлена клиентская TLS-аутентификация. Финальным штрихом было добавление функциональности по исполнению команд.
Подготовка полезной нагрузки и обход фильтров
Теперь оставалось обойти спам-фильтр и антивирусное ПО, затем обеспечить закрепление в инфраструктуре. Начнём с последнего пункта - закрепления(на англ. Persistence).
Persistence - категория техник, которые используются для поддержания постоянного доступа к атакуемой инфраструктуре.
От закрепления нам нужно было следующее:
Агент должен перезапускаться, если процесс будет завершён/убит
После перезагрузки агент также должен будет запуститься
Для проверки отсутствия процесса нашего агента, а также его перезапуска, мы применили не самое изящное, но очень действенное решение - крутить бесконечный цикл проверки наличия агента. Пример такого powershell-кода ниже.
while (1 -eq 1) {
if (-not (gps 'agent' -ea 0)) {
& '$env:TEMP\\agent.exe'
};
sleep 10
}Теперь нужно было как-то обеспечить возобновление работы агента и цикла проверки при перезагрузке. В Windows существует возможность создания .lnk файла с заранее заданными параметрами. Код выше достаточно короткий, чтобы его указать в качестве аргумента для ссылки на powershell. Осталось обеспечить запуск этого .lnk файла при запуске системы.
Windows после начала работы автоматически запускает программы из следующей директории:
«C:\\Users\\<user>\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\Programs\\Startup»
Очевидно, что .lnk файл стоит поместить сюда.
В итоговую полезную нагрузку была вшита логика по копированию агента, закреплению с использованием метода, описанного выше, а также отображению MessageBox с сообщением “Ok”, чтобы успокоить сотрудников после запуска и немного усыпить их бдительность.
Теперь надо было обойти почтовый антивирус. Любые загружаемые напрямую файлы подвергались динамическому анализу, а нам не нужны были лишние подозрения со стороны всевидящего ПО. Для обхода сканирования была применена техника HTML-smuggling.
О ней в двух словах: как правило почтовое антивирусное ПО дотошно сканирует файлы, но не контент HTML-страниц. Если вшить предварительно зашифрованное содержимое файла в страницу, а затем извлечь его с использованием JavaScript, то это может позволить обойти сканирование. Техника совсем не новая, более подробно о ней можно прочитать в этом ресёрче от Positive Technologies.
Настало время отправки писем. Для фишинговой рассылки мы использовали излюбленный инструмент любого пентестера - gophish. Он умеет делать массовые отправления писем через SMTP и IMAP и обладает функциональностью по заданию шаблонов писем и много чего ещё. Для его работы необходимо поднять свой SMTP или IMAP сервер.
Однако, сразу делать рассылку не очень разумная идея, лучше всего сначала отправить письмо на подконтрольную почту и самим увидеть в каком виде оно доходит до адресата. Без предварительного тестирования отправки писем фишинговая кампания может бесславно провалиться, поскольку спам-фильтр может просто не пропустить наши письма или вырезать нужный нам контент. Это и вскрылось в ходе проверки.
К контенту письма добавилась приписка. Это может насторожить получателя. Другое тестовое письмо уже с ссылкой просто не отобразилось в списке полученных и попало в спам. При этом у нас были настроены DMARC, SPF и другие штуки, которые должны были понравиться спам-фильтру.
Можно было долго играться с попытками обойти бдительный спам-фильтр почтового сервера, однако, время уже начинало поджимать. Поэтому было решено пойти на дерзкий шаг - сделать рассылку с подконтрольных почтовых ящиков, которые мы получили в ходе атаки password spraying. После того, как заказчик дал добро на использование захваченных учёток, мы начали думать о реализации.
Как я уже ранее говорил, gophish позволяет использовать почтовые протоколы SMTP и IMAP, но он не имеет встроенной функциональности по отправке писем через Outlook от имени пользователей. Значит, придётся реализовывать самим.
В теории ничего сложного в отправке писем через Outlook посредством кастомного клиента нет. Outlook имеет так называемый Exchange Web Service - веб API на основе SOAP для взаимодействия с сервером. На github можно найти множество реализаций EWS-клиента, что сильно упрощает задачу. Однако, напрямую встраивать такую функциональность в gophish задача, мягко говоря, не очень простая. Для этого нужно было бы серьёзно погрузиться в код очень немаленького проекта с большой историей, что уже является объёмной по времени и затратам сил(во всяком случае для меня) проблемой.
А что если сделать промежуточное приложение, конвертирущее письма отправленные по SMTP в нужный нам формат, и которое отправляет через EWS на целевой сервер? Эта задача уже выглядит как посильная. За основу была взята готовая реализация EWS клиента на Go. Было написано приложение-конвертер, но выяснилось, что исходная версия EWS клиента не умела отправлять письма в HTML-формате, что не позволяло скопировать корпоративную вёрстку письма. После чтения документации по EWS и пары коммитов, EWS-клиент удалось научить нужному формату.
Доработанное приложение-конвертор было развёрнуто и указано вместо SMTP сервера в настройках gophish. Теперь всё работало как надо, и мы были готовы к фишинговой рассылке.
Внутри офисной сети
В назначенный день началась фишинговая атака. Количество адресатов исчислялось тысячами, поэтому неудивительно, что кто-то из них запустил заветную полезную нагрузку на своей рабочей станции. Первая ligolo-сессия открыла нам врата во внутреннюю инфраструктуру и мы принялись искать уязвимости и способы повышения привилегий до доменного администратора. Приятным дополнением была ещё одна сотня полученных учётных записей.
Сначала была собрана информация о домене через джентельменский набор утилит любого пентестера: bloodhound, Certipy, sccmhunter и некоторые другие, которые будут обязательно упомянуты далее. Первичный анализ данных, полученных через вышеупомянутые инструменты, показал, что совсем коротких путей(например, ESC1 или ESC4) для повышения привилегий в домене нет. Сбор и перебор хэшей через атаку Kerberoasting, проверка машинных аккаунтов с пустым паролем или pre2k паролем тоже оказались не очень полезными. К тому же начальное замешательство, вызванное нашей фишинговой кампанией, сошло на нет, а значит, теперь нам больше нельзя было шуметь.
Продолжение истории будет в следующей части. Не переключайтесь!
