Держите торговых ботов, ноды или API бирж на VPS? На днях появился наглядный кейс, почему в один прекрасный день вы можете проснуться с абсолютно пустыми счетами.
Один из старейших и крупнейших хостинг-провайдеров в СНГ — FirstVDS — официально подтвердил критический взлом инфраструктуры. 17 октября 2026 года неизвестные злоумышленники десять часов подряд беспрепятственно выкачивали сырые образы дисков клиентских серверов прямо с уровня гипервизора.
Это не рядовая DDoS-атака и не взлом отдельного неаккуратного сайта. Атакующие получили доступ к узлам виртуализации, на которых работают тысячи виртуальных машин пользователей.
Что искали: кошельки, сид-фразы и биржевые API
В официальной рассылке клиентам хостер открыто признал приоритеты взломщиков: в первую очередь скрипты атакующих искали криптовалютные кошельки, seed-фразы для восстановления, приватные ключи валидаторов блокчейн-нод и API-ключи от криптобирж с правами на торговлю и вывод средств.
Если вы запускали на виртуальном сервере торгового робота, держали ноду с ключами или просто хранили скрипты автоматизации с переменными окружения .env, ваши данные с высокой вероятностью уже находятся в руках нападавших. Взломщикам даже не требовалось подбирать пароли от вашей операционной системы — гипервизор позволяет вычитать содержимое виртуального диска целиком, минуя любые барьеры внутри ОС.
1. Заводской бэкдор прямо из коробки
Первая и фундаментальная проблема таких хостингов — отношение к суверенитету клиентской системы. Берёте «чистую» свежеустановленную Ubuntu у FirstVDS — а в файле /root/.ssh/authorized_keys по умолчанию уже прописан мастер-ключ поддержки (supportAccessKey) и дополнительный служебный ключ развёртывания (root@gujegvdywx) вообще без каких-либо ограничений по исходному IP-адресу.
Служебные скрипты и сотрудники хостинга в любое время могут зайти на ваш сервер под пользователем root без вашего ведома и согласия. Большинство пользователей уверены, что надёжный пароль и отключение авторизации по паролю защищают их бота. В реальности на сервере годами работает открытый проходной двор. И если утекают мастер-ключи самого хостера, под угрозой моментально оказываются все клиентские серверы разом.
2. Дыра в гипервизоре, которую даже не смогли закрыть
Злоумышленникам не понадобилось взламывать SSH-порты отдельных клиентов. Они читали виртуальные накопители снаружи: файлы конфигураций, локальные базы данных, незашифрованные секреты ботов с ключами Binance, Bybit и OKX. Всё, что когда-либо записывалось на диск сервера, стало достоянием третьих лиц.
И главная вишенка на торте: в уведомлении для пострадавших клиентов хостер признаёт, что «уязвимость до конца не устранена, а предоставленный вендором патч не решил проблему полностью». Проще говоря: серверы продолжают обслуживать клиентов, пока критическая уязвимость в гипервизоре остаётся незакрытой.
3. Регулярные утечки и стойкий запах инсайда
Для FirstVDS это далеко не первый серьёзный инцидент безопасности. Инфраструктуру хостера и связанные с ней сервисы уже взламывали годами ранее — базы данных клиентов, паспортные данные и дампы серверов периодически всплывали на профильных теневых площадках.
Когда одна и та же компания годами наступает на одни и те же грабли, напрашиваются ровно два вывода. Первый: архитектура безопасности хостинга находится на неприемлемо низком уровне, а базовые принципы изоляции виртуализации игнорируются.
Второй вывод — ещё более тревожный. Когда злоумышленники целенаправленно и методично в течение десяти часов выкачивают именно криптокошельки, сид-фразы и биржевые API, возникает закономерный вопрос: не действовали ли нападавшие по прямой наводке изнутри самого хостинга? Списать внезапное исчезновение криптоактивов клиентов на «абстрактный внешний взлом» — слишком удобный и классический сценарий.
Что делать прямо сейчас, если вы пользовались VPS
Если у вас были запущены серверы у скомпрометированного хостера, действовать нужно без промедления:
1. Немедленно отзовите все API-ключи бирж. Зайдите в личные кабинеты бирж, удалите все существующие API-ключи, использовавшиеся на серверах, и выпустите новые с жёсткой привязкой к доверенным белым IP-адресам.
2. Переведите средства с кошельков. Если на сервере хранились сид-фразы, приватные ключи горячих кошельков или файлы keystore — эти адреса скомпрометированы навсегда. Создайте новые адреса на надёжном устройстве и выведите активы.
3. Проверьте SSH-ключи на всех серверах. Откройте /root/.ssh/authorized_keys и удалите все публичные ключи, кроме вашего собственного. Проверьте, чтобы параметр PasswordAuthentication в настройках SSH был переведён в no.
4. Пересмотрите подход к инфраструктуре. Критичные для денег задачи — торговые алгоритмы, подписание транзакций, управление нодами — нельзя доверять дешёвым виртуальным серверам общего пользования. Для таких задач подходят либо выделенные физические серверы без постороннего гипервизора над вами (Bare Metal), либо решения с локальным шифрованием и аппаратной подписью, где приватные ключи в принципе никогда не попадают на чужой диск в открытом виде.