ИСТОЧНИК: How I hacked a company
Hello World! Я давно не публиков постов в своем блоге на сайте. С середины 2022 годя я посвящаю своё время и энергию ищучению техники Red Teaming и всё ещё исследую бескрайний океан. Во время моего обучения я практиковался с уязвимыми средами(взламывал HackTheBox и другие подобные). Исходя из всего моего опыта, я бы сказал, что эта область стремительно развивается, с множеством новых векторов атак и способов их устранения на ежедневной основе. Это поле не останавливается, и оно будет развиваться в конкуретном темпе для Red Team и Blue Team.
Приложив максимум усилий, я начал понимать, как работают корпоративные сети и как настраивается их типичная архитектура. Недавно я впервые принял участие в команде красных. Заказчиком этого мероприятия была крупня финтех-компания с обширной сетью. Подход к взаимодействию заключается в выполнении симуляции противника с предполагаемым сценарием нарушения. В этом блоге описывается исключительно методология взаимодействия, которой придерживаюсь я сам, она может изменяться в зависимости от точки зрения других участников Red Team.
Компания-цель имела множество доменов в интернете, на которых размещались различные приложения для своих сотрудников и клиентов. Любая информация на веб-сайте важна для красной команды. Пентест веб-приложений играет большую роль при выполнении задания. Собрав информацию через общедоступный интернет, мы узнали о различных других доменах, используемых компанией. Некоторые важные тактики перечисления, которые необходимо выполнить перед непосредственныем исследованием внутренней сети пердприятия, залючаются в слейдующем:
- Перечисление поддоменов
- GitHub Dorking
- Shodan Dorking
- Google Dorking
- Пентест внешнего приложения
- Знакомство с архитектурой предприятия
Мы можем перебрать различные приложения(как внешние, так и внутренние), используемые предприятием, выполнив маштабное перечисление поддоменов. Масштаб целевой области просто расширяется случайным образом в зависимости от организации при выполнении перечисления поддоменов.
Для перечесления поддоменов я лично использую subfinder, который интегрирован со многими ключами API. Всегда полезно исследовать и проверять поддомены, независимо от того, доступны они из общедоступного интернета или нет. httpx делает всю работу за меня.
Здесь я нашел много поддоменов, названных для внутренних веб-приложений, которые недоступны из общедоступного интернета. Но большинство из них доступны. Итак пришло время протестировать эти приложения.
Это была утомительная работа по тестированию приложений, большинство из них были статичными для целей бизнес-маркетинга. Чем динамичнее функция, тем интереснее она становится для нас. Наша команда обнаружила множество уязвимостей веб-приложений в обширной целевой области. Лично я люблю тестировать SQLi, XML External Entity и Open Redirection для заданий красной команды.
Что ж, есть довольно веская причина искать эти ошибки, потому что SQL-инъекция и XML External Entity - это атаки на основе инъекций, которые помогают злоумышленнику извлекать конфиденциальную информацию из бэкэнда/сервера который исеть доступ к данным в реальном времени, и ими пользуется предприятие прямо сейчас. Это может быть дополнительно использовано для бокового перемещения в последующей фазе. И в современном мире информационной безопасности откртое перенаправление может расматриваться как обычная ошибка, где охотники за ошибками и платформы нормализовали её. Но красные команды знают этому цену, потому что его можно использовать, чтобы выманить жертву с предприятия. Жертвы легко ведутся на эту иллюзию, потому что перенаправление на наш вредоносный URL происходит с их корпоративного доменного имени. В основном нетехнические сотрудники поддаются этому приёму. В дикой природе существует множество известных уязвимостей, но это мои любимые, на которые стоит обратить внимание, и которые можно легко использовать для дальнейшего взаимодействия.
При поиске веб-уязвимостей, члены нашей команды обнаружили множество SQL-инъекций из целевой области. Я начал агрегировать домены и вручную начал фаззиг, чтобы определить, какую базу данных использовал этот сервер.
Когда дело доходит до SQL-инъекций, я всегда использую для справки шпаргалку - `https://portswigger.net/web-security/sql-injection/cheat-sheet`
Во время пентестирования этих сайтов я обнаружил одну общую черту, которая была присуща всем им. Некоторые конкретные группы сайтов использовали один и тот же технологический стек для сових веб-приложений. Они использовали .NET для внешнего интерфейса, сервер IIS для хостинга и MSSQL для внутреннего интерфейса.
Помимо этого, они использовали приложения Wordpress и приложения с PHP + MySQL, которые ведут себя аналогично Wordpress, но это не Wordpress.
Я использовал sqlmap для дампа всей базы данных MySQL, а на других сайтах(включая MSSQL, где у них была общая база данных, синхронизированная со многими веб-приложениями) был Blind SQLi, который требовал больше времени для брутфорса и дампа. Когда я увидел имена баз данных и таблиц - это дало мне хорошее представление об их внутренних доменах и внтренних веб-приложениях.
Дамп базы данных был золотой жилой, потому что в ней храниловсь много идентификаторов электронной почты и их паролей(сохранённых в виде обычного текста, что является плохой практикой).
Помимо пентеста веб-приложений, я получил так много открытых внутренних доменов с их IP-адресами благодаря их SSL-сертификату , который был получен при помощи Shodan Dorking. Shodan так же подсказалд RDP-порт 3389 в их компанию.
И последнее, но не менее важное - я получил пару учётных данных при помощи GiHub Dorking, где их внутренние разработчики написали несолько сценариев для тестирования некоторых функций API и оставили их, не удалив их из своего git commit. Я также получил кучу внутренних индентификаторов электронной почты для их предприятия.
После использования некоторых команд grep и автоматизации bash я записал эти учётные данные из дампа SQL и всё данные которые я получил при помощи дорок в один файл, теперь в этом файле было 340 учётных данных. Это огромная цифра, и это показывает, что предприятие не соблюдает строгие требования бозопасности и меры по их смягчению. Так, что же дальше?
Прежде чем начать использовать эти учётные данные, я просто хотел попробовать изучить другие поддомены в поисках других возможностей. На этом этапе я наткнулся на сервер MS Exchange их домена. Их страница входа в OWA Portal(Outlook Web App Portal) была там, и, увидев её, я был очень заинтригован. Поскольку я читал сообщения многих исследований безопасности, на которых я подписан в Twitter, я знаю, что на этом сервере можно использовать эксплоит под названием ProxyShell. Есть хорошая статья Orange Tsai об этой уязвимости - `https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html`. Я сразу запустил приложение OWA с помощью Burpsuite и нашёв версию сервера Exchange в заголовке ответа. Я запустил общедоступные эксплоиты для этой версии, в частности этот(`https://github.com/horizon3ai/proxyshell`), один из моих друзей, который воспроизвёл этот эксплоит, помог мне со своим взглядом на его атаку. Несмотря на то, что это дало мне оболочку, я не смог успешно выполнить команды. Я знал, что что-то не так, и начал воспроизводить эксплоит вручную, использую Burp и мои собственные скрипты на Python. Из это я понял, что индентификаторы электронной почты на сервере Exchange были для меня кроличьей норой. Полное доменное имя и идентификаторы электронной почты были специально размещены внутри сервера, чтобы заманить игрока Red Team(я впервые столкнулся с тактикой Blue Team). Я потратил почти 4 дня на то, чтобы проверить этот эксплоит в одиночку и наконец вера была заслужена.
Я поднимаюсь после неудачной попытки срубить низко висящий фрукт. Я начал изучать другие поддомены. Некоторые сайты перенаправили меня на страницу входа в SSO(система единого входа).
Выполнив запрос по приведённой выше ссылке, я подтвердил, что домены работают как фелеративный сервис для AD. Это означает, что они подключены к Microsoft Cloud(O365).
Теперь пришло время использовать учётные данные, которые я подготовил ранее. Я начал распылять эти учётные данные с помощью O365 Sprayer по целевому домену. Только одна из этих учётных данных работала. Это был поворотный момент для всего взаимодействия красной команды. Пароль, используемый для для действительных учётных данных, представляет собой простую комбинацию, используемую доменом.
Пришло время, для того чтобы нахмуриться. Используя эти учётные данные, я вошёл в систему как пользователь в их домене с помощью модуля Azure AD PowerShell. Чтобы подключиться к облаку Azure, нам нужен идентификатор клиента домена.
Запрашивая приведённо выше ссылку, мы получаем в ответ идентификатор арендатора целевого домена. Используя этот идентификатор клиента для подключения к Azure AD.
После подключения к Azure AD в нашем PowerShell перечисление становится намного проще с помощью модуля Azure AD PS. Перечисление пользователей, групп и устройств Azure AD с помощью `Get-AzureADUser -All $true` ,`Get-AzureADGroup -All $true`, `Get-AzureADDevice -All $true` и многих других. Get-AzureADDomain, мы можем проверить тип аутентификации для подключенных к нему доменов.
Теперь я могу легко получить все идентификаторы электронной почты, используемые в домене, от перечисленных пользователей. Я подумал о проведении атаки с использованием паролей с подстановкой домена, учитывая политику блокировки учётной записи и период её восстановления. После выполнения распыления паролей почти 60 учётных записей были скомпрометированы из-за их слабых, предсказуемых паролей.
Используя эти учётные данные, я вошёл в компьютер с учётной записью AD user privilege по умолчанию. Машина работала в ограниченном режиме с несколькими ошибками(не с самым высоким рейтингом) и продуктами AV для новичка редтимера, кем являюсь я. Я начал перечислять процессы и обнаружул, что в машине запущены слейдующие продукты. Когда я попытался посмотреть некоторые оскорбительные сценарии PowerSHell в браузере, он пометил их как вредоносные сайты. Я понял свою ситуацию в тот момент, когда понял, что собираюсь наступть на мину.
Я знал, что если я сброшу какой-нибудь исполняемы файл на диск, он отметит меня. И настройка тоже сценария EDR на моём локальном компьютере и компиляция этих двоичных файлов займёт много времени, что дл яменя является кошмаром. Так что память PowerShell - единственная надежда для меня. Когда я начинаю сценарии загрузки, извлечение через PowerShell, используя скрипты с GitHub, он помечает этот файл. Но если я закодирую его в Base64 и загружу в память PowerShell, он не будет помечен.
Вот и все, необходимые скрипты были загружены в память PowerShell без перехвата (удивительно для меня
). Я попытался повысить локальные привилегии, но, к моему ужасу, повышать было нечего.
Запустил Sharp Hound и перенес полученные данные на мой локальный компьютер для просмотра в BloodHound. После загрузки полученных данных (для тысяч рекламных объектов потребовалось больше времени) я начал внимательно просматривать и анализировать их. Всегда ищите исходящие списки управления доступом, потому что они являются скрытой связью между двумя объектами AD. Некоторые из скомпрометированных пользователей имели PS-сессию на некоторых машинах. Я использовал их учетные записи для получения сеанса PS и начал перечислять привилегии.
Удивительно, но некоторые пользователи имели полные привилегии на своих соответствующих компьютерах. Я воспользовался этой привилегией, чтобы сбросить LSASS.exe с procdump.exe . Это скрытый способ сбросить LSASS.exe , так как procdump.exe это двоичный файл, подписанный Microsoft, и он не помечается AV/EDRs.
После перемещения этого файла .dmp на мой локальный компьютер я запустил Mimikatz для анализа файла дампа и получил хэш NTLM для пользователя, который является членом привилегированной группы. У меня нет прав локального администратора на моей контролируемой машине. В результате я должен выполнить только “Передать хэш” через PS-сессию.Мой коллега помог мне с написанием необнаруживаемой обратной оболочки в Go. Мы скопировали этот двоичный файл на удаленный компьютер с PS-сессией и попробовали PTH с помощью Invoke-Mimikatz запустить обратную оболочку с PowerCat. Очевидно, что он запустился, и мы получили привилегированные права пользователя группы, но мы остановились из-за проблемы. Мы находились внутри брандмауэра, поэтому не смогли напрямую запросить DC для дальнейшего перемещения. Бедняжка я, не знал, что у меня есть обычный текстовый пароль для того же пользователя в дампе. Видя, как я был в восторге после попытки обратной оболочки PTH.
Кроме того, у пользователя, к которому я получил свой первоначальный доступ, я смог изменить пароль учетной записи с правами ACL. Я смог просмотреть пароль LAPS через AllExtendedRights на компьютере после использования учетной записи с измененным паролем. К сожалению, работа с этой машиной была пустой тратой времени.
BloodHound показал, что у скомпрометированного пользователя из дампа LSASS был сеанс на компьютере, где у одного из администраторов домена также был сеанс. Используя этот простой текстовый пароль, я сделал боковое движение с владением и сбросил LSASS с procdump.exe снова. На этот раз я получил обычный текстовый пароль для администратора домена. Войдя в DC, я сбросил файл NTDS.dit и кусты реестра.
Вот и все, финальная схватка. Я добавил свои необходимые учетные записи для сохранения и сбросил все хэши с целевого предприятия с помощью secretsdump.
Из дампа я получил 43856 хэшей учетных записей пользователей и 48587 хэшей учетных записей компьютеров от предприятия. В ходе этих встреч я также узнал от своего коллеги несколько приемов перечисления EDR и обхода. Это было мое первое участие в red team, и для меня это было довольно круто. Потому что в течение этих многих дней я пытался действовать в намеренно уязвимой среде, но в этом задании у меня была возможность имитировать наступательную угрозу, вторгающуюся в компанию, которая была совершенно новой для меня. Для моих будущих заданий я планирую написать свои собственные наработки на C # и Go, чтобы избежать обнаружения и узнать больше о внутренних компонентах Windows для обхода EDR и разработки эксплойтов. Я благодарен тем, кто помогал мне во время моих трудностей и помогал мне подняться на одну ступень выше в моем обучении. Я хотел бы закончить этот пост в блоге, сказав, что 2022 год был для меня великим годом с точки зрения достижений и самоудовлетворения. И для тех, кто читает этот пост: никогда не прекращайте исследовать.
Hello World! Я давно не публиков постов в своем блоге на сайте. С середины 2022 годя я посвящаю своё время и энергию ищучению техники Red Teaming и всё ещё исследую бескрайний океан. Во время моего обучения я практиковался с уязвимыми средами(взламывал HackTheBox и другие подобные). Исходя из всего моего опыта, я бы сказал, что эта область стремительно развивается, с множеством новых векторов атак и способов их устранения на ежедневной основе. Это поле не останавливается, и оно будет развиваться в конкуретном темпе для Red Team и Blue Team.
Приложив максимум усилий, я начал понимать, как работают корпоративные сети и как настраивается их типичная архитектура. Недавно я впервые принял участие в команде красных. Заказчиком этого мероприятия была крупня финтех-компания с обширной сетью. Подход к взаимодействию заключается в выполнении симуляции противника с предполагаемым сценарием нарушения. В этом блоге описывается исключительно методология взаимодействия, которой придерживаюсь я сам, она может изменяться в зависимости от точки зрения других участников Red Team.
Компания-цель имела множество доменов в интернете, на которых размещались различные приложения для своих сотрудников и клиентов. Любая информация на веб-сайте важна для красной команды. Пентест веб-приложений играет большую роль при выполнении задания. Собрав информацию через общедоступный интернет, мы узнали о различных других доменах, используемых компанией. Некоторые важные тактики перечисления, которые необходимо выполнить перед непосредственныем исследованием внутренней сети пердприятия, залючаются в слейдующем:
- Перечисление поддоменов
- GitHub Dorking
- Shodan Dorking
- Google Dorking
- Пентест внешнего приложения
- Знакомство с архитектурой предприятия
Мы можем перебрать различные приложения(как внешние, так и внутренние), используемые предприятием, выполнив маштабное перечисление поддоменов. Масштаб целевой области просто расширяется случайным образом в зависимости от организации при выполнении перечисления поддоменов.
Код:
cat targetDomains.txt | while read -r domain; do
( echo $domain | subfinder -silent >>subdomains.txt );
doneДля перечесления поддоменов я лично использую subfinder, который интегрирован со многими ключами API. Всегда полезно исследовать и проверять поддомены, независимо от того, доступны они из общедоступного интернета или нет. httpx делает всю работу за меня.
cat subdomains.txt | httpx -silent -scЗдесь я нашел много поддоменов, названных для внутренних веб-приложений, которые недоступны из общедоступного интернета. Но большинство из них доступны. Итак пришло время протестировать эти приложения.
Это была утомительная работа по тестированию приложений, большинство из них были статичными для целей бизнес-маркетинга. Чем динамичнее функция, тем интереснее она становится для нас. Наша команда обнаружила множество уязвимостей веб-приложений в обширной целевой области. Лично я люблю тестировать SQLi, XML External Entity и Open Redirection для заданий красной команды.
Что ж, есть довольно веская причина искать эти ошибки, потому что SQL-инъекция и XML External Entity - это атаки на основе инъекций, которые помогают злоумышленнику извлекать конфиденциальную информацию из бэкэнда/сервера который исеть доступ к данным в реальном времени, и ими пользуется предприятие прямо сейчас. Это может быть дополнительно использовано для бокового перемещения в последующей фазе. И в современном мире информационной безопасности откртое перенаправление может расматриваться как обычная ошибка, где охотники за ошибками и платформы нормализовали её. Но красные команды знают этому цену, потому что его можно использовать, чтобы выманить жертву с предприятия. Жертвы легко ведутся на эту иллюзию, потому что перенаправление на наш вредоносный URL происходит с их корпоративного доменного имени. В основном нетехнические сотрудники поддаются этому приёму. В дикой природе существует множество известных уязвимостей, но это мои любимые, на которые стоит обратить внимание, и которые можно легко использовать для дальнейшего взаимодействия.
При поиске веб-уязвимостей, члены нашей команды обнаружили множество SQL-инъекций из целевой области. Я начал агрегировать домены и вручную начал фаззиг, чтобы определить, какую базу данных использовал этот сервер.
Когда дело доходит до SQL-инъекций, я всегда использую для справки шпаргалку - `https://portswigger.net/web-security/sql-injection/cheat-sheet`
Во время пентестирования этих сайтов я обнаружил одну общую черту, которая была присуща всем им. Некоторые конкретные группы сайтов использовали один и тот же технологический стек для сових веб-приложений. Они использовали .NET для внешнего интерфейса, сервер IIS для хостинга и MSSQL для внутреннего интерфейса.
Код:
# Typical Enterprise Web Application Stack
Front End (.NET) <---> Server (IIS) <---> Back End (MSSQL)Помимо этого, они использовали приложения Wordpress и приложения с PHP + MySQL, которые ведут себя аналогично Wordpress, но это не Wordpress.
Я использовал sqlmap для дампа всей базы данных MySQL, а на других сайтах(включая MSSQL, где у них была общая база данных, синхронизированная со многими веб-приложениями) был Blind SQLi, который требовал больше времени для брутфорса и дампа. Когда я увидел имена баз данных и таблиц - это дало мне хорошее представление об их внутренних доменах и внтренних веб-приложениях.
Код:
#Fuzz for SQL Injection
sqlmap -r request.txt
#Specifying Database
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3
#Fuzzing Vulnerable Param
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 -p <PARAM_NAME_VULNERABLE_TO_SQLi>
#Dump database names
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 --dbs
#Dump table names
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 --tables
#Dump all data from the given database & table
sqlmap -r request.txt --dbms MySQL --level 3 --risk 3 -D <DB_NAME> -T <TABLE_NAME> --dumpДамп базы данных был золотой жилой, потому что в ней храниловсь много идентификаторов электронной почты и их паролей(сохранённых в виде обычного текста, что является плохой практикой).
Помимо пентеста веб-приложений, я получил так много открытых внутренних доменов с их IP-адресами благодаря их SSL-сертификату , который был получен при помощи Shodan Dorking. Shodan так же подсказалд RDP-порт 3389 в их компанию.
И последнее, но не менее важное - я получил пару учётных данных при помощи GiHub Dorking, где их внутренние разработчики написали несолько сценариев для тестирования некоторых функций API и оставили их, не удалив их из своего git commit. Я также получил кучу внутренних индентификаторов электронной почты для их предприятия.
После использования некоторых команд grep и автоматизации bash я записал эти учётные данные из дампа SQL и всё данные которые я получил при помощи дорок в один файл, теперь в этом файле было 340 учётных данных. Это огромная цифра, и это показывает, что предприятие не соблюдает строгие требования бозопасности и меры по их смягчению. Так, что же дальше?
Прежде чем начать использовать эти учётные данные, я просто хотел попробовать изучить другие поддомены в поисках других возможностей. На этом этапе я наткнулся на сервер MS Exchange их домена. Их страница входа в OWA Portal(Outlook Web App Portal) была там, и, увидев её, я был очень заинтригован. Поскольку я читал сообщения многих исследований безопасности, на которых я подписан в Twitter, я знаю, что на этом сервере можно использовать эксплоит под названием ProxyShell. Есть хорошая статья Orange Tsai об этой уязвимости - `https://blog.orange.tw/2021/08/proxylogon-a-new-attack-surface-on-ms-exchange-part-1.html`. Я сразу запустил приложение OWA с помощью Burpsuite и нашёв версию сервера Exchange в заголовке ответа. Я запустил общедоступные эксплоиты для этой версии, в частности этот(`https://github.com/horizon3ai/proxyshell`), один из моих друзей, который воспроизвёл этот эксплоит, помог мне со своим взглядом на его атаку. Несмотря на то, что это дало мне оболочку, я не смог успешно выполнить команды. Я знал, что что-то не так, и начал воспроизводить эксплоит вручную, использую Burp и мои собственные скрипты на Python. Из это я понял, что индентификаторы электронной почты на сервере Exchange были для меня кроличьей норой. Полное доменное имя и идентификаторы электронной почты были специально размещены внутри сервера, чтобы заманить игрока Red Team(я впервые столкнулся с тактикой Blue Team). Я потратил почти 4 дня на то, чтобы проверить этот эксплоит в одиночку и наконец вера была заслужена.
Я поднимаюсь после неудачной попытки срубить низко висящий фрукт. Я начал изучать другие поддомены. Некоторые сайты перенаправили меня на страницу входа в SSO(система единого входа).
https://login.microsoftonline.com/getuserrealm.srf?json=1&login=fakeID@domain.comВыполнив запрос по приведённой выше ссылке, я подтвердил, что домены работают как фелеративный сервис для AD. Это означает, что они подключены к Microsoft Cloud(O365).
Теперь пришло время использовать учётные данные, которые я подготовил ранее. Я начал распылять эти учётные данные с помощью O365 Sprayer по целевому домену. Только одна из этих учётных данных работала. Это был поворотный момент для всего взаимодействия красной команды. Пароль, используемый для для действительных учётных данных, представляет собой простую комбинацию, используемую доменом.
Пришло время, для того чтобы нахмуриться. Используя эти учётные данные, я вошёл в систему как пользователь в их домене с помощью модуля Azure AD PowerShell. Чтобы подключиться к облаку Azure, нам нужен идентификатор клиента домена.
https://login.microsoftonline.com/<TARGET_DOMAIN>/v2.0/.well-known/openid-configurationЗапрашивая приведённо выше ссылку, мы получаем в ответ идентификатор арендатора целевого домена. Используя этот идентификатор клиента для подключения к Azure AD.
Connect-AzureAD -TenantId <TENANT_ID>После подключения к Azure AD в нашем PowerShell перечисление становится намного проще с помощью модуля Azure AD PS. Перечисление пользователей, групп и устройств Azure AD с помощью `Get-AzureADUser -All $true` ,`Get-AzureADGroup -All $true`, `Get-AzureADDevice -All $true` и многих других. Get-AzureADDomain, мы можем проверить тип аутентификации для подключенных к нему доменов.
Теперь я могу легко получить все идентификаторы электронной почты, используемые в домене, от перечисленных пользователей. Я подумал о проведении атаки с использованием паролей с подстановкой домена, учитывая политику блокировки учётной записи и период её восстановления. После выполнения распыления паролей почти 60 учётных записей были скомпрометированы из-за их слабых, предсказуемых паролей.
Используя эти учётные данные, я вошёл в компьютер с учётной записью AD user privilege по умолчанию. Машина работала в ограниченном режиме с несколькими ошибками(не с самым высоким рейтингом) и продуктами AV для новичка редтимера, кем являюсь я. Я начал перечислять процессы и обнаружул, что в машине запущены слейдующие продукты. Когда я попытался посмотреть некоторые оскорбительные сценарии PowerSHell в браузере, он пометил их как вредоносные сайты. Я понял свою ситуацию в тот момент, когда понял, что собираюсь наступть на мину.
Я знал, что если я сброшу какой-нибудь исполняемы файл на диск, он отметит меня. И настройка тоже сценария EDR на моём локальном компьютере и компиляция этих двоичных файлов займёт много времени, что дл яменя является кошмаром. Так что память PowerShell - единственная надежда для меня. Когда я начинаю сценарии загрузки, извлечение через PowerShell, используя скрипты с GitHub, он помечает этот файл. Но если я закодирую его в Base64 и загружу в память PowerShell, он не будет помечен.
Код:
# Store the Base64 encoded file
$file = <BASE64_ENCODED_CONTENT_FILE>
$data = Get-Content $file
[System.Text.Encoding]::ASCII.GetString([System.Convert]::FromBase64String($data)) | IEX
# Delete the Base64 encoded fileВот и все, необходимые скрипты были загружены в память PowerShell без перехвата (удивительно для меня
). Я попытался повысить локальные привилегии, но, к моему ужасу, повышать было нечего.Запустил Sharp Hound и перенес полученные данные на мой локальный компьютер для просмотра в BloodHound. После загрузки полученных данных (для тысяч рекламных объектов потребовалось больше времени) я начал внимательно просматривать и анализировать их. Всегда ищите исходящие списки управления доступом, потому что они являются скрытой связью между двумя объектами AD. Некоторые из скомпрометированных пользователей имели PS-сессию на некоторых машинах. Я использовал их учетные записи для получения сеанса PS и начал перечислять привилегии.
Удивительно, но некоторые пользователи имели полные привилегии на своих соответствующих компьютерах. Я воспользовался этой привилегией, чтобы сбросить LSASS.exe с procdump.exe . Это скрытый способ сбросить LSASS.exe , так как procdump.exe это двоичный файл, подписанный Microsoft, и он не помечается AV/EDRs.
После перемещения этого файла .dmp на мой локальный компьютер я запустил Mimikatz для анализа файла дампа и получил хэш NTLM для пользователя, который является членом привилегированной группы. У меня нет прав локального администратора на моей контролируемой машине. В результате я должен выполнить только “Передать хэш” через PS-сессию.Мой коллега помог мне с написанием необнаруживаемой обратной оболочки в Go. Мы скопировали этот двоичный файл на удаленный компьютер с PS-сессией и попробовали PTH с помощью Invoke-Mimikatz запустить обратную оболочку с PowerCat. Очевидно, что он запустился, и мы получили привилегированные права пользователя группы, но мы остановились из-за проблемы. Мы находились внутри брандмауэра, поэтому не смогли напрямую запросить DC для дальнейшего перемещения. Бедняжка я, не знал, что у меня есть обычный текстовый пароль для того же пользователя в дампе. Видя, как я был в восторге после попытки обратной оболочки PTH.
Кроме того, у пользователя, к которому я получил свой первоначальный доступ, я смог изменить пароль учетной записи с правами ACL. Я смог просмотреть пароль LAPS через AllExtendedRights на компьютере после использования учетной записи с измененным паролем. К сожалению, работа с этой машиной была пустой тратой времени.
BloodHound показал, что у скомпрометированного пользователя из дампа LSASS был сеанс на компьютере, где у одного из администраторов домена также был сеанс. Используя этот простой текстовый пароль, я сделал боковое движение с владением и сбросил LSASS с procdump.exe снова. На этот раз я получил обычный текстовый пароль для администратора домена. Войдя в DC, я сбросил файл NTDS.dit и кусты реестра.
Вот и все, финальная схватка. Я добавил свои необходимые учетные записи для сохранения и сбросил все хэши с целевого предприятия с помощью secretsdump.
Код:
aidenpearce369@jackdaw:~/DC5-LSASSDump$ ls
RegHive allHashes.txt log.dmp ntds.dit
aidenpearce369@jackdaw:~/DC5-LSASSDump$ cat allHashes.txt | grep ':::' | grep -v "$:" | wc -l
43856
aidenpearce369@jackdaw:~/DC5-LSASSDump$ cat allHashes.txt | grep ':::' | grep "$:" | wc -l
48587
aidenpearce369@jackdaw:~/DC5-LSASSDump$Из дампа я получил 43856 хэшей учетных записей пользователей и 48587 хэшей учетных записей компьютеров от предприятия. В ходе этих встреч я также узнал от своего коллеги несколько приемов перечисления EDR и обхода. Это было мое первое участие в red team, и для меня это было довольно круто. Потому что в течение этих многих дней я пытался действовать в намеренно уязвимой среде, но в этом задании у меня была возможность имитировать наступательную угрозу, вторгающуюся в компанию, которая была совершенно новой для меня. Для моих будущих заданий я планирую написать свои собственные наработки на C # и Go, чтобы избежать обнаружения и узнать больше о внутренних компонентах Windows для обхода EDR и разработки эксплойтов. Я благодарен тем, кто помогал мне во время моих трудностей и помогал мне подняться на одну ступень выше в моем обучении. Я хотел бы закончить этот пост в блоге, сказав, что 2022 год был для меня великим годом с точки зрения достижений и самоудовлетворения. И для тех, кто читает этот пост: никогда не прекращайте исследовать.