Одной из самых актуальных уязвимостей в 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)

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

Примером такой уязвимости является 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

• Учетная запись в домене с самыми рядовыми привилегиями.
• На атакуемом устройстве не настроено принудительное требование подписи 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

Одной из самых популярных техник для повышения привилегий в домене Active Directory является Relay. Долгое время всем были хорошо известны атаки NTLM Relay, но не так давно было описано несколько техник, позволяющих выполнить Relay с использованием Kerberos. Многим будет понятнее, о чем речь, если сказать SMB Relay или ADCS ESC8. Но техник для Relay-атак гораздо больше, выполнять их можно на HTTP, SMB, RPC, MSSQL, WinRMS, LDAP и, вероятно, еще на какие-то протоколы, которые будут описаны в будущем.

Если Relay-атакам подвержены NTLM и Kerberos в связке с различными протоколами, то как защититься от них? На самом деле существуют встроенные механизмы защиты, которые просто нужно отладить. Подробнее о каждом из них поговорим в следующих постах. Но сегодня хочется акцентировать внимание на недавно обнаруженной уязвимости — CVE-2025-33073.

❗️ Сначала немного о самой уязвимости. Эксплуатация проходит в связке с Relay-атакой — хоть Kerberos, хоть NTLM. Корни ее уходят в далекий 2008 год. В том году Microsoft выпустила бюллетень по безопасности MS08-068, после которого перестала работать техника Relay, когда компьютер атаковал бы сам себя.

В то время еще не были широко известны техники типа Coerce, но ярлычками уже активно пользовались (например, LNK-файлами, которые хакеры разбрасывали в доступных для записи общих папках SMB) для получения сессии администратора на устройстве и выполнения Relay-атаки на него же для повышения привилегий. Такой Relay будем называть Reflective.

С тех пор появились техники принуждения к аутентификации — Coerce- и сами Relay-атаки стали более изощренными, но Reflective Relay именно через сеть не было. Но вот наступает 2021 год, и в сети появляется исследование, в котором достаточно подробно описывается механизм Kerberos-аутентификации, в том числе на SMB-сервере. Нет смысла повторятся, стоит лишь сказать, что там впервые фигурирует странное хостовое имя:

fileserver1UWhRCAAAAAAAAAAUAAAAAAAAAAAAAAAAAAAAAfileserversBAAA

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

🗓 Вот наступает 2025 год, и 11 июня выходит два исследования подряд: первое и второе. Они тесно связаны друг с другом и основаны на ресерче 2021 года, поэтому читать их лучше именно в таком порядке. В этих исследованиях демонстрируется возможность Reflective Relay как NTLM, так и Kerberos.

Про эксплуатацию CVE-2025-33073 в посте ниже👇

#cve #win #offensive
@ptescalator