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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

POST /v1/sys/plugins/catalog/non_existing_name 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Certificate Services approved a certificate request and issued a certificate. 

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

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

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

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

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

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

EventID:4886 AND  
EventData.SubjectAlternativeName:* 

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

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

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

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

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

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

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

Про уязвимости типа Path Traversal должен знать даже начинающий пентестер. И не только потому, что этот вопрос может попасться на собеседовании. Когда приложение начинает доверять пути из запроса больше, чем своей собственной логике, появляются те самые "../", позволяющие выбраться за пределы разрешённого каталога и добраться до конфигов, исходников, логов – всего, что процесс может прочитать.

OWASP формально относит Path Traversal к категории A01:2021 (Broken Access Control), но по факту, это ошибка валидации входных данных при работе с файловой системой, а не сбой в логике авторизации. И на практике Path Traversal остается актуальной угрозой даже в зрелых продуктах.

Яркий пример – уязвимости CVE-2024-5865 и CVE-2024-5866 в Centrify PAS. Первая из них позволяла читать произвольные файлы за счёт передачи пути с последовательностями типа ../, открывая доступ и к системным файлам, и к конфигурациям с ключами. А благодаря второй CVE можно было получать списки содержимого директорий за пределами корня приложения. Комбинация этих багов давала возможность сориентироваться в структуре каталогов, а затем прицельно считывать нужные файлы, давая полный доступ на чтение в пределах прав процесса.

Для систем, работающих с секретами (PAM, хранилища учётных данных), эксплуатация Path Traversal особенно неприятна. Случай из нашей практики: через обход каталогов с помощью Path Traversal забрали конфигурации с секретом для расшифровки шифротекста, который хранился в базе данных. А затем, используя SQL-инъекцию, вычитали зашифрованные строки с паролями, и использовали их для развития атаки.

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

Как выявить Path Traversal на тестировании:

– Экспериментируйте с ../ в URL и параметрах, пробуйте различные энкодинги (%2e%2e%2f, %252e%252e%252f), используйте null bytes (%00).

– Тестируйте абсолютные пути (/etc/passwd, C:\windows\system32\drivers\etc\hosts) и длинные пути для обхода фильтров.

– Проверяйте работу с файловыми операциями в разных частях приложения: загрузка, экспорт, логи, бэкапы. Для разминки (в WebGoat или аналоге) можно погонять варианты с ../ и посмотреть логи: как атаку можно отследить? Помните, что Path Traversal легко упустить на ручном тестировании, если не проверять все файловые операции приложения.

«Взрослые» вендоры реагируют быстро при грамотном репорте: обе вышеописанные уязвимости были закрыты после нашего уведомления.

Как защищаться от Path Traversal:

– Не пускать пользовательский ввод напрямую в файловую систему. Вместо реальных имён файлов использовать контролируемые идентификаторы (UUID, хэши), а всю обработку путей на сервере делать через каноникализацию и проверку принадлежности целевого пути разрешённому корню. Любые «..», странные симлинки и попытки вывернуться за пределы директории должны отбрасываться.

– Изолировать пространство пользовательских файлов: отдельный логический диск/маунт, chroot или контейнеры в Unix, отдельная буква диска в Windows.

– Жёстко ограничивать права сервисного пользователя по принципу наименьших привилегий. Включить превентивные слои: сигнатуры WAF на обход каталогов, мониторинг и алерты по нетипичным путям в логах.

– Если вы пользуетесь Centrify PAS, проверьте версии и установите обновления. Своевременные патчи, правильный процесс управления уязвимостями, регулярный аудит и наблюдение за журналами – обязательная гигиена против Path Traversal.

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

Ну а теперь — про коды. В проектах по анализу защищённости одним из самых трудоёмких дел является фаззинг прошивок. Здесь и приходит на помощь фреймворк для эмуляции Qiling, названный в честь сказочного зверя Цилиня.

Qiling ведёт своё происхождение от другого мифического существа — Единорога, то есть фреймворка Unicorn, что обещает нам обилие эмулируемых архитектур (8086, X86, X86_64, ARM, ARM64, MIPS, RISC-V, PowerPC). Архитектурное разнообразие Unicorn имеет обратную сторону в виде отсутствия возможностей по работе с кодом, предполагающим запуск в операционных системах (syscalls, FS, etc.).

Здесь-то Qiling и проявляет себя во всей красе. Он не просто имеет хороший набор уже реализованных сущностей, но и предоставляет минималистичные rootfs-ы для многих наборов архитектур и операционных систем. А ещё всё это имеет реализацию на Python, что позволяет почти безболезненно дописывать что-то отсутствующее прямо "на ходу".

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

Если вы работаете в SOC, то наверняка видели, какой зоопарк библиотек и экспортируемых функций может запускать системный процесс rundll32. Согласно отчётам нашей команды MDR, это вторая по частоте (после powershell) системная компонента, которую используют злоумышленники для запуска вредоносов.

Однако угрозу можно детектировать, если определить, чего rundll32 никогда не должен запускать. Например, функции, релевантные COM-серверам. Процесс rundll32 не должен хостить COM-сервер, не должен регистрировать его.

А вот функции, которые нужны для работы с COM:

— DllGetClassObject — ключевая точка входа COM: рантайм вызывает её, чтобы получить указатель на фабрику нужного CLSID. Обязательна для DLL, которые реально создают COM-объекты.

— DllCanUnloadNow — используется Service Control Manager/COM-рантаймом для решения, можно ли выгружать библиотеку (возвращает S_OK/S_FALSE).

— DllRegisterServer / DllUnregisterServer — создают/чистят записи в реестре. Это те самые точки, которые вызывает regsvr32.

— DllInstall (необязательная) — установочные сценарии (per-user/per-machine, дополнительные шаги); вызывается только по /i.

Значит, мы можем создать хант для ловли rundll32.exe, который дергает одну из перечисленных функций — такого операционка делать не должна:

cmdline:(
"rundll32.exe" AND
(
"DllRegisterServer" OR "DllUnregisterServer" OR
"DllGetClassObject" OR "DllCanUnloadNow" OR
"DllInstall"
)
)

В 2016 году один из банков Индонезии подвергся атаке хакерской группы Lazarus. В инфраструктуре банка ИБ-эксперты нашли полный джентльменский набор этой группы: инструменты для горизонтального перемещения по корпоративной сети, клавиатурный шпион для кражи банковских данных, модуль для подключения к SWIFT, туннели для связи с управляющими серверами, вайпер для зачистки… А точкой входа для злоумышленников стал сайт банка, заражённый вредоносным скриптом.

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

И вот спустя 10 лет — очень похожая история. Разработчики децентрализованного финансового сервиса BetterBank на основе блокчейн-платформы PulseChain заказали анализ защищённости. В результате исследования протокола BetterBank была найдена уязвимость в системе начисления бонусов. При этом пентестеры показали заказчику не только PoC, но и необходимый патч.

Но заказчик не исправил уязвимость, сочтя её некритичной. Через месяц злоумышленник вывел из BetterBank активы на сумму около 5 миллионов долларов, используя именно этот косяк в архитектуре протокола. Подробности взлома — в статье нашего эксперта Эльсайеда Эльрефаэя.

Наши эксперты заметили использование злоумышленниками утилиты 3snake для кражи паролей. Расскажем, как её детектировать. Но для начала разберёмся, что она делает.

— Детект спауна целевых процессов: 3snake открывает сокет AF_NETLINK с протоколом NETLINK_CONNECTOR и подписывается на proc events (CN_PROC). Приходит событие fork/exec/exit/... и он видит новых sshd-детей и sudo. Это стандартный механизм ядра для уведомлений о процессах.

— Докопаться до процесса: 3snake делает ptrace(PTRACE_ATTACH) на подходящие PID и начинает трассировку системных вызовов. Это классическая техника, как у утилиты strace.

— Извлечение секрета: 3snake ловит входы/выходы read/readv (иногда и write/writev — чтобы синхронизироваться по промптам Password:) и читает содержимое пользовательских буферов процесса-цели (через ptrace-чтение памяти или process_vm_readv-подобные техники). Именно там оказываются введённые пользователем пароли к sshd и sudo. Это ровно то, что делают и демонстрационные приёмы со strace — перехватить read() по дескриптору TTY и прочитать байты ввода.

Важно понимать, что это не дамп всего /proc/<pid>/mem , как делает mimipenguin или linikatz. Утилита 3snake целенаправленно «подслушивает» пароли в момент их ввода.

— Модель применения: 3snake работает только с root (или с CAP_SYS_PTRACE). Не пишет в память цели, а спаунит отдельный воркер под каждый целевой процесс (ребёнок sshd, инстанс sudo).

Что детектировать:

Вызовы ptrace(PTRACE_ATTACH), где в качестве цели — один из "святых" процессов: sshd, sudo, gnome-keyring, login и т.д.

Почему это важно: никто легитимно не дебажит sshd или gnome-keyring на продакшене. А если делает — пусть объясняет.

Для получения данных о ptrace(PTRACE_ATTACH) используйте auditd, eBPF/kprobes, Tetragon, Tracee — всё, что умеет следить за sys_ptrace и скажет вам, кто target.

Дополнительно: AF_NETLINK + NETLINK_CONNECTOR — любимый способ атакующего подслушивать, когда появляется цель.

Целевые процессы, интересующие 3snake:

Аутентификация: sshd, sudo, su, passwd, login, systemd-logind, polkitd, pkttyagent, authentication*, policykit*, polkit*

Хранение секретов: gpg-agent, pinentry*, ssh-agent, ssh-askpass, ksshaskpass, gnome-keyring-daemon, kwalletd, kwalletd5

Сетевые клиенты и VPN: NetworkManager, nm-applet, openvpn, openconnect, xrdp, smbclient, mount.cifs

Сессии и экраны: gdm-session-worker, gnome-shell, lightdm-gtk-greeter, i3lock, swaylock, xscreensaver, kwin_wayland

Передача файлов и базы данных: ssh, scp, sftp, rsync, psql, mysql, mongo

Браузеры и IPC: chrome, chromium, dbus-daemon, sssd_kcm, winbindd, vino-server, Xvnc, x0vncserver

Эти цели и ищите в вашей телеметрии:

path:(
"sshd" OR "sudo" OR "su" OR "passwd" OR
"login" OR "systemd-logind" OR "polkitd" OR
"pkttyagent" OR *authentication* OR *policykit* OR *polkit* OR
"gpg-agent" OR pinentry* OR "ssh-agent" OR "ssh-askpass" OR "ksshaskpass" OR
"gnome-keyring-daemon" OR "kwalletd5" OR "kwalletd" OR "NetworkManager" OR
"nm-applet" OR "openvpn" OR "openconnect" OR "gdm-session-worker" OR
"gnome-shell" OR "sddm-greeter" OR "lightdm-gtk-greeter" OR "i3lock" OR
"swaylock" OR "xscreensaver" OR "gnome-shell" OR "kwin_wayland" OR
"ssh" OR "sftp" OR "scp" OR "rsync" OR "psql" OR "mysql" OR "mongo" OR
"mount.cifs" OR "smbclient" OR "xrdp" OR "xrdp-sesman" OR
"x0vncserver" OR "Xvnc" OR "vino-server" OR
"sssd_kcm" OR "winbindd" OR
"chrome" OR "chromium" OR
"dbus-daemon"
)

И поисключайте, конечно

отладчик_типа:(
"chrome_crashpad_handler" OR "chromium-browser" OR
"chromium-gost"
) AND
цель_типа:(
"chromium-gost" OR "chromium-browser" OR "chrome" OR
"chromium"
)

отладчик:(
"/bin/strace" OR "go/bin/dlv"
)