Данный инцидент в настоящее время активно расследуется. Информация в этом блоге основана на данных, доступных на дату его публикации, поэтому сведения о ходе расследования могут меняться.

21 сентября 2026 года агентный субъект угрозы (ATA) атаковал breached the Dutch Institute for Vulnerability Disclosure (DIVD), добровольческую некоммерческую организацию, которая находит уязвимые системы в интернете и предупреждает их владельцев. ATA получил доступ, объединив две ранее неизвестные уязвимости в платформе техподдержки Zammad, CVE-2026-102489 и CVE-2026-102490, и за считанные секунды перешел от перехвата сессии к получению прав root.

Согласно заявлению DIVD, организация заметила подозрительную активность, начала расследование и осознала, что подверглась взлому. Организация охарактеризовала ATA как «шумного и очень, очень неаккуратного», вероятно, потому что AI-агенты недетерминированы и выбирают каждое последующее действие на машинной скорости. Этот шум создает широкие возможности для обнаружения со стороны команд безопасности. Кроме того, как уже наблюдала команда Sysdig Threat Research Team (TRT) у таких ATA, как JADEPUFFER, AI-агент, стоящий за взломом DIVD, оставлял в коде комментарии, объясняющие его действия и логику. Именно этот шум позволил DIVD выявить взлом в течение дня; однако из-за скорости атаки даже этого оказалось недостаточно.

Хотя этот агент, возможно, был плохо обучен и настроен, он все же смог выполнить свою задачу, перейдя от ПО техподдержки к системе DIVD и похитив данные. Неясно, сколько подтвержденных пользователей Zammad затронуто этими уязвимостями нулевого дня, но, согласно веб-сайту компании, у нее более 2000 клиентов и 55 000 пользователей. В этом блоге подробно рассказывается о том, что нам известно о ходе вторжения и о том, как команды безопасности могут обнаруживать и отражать подобные атаки в ускоренном режиме, даже не зная CVE.

Что произошло в DIVD?

1 октября 2026 года DIVD подтвердила, что взлом привел к утечке данных. Расследование продолжается, и понимание инцидента организацией, вероятно, будет дополняться.

Приведенная ниже хронология основана на материалах дела, открытого DIVD по факту взлома и уязвимостей:

Дата

Активность

21 сентября

Злоумышленник впервые получил доступ к системам DIVD

22 сентября

DIVD обнаружила вторжение, заблокировала доступ ко всем системам в своем дата-центре и начала криминалистическое расследование совместно с Merlon Security.

22–23 сентября

DIVD проанализировала и воспроизвела уязвимости.

24 сентября

DIVD сообщила о взломе голландскому органу по защите данных и Национальному центру кибербезопасности. DIVD также публично объявила о взломе и уведомила Zammad об уязвимостях.

26 сентября

DIVD просканировала общедоступные экземпляры Zammad и начала уведомлять уязвимые организации.

29 сентября

DIVD опубликовала материалы дела и две записи CVE.

Уязвимости

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

CVE-2026-102489

Ошибка удаленного выполнения кода (RCE), затрагивающая версии с 6.3.0 по 6.5.4. Она также присутствует в версиях с 7.0.0 по 7.1.3, но не является эксплуатируемой из-за специфических условий среды. Влияние на версии до 6.3.0 неизвестно.
Классифицирована как уязвимость высокой степени опасности с оценкой CVSS 8.7. Это уязвимость с низкой сложностью эксплуатации, не требующая привилегий, и поскольку Zammad является веб-приложением, доступным из интернета, она открыта на веб-уровне и доступна через общедоступный интернет.

CVE-2026-102490

Ошибка локального повышения привилегий (LPE), затрагивающая все версии от 1.5.0 до 7.1.0-alpha.
Классифицирована как уязвимость высокой степени опасности с оценкой CVSS 8.5. Это уязвимость с низкой сложностью эксплуатации, требующая локального доступа и минимальных привилегий.

Цепочка CVE

RCE можно эксплуатировать только в версиях с 6.3.0 по 6.5.4, поэтому цепочка применима к этому диапазону.
Классифицирована как уязвимость критической степени опасности с оценкой CVSS 9.4.

Атрибуция

На момент публикации этого блога ни один оператор-человек не был связан с ATA, и ни одна группа не взяла на себя ответственность. DIVD заявила в LinkedIn, что агент читал и похищал данные, но точная цель и последствия атаки только начинают проясняться по мере того, как мы узнаем больше о украденных данных.

Плейбук агента

DIVD уже идентифицировала злоумышленника как «автономного AI-агента», и многочисленные доказательства подтверждают, что это не была кампания, управляемая человеком.

Особенности, которые отличали эту операцию:

Автономные, недетерминированные решения: цепочка атак не была заранее спланирована. Вместо этого ATA выбирал следующий шаг после каждого действия на машинной скорости.
Самодокументируемые скрипты: агент объяснял свои решения в комментариях к скрипту, что является обычной практикой для машиночитаемости. Некоторые из этих комментариев описывали действия как безвредные; например, «no phishing» (без фишинга) и «no spam» (без спама).
Самопомехи: рассылка паролей агентом нарушила его собственную атаку «человек посередине» (MitM).
Плохо выполненный путь атаки: атака была шумной и неаккуратной, но задача в конечном итоге была выполнена. Агент сделает все необходимое для завершения задачи, независимо от беспорядка, который он создает, и того, насколько он дерзок. Путь атаки и скрипты человека часто прямо противоположны: чище и скрытнее.

Этап 1: Первоначальный доступ через CVE-2026-102489

ATA получил первоначальный доступ через уязвимость нулевого дня RCE CVE-2026-102489, которую DIVD описала как перехват сессии, приведший к выполнению кода от имени пользователя службы zammad.

Что можно обнаружить?

Процесс приложения Zammad (Rails, Puma и его дочерние рабочие процессы) не должен запускать интерактивную оболочку, загружать инструменты или открывать исходящие соединения с хостами, с которыми он ранее не связывался. Если вы профилируете то, что обычно выполняет пользователь zammad, первая команда, которую запускает агент, будет выделяться. Чтобы выявить перехват сессии, проверяйте сессии, используемые с нового исходного адреса вскоре после входа в систему, а также запросы, которые пропускают ожидаемый процесс входа.

Этап 2: Повышение привилегий через CVE-2026-102490

ATA объединил вторую уязвимость нулевого дня, CVE-2026-102490, с первой и получил root-доступ для пользователя zammad.

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

Что можно обнаружить?

Сервисная учетная запись на хосте никогда не должна менять свой эффективный идентификатор пользователя на root; это высокоточный сигнал. В Linux следите за вызовами семейства setuid от пользователя zammad, новыми дочерними процессами с правами root в дереве приложения и записями в привилегированные пути от этой учетной записи. Ниже приведены правила Falco с открытым исходным кодом для повышения привилегий и оболочек, запущенных сервисными учетными записями, которые охватывают эти действия:

Запуск привилегированного контейнера
Non sudo setuid
Установка бита Setuid или Setgid
Изменение пространства имен потока
Потенциальное повышение привилегий на уровне локальной системы из-за неправильного использования переменных окружения
потенциальное повышение привилегий в sudo

Этап 3: Атаки с использованием учетных данных

Получив доступ уровня root, ATA провела атаку типа password spraying и атаку «человек посередине» (MitM), однако в настоящее время неясно, на какие именно системы или учетные записи были нацелены эти атаки. Тем не менее, из-за предположительно недостаточного уровня подготовки этого агента атака password spraying помешала его собственной MitM-атаке, что добавило шума этой конкретной операции.

Хост службы поддержки (helpdesk) обычно представляет собой концентрацию конфиденциальных данных, именно поэтому Zammad стала ценной целью. На нем хранятся учетные данные баз данных, почтовые и API-токены, а также ключи API для каждой системы, с которой работает служба поддержки. Доступ с правами root раскрывает их все одновременно.

Что подлежит обнаружению?

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

Этап 4: Доступ к данным и их эксфильтрация

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

Данные, утечка которых подтверждена: адреса электронной почты волонтеров DIVD в домене организации.
Возможно, подвергшиеся утечке данные: контактные данные волонтеров.
Точка входа с признаками компрометации: тикет-система CSIRT (включая каждое электронное письмо, отправленное в почтовый ящик CSIRT, и каждый ответ), однако DIVD полагает, что она была выгружена лишь частично. Эта информация может содержать запросы на уточнение по данным сканирования (включая IP-адреса уязвимых систем), сообщения об уязвимостях и выгрузки дампов учетных данных с замаскированными паролями.
Другие признаки компрометации: среда поддержки проектов (Jira и Confluence), а также системные данные на IT-системах, поддерживающих деятельность DIVD.
Текущие расследования: Google Workspace (офисный и административный), HR-системы, системы IT-поддержки, включая службу поддержки (helpdesk), Slack, исходный код в GitHub и GitLab, а также конфиденциальные исследовательские данные, которыми располагает DIVD, такие как списки уязвимых систем, отпечатки (fingerprints), эксплойты типа PoC, очищенные от вредоносного кода, детали уязвимостей нулевого дня и утечки дампов учетных данных.
Данные без выявленного влияния: бухгалтерская информация, банковские счета и первоначальные уведомления CSIRT.

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

Что подлежит обнаружению?

Ищите исходящие соединения из сегмента службы поддержки на адреса, с которыми она никогда не связывалась, большие или необычные объемы выгружаемых данных, а также новые инструменты, записанные в временные директории и запущенные оттуда. Политика исходящего трафика по умолчанию запрещает все (default-deny) для сегмента службы поддержки, что превращает эксфильтрацию из незаметного события в заблокированное.

Обнаружение и минимизация рисков для уязвимостей нулевого дня в Zammad и агентов ATA

Обновите Zammad или отключите его

Обновите систему до версии Zammad 7.0.0 или новее либо полностью отключите экземпляр. Эти версии неуязвимы к эксплойтам, но все еще подвержены риску ошибки повышения привилегий (LPE). Следите за бюллетенями безопасности Zammad, чтобы получить исправленную сборку, и тем временем контролируйте свою среду на предмет аномального поведения пользователя zammad, если вы не отключаете экземпляр.

Дополнительные рекомендации и индикаторы компрометации доступны здесь: https://csirt.divd.nl/cases/DIVD-2026-00015/.

Изолируйте службу поддержки

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

Сохраните улики, затем проведите поиск

Сохраните /var/log/zammad и /var/log/nginx перед пересборкой любых компонентов. Запустите script от DIVD для поиска индикаторов эксплуатации CVE-2026-102489. Чистый результат не означает чистый хост, поэтому также ищите незнакомые процессы и файлы. Относитесь к любым признакам эксплуатации как к полной компрометации хоста, поскольку злоумышленник имел доступ с правами root. Смените все учетные данные, хранящиеся на хосте или доступные с него.

Обнаружение на основе поведения, а не сигнатур

У уязвимости нулевого дня нет сигнатуры. Сервисной учетной записи, порождающей оболочку (shell), повышающей привилегии до root или обращающейся к незнакомым адресам, она и не нужна. Обнаружение на этапе выполнения (runtime detection) для повышения привилегий, оболочек в процессах приложений и аномального исходящего трафика охватывает описанные выше этапы без необходимости знать CVE.

Планируйте реагирование со скоростью работы машин

Агент, получающий права root за считанные секунды, не ждет вашей очереди тикетов. Заблаговременно разрешите автоматическое сдерживание для высоконадежных оповещений (например, завершение процесса или изоляция хоста) и отработайте сценарий отключения всего дата-центра, который использовал DIVD.

Стандарт Sysdig 555 Benchmark для обнаружения угроз в облаке и реагирования на них задает высокую планку и побуждает организации обнаруживать облачные атаки и реагировать на них быстрее, чем те успевают завершиться.

Заключение

На этот раз обошлось без кражи учетных данных. Для атаки потребовались всего две уязвимости нулевого дня и агент на базе ИИ.

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

Агенты действуют быстро, и более совершенный агент может шуметь меньше, но производимое ими поведение не меняется. Сервисная учетная запись, порождающая оболочку, процесс, повышающий привилегии до root, и незнакомые исходящие соединения выглядят одинаково независимо от того, является ли эксплойт известной уязвимостью CVE или уязвимостью нулевого дня, и является ли злоумышленник человеком или ATA.

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

Пока ваша организация готовится к защите от агентов-злоумышленников, задайте себе сегодня три вопроса:

Узнали бы вы в течение нескольких секунд, если бы сервисная учетная запись на ваших хостах породила оболочку или получила доступ с правами root?
Дошло ли бы это оповещение до человека или инициировало автоматическую реакцию до того, как ATA завершит свой следующий шаг?
Смогли бы вы отключить сегмент сети, не выводя из строя бизнес или его критически важные приложения?

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