Заметки на полях: AD для тестирования

При RedTeam нужна определенная среда для тестирования различных тулз на разных операционных системах. Да и вообще иметь собственную AD для разработки новых методик - это всегда круто. Есть несколько вариантов:

1. развернуть на своих мощностях

2. прикупить железку в дата центре (как пример Hetzner)

3. развернуть на облачных платформах

Выбор одного из вариантов зависит только от ваших потребностей, приципов и бюджета.

Сегодня поделимся с вами опытом по разворачиванию AD в Azure.

Хороший и очень подробный гайд можно найти тут: https://medium.com/@kamran.bilgrami/ethical-hacking-lessons-building-free-active-directory-lab-in-azure-6c67a7eddd7f

Однако, есть пара моментов, о которых нужно знать:

1. Microsoft поддерживает санкции и завести Azure из России не получится. Нужно использовать VPN, при указании страны не выбирать Россию и номер телефона тоже желательно иностранный (хотя раз через раз, иногда смски приходят и на российский номер, закономерность не выявлена). Потом заходить под созданным аккаунтом  можно и из России.

2. Номер телефона должен принимать смски или звонки - код обязательно надо получить

3. Привязать карту банковскую тоже необходимо - с вас снимут 1 доллар для подтверждения работоспособности карты (виртуальные карты точно подходят, а вот про "мир" не уверены, опыты не проводили)

4. Почему-то не всегда дается бесплатный год пользования сервисом. Но бесплатные 30 дней есть и счет выставляется по итогу использования. В случае не оплаты и большого долга - аккаунт будет заблокирован

5. Даже за приостановленные виртуалки берут деньги

6. Azure разворачивает все очень быстро, поэтому основная рекомендация - развернуть контроллер домена и пару машин с разными версиями ОС в домене (мощности таких машин можно выбрать минимальные). Остальное наполнение зависит уже от вашего бюджета и нужные машины можно будет развернуть достаточно оперативно.

Процесс наполнения AD различными пользователями и OUшками можно автоматизировать с помощью тулзы: https://stealingthe.network/rapidly-creating-fake-users-in-your-lab-ad-using-youzer/

Заметки на полях: групповые политики сайтов в AD

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

Однако, в данном случае есть один момент, который не учитывается - многие сайты содержат контроллеры домена. При неправильном делегировании ссылки на объект групповой политики можно придумать различные виды атак на AD. От вредительства (связывания произвольных объектов с сайтом, содержащим контроллер домена) до дальнейшего развития атаки в AD и повышения привилегий.

GPMC (group policy management console) не показывает политики, связанные с сайтами.
Получить их можно, выполнив команду с помощью powershell.

Get-ADObject -Filter * -SearchBase "CN=Sites,CN=Configuration,DC=domain,DC=com" -SearchScope OneLevel | % { "Site Name: $($.Name)",((Get-Acl "AD:\$").Access | select IdentityReference,ActiveDirectoryRights | fl) }

Если в вашем или исследуемом домене найдены такие сайты - повод посмотреть групповые политики внимательно

Заметки на полях: Honeypots в Active Directory - насколько необходимо?

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

Откровенно говоря, коммерческие компании используют ханипоты даже на внешнем периметре очень редко. Потому что это определенные риски в связи с меньшей защищённостью ресурса, ещё одна точка, которую нужно постоянно мониторить. Чаще всего ханипоты разворачивают компании-разработчики СЗИ для обнаружения новых атак.

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

Современные СЗИ умеют работать с AD - детектировать логины привилегированных пользователей и использование таких инструментов, как BloodHound, мониторить контроллер домена и т.д.

Таким образом использование ханипотов не является целесообразным. Однако, не все СЗИ детектируют всё, что хочется и, иногда, это стоит очень дорого.

Часто использование BloodHound (для поиска кратчайшего пути до сессии доменного администратора) никак не детектируется, поэтому стали придумывать различные способы, которые не дадут злоумышленнику развиться дальше, но будут служить сигналом для BlueTeam о том, что в сети кто-то есть. Оптимальный вариант, который используют - детектирование по событиям. Однако не все его используют в силу ряда причин. Поэтому пытаются использовать ханипоты.

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

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

https://www.labofapenetrationtester.com/2018/10/deploy-deception.html?m=1

https://apt29a.blogspot.com/2019/11/deploying-honeytokens-in-active.html?m=1

​​Cheet Sheet: Metasploit

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

Заметки на полях: получение списка существующих пользователей

Одна из главных задач на первом этапе RedTeam - определение сотрудников Заказчика для составления списка пользователей для дальнейших манипуляций с ними.

Для перебора существующих имен пользователей можно использовать сервисы Office365 и AzureAD.

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

Ну и, конечно, у вас должно быть понимание как формируется username и почтовый ящик пользователя в компании Заказчика.

o365creeper - https://github.com/LMGsec/o365creeper -  инструмент, который проверяет на валидность почтовые ящики из предварительно составленного вами списка

msmailprobe - https://github.com/busterb/msmailprobe - можно использовать, если на стороне заказчика есть OWA

Office 365 User Enum - https://bitbucket.org/grimhacker/office365userenum/src/master/ - была отличная тулза, которая использовала ответы от ActiveSync для перебора пользователей. Однако, после обновлений от Microsoft - перестала работать. Но нашлись другие недостатки в ActiveSync, которые также по ответам могут помочь определить валидность пользователя - это новая тулза - https://github.com/gremwell/o365enum, которая на данный момент работает

o365recon - https://github.com/nyxgeek/o365recon - помогает получить список пользователей и групп из AzureAD, если вы смогли залогиниться под каким-либо пользователем компании Заказчика

​​Заметки на полях: условный доступ

Иногда получается подобрать имя пользователя и пароль к учетной записи Microsoft, увидеть, что не запросил второй фактор и обрадоваться..., но почему-то доступа нет. Почему такое происходит? Все дело в одной из фишек от microsoft для приложений Offcice365 и AzureAD - так называемом условном доступе.

Что это такое? Политики условного доступа в своей простейшей форме — это операторы если-то; если пользователь хочет получить доступ к ресурсу, то он должен выполнить действие или соответствовать каким-то условиям.

Зачем он нужен? Не у всех компаний есть возможность добавлять второй фактор для всех пользователей (не для всех это целесообразно). Поэтому MFA включается только для привилегированных пользователей, а остальные ограничиваются условным доступом - дополнительными ограничениями на местоположение, платформу устройства и клиентское приложение. Плюс это дополнительный фактор для защиты пользователей с MFA. Причем вариантов действия всего 3 - разрешить доступ, запретить доступ и запросить дополнительную проверку с помощью MFA.

Что используется в качестве дополнительной проверки? Очень часто в качестве дополнительной проверки пользователя используются:

- платформы, с которых пользователь пытается получить доступ. На данный момент разрешенные в AzureAD - Android, iOS, Windows Phone, Windows, macOS - обратите внимание, что Linux логично отсутствует

- местоположение (IP-адрес откуда пользователь пытается получить доступ). Местоположение может быть по-разному ограничено администратором AD - как белым, так и черным списком. Например, если пользователь подключается из местоположения, отмеченного как надежное (например, офис компании) - у него не будет запрашиваться дополнительная проверка.

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

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

Зачем мы это написали? Чтобы предупредить о том, что существует возможность дополнительных проверок (по сути это известный факт). И эти проверки уже не просто возможность, а активно используются компаниями. Для RedTeam это отличная почва для экспериментов, для BlueTeam - отличная возможность закрутить гайки и обезопасить пользователей.

​​​​Забираем ажурный токен доступа

Рассмотрим пример, когда мы получили доступ к рабочей станции пользователя, который является администратором Azure. Для более быстрой и комфортной работы администраторы используют Powershell Az для администрирования Azure  со своей рабочей станции.

Особенность использования командлетов PowerShell Az состоит в том, что они сохраняют токены доступа в папке .Azure в профиле пользователя. Это не секрет. И ходят слухи, что таких токенов недостаточно - можно использовать только файл со специально сохраненными пользователем токенами доступа. Наши эксперименты показали, что достаточно использовать только файлы из указанной выше папки для получения доступа к аккаунту

Итак, для того, чтобы забрать у пользователя токен доступа нужно сделать следующее:

1. Найти папку Azure в профиле пользователя (обычно путь следующий: C:\Users\user\.Azure\)

2. Скопировать на свой компьютер в такую же папку в профиле своего пользователя (для этого у вас должен быть установлен командлет Powershell AZ (Install-Module Az -AllowClobber))

3. В файле AzureRmContextSettings.json меняем путь на своего пользователя

4. Токен доступа хранится в файле TokenCache.dat (вы должны увидеть значения в base64), а остальная информация по доступу в AzureRmContext.json

5. Теперь нам необходимо все сохраненное в файлах как-то использовать. Командой Get-AzContext -ListAvailable проверяем, что у нас нет никакого доступа

6. командой Import-AzContext -Path C:\Users\user\.Azure\AzureRmContext.json импортируем содержимое файла

7. После импорта видим, что появляется доступ к AzureCloud

8. Для проверки доступа выполняем команду Get-AzVM -Status для получения информации о виртуальных машинах в Azure

9.Для проверки можем выполнить команду Disconnect-AzAccount и выполнить команду Get-AzVM -Status - результат должен быть отрицательным

Заметки на полях: LAPS

Что такое LAPS? LAPS (Local administrator password solution) - официальная утилита от Microsoft, которая позволяет управлять паролями локальных администраторов на компьютерах домена.

Зачем это нужно? Проблема многих компаний - одинаковые пароли локального администратора на всех (либо части) доменных машинах (серверах и компьютерах). LAPS позволяет решить этот вопрос и установить на каждую машину уникальные случайно сгенерированный пароль локального администратора, который автоматически меняется раз в определенное время. Это позволяет усложнить горизонтальное перемещение злоумышленника по машинам домена.

Есть ли какие-то особенности в настройке? Конечно есть. Любые утилиты надо применять с умом, иначе вы своими руками создадите ещё одно уязвимое место, которым злоумышленник с радостью воспользуется.
Очень часто встречается проблема с неправильным делегированием, которая позволяет злоумышленнику получить доступ ко всем паролям LAPS.

Рекомендации

1. При развертывании LAPS необходимо убедиться, что все доменные машины добавлены в LAPS.

2. Необходимо постоянно мониторить группы AD, которые имеют доступ к чтению паролей LAPS

3. Проверьте, что не настроено делегирование в тех OU, где хранятся пароли LAPS

4. Проверьте правильность настройки групповых политик

5. Проверьте, что у вас не стоит галочка предоставления прав доступа всем пользователям с правками AllExtendedRights

Делимся с вами полезной статьей о том как настроить LAPS

https://getshitsecured.com/2020/03/20/stop-being-lazy-and-deploy-laps/

​​​​Заметки на полях: Расшифровываем пароли Cisco

В условиях повсеместного удаленного доступа очень важно обечпечить безопасность сетевых устройств. Сегодня рассмотрим устройства на базе Cisco IOS.

Получение доступа к сетевому устройству - лакомый кусочек для злоумышленника и пентестера. Первое, что делается при попадании на циску - получение текущей конфигурации устройства и поиск сохраненных паролей.

У Cisco существует несколько типов паролей:

Type 0: пароль, который хранится как plaintext

Type 7: использует шифр Vigenere, который не является надежным и взламывается с помощью онлайн сервисов, которые очень просто найти

Type 4: использует SHA256 без соли

Type 5: использует MD5

Type 8: использует алгоритм PBKDF2 и 10-символьную соль (80 бит)

Type 9: испрльзует алгоритм SCRYPT, 80-битную соль и 16384 итерации

Расшифровываются все типы паролей, причем используя всем доступные инструменты - HashCat и John The Ripper

На расшифровку пароля Type 9 уйдет гораздо больше времени. Однако не все сетевые устройства поддерживают такой тип пароля.

Более подробную информацию по расшифровке можно посмотреть здесь: https://www.infosecmatter.com/cisco-password-cracking-and-decrypting-guide/

Заметки на полях: Расшифровываем пароли и куки в новых версиях Chrome

В новых версиях браузера Chrome изменился алгоритм шифрования паролей и cookies. Теперь в качестве алгоритма шифрования для паролей и кук используется AES GCM, а ключ шифрования опять же шифруется через DPAPI и сохраняется в файле "local state" в профиле пользователя.

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

Но тем не менее - теперь для расшифровки паролей и cookies из браузера Chrome нам необходимо забирать еще и файл "%appdata%\local\google\chrome\User Data\local state".

Для того чтобы можно было оперативно расшифровывать пароли и куки от новых браузеров мы внесли изменения в соответствующий модуль dpapick. (https://github.com/mis-team/dpapick). В модуле добавился параметр --lstate, указывающий на соответствующий файл.