purple shift

Говорят, импортозамещение идёт полным ходом: за 2025 год доля отечественных систем управления ресурсами предприятия (ERP) на российском рынке достигла 75%. И основную часть этих ERP-проектов (около 80%) составляют решения компании 1С.

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

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

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

2. В результате ещё одной мисконфигурации злоумышленник может увидеть на панели входа в 1С раскрывающийся список пользователей базы, что упрощает дальнейшее развитие атаки. Такая открытость имён пользователей происходит потому, что при добавлении нового пользователя в базу 1С по умолчанию выставляется флаг «Показывать в списке выбора».

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

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

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

Об этих и других опасных косяках в настройке 1C, а также о том, как исправить их, пока вас не поломали — читайте в статье Алины Сухановой "По следам реальных атак: как можно было избежать компрометации 1C".

Как вы могли заметить, наши "красные" регулярно создают полезные инструменты (BFScan, UnUnicode, Collab2, osmo-nidc, разные штуки для Mythic). Вот и сегодня расскажем, как мы улучшили работу с модулем Hive для коллаборации пентестеров на платформе Hexway Pentest Suite.

Приложение Hive позволяет собирать в одном месте результаты сканов, заметки, скриншоты и другую инфу о сервисах. А ещё мы используем Hive для того, чтобы отслеживать план работ: отмечать, что уже проверено, на что стоит обратить внимание, и кто из команды какой сервис смотрит сейчас. Это позволяет не выполнять проверки дважды (или больше раз, если в проектной команде много пентестеров и каждый хочет запустить условный ffuf со словарем raft-large-directories-lowercase.txt), а также фильтровать сервисы по статусам.

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

У компании Hexway есть библиотека на Python для работы с Hive REST API, но она давно не обновлялась. Однако в документации описано, как получить спецификацию OpenAPI.

В итоге мы написали утилиту scan2hive, которая парсит результаты работы разных инструментов и загружает в Hive. Вот что делают её модули:

HTTPX. Парсит результат httpx в формате JSON, добавляет к портам тег и заметку вида:

httpx result:
url: {url}
title: {title}
webserver : {webserver}
tech: {tech}
final_url: {final_url}

Удобно пролистывать список портов и сразу понимать, что это за сервис. Для поиска можно использовать фильтр по заметке, например, note == '%nginx%'.

Nmap. Модуль для импорта результатов nmap и masscan (формат XML). В веб-интерфейсе Hive есть возможность импорта файлов с результатами работы этих утилит, но мы добавили несколько фич:

— Если на хосте больше 300 портов (можно число задать параметром -m), то порты не импортируются (используем для отсетивания false positive) и к IP-адресу добавляется заметка:

  if len(host.ports) > self._max_ports:
    host.notes.append(HiveLibrary.Note(text=f"{len(host.ports)} ports. No port will be imported"))
    logger.info(f"Host {host.ip} has {len(host.ports)} open ports. Skip ports.")
    host.ports = list()

— К каждому порту добавляется тег.
— Результаты скриптов можно добавить в заметки или проигнорировать их (параметр --script-parsing). По умолчанию данные добавляются в Records, как и при импорте из веб-интерфейса.

Nuclei. Из формата JSON или JSONL забирает template_id, severity (можно указать параметр --min-severity), description, extracted_results, matched-at и matcher-name и добавляет заметку к порту (по одной заметке на severity). Можно игнорировать часть шаблонов.

Gowitness. Может импортировать скриншоты (по умолчанию без скринов, можно выбрать все или только для ответов 200 ОК) и добавлять заметку с данными из базы:

gowitness result:
url: {url}
response_code: {response_code}
title: {title}
webserver : {webserver}
final_url: {final_url}
tech: {tech}
cookies: {cookies}

Poseidon. Парсит json с результатом таски в агенте poseidon C2 Mythic.

В теге мы обычно указываем IP, с которого обращались к хостам, что помогает составить карту сети на внутреннем пентесте или, например, понять, что какие-то сервисы доступны только из конкретной страны. Для того, чтобы проверить, как распарсится файл, можно использовать режим --dry-run, а для загрузки в Hive использовать режим --upload.

А в /tests мы добавили сгенерированные скриптом результаты сканов nmap и masscan, чтобы не тестировать на данных заказчиков.

Февраль в ИБ начался с громкой истории о компрометации инфраструктуры обновлений популярного редактора Notepad++. Злоумышленники в течение нескольких месяцев имели доступ к центру обновлений Notepad++ и раздавали оттуда кастомное вредоносное ПО специально выбранным жертвам.

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

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

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

— проверить, использовался ли в ваших системах инсталлятор NSIS, который применялся на первом этапе во всех указанных атаках; выявить это можно по системным логам, показывающим создание директории %localappdata%\Temp\ns.tmp,
— поискать в логах сетевого трафика обращения к сервисам на экзотическом домене temp[.]sh. Это очень нетипичное поведение для корпоративных систем, зато очень типичное для обращений к С2, которые использовались в данных атаках.

Что ещё может увидеть SOC?

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

А для выявления именно этой атаки с подменой обновлений Notepad++ рекомендуем:

— Проверить, обращался ли процесс gup.exe (обновлятор Notepad++) к нетипичным адресам, помимо notepad-plus-plus.org, github.com и release-assets.githubusercontent.com. Любые другие домены или IP в запросах обновления — это тревожный сигнал.
— Если есть соответствующие журналы, можно проверить, что именно качал и запускал gup.exe. Появление процесса-ребёнка gup.exe с именем update.exe или AutoUpdater.exe, тем более во временной папке пользователя — явный индикатор атаки.

Год назад мы рассказывали, как учётные данные тысяч клиентов Fortinet утекли в Интернет благодаря уязвимости в системе аутентификации. И вот опять защитные системы той же компании оказались не очень защитными.

В декабре 2025 года были обнаружены две уязвимости CVE-2025-59718 и CVE-2025-59719 для обхода аутентификации в продуктах Fortinet с использованием механизма single sign-on (SSO) и учетной записи FortiCloud. Эти уязвимости позволяли атакующим пройти аутентификацию с помощью специально подготовленного SAML-пакета, который отправляется в FortiOS, FortiWeb, FortiProxy, или FortiSwitch Manager, если на устройстве включен функционал SSO.

Аналогичные атаки с обходом SSO-аутентификации наблюдались у клиентов Fortinet и в январе. Это была уже новая уязвимость CVE-2026-24858, и она тоже позволяла злоумышленнику с учёткой FortiCloud логиниться в чужие аккаунты FortiOS, FortiManager, FortiAnalyzer, FortiProxy и FortiWeb.

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

Компания Fortinet отключила аутентификацию через FortiCloud SSO для уязвимых версий продуктов. Клиентам рекомендуется обновить эти продукты до исправленных версий, тогда SSO- аутентификация снова заработает. Можно и самостоятельно отключить SSO в ваших продуктах – на случай, если вскоре найдётся и четвёртая уязвимость того же рода.

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

Помимо IOCs, атака выявляется по характерным действиям после проникновения в систему: это экспорт системной конфигурации и создание административной учетной записи для закрепления.

С продуктов Fortinet можно собирать телеметрию для детектирования этой вредоносной активности:
— данные по учетной записи, IP-адресу и методу аутентификации есть в событиях аутентификации (FTNTFGTmethod=sso или method=sso),
— информацию о создании административной учетной записи (msg=”Add system.admin …”),
— информацию об экспорте конфигурации (msg=”System config file has been downloaded by user …”).

А ещё в январе, почти одновременно с атаками на Fortinet, злоумышленники скомпрометировали другой ИБ-продукт: вредоносное ПО распространялось через сервер обновлений антивируса eScan. Мораль: мониторить нужно все продукты, включая и те, что призваны обеспечивать безопасность.

Фреймворк Mythic остаётся одним из ключевых инструментов в арсенале пентестеров. Модульная архитектура, контейнерный деплой и удобный веб-интерфейс делают его практичным выбором для операций Red Team. В наших предыдущих постах мы уже разбирали тонкости этого фреймворка, от развёртывания до OPSEC-нюансов.

Защитники тоже знают Mythic не понаслышке: его артефакты достаточно характерны, чтобы выстраивать эффективное детектирование. Исторически агенты Mythic чаще выходят в сеть по каналам HTTP(S). Это универсально, но предсказуемо: современные средства защиты, от TLS-инспекции до поведенческого анализа, хорошо ловят подозрительный веб-трафик.

В частности, наши коллеги недавно опубликовали подробный разбор сетевых признаков Mythic с конкретными паттернами и артефактами в трафике; по сути, это готовое настольное руководство для SOC-аналитиков.

Но что если перейти на другой транспорт? Поддержка TCP даёт пространство для маневра. Вместо HTTP-заголовков и типовых TLS-рукопожатий получаем L4-сессии с настраиваемым фреймингом.

Однако надо помнить, что это не «невидимость», а другая поверхность детектирования. Веб-паттерны исчезают, но остаются признаки на egress-контролях и по L4-поведению. Плюс появляется возможность тонко настраивать протокол обмена, удерживать устойчивые сессии для туннелирования и снижать задержки при выполнении команд.

Наша красная команда продолжает вносить свой вклад в развитие удобных пентест-инструментов: реализация нативного TCP-транспорта для агента Xenon уже добавлена в основную ветку проекта. Теперь пентестеры получают дополнительный канал связи с гибкими настройками подключения и поддержкой типовых функции Mythic — управление задачами, передача файлов, проброс портов через новый транспорт.

Важно: TCP в случае Xenon используется прежде всего как P2P/Link-транспорт внутри сети; внешний egress в большинстве сценариев по-прежнему обеспечивает агент HTTP/WS.

Что делать защите?

Для синей команды переход Mythic на TCP-транспорт — это сигнал обновить методологию.

Рекомендуем:
— пересмотреть правила мониторинга сетевого трафика,
— добавить корреляции между сетевыми соединениями и активностью процессов,
— проверить применение egress-политик в сегментах без веб-прокси,
— расширить охоту по L4-поведению.

Вот интересная ситуация: аналитик SOC получает алерт, указывающий на запуск какого-то подозрительного сервиса. Однако имя процесса говорит о том, что это легитимный системный процесс (см. первую строчку скриншота). Поэтому аналитик игнорирует алерт.

И зря. Если внимательнее изучить дополнительные данные, можно обнаружить, что на самом деле был запущен инструмент для туннелирования, который замаскирован под системный процесс. Подозрение аналитика должны были вызвать такие действия, как переименование процесса и его размещение в папке system32.

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

А вот другой пример: некое правило детектирования часто даёт ложноположительные срабатывания (FP). Привыкнув к этому, аналитик SOC закрывает очередной алерт, не проявив к нему должного внимания... а это была реальная атака.

Это ещё одно известное когнитивное искажение, которое свойственно рассуждениям по аналогии. Оно тоже закреплено в народной культуре – в виде истории про мальчика, который слишком часто кричал в шутку "волки, волки!"

Наш коллега, аналитик SOC Таха Хаким, собрал в своей статье примеры таких стереотипов мышления и «слепых пятен», характерных для специалистов по кибербезу. А также предложил ряд методов, позволяющих аналитикам выявлять подобные предубеждения и косяки в своей логике.

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

Подробнее – в статье "Человеческий фактор в кибербезе: когда враг — наше собственное мышление"

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

В 2025 году появилось несколько новых атак, позволяющих это сделать. Летом мы рассказывали о техниках с использованием уязвимого драйвера (BYOVD). А осенью исследователи из Zero Salarium обнародовали метод отключения Windows Defender без всякого дополнительного ПО — через символическую ссылку (symlink).

Как устроена атака:

Windows Defender хранит свою исполняемую часть в такой папке:

%PROGRAMDATA%\Microsoft\Windows Defender\Platform\[номер_версии] 

Каждый раз, когда Defender обновляется, создаётся новая подпапка с номером версии, и служба Defender запускается именно из неё.

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

Это приведёт к тому, что после успешной подмены пути Defender начинает использовать файлы из папки под контролем атакующего, что позволяет:

— внедрять свои библиотеки (DLL sideloading);
— исполнять произвольный код в контексте службы Defender;
— изменять или удалять исполняемые файлы Defender;
— просто ломать работу Defender (удаление символической ссылки делает невозможным запуск службы MS Defender).

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

1) Скопировать последнюю версию Defender из Platform в другую папку — допустим, в C:\temp\999

2) В каталоге Platform создать символическую ссылку с именем, соответствующим более поздней версии (например, для текущей версии 4.18.25020.1009-0 дать название 5.18.25020.1009-0). Для этого выполнить команду:

mklink /D "C:\ProgramData\Microsoft\Windows Defender\Platform\5.18.25020.1009-0" "C:\temp\999"

3) Перезагрузить Windows.

После перезагрузки будет использоваться якобы новая версия Defender, обновятся абсолютные пути в реестре, которые через символическую ссылку будут указывать на директорию C:\temp\999. Удаление этой ссылки приведет к тому, что Defender перестанет запускаться.

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

Поскольку создание символических ссылок не логируется системой, нужно выявлять их создание, отлавливая командные строки с аргументами mklink, New-SymLink, symboliclink и директорией \Windows Defender\Platform\

В конце года все подводят итоги, и мы решили не отставать: выбрали топ-10 постов нашего канала, набравших наибольшее число лайков в 2025 году.

Авторы этих исследований, утилит и полезных ИБ-советов будут конечно же награждены! Ну а вы, дорогие читатели, можете проверить, все ли наши топовые истории вы читали:

[1] Pentest Awards, третье место в номинации "Пробив инфраструктуры" (описание кейса)

[2] Плагин UnUnicode для преобразования JSON с экранированными символами в удобочитаемый формат

[3] Исследование безопасности интерфейса RPC

[4] Использование скрытых и односимвольных файлов в атаках на Linux

[5] Обещание исследования безопасности протокола Zigbee (и отдельным постом — результаты исследования)

[6] Pentest Awards, приз Top-10 в номинации "Пробив инфраструктуры" (описание кейса)

[7] Критическая уязвимость в HashiCorp Vault

[8] Утилита ParseJsonWithSDDLs для проверки прав в списках контроля доступа DACL

[9] Как разговаривать с воздухом, не привлекая внимания санитаров

[10] Как извлекать секреты из реестра Windows, не привлекая внимания EDR

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

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

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

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

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

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

Уязвимость 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как ловить?

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

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

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

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

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

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

Продолжаем рассказывать поучительные истории из практики нашей «красной команды». Во время недавнего пентеста мы столкнулись с интересной 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.

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