Домен-фронтинг на базе TLS 1.3. Часть 2

Сегодня делимся с вами второй частью статьи про домен-фронтинг

https://habr.com/ru/post/477696/

Немного про OSINT

При проведении RedTeam этап разведки играет очень важную роль - если osint проведен недостаточно качественно, то вся кампания может быть бесполезной. Конечно, основное внимание уделяется сетям компании, корпоративным почтовым адресам и той информации, которая пригодится без этапа фишинга.

Ресурсов для OSINT огромное количество. Как платных, так и бесплатных. Для тех, кто хочет прокачаться - есть крутой бот в телегам, который рассказывает про методы и ресурсы для OSINT - @HowToFind_RU_bot

Предупреждаем, что не все ресурсы, которые есть в боте - дают качественный результат.

Чаще всего нужно искать информацию по человеку по его email. Делимся с вами небольшой частью ресурсов, которые используем сами:

1. @Smart_SearchBot - бот в телегам, который позволяет искать информация по email, vk id, номеру телефона и ИНН. Бесплатный только 1 запрос, остальное за совершенно небольшие деньги.

2. @mailsearchbot - бот в телегам, который проверяет находится email в базах утечек паролей или нет. Показывает найденный пароль со звёздочками (т.е. не полностью). Однако, купив доступ может получить информацию полностью. Мы никогда не оплачивали. И так видно колличество символов в пароле и большинство символов - можно поискать в других местах.

3. https://domainbigdata.com/ - подскажет какие домены зарегистрированы на email

4. http://emailrep.io - подскажет на каких ресурсах есть аккаунты, зарегистрированные на искомый email

5. http://intelx.io - отличный поисковый ресурс, который ищет информацию по разным источникам, в том числе утекшим базам данных и даркнете

6. https://hunter.io/ - ресурс, который из открытых источников (презентации, сайты и др.) по домену компании ищет корпоративные email адреса.

#osint

Полезные исключения

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

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

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

Интересно, что какие-то антивирусы записывают исключения в реестр, какие-то хранят в локальной базе данных.

Делимся вами информацией, где можно найти исключения для 4х популярных антивирусов:

SEP (Symantec Endpoint Protection)

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Symantec\Symantec Endpoint Protection\AV\Exclusion\ScanningEngines\

Kaspersky Internet Security 20

C:/ProgramData/KasperskyLab/AVP20.0/Data/settings_kis.kvdb

Microsoft Windows Defender

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Defender\Exclusions\

McAfee

HKEY_LOCAL_MACHINE\SOFTWARE\McAfee\ManagedServices\VirusScan\Exclude

Мифы информационной безопасности

Под конец года решили сделать небольшую подборку наиболее часто встречающихся заблуждений у заказчиков и попробовать их развеять.

Все мифы основаны на реальных ситуациях с реальными заказчиками

1. Отключенная запись krbtgt автоматически защищает от атаки Golden Ticket

Данная учетная запись по умолчанию отключена. Однако, с ней невозможно ничего сделать (удалить, переименовать или включить), потому что учётная запись необходима для нормальной работы Kerberos в домене. На контроллерах домена хранится зашифрованная форма пароля KRBTGT - именно так проверяются билеты Kerberos - и именно ею успешно пользуются злоумышленники для формирования своего golden ticket.

2.  При создании Golden Ticket для одного домена из леса – остальные домены в безопасности

Неправда. Можно не просто провести атаку, но и добавить дополнительный SID в группу Enterprise Admins. А каждый член группы Enterprise Admins является локальным администратором на контроллерах домена всех child- доменов в лесу. Таким образом, если злоумышленник сделает golden ticket для root домена - он будет обладать всем лесом.

3. Запись паролей некоторых учетных записей в поле denoscription не несет никакого риска, потому что у пользователей, не являющихся администраторами, не установлен ADUC

Получить информацию из denoscription может любой пользователь с помощью любых других утилит – ldap browser, powershell, adexplorer.

4. Всем сервисным аккаунтам требуются права доменного администратора

Неправда. Совершенно не всем. Для правильной настройки прав доступа системный администратор должен понимать каким сервисным учеткам действительно нужны права побольше (иногда достаточно локального администратора), а каким достаточно поменьше

5. Права доменного администратора можно получить только из-за неправильных настроек Active Directory

В большинстве своем проблема в словарных паролях и неконтролируемых учетных записях. Даже при наличии LAPS присутствуют различные учетки (уровня минимум локального администратора), которые не контролируются LAPS и создаются «временно, для тестов».

6. Админу постоянно в работе нужны права доменного администратора

На самом деле в работе системного администратора права доменного админа используются очень редко. Поэтому в целях безопасности у системного администратора должны быть 2 учетные записи – обычная для повседневного использования и с правами доменного администратора для особых случаев.

7. "Я поставил кучу антивирусов, anti-apt решений и полностью защищён"

Такая ошибка встречается постоянно. Многие компании становятся жертвами маркетинга и считают, что поставив дорогую железку, называемую anti-apt, смогут отбивать все атаки на свою систему... И это является основной ошибкой. Не существует волшебного сзи.
Все средства защиты надо правильно выбрать, правильно настроить и правильно реагировать на их срабатывания.

Дорогие друзья, коллеги, единомышленники!

Команда [MIS]Team от всей души поздравляет вас с наступающим Новым годом!

Желаем вам удачи и профессиональных успехов в 2020 году. Крутых ресечей, интересных уязвимостей.

Спасибо вам за то, что вы нас читаете, репостите и оцениваете наши старания!

Увидимся с вами в следующем году на различных конференциях!

Счастливого Нового года!

Ваши [MIS]Team

​​Заметки на полях: Defender Check

При проведении RedTeam постоянно приходится проверять насколько наши тулзы и пейлоады детектируются антивирусом.

Однако, порой совершенно непонятно, что же является причиной детекта. Сегодня делимся с вами супер полезной тулзой, которая позволяет проверить на что реагирует Microsoft Defender. Называется Defender Check (https://github.com/matterpreter/DefenderCheck). С помощью нее можно увидеть какие именно байты вашей программы не устраивают Microsoft Defender и есть ли уже сигнатуры на проверяемую программу.

На картинке показаны результаты проверки с помощью Defender Check.

Красным цветом выделены результаты проверки последней официальной сборки mimikatz от 4.01.2020. Mimikatz выбран по причине того, что это 100% вариант детектирования всевозможными сзи.

Зелёным цветом выделен результат проверки нашей скомпилированной полезной нагрузки.

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

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

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

Мы хотим с вами поделиться информацией о полезных файлах, которые вам могут пригодиться после эксплуатации уязвимости:

1. /flash/nsconfig/ns.conf - хранятся хеши паролей

2. /flash/nsconfig/ssl - ssl сертификаты

3. /var/nstmp/sess_ - можно забрать проверенные cookie и использовать их повторно

Если получилось забрать файлы из пунктов 1 и 2 - можно настроить точно такой же NetScaler и использовать его как подставной для пользователей (ну или придумать другие сценарий на свой вкус).

Кстати, hashcat добавил функционал по подсчёту хешей NetScaler.

Небольшая заметка про хеши:

https://gist.github.com/rxwx/8d888e9169a3513479af69fc11a459a3

Заметки на полях: 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.

http://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 - результат должен быть отрицательным