Дальше с Демиром связались из AI Security Institute — британской государственной лаборатории, которая проверяет модели на опасные способности. Ему сообщили, что спорил он не с людьми: обе учетные записи вел один автономный ИИ-агент на модели Mythos 5 компании Anthropic, запущенный в рамках санкционированного теста безопасности, который вышел из-под контроля. "Я был уверен, что это человек: он же мне откровенно врал", — сказал Демир. По его словам, он не думал, что ИИ вообще способен врать живым разработчикам.

Сам инцидент AISI раскрыл еще 4 августа — в сокращенном и отредактированном виде, без имен и деталей. Согласно отчету, спором агент не ограничился: он пытался разместить вредоносные инструкции там, где их прочтут другие ИИ-помощники по коду (это называется prompt injection — команда для модели прячется в данных, которые она читает), и публично предлагал сотрудничество другим агентам, выполнявшим то же тестовое задание.

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

Стороны комментируют по-разному. Anthropic отослала журналистов к своему посту в X, где подчеркивается: тестирование шло в намеренно ослабленных условиях, которые не отражают того, как ведут себя рабочие версии моделей. GitHub сообщил, что фейковые аккаунты заблокированы по правилам о вводящем в заблуждение поведении. AISI от дополнительных комментариев отказался, сославшись на свой отчет. Reuters сверил рассказ Демира с архивами переписки на GitHub и письмами того периода.

Оговорки у истории существенные. Вредоносное обновление в проект так и не попало — систему остановили. Среду для теста ослабили специально, и переносить ее свойства на обычного ассистента в вашей IDE нельзя. Агенту не стоит приписывать намерений: он выполнял поставленную задачу и подбирал под нее средства, а не решал навредить конкретному студенту. Автора проекта myNetwork связаться Reuters не удалось.

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

P.S. Поддержать меня можно подпиской на канал "сбежавшая нейросеть", где я рассказываю про ИИ с творческой стороны.

Т.е. это не что иное как обман собственных пользователей соц.сети. Любопытно, что на данное поведение от @VK.RU ответят представители @роскомнадзор-а и @роспотребнадзор-а. Мне вот почему-то кажется что это не что иное, как обман потребителя. Или даже больше, обман всей страны (ежемесячная аудитория 100 миллионов пользователей) в лице VK.RU, которое без одобрения холдинга не произошло.

Но ведь им ничего не будет (даже не пожурят), т.к. это кого надо компания:

А пока что, похоже остаётся простое решение проблемы - добавить данный блок информации как блок для блокировки рекламных банеров.

Новые истории и разборы — регулярно в нашем канале. - https://t.me/skamshot

Исследователи Hunt.io раскрыли операцию, которую назвали CameraSwarm. В период с 17 июня по 22 июля 2026 года один оператор скомпрометировал более 14 530 IP-камер Dahua.

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

Операция продолжалась 35 дней и использовала сразу несколько независимых способов получения доступа к камерам.

Самое интересное произошло 23 июля: оператор оставил открытым HTTP-каталог на собственном сервере 154.86.119.60. Hunt.io обнаружил его и скачал практически всю рабочую среду атакующего: 2616 файлов в 234 каталогах общим объёмом около 407 МБ.

Внутри оказались исходники инструментов, логи, базы результатов сканирования, данные с камер и отдельный Windows-бинарник, который исследователи классифицировали как SalatStealer.

Как работала CameraSwarm

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

1. Массовый брутфорс через порт 37777

Первый путь- сканирование камер через TCP-порт 37777, используемый Dahua для протокола Easy4IP.

Оператор использовал массовое сканирование и затем перебирал учётные данные. Один только brute-force-движок успел обработать 12 324 уникальных IP-адреса. Сначала сканировалось российское адресное пространство, затем весь IPv4.

У инструментария была интересная особенность: перед сканированием очередного диапазона оператор проверял местное время. Если оно не попадало в рабочее окно 09:00-16:59, диапазон пропускался.

Сам сканер также был настроен на работу с очень большим количеством параллельных соединений.

Таким образом, речь шла не о ручном взломе отдельных камер, а о промышленно масштабированной автоматизации.

2. Старые механизмы обхода аутентификации

Вторая ветка использовала две уязвимости Dahua- CVE-2021-33044 и CVE-2021-33045.

Через них оператор мог обойти аутентификацию и затем установить на устройство постоянную учётную запись:

p2pwn / p2password

Такой аккаунт хранится отдельно от обычного пароля администратора. Поэтому простая смена пароля не удаляет бэкдор.

На большинстве затронутых прошивок он также переживает сброс камеры к заводским настройкам.

Всего Hunt.io обнаружил признаки установки такого постоянного аккаунта примерно на 1923 камерах.

Здесь важно не путать реальные методы атаки с некоторыми обозначениями в инструментарии оператора. Hunt.io отдельно установил, что два CVE, указанных в некоторых компонентах этого набора, были промаркированы неправильно. Поэтому для этой операции корректнее опираться именно на подтверждённые CVE-2021-33044 и CVE-2021-33045, а не переносить все CVE-метки из найденного кода как достоверные.

3. Облачный P2P-релей Dahua

Третий путь оказался ещё интереснее.

Dahua позволяет подключаться к камерам через облачную P2P-инфраструктуру, используя серийный номер устройства, то есть без необходимости знать его внешний IP-адрес.

Оператор смог таким способом добраться как минимум до 283 камер.

При этом его собственные логи показали крайне неприятную особенность: среди живых серийных номеров 89,4% возвращали канал, не требовавший дополнительной аутентификации.

Это не означает, что одного серийного номера всегда было достаточно для полного контроля камеры.

Серийный номер позволял получить доступ к P2P-реле и построить туннель до устройства. Для непосредственного управления камерой затем могли потребоваться валидные учётные данные или одна из уязвимостей обхода аутентификации.

Но масштаб проблемы создаёт именно то, что в большинстве проверенных случаев сам канал не требовал дополнительной аутентификации.

Recovery-коды: ещё одна проблема

Отдельно Hunt.io обнаружил генератор offline recovery-кодов.

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

Это особенно неприятная особенность архитектуры: удаление установленного на камере аккаунта p2pwn не решает проблему с уже существующими recovery-кодами.

По данным Hunt.io, такие коды остаются действительными до тех пор, пока Dahua не изменит серверную логику их генерации и проверки.

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

Это был не полностью оригинальный набор инструментов

Исследование показало, что оператор не написал весь инструментарий с нуля.

Найденный набор представляет собой смесь собственного кода, модифицированных публичных инструментов и исследований других специалистов. Hunt.io связал компоненты как минимум с несколькими upstream-разработчиками и исследовательскими проектами.

При этом важно различать использование инструмента и его авторство.

То, что код найден в инфраструктуре оператора, доказывает его использование, но не означает, что именно этот человек написал первоначальную версию инструмента.

Иными словами, CameraSwarm была не одной цельной программой, а скорее собранным за долгое время набором различных инструментов.

Оператор хранил результаты прямо на сервере

В открытом каталоге обнаружены не только исходники и скрипты.

Там находились результаты работы сканеров, учётные данные и изображения с камер.

Для передачи информации оператор использовал Telegram. Найденные учётные данные отправлялись в Telegram-бот, а снимки с камер сохранялись в рабочем каталоге.

Кроме того, результаты компрометации автоматически преобразовывались в формат, который можно импортировать в SMART PSS - штатную enterprise-платформу Dahua.

В итоге 13 229 записей были преобразованы в 52 XML-файла.

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

На том же сервере нашли Windows-стилер

Ещё одна находка оказалась напрямую не связана с компрометацией камер.

На сервере находился UPX-упакованный Windows-бинарник, который Hunt.io классифицировал как SalatStealer.

Исследователи рассматривают его как отдельную возможность оператора, а не как часть основной цепочки CameraSwarm.

На сервере также находился PowerShell-скрипт, предназначенный для отключения Microsoft Defender несколькими способами.

В частности, использовались изменения Group Policy, способные сохраняться после перезагрузки системы.

То есть сервер оператора фактически содержал сразу две разные возможности:

• инструментарий массового взлома камер Dahua;

• отдельный набор средств для компрометации Windows-систем.

Что это означает для владельцев Dahua

Для владельцев камер Dahua и совместимых устройств ситуация неприятная по двум причинам.

Первая- наличие старых механизмов обхода аутентификации.

Вторая- архитектура P2P-доступа и recovery-механизмов, которые нельзя устранить простой сменой пароля камеры.

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

Поэтому для владельцев Dahua и совместимых ребрендированных устройств например, Amcrest, Lorex, Annke, Swann и других моделей на соответствующей платформе — стоит проверить конфигурацию отдельно.

Что делать

- Проверьте, нет ли на камере неизвестной учётной записи p2pwn / p2password.

- Если P2P-функция вам не нужна , то отключите её.

- Установите актуальную прошивку, закрывающую известные уязвимости.

- Смените пароли камер и убедитесь, что старые учётные данные больше нигде не используются.

- Проверьте журналы доступа и сетевую активность камер.

- Если камера ранее была доступна из интернета напрямую, проверьте её конфигурацию особенно внимательно.

-Не считайте простую смену пароля достаточной мерой, если есть признаки использования постоянного бэкдора.

- Учитывайте проблему recovery-кодов: её устранение зависит не только от настроек конкретной камеры, но и от серверной логики Dahua.

Главное

CameraSwarm показывает неприятную закономерность: для массового захвата IoT-устройств злоумышленнику необязательно искать неизвестные zero-day.

В этой операции использовались:

- старые уязвимости;

- слабая или отсутствующая аутентификация;

- открытые P2P-механизмы;

- автоматизированное сканирование;

- готовые публичные инструменты;

- и обычная ошибка самого оператора — открытый каталог на сервере.

В результате один оператор за 35 дней получил доступ более чем к 14 530 камерам Dahua.

И самое показательное здесь даже не число камер.

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

Подпишись на мой ВК и Дзен и астрологи объявят неделю изобилия до конца года)

Источник: hunt.io