Exchange Online и Basic Auth

Basic Auth в Exchange Online всё!
Точнее будет отключена с 13 октября 2020 года. И это большой удар по RedTeam командам, которые пользуются именно возможностью перехвата учётных записей, отсутствием mfa и zero trust в компании.

Что изменится? Basic Auth больше не будет работать. Пользователи будут использовать современную аутентификацию на основе генерируемого OAuth2.0 токена.

Как с этим жить пользователям? Придется использовать приложения, которые поддерживают Modern Auth (например, официальные приложения от Microsoft уже сейчас поддерживают).

Будут ли проблемы у пользователей и Blueteam в октябре 2020 года? Если вовремя учесть информацию и подготовить все для комфортной работы, то нет. Если ничего не делать (как это обычно и бывает), то проблем не избежать.

Будут ли проблемы у RedTeam? Да. Часть методик перестанет работать и надо придумывать новые способы получения аутентификационных данных

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

https://techcommunity.microsoft.com/t5/Exchange-Team-Blog/Improving-Security-Together/ba-p/805892

Bloodhound Cypher Cheatsheet

Все знают про Bloodhound - мощный инструмент, который показывает связи между объектами в Active Directory.

Для графической оболочки используется Neo4j (графовая база данных), которая, в свою очередь, использует язык Cypher. Cypher сложный язык. Поэтому ребята составили табличку, которая отражает самые популярные и нужные запросы (все уже написано - можно брать и использовать на своих данных).

А мы делимся с вами ссылкой:

https://hausec.com/2019/09/09/bloodhound-cypher-cheatsheet/

#redteam #blueteam

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

Довольно часто в Burp Suite требуется профазить какой-либо заенкоженный параметр, например, поле username в basic authorization, или значение userid внутри заенкоженного параметра cookie. Например, session=eyJhdXRoIjp7InVzZXJpZCI6ImFkbWluIiwidXNlcnRva2VuIjoiMTIzNDUifX0= ( {"auth":{"userid":"admin","usertoken":"12345"}} ).

В таком случае из стандартных средств нам подойдёт только Burp Intruder. Однако тогда не получится использовать Active Scan и дополнительные экстеншны, а устраивать танцы с бубнами вокруг составления итогового payload с последующим енкодингом - потраченное время и никакого удовольствия.

Но нас может выручить полезный экстеншн - Python Scripter. После его подключения появляется отдельная вкладка - Script, куда мы можем вписать свои скрипт для питона. Таким образом алгоритм работы следующий: декодим нужную cookie в Repeater или Intruder, устанавливаем место для фазинга (через scan manual insertion points или спец символ в Intruder), а во вкладке Script - пишем скрипт по енкодингу в base64. После этого - отправляем запрос на активное сканирование.

Для енкодинга нужных параметров мы используем следующие скрипты (https://github.com/mis-team/burpnoscripts):

1. В скрипте param-replacer.py необходимо указать:
- header и/или GET/POST параметр, который необходимо енкодить,
- функции енкодинга: processHeader, processParam (в скрипте написан base64)
- место, куда вставлять заенкоженный параметр (GET, POST, COOKIE).

2. Скрипт fuzz-replacer.py - альтернативный и более удобный вариант. Теперь наоборот - место енкодинга в запросе необходимо "обернуть" в FUZZ (как в знаменитом web фазере), а скрипт уже распознает его и сделает все сам.

Рубрика "Новости от Microsoft"

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

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

Защита Microsoft очень растет в последнее время!

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Users-can-now-check-their-sign-in-history-for-unusual-activity/ba-p/916066

Исследование обхода антивируса

Мы постоянно сталкиваемся с антивирусами. Постоянно наше ПО не работает, потому что детектируется антивирусом. Мы уже ввели в свой RedTeam процесс целый блок под названием "отмазывем от авера", в рамках которого проводим большую работу по предотвращению детектирования наших (и опенсорсных) утилит, скриптов и т.д. А все из-за того, что антивирусы очень хорошо развиваются в поведенческом детектировании и используют облачные базы для оперативного распространения информации. Таким образом то, что работало месяц назад - перестает работать.

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

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

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

https://www.trustedsec.com/blog/discovering-the-anti-virus-signature-and-bypassing-it/

Статья очень классная и описывает как заведомо детектируемое ПО можно отмазать от антивируса.

Домен-фронтинг на базе TLS 1.3

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

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

OpenSSH в Windows 10

Сегодня поговорим ещё об одной "фишечке" от Microsoft - встроенных утилитах OpenSSH в Windows 10

Что это такое и зачем? Microsoft придумал встроить в Windows 10 утилиты OpenSSH, чтобы не надо было ставиться дополнительные утилиты, типо Putty.

Надо ли что-то включать дополнительно? Нет. Запустили эту "фишечку" уже давно, ещё в середине 2018 года и ssh-agent включен по умолчанию.

Удобно ли это? Да, удобно. Особенно для тех серверов, к которым доступ происходит не по паролю, а по ключу.

Насколько безопасно? А вот тут та самая "фишечка" и вылазит. С точки зрения Microsoft все классно. Все приватные ключи защищены с помощью DPAPI. С нашей точки зрения тоже все классно, потому что используется DPAPI, с помощью которого мы можем извлекать нужные нам данные.

Часто ли администраторы используют эту "фишечку"? Сложилось ощущение, что не все о ней знают. Но мы на практике пару раз встречали, что используют

Делимся с вами статьей, где можно найти подробности:
https://blog.ropnop.com/extracting-ssh-private-keys-from-windows-10-ssh-agent/

Домен-фронтинг на базе 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 - отличная возможность закрутить гайки и обезопасить пользователей.