Operation CameraSwarm: как один набор инструментов получил доступ к 14 500 камерам Dahua
18 августа 2026 года исследователи Hunt.io опубликовали разбор операции CameraSwarm. За 35 дней один оператор смог получить доступ более чем к 14 500 камерам Dahua по всему миру.
Особенность этой истории в качестве доказательной базы. Исследователи обнаружили открытый HTTP-каталог злоумышленника и скачали 2 616 файлов общим объёмом около 407 МБ. В архиве находились исходный код, журналы запусков, результаты сканирования и вспомогательные скрипты. Затем полученные данные сопоставили с собственной сетевой телеметрией.
Расследование показало: атакующий не использовал одну универсальную "магическую" уязвимость. Массовый доступ стал возможен благодаря сочетанию нескольких давно известных проблем - слабых паролей, устаревших прошивок, открытых служебных портов и особенностей P2P-инфраструктуры камер.
Как работала атака
По данным Hunt.io, оператор применял три основных сценария:
- подбор учётных данных через TCP-порт 37777 - 12 324 уникальных адреса;
- эксплуатация уязвимостей CVE-2021-33044 и CVE-2021-33045 - 1 923 устройства;
- подключение через облачный P2P-релей по серийному номеру - 283 камеры.
Всего исследователи насчитали более 14 530 потенциально скомпрометированных устройств. Наиболее масштабной частью кампании оказался именно подбор паролей: он сработал там, где владельцы сохранили заводские комбинации, использовали простые секреты или повторяли один пароль на большом количестве камер.
Первый путь: масштабный подбор паролей
Открытый служебный порт сам по себе ещё не означает успешную атаку. Однако если на нём доступен интерфейс управления, а пароль слабый или стандартный, камера становится удобной целью для автоматизированного сканирования.
Оператор CameraSwarm, судя по найденным журналам, системно проверял большие диапазоны адресов. После обнаружения доступного устройства инструменты пытались пройти аутентификацию, определить модель, получить служебную информацию и понять, какие действия доступны дальше.
Проблема здесь не только в том, что кто-то использует пароль "admin". В крупных организациях одинаковые или похожие учётные данные нередко применяют при массовой установке оборудования. В результате компрометация одной камеры может подсказать атакующему подход к десяткам или сотням других устройств.
Второй путь: две уязвимости в прошивке
CVE-2021-33044 и CVE-2021-33045 стали вторым каналом доступа. Они позволяли обходить аутентификацию на уязвимых устройствах, если камера работала на версии прошивки, где проблема ещё не была устранена.
Этот сценарий особенно опасен тем, что не требует знания корректного пароля. Атакующий может найти устройство, определить его программную версию и отправить специально сформированный запрос. Если камера не обновлена, дальнейший доступ может быть получен автоматически.
Важно понимать: наличие исправления не означает, что оно установлено. Между публикацией патча и реальным обновлением оборудования часто проходят месяцы или годы. Часть устройств находится на объектах без регулярного обслуживания, а некоторые камеры вообще не имеют понятного процесса безопасного обновления.
Третий путь: P2P-релей и устройства за NAT
Третий механизм связан с удалённым доступом через P2P-инфраструктуру. Камера за домашним или корпоративным маршрутизатором может быть недоступна из интернета напрямую, но при этом поддерживать соединение с облачным сервисом производителя.
NAT скрывает внутренний адрес устройства, однако не превращает камеру в доверенный объект. Если злоумышленник получает серийный номер, идентификатор устройства или иной необходимый параметр, он может попытаться обратиться к камере через релейную инфраструктуру.
Именно поэтому закрытые входящие порты не всегда гарантируют безопасность. При наличии исходящего соединения с внешним сервисом устройство может оставаться доступным через предусмотренный производителем удалённый канал.
Камера - часть системы, а не отдельный endpoint
IP-камера - это полноценная вычислительная платформа. В ней есть процессор или SoC, оперативная и постоянная память, загрузчик, операционная среда, сетевой стек, веб-интерфейс, видеокодеки, сервисы удалённого доступа и механизм обновления.
Firmware, то есть встроенное программное обеспечение, управляет почти всеми функциями устройства: от запуска и сетевого подключения до обработки видеопотока и обновления компонентов.
SDK содержит библиотеки, заголовочные файлы, примеры и инструменты, на базе которых производитель или OEM-партнёр создаёт программную платформу. Ошибка на уровне SDK может повториться сразу в большом количестве моделей и брендов.
Поэтому уязвимость в камере способна затронуть не только одну систему видеонаблюдения. Она может повлиять на мобильное приложение, облачную платформу, шлюзы удалённого доступа и сервисы технического обслуживания.
Почему риск не ограничивается просмотром видео
После получения доступа злоумышленник может не просто наблюдать за изображением. В зависимости от прав и конфигурации он способен менять настройки, создавать учётные записи, отключать уведомления, перенастраивать сетевые параметры и использовать камеру как точку входа в сегмент организации.
Камера также может стать источником разведывательной информации. Даже без постоянной записи видео можно анализировать повторяющиеся маршруты, время появления сотрудников, режим работы объекта и перемещения людей.
Физически устройство продолжит выполнять свои штатные функции. Оператор может не заметить вмешательства, пока копия видеопотока уже уходит третьей стороне. В этот момент камера перестаёт быть просто сетевым оборудованием с логином и паролем - она становится сенсором, который можно использовать для наблюдения и построения поведенческих моделей.
Почему одного фаервола недостаточно
Фаервол ограничивает сетевые направления, но не исправляет слабый пароль и не устраняет уязвимость прошивки. VPN повышает защищённость удалённого доступа, однако неправильно настроенный VPN может лишь перенести проблему внутрь доверенной сети.
IDS/IPS способен обнаружить подозрительную активность, но эффективность зависит от качества правил, видимости трафика и скорости реакции. Если система не получает журналы с камер и сетевых шлюзов, значительная часть событий останется незамеченной.
Нужна совокупность мер: ограничение доступности, сегментация, управление обновлениями, контроль учётных записей, мониторинг исходящих соединений и регулярная проверка конфигурации.
Что проверить в своём парке камер
1. Провести инвентаризацию
Для каждой камеры следует зафиксировать модель, серийный номер, IP-адрес, версию firmware, используемые протоколы, владельца и место установки. Отдельно стоит отметить устройства, связанные с облачными сервисами и P2P-доступом.
2. Убрать прямую публикацию служебных портов
Камеры не должны без необходимости быть доступны из интернета. Следует проверить правила маршрутизаторов, NAT, проброс портов и внешние сканируемые адреса.
3. Пересмотреть учётные записи
Нужно заменить заводские пароли, удалить неиспользуемые аккаунты и отказаться от единого секрета для всего парка. Для администраторов желательно включить многофакторную аутентификацию, если модель и система управления это поддерживают.
4. Проверить исходящие соединения
Важно знать, с какими доменами и IP-адресами связываются камеры. Неожиданные соединения, новые релейные узлы и резкое увеличение исходящего трафика требуют проверки.
5. Сегментировать видеонаблюдение
Камеры, сервер записи и рабочие места операторов должны находиться в отдельных сетевых сегментах. Доступ из видеосегмента к офисным системам следует ограничивать по принципу минимально необходимых разрешений.
6. Управлять обновлениями как программным обеспечением
Прошивку нельзя обновлять хаотично. Нужны тестовая установка, резервная копия конфигурации, контроль целостности пакета и понятная процедура отката. Устройства, которые нельзя безопасно обновить, следует включать в отдельный реестр риска.
7. Искать признаки закрепления
Проверять нужно не только версию firmware, но и новых пользователей, изменённые правила доступа, неизвестные DNS-настройки, перенастроенные сервисы, нестандартные скрипты и подозрительные задачи.
8. Подключить наблюдаемость
Журналы камер, контроллеров, маршрутизаторов и серверов записи должны собираться централизованно. Полезно отслеживать массовые ошибки входа, изменения конфигурации, перезапуски и необычные обращения к административным интерфейсам.
Российские решения: контроль или иллюзия безопасности
Локальное размещение системы не делает её автоматически защищённой. Отечественное оборудование может иметь собственные уязвимости, ошибки интеграции и проблемы с обновлениями. Смена бренда не заменяет базовые меры безопасности.
При выборе платформы следует оценивать не только характеристики матрицы и качество изображения. Не менее важны защищённый загрузчик, механизм подписи прошивок, журналирование, регулярность обновлений, возможность отключения ненужных сервисов и прозрачная процедура уведомления об уязвимостях.
Особое внимание стоит уделить цепочке поставок. Нужно понимать, кто производит SoC, кто собирает firmware, кто отвечает за SDK и кто будет выпускать исправления после завершения гарантийного периода.
Что показала Operation CameraSwarm
Главный урок кампании - массовый взлом не всегда требует сложной авторской техники. Достаточно автоматизировать поиск доступных устройств, добавить базу стандартных паролей, проверку известных уязвимостей и работу с удалённой инфраструктурой.
Слабость всей системы часто определяется самым забытым элементом: камерой на складе, старым регистратором, тестовым устройством или оборудованием, которое никто не включил в реестр.
Безопасность видеонаблюдения начинается не с выбора красивого приложения и не с установки дополнительного фаервола. Она начинается с понимания того, какие устройства существуют, кому они доступны, куда они подключаются и кто отвечает за их обновление.
CameraSwarm также показывает, что видеонаблюдение нельзя рассматривать исключительно как физическую безопасность. Это одновременно ИТ-система, источник персональных данных и потенциальный элемент критической инфраструктуры. Чем больше камер установлено в организации, тем важнее централизованное управление, контроль конфигураций и постоянная проверка фактического поведения устройств.