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

В конце года все подводят итоги, и мы решили не отставать: выбрали топ-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

Предполагается, что 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\

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

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

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

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

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

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

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

Подробнее – в статье "Human factor in cyber defense: when the enemy is our own mindset"

Фреймворк 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-поведению.

Год назад мы рассказывали, как учётные данные тысяч клиентов 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. Мораль: мониторить нужно все продукты, включая и те, что призваны обеспечивать безопасность.

Февраль в ИБ начался с громкой истории о компрометации инфраструктуры обновлений популярного редактора 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, тем более во временной папке пользователя — явный индикатор атаки.

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

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

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

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

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

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

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

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

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

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

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

После получения повышенных привилегий на хосте злоумышленники установили Velociraptor, указав в server_urls свой C2-сервер. С этого момента дальнейшее управление системой осуществлялось уже через него.

После базового Discovery они скачали Visual Studio Code (Insiders) и установили VS Code Tunnel в режиме Install as a service. Важно понимать, что под капотом это не «настоящий сервис», а запись в Run-ключе:

HKU\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Run

Далее — ещё немного Discovery, но уже через VS Code Server, и следующим шагом появляется Cloudflare Tunnel.

Однако и этого атакующим оказалось недостаточно: финальным штрихом стал Zoho Assist в режиме Unattended Remote Session, позволяющий подключаться к системе без какого-либо подтверждения со стороны пользователя.

Итог: четыре независимых канала удалённого доступа к одному хосту. При этом три из них — Velociraptor, VS Code Tunnel\Server и Zoho Assist — встречаются не так уж часто.

Что здесь можно детектировать?

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

— VS Code Tunnel. Обращайте внимание на установку сервиса, будут примерно такие команды:

    code-insiders.exe tunnel --accept-server-license-terms service install
    code-tunnel.exe tunnel service uninstall 

Также смотрите на Run-ключ:

    key: Visual Studio Code - Insiders Tunnel
    value: ...\code-insiders.exe --verbose --cli-data-dir C:\Windows\system32\config\systemprofile\.vscode-insiders\cli tunnel service internal-run --log-to-file C:\Windows\system32\config\systemprofile\.vscode-insiders\cli\tunnel-service.log

И ещё обращайте внимание на активность от процессов VS Code Server, расположенных по пути .vscode\cli\servers\ или .vscode-insiders\cli\servers\.

— Cloudflare Tunnel. При старте/остановке сервиса и запуске туннеля генерируется EventID: 1 в журнале Application (Source: Cloudflared) — это удобная точка для алертов.

— Zoho Assist. Для его использования в режиме Unattended требуется запуск сервиса Zoho Assist – Unattended Support, реализованного в файле ...\ZohoMeeting\UnAttended\ZohoMeeting\ZohoURSService.exe.

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

В одном из инцидентов злоумышленник модифицировал конфигурацию веб-сервера Apache так, чтобы все запросы, поступающие на URL-адрес https://[имя домена]/proxy/tunnel, проксировались на внутренний адрес 127.0.0.1:8080, с использованием протокола WebSocket Secure. Данный протокол предоставляет двунаправленную шифрованную связь между клиентом (атакующим) и сервером. Содержимое файла конфигурации веб-сервера Apache выглядело так:

<VirtualHost *:443>
    ...
    <Location "/proxy/tunnel">
         ProxyPass "wss://127.0.0.1:8080"
     </Location>
</VirtualHost>

А на порту 8080 для создания канала связи злоумышленник запустил утилиту chisel в качестве сервера, ожидающего входящих соединений, с параметром –reverse.

Эти действия позволили злоумышленнику создать туннель и получить доступ к внутренней инфраструктуре, маскируя сетевую активность под легитимный шифрованный HTTPS-трафик.

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

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

— отслеживать изменения файлов конфигурации веб-сервера Apache и проверять их на наличие строк «ProxyPass» и «wss://»,

— мониторить запуски процессов с подозрительными аргументами (например --reverse, --socks5),

— выявлять в журналах веб-приложений аномальное количество обращений к URL-адресам, не предусмотренных в логике веб-приложения.

Также рекомендуется размещать публично доступные серверы в отдельном сегменте (DMZ) и мониторить активность на них средствами EDR.

Как вы наверняка помните, недостаток котиков в нашей ленте мы обычно компенсируем другими животными — из ежегодных отчётов наших команд MDR и Incident Response (2023 год, 2024 год).

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

Вот например, наш коллега Сергей Солдатов решил посмотреть, как в разные годы (2020-2025) распределялись по отраслям разные типы высококритичных инцидентов (социальная инженерия, человекоуправляемые атаки, атаки ВПО).

В частности, на диаграмме выше показано количество человекоуправляемых атак в разных сферах. Можно заметить всплеск таких атак на Госсектор и Телекомы в 2021 году. А в 2022 году сильно досталось средствам массовой информации — при том, что в 2020 и 2021 годах интерес атакующих к СМИ отсутствовал вовсе.

Однако следует ещё раз уточнить, что данный график отражает только один тип атак — но есть и другие. Так, в 2025 году значительно выросло число критичных инцидентов типа «социальная инженерия» в таких отраслях, как СМИ, Госсектор и Финансы. А поскольку за успешным фишингом обычно следуют более разрушительные типы атак, мы получаем очень неутешительный прогноз для этих отраслей.

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

За последние несколько лет рынок наполнился огромным количеством новых процессорных чипов из Поднебесной — в частности, на базе стандарта RISC-V, со своими собственными реализациями ядер и расширениями.

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

Поэтому пришлось:

— пройти квест по определению, что это за инструкции; оказалось, что они относятся к расширению P Extension (оно же Packed SIMD Extension);

— на основе раннего черновика спецификации P Extension написать декодер для этих инструкций и подружить его с IDA Pro;

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

Подробности этого приключения по улучшению инструментария — в статье "От скалярной тоски к SIMD-эйфории: как подружить IDA Pro с инструкциями RISC-V P Extension".