Вы восстановили взломанный Proxmox из бэкапа. А атакующий уже снова внутри

Почти детектив: как в августе‑сентябре 2026 года массово взламывали гипервизоры Proxmox VE, прятали майнеры даже от root‑а, исправляли уязвимости на захваченных серверах и возвращались после восстановления инфраструктуры.

7 сентября 2026 года хостинг‑провайдер Netfront завершил восстановление кластера из 22 гипервизоров Proxmox VE. За предыдущую неделю злоумышленники получили административный доступ к серверам, внедрили руткиты, установили майнеры и проникли внутрь клиентских виртуальных машин. Администраторы восстанавливали системы из резервных копий, меняли пароли и SSH‑ключи, проверяли целостность файлов. После нескольких суток работы инфраструктуру наконец вернули клиентам.

За время расследования выяснилось, что на серверах побывали атакующие с как минимум тридцати трёх разных внешних IP‑адресов. Одни атакующие последовательно обходили узлы кластера, другие выполняли тысячи команд, третьи устанавливали средства скрытого доступа. На части гипервизоров системные утилиты перестали нормально работать: top аварийно завершался, команды зависали, а load average достигал 160 при отсутствии соответствующей вычислительной нагрузки (более того, как позже узнали, использованный хакерами eBPF‑руткит пережил даже восстановление файловой системы командой rsync --delete — она успешно отработала, но не смогла обнаружить и удалить скрытые вредоносные файлы). В общем, администраторы Netfront не спали почти неделю, восстанавливая всё и вся.

Однако вечером 7 сентября, вскоре после объявления о восстановлении инфраструктуры, злоумышленники снова вошли в кластер. В 20:31 началась новая подозрительная активность, а в 22:22 неизвестный пользователь запросил расписание резервного копирования и сразу после этого — список виртуальных машин, для которых резервное копирование не настроено. Позднее выяснилось, что атакующие заранее создали десятки API‑токенов и дополнительные учётные записи. Эти механизмы доступа сохранились в общей конфигурации кластера и пережили восстановление всех 22 серверов.

Это не вымышленный сценарий, а опубликованный Netfront технический отчёт об инциденте 1–9 сентября 2026 года.

Уязвимость, которую случайно исправили три года назад

31 августа 2026 года на официальном форуме Proxmox появилась тема «Proxmox VE 7 is vulnerable to some type of 0day/RCE non auth». Администратор под ником pve7bug сообщил, что его четырёхлетний сервер на Proxmox VE 7 подвергся атаке с требованием выкупа. Логи были уничтожены, а доступ злоумышленников, судя по оставшимся следам, не требовал знания пароля - они буквально заходили на машину как к себе домой.

Первоначальная реакция сообщества была вполне предсказуемой. Пользователю напомнили, что Proxmox VE 7 уже два года не поддерживается и что нельзя открывать административный интерфейс в Интернет. Всё это справедливо, но не отвечало на главный вопрос: каким образом злоумышленники получили доступ к системе с единственной учётной записью root и "честно" сгенерированным паролегенератором паролем в 30+ символов?

В течение следующих суток появились аналогичные сообщения, по которым участники форума смогли восстановили механизм атаки. 1 сентября разработчики опубликовали бюллетень PSA-2026-00043-1. Выяснилось, что в пакете libpve-access-control существует критическая уязвимость обхода аутентификации CVE-2023-54391 с оценкой CVSS 9.8.

Проблема находилась в обработке параметра tfa-challenge, используемого при двухфакторной аутентификации. Уязвимый код позволял пропустить проверку пароля, а для пользователя без настроенного второго фактора отсутствовала необходимая дополнительная проверка. В результате специально сформированный запрос к API мог вернуть действительный сеанс существующего пользователя, включая root@pam. Для эксплуатации требовался сетевой доступ к управляющему API Proxmox, обычно работающему на TCP/8006, но не требовались ни пароль, ни предварительная авторизация.

Уязвимым оказался libpve-access-control версий от 7.0-7 до 8.0.4, не включая последнюю. Это соответствует Proxmox VE 7.0–7.4 и первоначальным выпускам 8.0. Причём ошибку устранили ещё в июле 2023 года, когда перерабатывали механизм двухфакторной аутентификации. Разработчики тогда не знали, что исправляют критическую уязвимость, поэтому изменения не перенесли в ветку PVE 7, которая продолжала поддерживаться до июля 2024 года.

Таким образом, в течение приблизительно года две официально поддерживаемые ветки Proxmox содержали разную реализацию критического участка аутентификации. В одной проблема уже была устранена, в другой оставалась. Публично об уязвимости узнали только спустя три года, когда её начали массово эксплуатировать.

Пострадали не только хостинг-провайдеры

Крупный провайдер может опубликовать подробный отчёт: сколько узлов заражено, когда началась атака, какие команды выполнялись и как удалось восстановиться. Но значительная часть Proxmox работает в других условиях. Это одиночные серверы небольших компаний, несколько машин в офисе или арендованный dedicated server с корпоративной почтой, 1С, базами данных и прочими внутренними сервисами. Такие инфраструктуры могут годами существовать практически без изменений: виртуальные машины исправно работают, гипервизор не требует внимания, а обновление основной версии откладывается. Ведь ради него нужно согласовать простой, иметь, чёрт побери, работающий и проверенный бэкап, проверить совместимость и предусмотреть откат. Единственный сисадмин в компании не всегда видит необходимость трогать работающую платформу.

Отдельная история — доступ к управлению. Небольшая компания арендует сервер, штатный или приходящий администратор устанавливает актуальную на тот момент PVE, создаёт виртуальные машины, задаёт root длинный случайный пароль и на этом заканчивает настройку безопасности. Межсетевой экран нередко оставляют выключенным вполне сознательно: ошибка в правилах может лишить доступа к серверу за сотни километров, а независимая консоль провайдера есть не всегда. Зачем усложнять себе жизнь, если пароль состоит из тридцати случайных символов? Через несколько лет администратор может уже не работать в компании, версия Proxmox давно не поддерживается, но TCP/8006 по-прежнему доступен всему Интернету. Именно в такой конфигурации уязвимость CVE-2023-54391 делала длину пароля совершенно несущественной.

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

Первый пострадавший, pve7bug, признался, что во время поездки временно отключил правила межсетевого экрана для удалённого доступа к Proxmox, а затем забыл вернуть их обратно. Гостевые сервисы были защищены собственными файрволами и проксированием через Cloudflare, но административный интерфейс гипервизора остался доступен извне. Пароль root был длинным, случайным и уникальным. В результате злоумышленники повредили данные и потребовали выкуп. К счастью, резервные копии сохранились, и администратор восстановил инфраструктуру уже на Proxmox VE 9.

Другой участник форума, rodrigobaldasso, сообщил о нескольких клиентах с физическими серверами OVH под управлением Proxmox VE 7.2. Все пострадавшие получили одинаковые требования выкупа. По его наблюдениям, атакующие искали смонтированные NFS-ресурсы с backup в названии и уничтожали находившиеся там данные. Точный способ проникновения установить не удалось: значительную часть журналов удалили. Строго говоря, эти случаи нельзя уверенно связать именно с CVE-2023-54391, хотя по времени и характеру они совпадают с общей волной атак.

Особенно показательно сообщение пользователя dsql от 4 сентября. Он восстанавливал системы двух клиентов, использовавших несколько виртуальных машин Ubuntu 20.04 с веб-приложениями, ботами, служебным ПО и MongoDB. Сначала атака напоминала работу шифровальщика, но при анализе выяснилось, что злоумышленники уничтожали таблицы разделов, основные суперблоки и отдельные участки виртуальных дисков, записывая поверх них случайные данные. На разрушение файловых систем уходило менее пяти минут. Однако значительная часть содержимого дисков физически сохранялась, и, используя резервные суперблоки и восстановление геометрии разделов, администратору удалось вернуть примерно 90–92% данных.

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

Есть и менее документированные свидетельства. Представитель бразильского сообщества Proxmox писал о многочисленных жалобах небольших провайдеров в местном Telegram-чате. По его словам, многие пострадавшие использовали устаревшие версии гипервизоров и плохо представляли устройство собственной инфраструктуры. Независимой статистики за этими сообщениями нет, но вряд ли небольшая компания станет публиковать технический отчёт с контрольными суммами вредоносных файлов и реконструкцией сетевых сессий. Скорее её администратор проведёт несколько бессонных ночей, восстанавливая почту и базы данных, а затем вернётся к обычной работе.

Поэтому определить действительное число пострадавших небольших инфраструктур практически невозможно. Публичные расследования показывают лишь ту часть инцидентов, о которых кто-то решил рассказать. При этом важно не преувеличивать угрозу: Proxmox, управляющий интерфейс которого недоступен из Интернета, не мог быть атакован через CVE-2023-54391 непосредственно из внешней сети. Отдельная управляющая сеть, VPN или хотя бы ограничение доступа к API доверенными адресами существенно снижают этот риск. Правда, для всего этого нужны настройка и сопровождение, а также возможность восстановить доступ при ошибке. Поэтому временное решение «пока оставим 8006 открытым» иногда переживает и администратора, который его принял.

И, разумеется, это не исключительно проблема Proxmox. Те же эксплуатационные ошибки встречаются с VMware ESXi, vCenter и Hyper-V. Различаются интерфейсы и конкретные уязвимости, но принцип остаётся прежним: административный доступ к гипервизору нельзя защищать одним только длинным паролем.

Майнер, которого не видно даже из‑под root

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

2 сентября MDSOperator опубликовал технический разбор заражения двух Proxmox VE 7.1. На обоих гипервизорах обнаружился XMRig, установленный практически одновременно — с разницей примерно в две минуты. Исполняемый файл находился в /var/lib/systemd/PVE-1, а systemd‑службы обеспечивали автоматический запуск, перезапуск и обновление майнера.

Однако главную опасность представлял не XMRig, а инструментарий вокруг него. Библиотека libhide.so загружалась через LD_PRELOAD и перехватывала системные библиотечные вызовы, скрывая процессы майнера, его файлы и сетевые соединения. Обычный ps не показывал процесс, ls и find пропускали вредоносные файлы, а ss и netstat могли не показывать подключения к майнинговому пулу. Стандартные бинарники при этом оставались неизменёнными: подменялись результаты выполнения операций, а не сами утилиты.

На серверах дополнительно обнаружили отдельный SSH‑бэкдор. В конфигурации sshd появился блок Match User root, использовавший AuthorizedKeysCommand для получения ключа злоумышленника из скрытого файла. Это означало, что даже полное удаление XMRig и связанных systemd‑служб не лишало атакующего доступа к гипервизору.

Журналы системной аутентификации были уничтожены или перенаправлены в /dev/null, журналирование отключено, а временные метки некоторых файлов подделаны. Важную роль при расследовании сыграло время создания файлов в файловой системе: оно противоречило изменённому mtime и позволило восстановить последовательность установки вредоносного ПО.

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

Злоумышленники исправляют уязвимость, чтобы никто другой не проник

17 сентября финский провайдер Pulsed Media обнаружил аналогичную кампанию в собственной инфраструктуре. По результатам расследования были скомпрометированы 12 гипервизоров, а первоначальное проникновение датировалось 31 августа. Технический отчёт опубликовали 20 сентября.

Исследователи изучили XMRig 6.26.0, загрузчик, руткит, скрипты восстановления и дополнительные средства удалённого управления. Майнер маскировался под PVE-1, а связанные с ним systemd‑службы имитировали штатные компоненты Proxmox. Вредоносное ПО имело несколько независимых механизмов закрепления и могло автоматически восстанавливаться после удаления отдельных компонентов.

Но самой неожиданной находкой оказался изменённый файл /usr/share/perl5/PVE/AccessControl.pm. Злоумышленник добавил в него проверку, устранявшую CVE-2023-54391, то есть самостоятельно исправил ошибку, благодаря которой получил административный доступ.

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

Такое поведение меняет привычную логику реагирования. Уязвимость может быть уже исправлена, а сервер — продолжать работать на злоумышленника. Более того, если удалить майнер, восстановить оригинальный пакет libpve-access-control из репозитория неподдерживаемой ветки и не выполнить полноценное обновление, можно снова сделать систему уязвимой.

Pulsed Media описал и изменение самой кампании. С 9 сентября злоумышленники начали использовать другой майнинговый пул, TLS‑соединения через порт 443 и новую схему идентификации серверов. В качестве имени worker майнер стал передавать реальный hostname заражённой машины.

Эта особенность помогла исследователям оценить масштабы операции.

Сколько серверов действительно заразили

На 17 сентября 2026 года Pulsed Media обнаружил в статистике майнинговых пулов 1123 уникальных идентификатора workers. Они были связаны с адресами Monero, используемыми исследованным вредоносным ПО. Среди имён преобладали названия, характерные для Proxmox‑хостов, в том числе размещённых в сетях OVH, Hetzner, Contabo, Strato и Hivelocity.

По данным того же исследования, пул принял 23 008 168 valid shares, а злоумышленникам было выплачено 3,6434 XMR. Ещё 0,5901 XMR числились начисленными, но не выплаченными. Важнее самих сумм то, что удалось связать активность майнеров с конкретной исследованной кампанией.

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

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

Другие опубликованные инциденты дают подтверждённые, но значительно меньшие числа: 22 гипервизора Netfront, 12 гипервизоров Pulsed Media, два сервера MDSOperator и ещё несколько отдельных случаев из обсуждений на форуме. Суммировать их с 1123 идентификаторами некорректно: выборки могут пересекаться, а некоторые сообщения не содержат достаточных данных для независимой проверки.

9 сентября SANS Internet Storm Center также зафиксировал увеличение сканирования TCP/8006 и попыток подбора паролей к Proxmox. Это дополнительное свидетельство повышенного интереса атакующих, но не показатель успешных компрометаций.

По состоянию на 16 октября 2026 года мне не удалось найти опубликованную оценку общего количества заражённых PVE‑хостов, более полную и достоверную, чем исследование Pulsed Media. Поэтому утверждать, что за последние полгода количество атак выросло в несколько раз, было бы преждевременно. Подтверждена масштабная автоматизированная кампания августа‑сентября; её фактический охват остаётся неизвестным.

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

Почему восстановление файлов в Netfront не устранило компрометацию

История Netfront примечательна не только масштабом: она показала два принципиально разных механизма, благодаря которым вредоносное ПО пережило восстановление.

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

Для восстановления администраторы использовали команду rsync -aHAX --delete, копируя доверенную резервную копию поверх существующей файловой системы. Однако rsync определяет лишние файлы в каталоге назначения путём его перечисления. Когда руткит скрывает свои файлы от getdents, программа просто не получает информации об их существовании, а значит, не удаляет их.

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

Второй механизм оказался связан с архитектурой кластера Proxmox. Общая конфигурация хранится через pmxcfs и доступна в /etc/pve; она автоматически синхронизируется между узлами. Для сохранения работоспособности кластера администраторы не восстанавливали этот каталог как обычную файловую систему каждого узла.

Именно там находились созданные злоумышленниками учётные записи и API‑токены. При последующей проверке обнаружили 42 API‑токена root@pam, из которых 41 использовался для успешной аутентификации, а также десять посторонних учётных записей. Восемь этих записей вообще не использовались: их оставили как резервные механизмы доступа.

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

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

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

Как проверить свои гипервизоры

Для первичной проверки стоит начать с версии пакета libpve-access-control, а не только с версии самого Proxmox. Актуальный релиз PVE и версия уязвимого компонента не всегда совпадают напрямую.

pveversion -v
dpkg-query -W libpve-access-control
dpkg -V libpve-access-control

systemctl list-unit-files --all | grep -Ei 'PVE-1'
test -s /etc/ld.so.preload && echo "CHECK: ld.so.preload"

for b in top htop w who uptime; do
    command -v "$b" >/dev/null || echo "MISSING: $b"
done

sshd -T -C user=root,host=localhost,addr=127.0.0.1 |
    grep -i authorizedkeyscommand

command -v bpftool >/dev/null &&
    bpftool map show |
    grep -E 'protected_pids|hidden_filename|ghost_files'

Первые команды проверяют версию и целостность пакета авторизации. Последующие ищут отдельные индикаторы описанных кампаний: замаскированные systemd‑службы, вмешательство через LD_PRELOAD, исчезновение штатных программ, нестандартный SSH‑бэкдор и характерные eBPF‑карты.

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

Обязательно нужно проверить административных пользователей, API‑токены, ACL и SSH‑ключи, сверив их с собственным реестром разрешённых доступов. Особого внимания заслуживают токены Proxmox: их наличие не устанавливается одним только просмотром списка пользователей.

Если имеются подтверждённые признаки root‑компрометации, простой apt upgrade, удаление майнера или переустановка нескольких пакетов не возвращают доверие к гипервизору. Надёжный путь — восстановление из доверенной среды на поддерживаемой версии Proxmox, полная ревизия общей конфигурации кластера и проверка гостевых систем.

Для предотвращения повторения такой истории административный API должен находиться в отдельной управляющей сети или за VPN, с дополнительным ограничением источников доступа. Нужны двухфакторная аутентификация, внешнее журналирование и независимый мониторинг физических гипервизоров. Резервные копии следует хранить так, чтобы захвативший root на PVE не мог их изменить или уничтожить.

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

Российские реалии: переход на собственные серверы после «облачных хлопков»

Недавние прилёты в ЦОДы крупных облачных провайдеров вновь сделали популярной идею возврата к собственным и арендованным физическим серверам. Это вполне рациональный выбор для стабильных нагрузок: зачастую он позволяет заметно снизить затраты, получить предсказуемую производительность и самостоятельно определить архитектуру отказоустойчивости. Ну и уменьшает цель для налёта, чего уж греха таить.

В качестве платформы виртуализации в такой ситуации многие рассматривают Proxmox VE. Он предоставляет KVM, LXC, кластеризацию, поддержку различных систем хранения, резервное копирование и удобную административную панель. Для небольших компаний это возможность получить полноценную инфраструктуру без существенных лицензионных затрат.

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

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

Речь не о том, что собственные серверы опаснее облака. Просто при переходе на них нужно различать три вещи: доступность оборудования, сохранность данных и безопасность управления. RAID, кластер из трёх узлов и ежедневный бэкап решают разные задачи и не заменяют друг друга.

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

В общем, одной фразой: PVE вполне себе вариант, но не забываем про предохранение! Других гипервизоров, кстати, это касается чуть ли не в большей даже степени.

Заключение

Самая неприятная подробность этой истории — не сама CVE-2023-54391. Критические ошибки аутентификации встречались и в других платформах виртуализации, гораздо интереснее оказались действия злоумышленников после получения доступа.

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

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

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

Все ваши виртуальные машины могут работать совершенно нормально. Просто вы уже не единственный, кто управляет сервером.

Основные источники

• Proxmox Security Advisory PSA-2026-00043-1 — описание уязвимости, версии пакетов и история исправления.

• Proxmox Support Forum — обсуждение массовых компрометаций — свидетельства отдельных администраторов и материалы расследований.

• MDSOperator — технический анализ XMRig, rootkit и SSH‑бэкдора — исследование двух заражённых гипервизоров.

• Pulsed Media — расследование майнинговой кампании — вредоносный инструментарий, исправление CVE атакующим и 1123 идентификатора майнеров.

• Netfront — отчёт о компрометации кластера из 22 узлов — хронология атак, восстановление и повторная компрометация.

• SANS Internet Storm Center — Scans for Proxmox Servers — наблюдения увеличения сканирования административных интерфейсов Proxmox.