Как ловить обфускацию? Зачастую в техниках обфускации Powershell можно встретить стандартные вызовы System.Text.Encoding и iex. Эти вызовы сами по себе не раскрывают полезную нагрузку — они лишь конвертируют/выполняют уже скрытый контент.

Основная цель атакующего — спрятать саму полезную нагрузку. Для этого может быть использовано шифрование/кодировка (Base64, AES и др.), разделение строки по частям и динамическая сборка, перемешивание/шифрование идентификаторов переменных.

Но при этом командлеты System.Text.Encoding и Invoke-Expression/iex остаются незамаскированными (см. пример на скриншоте). Это связано с тем, что обфускация их имён часто невозможна без изменения самого рантайма или без вызова по строкам, что усложняет код и добавляет вероятность ошибок.

Атакующий мог бы попробовать заменить Invoke-Expression на динамический вызов Invoke-Expression через & (call), New-Object System.Management.Automation.ScriptBlock::Create(...).Invoke(), или механизм Reflection. Но это также делает код громоздким и может нарушить политики безопасности (ConstrainedLanguageMode) либо поведение окружения (контекст исполнения, $ExecutionContext и др.).

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

Отсюда получаем рекомендации для защиты:

– Блокируйте выполнение таких небезопасных команд, как Invoke-Expression;

– Детектируйте строки такого вида:

$s = [System.Text.Encoding]::UTF8.GetString([Convert]::FromBase64String("...")) 

iex $s

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

Атакующие часто применяют встроенные инструменты системы, а ещё они любят скрытые и односимвольные файлы. Типичный пример такого использования Python на Linux представлен на скриншоте выше.

Злоумышленники использовали этот однострочник, чтобы загрузить файл с удаленного web-ресурса, сохранить его в скрытый файл .1, назначить ему права executable и запусить этот файл.

Мораль: надо следить за такими проявлениями минимализма, как создание и исполнение скрытых и односимвольных файлов, а также за подозрительными командами Python.

В больших AD-лесах админы часто «забывают» или ошибочно настраивают списки контроля доступа (ACL), не желая заморачиваться с чётким разделением и выдачей прав. В таких списках могут оставаться широкие разрешения для Everyone/Authenticated Users/Domain Computers, причём с расширенными правами на чувствительные объекты.

Это не мелочь: именно список DACL в nTSecurityDescriptor определяет, кто и что может делать с объектом. Но есть проблема: такие списки прав указаны для каждого отдельного субъекта (нет одной таблички), GUID’ы прав нечитабельны, а определения дескрипторов безопасности (SDDL) тяжело смотреть глазами.

Наш эксперт Александр Родченко написал утилиту ParseJsonWithSDDLs для решения этой проблемы. Основная идея: показать, какими правами обладают «все», то есть достаточно большой и потенциально неограниченный круг субъектов (анонимы, аутентифицированные пользователи, все ПК и т.д). Другими словами, утилита отвечает на вопрос: «Есть ли у нас в домене какие-то объекты, с которыми может сделать что-то любой пользователь?»

Функционал, реализованный в программе:

— парсит SDDL из nTSecurityDescriptor, вычленяет «широкие» ACE и показывает их в удобном виде (читаемые имена субъектов и объектов, декодированные GUID расширенных прав);
— умеет сама выгрузить весь лес и трасты в JSON (LDAP paging + SecurityDescriptorFlagControl для DACL), если у вас нет готовых экспортов ваших доменов; в некотором роде это работа SharpHound с опцией "вместе с DACL", но в данном случае автор сам реализовал это в коде;
— даёт HTML-сводку и при желании CSV для дальнейшей аналитики/хантинга.

Что даёт использование утилиты?

Это закрывает типовой класс конфиг-дефектов, про которые Microsoft годами пишет в своих рекомендациях по безопасности AD. Прогоны такой утилитой часто приносят «бесплатные» находки перед аудитами и пентестами. Примеры находок приведены на скриншотах выше:

(1) объект, который может изменить любой ПК — и никто не не знает, для чего это нужно; у клиента это был объект, относящийся к системе корпоративной печати,
(2) очень странный объект групповой политики — это заявка на повышение привилегий в домене,
(3) очень неправильно настроенные разрешения создавать общие папки: на самом деле, дали возможность создать объект-корень FTRoot (новый namespace) и создать под ним любые FTDfs-объекты — ссылки (на любой сервер) и их Target-списки.

Утилиту можно скачать в репозитории автора на Гитхабе — там же оставляйте отзывы и предложения по улучшению программы:
https://github.com/gam4er/DACLPlayground/tree/master

И снова в эфире наша любимая рубрика «Минимализм спасёт Галактику».

За последний год было описано несколько атак (Kerberos Relay, NTLM Reflection), связанных с оригинальным ислледованием Project Zero, и в частности, со специфичным маршаллингом дополнительных данных внутри SPN.

Детектировать подобные атаки часто предлагают по событиям DNS\SMB запросов\трафика с именем примерно такого формата:

 
.+1UWhRCAAAAAAAAAAAAAAAAAAAAAA.+YBAAAA.* 

либо по чуть более широкому варианту:

 
.+1UWhRC.+ 

На самом деле, подобный детект можно обойти, указав вот такое имя (тоже будет работать):

 
<hostname>1UWhRGAAAAAAAAAAIAAAAAAAAAAAAAAAQAAAAAtestKerberoswBAAAA 

Поэтому рекомендуем пересмотреть уже существующую у вас логику детектирования и расширить формат детектируемого имени до вот такого: 1UWhR

C 15 по 19 сентября в Самаре пройдёт финал соревнований VolgaCTF. И это не только хакерские битвы: здесь же можно послушать, о чём рассказывают друг другу ИБ-специалисты, когда они собираются вместе.

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

Подробностями таких кейсов, которые не нужно повторять, поделится Григорий Саблин в докладе «Купить защиту — не значит защититься» (16 сентября, 12.00, трек Б)

А Виктор Зварыкин, уже известный вам по призовым историям на конкурсе Pentest Awards (раз и два), расскажет на VolgaCTF, почему финансовое вознаграждение в программах Bug Bounty не всегда является лучшим достижением для тех, кто любит offensive. Вместо этого можно неплохо прокачать скилы, завести полезные профессиональные знакомства, и в итоге получить гораздо больше выгоды в тех хакерских соревнованиях, где не платят денег.

Доклад Виктора с примерами успешного применения такого подхода называется "Киберполигон: Развитие карьеры" (16 сентября, 15.30, трек А)

Все вокруг так носятся с искусственным интеллектом, что будет даже странно, если это массовое увлечение не станет популярным вектором атак.

Можно также наванговать, что значительная часть атак будет организована по классике: через вредоносные расширения и разнообразные "посреднические" сервисы для работы с модными LLM-приложениями.

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

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

Более продвинутый вариант атаки: злоумышленник публикует и рекламирует MCP-сервер как полезный инструмент для работы с Cursor, Claude Desktop или другими LLM-приложениями. После установки инструмент действительно демонстрирует заявленную функциональность — однако параллельно производятся скрытые вредоносные действия (например, шпионаж).

Чтобы смоделировать такую угрозу и разработать меры защиты, наши эксперты создали MCP-сервер, который был упакован как пакет PyPI и предлагал полезные для разработчиков функции: анализ проектов, проверка безопасности конфигурации и настройка окружения. Но одновременно с этими полезными делами, запускался вредоносный модуль сбора данных.

Главный вывод: установка MCP-сервера фактически дает ему разрешение выполнять код на вашей машине с вашими привилегиями.

Подробности этого эксперимента, а также рекомендации по обнаружению и предотвращению подобных атак — в статье Мохамеда Гобаши.

Летом мы начали рассказывать об исследовании защищённости Zigbee-сетей, которое провёл наш эксперт Хайдар Кабибо. Пока полная версия исследования готовится к публикации, поделимся некоторыми деталями о начальной фазе пентеста.

В отличие от бытовых систем умного дома, промышленные сети имеют свои особенности реализации и часто требуют кастомизированного подхода к анализу. В нашем случае, исследуемая система включала координатор с несколькими интерфейсами (Wi-Fi, LTE, Bluetooth, ZigBee) и конечное устройство, контролирующее промышленное реле. Главной целью первого этапа тестирования было понимание работы сети и механизмов защиты трафика.

Для снифинга ZigBee-трафика использовался доступный USB-донгл. Однако сама процедура перехвата в промышленных системах имеет свои нюансы:

— После подключения донгла и загрузки специальной прошивки необходимо последовательно сканировать все 16 каналов диапазона 2,4 ГГц (с 11 по 26),
— ZigBee-сети могут работать на любом из доступных каналов, что усложняет процесс поиска,
— Даже при обнаружении трафика, его расшифровка представляет отдельную сложность.

Интересное наблюдение: несмотря на то, что данные в ZigBee-пакетах зашифрованы, заголовки MAC и Network остаются в открытом виде. Это позволяет получить ценную информацию о структуре сети:

— PAN ID сети (2-байтный идентификатор)
— Короткие адреса устройств (2 байта)
— Расширенные адреса, аналогичные MAC (8 байт)
— Идентификатор координатора (всегда имеет адрес 0x0000)

Механизмы шифрования и другие детали будем разбирать в следующих постах на эту тему. А кому хочется узнать раньше — слушайте доклад Хайдара Кабибо "Turn Me Off, Turn Me On" на VolgaCTF (17 сентября, 13:15, трек А)

Как-то в одном американском городке полиция эвакуировала посетителей спортивного клуба, а само помещение тщательно обыскали со служебными собаками в поисках взрывчатки. Всему виной был шутник, который назвал свою WiFi-точку "remote detonator".

Аналогичные случаи возможны и в работе специалистов по offensive security. Представим себе типичную инфраструктуру банка/энтерпрайза. DNS для доменных контроллеров выглядят как вариация из букв-локаций, букв DC и порядкового номера (MSK-DC-007, JED-RODC-2). Компьютеры сотрудников состоят из названия департамента и опять-таки порядкового номера (IT00001337).

Красиво и понятно, да? А теперь представьте, что в этой инфраструктуре в различных журналах безопасности появляются:

— разнообразные "debian" и "ubuntu"
— "kali"
— "WIN-7MWPPTDA"
— "HackPC"

Как правило, все эти варианты означают одинаковый диагноз: "лень поменять название собственного ПК". Но являются ли они легитимными? Стоит ли их опасаться/расследовать?

Ответ может быть разный. Если мы рассматриваем "лень" со стороны IT, то любое из этих имен может быть легитимным.

Если смотрим со стороны SOC, то все такие машины стоит пометить как потенциально опасные. Или даже завести ханты на типовые RiskOS/HackOS, а также шаблоны имён "по умолчанию" для ОС Windows. В идеальном мире можно договориться с IT, чтобы у машин в инфраструктуре были предсказуемые имена, а если появляется что-то странное — расследовать.

Если же мы смотрим со стороны атакующего (пентестера) — не поменяв себе имя узла, вы усложняете жизнь и себе, и экспертам SOC, и многим другим. Примерно как тот деятель, у которого точка доступа называлась remote detonator.

А какие типично "зловредные" доменные имена знаете вы? Присылайте в личные сообщения нашего канала! Мы опубликуем эти примеры в одном из следующих постов серии "Зарисовки про базовый OPSEC".

В атаках на Linux-системы злоумышленники часто используют директорию /dev/shm для сохранения вредоносных файлов. На скриншоте выше — пример вредоносной команды, использовавшейся в одной из атак.

Почему именно эту локацию так любят атакующие? Директория /dev/shm — часть виртуальной файловой системы tmpfs, предназначенная для разделяемой памяти (shared memory). Основные её особенности:

— содержимое хранится в памяти (RAM), не оставляя следов на диске, что помогает атакующим скрываться от систем обнаружения,
— содержимое автоматически очищается при перезагрузке, что может затруднять форензику.

Вообще при компрометации Linux-систем атакующие, как правило, сохраняют свои скрипты и исполняемые файлы в директориях с упрощённым доступом на запись. Наиболее уязвимыми в этом плане являются world-writable каталоги: /tmp, /var/tmp и /dev/shm.

При этом /tmp и /var/tmp могут быть смонтированы либо на диск, либо как временное хранилище tmpfs. А уже упомянутая /dev/shm всегда работает на tmpfs, то есть хранит данные только в оперативной памяти. Эти директории удобны для злоумышленников: они редко мониторятся админами, а их содержимое в случае tmpfs исчезает после перезагрузки.

Кроме того, атакующие часто задействуют служебные каталоги приложений, куда процессы имеют права записи. Классический пример — каталог /var/www, используемый веб-серверами. Если удаётся загрузить туда скрипт (например, PHP-шелл), он становится доступен напрямую через HTTP-запрос. Это обеспечивает и сохранность артефактов между перезагрузками, и удобный удалённый доступ к системе.

Мораль: защитникам полезно следить за упомянутыми директориями.

Обычно при анализе защищённости мы не мучаемся проблемой интерфейса. Особенно если речь идёт о классическом TCP/IP-стеке и каком-нибудь сервисе, принимающем данные из TCP: мы просто абстрагируемся от нижних уровней.

Если дело доходит до сетевых атак на протоколы, работающие поверх Ethernet, картина тоже весьма понятна: современные системы и драйвера позволяют собирать сырые кадры и манипулировать любыми полями вложенных протоколов.

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

О работе с такими "пациентами" рассказал наш эксперт Сергей Андреев в докладе "Как разговаривать с воздухом, не привлекая внимания санитаров" на конференции OFFZONE. В докладе описаны:

— методы получения параметров канала связи,
— немного теории по SDR/DSP и сигналам,
— принципы технического анализа неизвестных сигналов (определение несущей частоты, типа модуляции и т.д.)
— реализация трансивера на боевом примере для эксплуатации найденных уязвимостей поверх канала 433 МГц (на основе инструментария GNU Radio).

Подробности смотрите в видеозаписи доклада (и отдельно можно скачать слайды). Кроме того, мы планируем развить тему технического анализа беспроводных сигналов в последующих публикациях. Stay tuned!

В последнее время атакующие часто используют в качестве инфраструктуры VPS-сервера различных VPS-провайдеров. Например, эксперты из Black Lotus недавно обнаружили, что ботнет SystemBC поддерживает ежедневно около 1500 заражённых устройств, причём 80% из них – это VPS-сервера пяти крупных коммерческих провайдеров, содержащие множество легко эксплуатируемых уязвимостей.

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

При этом на VPS-серверах ботнет живёт дольше, чем на персональных устройствах: 40% VPS-серверов остаются заражёнными более месяца.

Как защищаться?

Типичная активность злоумышленников, использующих VPS: брут сервиса, например RDP, а при успешном бруте – последующий логон. Это и будем детектировать.

Событие 4624(S): An account was successfully logged on широко используется в мониторинге ИБ, и есть множество полезных правил, которые можно сделать над этим событием.

В частности, если значение из поля Source Network Address события 4624 обогащать информацией о владельце сети (Whois), можно обнаруживать попытки успешных логонов в корпоративную сеть с IP-адресов VPS-провайдеров.

Такой пример из практики нашего SOC – на скриншоте выше: правило показывает подозрительный заход через сервер одного из крупных облачных хостинг-провайдеров, который с большой вероятностью используется в качестве прокси для атаки.

HashiCorp Vault — мощный opensource-инструмент, предназначенный для хранения, управления и защиты доступа к чувствительным данным: паролям, API-ключам, сертификатам. Он централизует работу с секретами, автоматизирует их выдачу и отзыв, а также обеспечивает тонкий контроль доступа в сложных распределённых инфраструктурах. Взаимодействие с Vault возможно через API, веб-интерфейс или CLI, а аутентификация поддерживает широкий спектр методов, включая интеграцию с Kubernetes и облачными платформами.

Однако... в августе этого года в HashiCorp Vault было обнаружено 9 уязвимостей, одна из которых (CVE-2025-6000) критическая (score 9.1). И это первая в истории публично задокументированная RCE-уязвимость в HashiCorp Vault, просуществовавшая 9 лет до исправления.

Уязвимость позволяет привилегированному оператору Vault создать подконтрольный файл аудита и зарегистрировать его как плагин, чтобы получить возможность выполнения произвольного кода.

Для эксплуатации нужно:

0. Иметь root токен. Его получение выходит за рамки данной статьи, однако стоит упомянуть, что связка нескольких CVE даёт возможность это сделать: CVE-2025-6037 позволяет имперсонироваться через уязвимость проверки сертификатов, CVE-2025-5999 позволяет повысить привилегии до root.

Условие является необходимым, так как для создания аудита и регистрации плагина обычно нужны привилегии root.

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

POST /v1/sys/plugins/catalog/non_existing_name 

и в ответ получить

1 error occurred:\n\t* failed to verify plugin plugin \"non_existing_name\" version \"v1.0.0\": extracted artifact directory not found: /home/vault/vault_plugins/non_existing_name_1.0.0_linux_amd64\n\n 

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

2. Записать файл аудита в каталог плагинов. Для этого зарегистрировать аудит с такими параметрами:

file_path (путь к файлу аудита) = "/home/vault/vault_plugins/script.sh"

Указывается директория с плагинами из предыдущего шага.

mode (права на файл аудита) = "0755"

Файл аудита должен быть исполняемым (rwxr-xr-x)

prefix (префикс будет добавлен перед каждым логом) = "#!/bin/bash\n(some bash payload)"

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

3. Зарегистрировать плагин. Для регистрации плагина необходимо указать его sha256, однако тут есть загвоздка: лог аудита содержит различные временные метки, а также хэшированные данные, предсказать которые практически невозможно. Поэтому для получения точной копии лога аудита, можно предварительно зарегистрировать еще один аудит, транслирующий логи на подконтрольный нам сокет. В этом случае добавляется шаг по удалению аудита с префиксом перед подсчетом sha256.

После регистрации исполняемого файла в качестве плагина, он выполняется от имени пользователя vault.

Как обнаружить эксплуатацию CVE-2025-6000:

1. Корреляция событий из шагов выше явно укажет на попытку эксплуатации:

- Попытка регистрации несуществующего плагина;
- Cоздание аудита с указанием prefix и mode;
- Удаление недавно созданного аудита (также рекомендуем мониторить удаление аудита в принципе, так как это событие само по себе должно вызывать подозрения);
- Регистрация подозрительного плагина.

2. Отслеживайте аномалии в цепочках процессов от vault. Например, запуск скриптов.

Методы защиты:

Уязвимость CVE-2025-6000 исправлена в Vault Community Edition 1.20.1 и Vault Enterprise 1.20.1, 1.19.7, 1.18.12 и 1.16.23.

Поэтому стоит обновиться до этих версий. В исправленных версиях аудит с префиксом требует явного указания в конфигурации vault, а также аудит не может использовать файлы с правами на выполнение (0777, 0755 и т.д.) и не может быть записан в директорию плагинов.

Представьте, что атакующий получил доступ к одному из Windows-хостов в корпоративной сети. Чаще всего следующий шаг – попытка скомпрометировать другие машины, используя добытые в системе учётные данные и прочие секреты.

В наши дни большинство техник сбора секретов детектируются и блокируются EDR-системами. Однако при решении задач по анализу защищённости и редтимингу бывает полезно добыть учётные данные, не привлекая внимания «синих».

Наш коллега Хайдар Кабибо нашёл простой метод, позволяющий извлекать секреты из реестра Windows на лету – без записи на диск, доступа к LSASS, срабатывания EDR и даже без привилегий SYSTEM, используя легитимные функции самой Windows.

Общая идея техники:

– За хранение секретов в Windows отвечает подсистема Local Security Authority, работающая через процесс lsass.exe. Подсистема использует две базы данных в памяти, которым соответствуют кусты реестра SAM и SECURITY. В первой базе хранятся пользовательские учётные данные, во второй – другие секреты (кэшированные учетные данные домена, различные ключи и т.д).

– Каждый куст защищен списком контроля доступа (DACL), который требует привилегий SYSTEM для доступа по стандартным API-интерфейсам. Но оказывается, можно прочитать значения этих кустов с более низкими правами (правами локального администратора), если работать с бэкапами кустов реестра: включение привилегии SeBackupPrivilege отменяет проверки безопасности на основе ACL.

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

– В частности, попытка прочитать значения из SAM или SECURITY будет отслежена по использованию таких типичных API, как RegQueryValueExW или NtQueryValueKey. Чтобы обойти эту проверку, достаточно найти более редкую API-функцию для чтения, которую не отслеживает EDR. И такие API существуют. Например, RegQueryMultipleValuesW.

– Это ещё не всё! Значения, прочитанные из SAM и SECURITY, зашифрованы. Последний шаг: для расшифровки надо восстановить ключи, используя данные из куста SYSTEM.

Как защищаться:

Необходимо добавить к детектирующей логике защитных решений проверку запуска RegQueryMultipleValuesW.

Подробности техники читайте в блоге Хайдара. Ещё больше подробностей – в видеозаписи его доклада на OFFZONE.

Атака с использованием поддельных сертификатов – один из самых эффективных методов получения неавторизованного доступа к ресурсам внутри корпоративной сети. Мы уже рассказывали, как ловить такие атаки, выявляя аномалии при запросе TGT-билета по сертификату. Сегодня добавим ещё ряд идей для детектирования других Kerberos-атак на основе аномальных опций билета.

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

Например, билет шифрован RC4 и содержит специфичные флаги в опциях:

EventID:(4768 OR 4769) AND  
TicketOptionsList:( 
     "Proxiable" AND -"Name-canonicalize" AND -"Renewable-ok" 
) AND  
TicketEncryptionType:"0x17" 

Или билет запрошен без PreAuth и содержит специфичные флаги в опциях:

EventID:(4768 OR 4769) AND  
TicketOptionsList:( 
     "Proxiable" AND -"Name-canonicalize" AND -"Renewable-ok" 
) AND
PreAuthType:"0" 

А ещё в конце прошлого года обновилась схема событий запросов Kerberos-билетов (4768, 4769). Там добавилось много полей, которые могут помочь в детектировании различных атак на Active Directory, в дополнение к описанным выше хантам.

Например, с помощью поля ClientAdvertizedEncryptionTypes мы можем добавить хант на запрос TGT- и TGS-билетов со специфичными флагами в опциях и только для клиентов, которые указывают алгоритм шифрования RC4-HMAC-NT:

EventID:4768 AND  
TicketOptions:"0x40800010" [Forwardable, Renewable, Renewable-ok] AND 
ClientAdvertizedEncryptionTypes.raw:"RC4-HMAC-NT”

Также поле ClientAdvertizedEncryptionTypes можно использовать для детектирования других impacket-подобных утилит, которые используют аутентификацию с предъявлением сертификата:

EventID:4768 AND  
PreAuthType:16 AND  
ClientAdvertizedEncryptionTypes:"AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96"

...Или для детектирования U2U-запросов (UnPAC-the-Hash) от подобных утилит. При таком запросе поля TargetAccountName и ServiceName будут равны и нужно добавить следующие критерии поиска:

EventID:4769 AND  
TicketOptionsList:"Enc-tkt-in-skey" AND  
ClientAdvertizedEncryptionTypes.raw:"AES256-CTS-HMAC-SHA1-96 RC4-HMAC-NT"

Во время проведения работ по анализу защищенности регулярно возникает потребность поймать DNS или HTTP-отстук. Исследователям это нужно при поиске и эксплуатации SSRF-уязвимостей, или при эксфильтрации данных с помощью техник Out-of-Band.

Или, например, хочется принять e-mail. При этом нужно, чтобы все участники команды могли посмотреть входящие письма, но не хочется это делать на каких-то публичных почтовых сервисах.

Подобные задачи решает Burp Collaborator, однако некоторых вещей он не умеет. Например, Burp Collaborator не предназначен для совместного использования несколькими исследователями, его сервер не хранит историю обращений: как только вы увидели входящий запрос, он немедленно удаляется, и другие исследователи не имеют удобной возможности увидеть полученный отстук.

А ещё Burp Collaborator не предоставляет функционал для тестирования уязвимости DNS rebinding, и не поддерживает удобную кастомизацию ответов под конкретные запросы. Да, можно сформировать такой конфигурационный файл при старте, но разве это удобно делать каждый раз?

В итоге у наших экспертов родился проект Collab2 — это инструмент с веб-интерфейсом, который позволяет собирать DNS/HTTP(s)/SMTP-запросы примерно так же, как Burp Collaborator, но имеется ещё ряд дополнительных фич. Пользователь Collab2 может:

— зарегистрировать новое имя для поддомена и поделиться доступом к созданному поддомену с коллегами для совместной работы: нужно просто ипортировать ключ доступа,
— фильтровать прилетающие запросы по типам и паттернам, а также просматривать их содержимое; есть персистентное хранилище для ответов,
— настроить ответы HTTP(s)-сервера, в зависимости от запроса; также есть возможность назначать внешний обработчик для запросов,
— конфигурировать DNS-ответы, в том числе для тестирования DNS rebinding.

Инструмент Collab2 будет развиваться и дальше, но уже сейчас он доступен в нашем GitHub-репозитории:
https://github.com/klsecservices/collab2 — это сам Collab2, c фронтендом и инструкцией, как развернуть инструмент у себя.
https://github.com/klsecservices/collab-agent — это модуль для Collab2, который прослушивает необходимые порты, собирает запросы и возвращает требуемые результаты.

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

В конце сентября в популярном редакторе Notepad++ версии 8.8.3 была обнаружена уязвимость типа DLL Hijacking (CVE-2025-56383) и опубликован соответствующий PoC.

Суть проблемы: если приложение загружает DLL по относительному или неполному пути, Windows может найти и подгрузить DLL из каталога с более высоким приоритетом (binary search order / DLL search path).

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

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

Атака действительно требует доступа к файловой системе цели (локально или через ранее полученный доступ), но не всегда требует взаимодействия пользователя, помимо запуска приложения.

В отсутствие жёсткой привязки к полным абсолютным путям при загрузке внешних библиотек, при вызове LoadLibraryA/LoadLibraryW без полного пути и без безопасных флагов (например, LOAD_LIBRARY_SEARCH_SYSTEM32/LOAD_LIBRARY_SEARCH_USER_DIRS) загрузчик Windows применяет алгоритм поиска библиотеки по набору директорий вместо однозначного файла. И что существенно — Windows не выполняет проверку цифровой подписи при вызове LoadLibrary.

Алгоритм эксплуатации:

— Приложение вызывает LoadLibrary("evil.dll") без полного пути и без безопасных флагов.

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

— Атакующий ранее подменил dll. Подпись файла не проверяется, поэтому загрузчик выполняет его код в контексте процесса, что даёт атакующему возможности выполнения кода с правами процесса.

На скриншоте выше показан пример с поддельной библиотекой NppExport.dll. После подстановки такого файла (уже переименованная нежелательная библиотека с функционалом загрузчика) при запуске Notepad++ вызывается вредоносный код.

Для детектирования подобных атак нужно обращать внимание на:

— Наличие в директориях часто используемых приложений DLL с именами, совпадающими с системными/ожидаемыми библиотеками.

— Отсутствие цифровой подписи или подписи от неизвестного издателя у загруженных модулей.

В целом, есть ещё много приложений, которые допускают DLL Hijacking. И поскольку ручной анализ сотен загружаемых библиотек — довольно трудоёмкий процесс, имеет смысл детектировать DLL Hijacking с помощью систем на основе машинного обучения. О нескольких реальных инцидентах, которые удалось обнаружить таким способом, читайте в статье наших экспертов.

Cо вчерашнего дня компания Microsoft официально прекратила поддерживать Windows 10. Поэтому ожидается рост числа систем под управлением Windows 11, и специалистам по реагированию на инциденты будет полезно узнать о новых артефактах этой ОС, которые можно использовать в расследованиях.

Вот например, в прошлом году в Windows 11 добавили новую опцию Recall с очень спорным функционалом. Каждые несколько секунд Recall делает снимки пользовательского экрана, а затем анализирует их c помощью искусственного интеллекта и сохраняет метаданные в специальных базах для поиска.

Неудивительно, что СМИ сразу окрестили эту функцию "шпионской", а пользователи побежали читать инструкции по отключению этого фотоаппарата.

Сейчас опция Recall по умолчанию отключена в корпоративных сборках Windows 11. Однако представим, что её активировали злоумышленники или вредоносное ПО (или просто любопытный админ). В этом случае артефакты Recall будут очень полезны для анализа инцидента: благодаря им можно подробно восстановить активность злоумышленника в скомпрометированной системе.

Вот несколько фактов об этих артефактах:

— Необработанные изображения снимков экрана в формате JPEG можно найти по пути %AppData%\Local\CoreAIPlatform.00\UKP\{GUID}\ImageStore\*. В качестве имен файлов используются идентификаторы снимков экрана.

— Вместе со снимками экрана сохраняются их метаданные, которые записываются в стандартный тег Exif.Photo.MakerNote (0x927c) и содержат множество интересной информации: например, если во время создания снимка экрана используется браузер, могут быть сохранены URI, домен и т. д.

— За включение и отключение сохранения снимков экрана отвечает ключ пользовательского куста реестра Software\Policies\Microsoft\Windows\WindowsAI\. Также в последних сборках Windows 11 Microsoft добавили несколько новых ключей реестра, связанных с управлением Recall.

— Наиболее полезной для расследователя будет база данных SQLite по адресу %AppData%\Local\CoreAIPlatform.00\UKP\{GUID}\ukg.db, состоящая из 20 таблиц. В них можно найти не только данные о процессе, запустившем окно графического интерфейса приложения (полный путь процесса, время запуска и т.д.), но и содержимое снимков экрана (текст со скриншотов, распознанный при помощи Optical Character Recognition).

Подробнее об этих и других изменениях в артефактах Windows 11, которые наиболее интересны с точки зрения форензики — в статье Кирилла Магаськина.

Мы часто видим, что в различных статьях по детектированию техник повышения привилегий с использованием ADCS (ESC-атаки) авторы до сих пор используют старый формат событий запросов сертификатов в ADCS (события 4886—4889). Однако в этом году компания Microsoft обновила формат упомянутых событий, и обновлённая схема даёт намного больше возможностей для написания хантов.

К сожалению, документации от Microsoft на эти события пока нет. Но несложно догадаться, какая информация содержится в каждом новом поле.

На скриншоте выше показано, как выглядит событие 4886 при запросе сертификата с использованием ESC1-уязвимого шаблона утилитой certify.

В обновлённом формате видно использованный шаблон, subjectAltName (SAN) в CSR, RequestClientInfo с пользователем, хостом и даже процессом из COM-объекта, использованный протокол для запроса (RPC или DCOM) и т.д.

А вот как выглядит теперь событие 4887 при таком запросе:

Certificate Services approved a certificate request and issued a certificate. 

Request ID:        79 
Requester:        ESSOS\daenerys.targaryen 
Attributes:         
 
ccm:meereen.essos.local 
Disposition:        3 
SKI:  93 be 4b 84 64 d7 19 20 6e 94 82 4d 1f ed 86 a5 c1 2c 0e 09 
Subject:        CN=daenerys.targaryen, CN=Users, DC=essos, DC=local 
Subject Alternative Name: 
Other Name: 
     Principal Name=viserys.targaryen 

Certificate Template:        ESC1 
Serial Number:                200000004f317b974a5431d29a00000000004f 
Authentication Service:        Kerberos 
Authentication Level:        Privacy 
DCOMorRPC:                DCOM 

Здесь, помимо уже перечисленных полей, наконец-то появился Serial Number сертификата. Его можно использовать при поиске событий запроса TGT-билетов с выданным сертификатом (поле CertSerialNumber).

К сожалению, до сих пор нет информации об IP-адресе клиента, ApplicationPolicy в запросе, SID Extension в выданном сертификате. Но даже с таким набором полей уже намного удобнее работать, и гораздо меньше необходимости обогащать события данными из БД ADCS.

Рекомендуем обновить ваши ADCS-сервера, если вы ещё этого не сделали, и проверить, настроены ли ваши аудиты. А мы в следующем посте расскажем, как можно использовать новые поля в хантах для детектирования ESC-атак.

Как мы рассказывали в прошлом посте, Microsoft наконец-то обновил события запросов сертификатов ADCS (4886-4889), что даёт больше возможностей для детектирования техник ESC ADCS. Например, теперь можно легко детектировать запросы с указанием SAN в CSR, что используется, в частности, для атаки ESC1:

EventID:4886 AND  
EventData.SubjectAlternativeName:* 

Также во многих инфраструктурах обычно используется протокол DCOM для запросов сертификатов, а запросы с использованием RPC являются очень редкими. Стоит обращать внимание на такие подозрительные запросы:

EventID:(4886 OR 4887 OR 4888 OR 4889) AND  
EventData.DCOMorRPC:"RPC"  

А ещё в событиях появилось поле AuthenticationLevel, которое можно использовать для детектирования запросов сертификатов с использованием RPC при отключенном packet privacy, за который отвечает флаг ENFORCEENCRYPTICERTREQUEST (техника ESC11):

EventID:(4886 OR 4887 OR 4888 OR 4889) AND  
EventData.DCOMorRPC:"RPC" AND  
EventData.AuthenticationLevel:"Connect" 

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

EventID:4886 AND  
RequestClientInfo:* AND  
NOT RequestClientInfo:(*MMC.EXE* OR *taskhostw.exe* OR *dmcertinst.exe* OR *certreq.exe*) 

О других способах детектирования атак ESC9-ESC15, а также о том, как самостоятельно воспроизвести их на актуальных версиях ОС, вы можете узнать из видеозаписи доклада Дмитрия Щетинина и Андрея Скаблонского на OFFZONE-2025. Дополнительные материалы по докладу (события, ханты и др.) выложены в Гитхабе.