Как мы обезвредили Kinsing: кейс по борьбе с криптоджекером на Linux-сервере

Как мы обезвредили Kinsing: кейс по борьбе с криптоджекером на Linux-сервере

Введение: тихая угроза, которая съела все ресурсы

Привет, на связи Максим из DO DIGITAL, рассказываю о разработке.

В конце июня 2025 года к нам обратился клиент с необычной проблемой: его сервер на Digital Ocean работал нестабильно, база данных PostgreSQL периодически "падала", а потребление процессора зашкаливало даже в периоды минимальной нагрузки. При первом же анализе мы обнаружили процесс с подозрительным названием kinsing — и это стало началом операции по обезвреживанию одного из самых коварных майнеров-вымогателей для Linux-систем.

В телеграм-канале ICE breaker @rakestep еще больше реальных кейсов

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

Что такое Kinsing и почему он опасен?

Kinsing — это sophisticated-вредонос, нацеленный преимущественно на Linux-серверы и контейнерные среды (Docker, Kubernetes). Написанный на Go, он сочетает в себе функции криптоджекинга, распространения по сети и сокрытия своей деятельности.

Основные возможности Kinsing:

  • Майнинг криптовалюты (обычно Monero) с потреблением до 99% ресурсов CPU
  • Саморепликация и распространение через уязвимости в ПО
  • Взлом через слабые пароли SSH и неправильно сконфигурированные сервисы
  • Установка руткитов для сокрытия процессов и файлов
  • Удаление конкурирующих майнеров и отключение систем безопасности

В 2025 году ущерб от киберпреступности достиг 9 трлн долларов, причем каждая вторая российская компания сталкивалась с инцидентами информационной безопасности. Атаки программ-вымогателей выросли на 35% по сравнению с предыдущим годом

Детектирование: как мы обнаружили угрозу

Первым сигналом стали аномалии в работе PostgreSQL. В логах базы данных появились ошибки, которых раньше не наблюдалось:

2025-06-30 09:08:54.668 UTC [235579] FATAL: database "telegram_bot_db" does not exist 2025-06-30 09:08:54.779 UTC [235571] ERROR: permission denied to alter role

Клиент сообщал о непонятной нагрузке на сервер и периодических отказах в работе приложения. Наш первоначальный анализ выявил несколько подозрительных процессов:

ps aux | grep kinsing do-agent 423336 0.0 0.6 708620 12152 ? Sl Jun28 0:37 /tmp/kinsing

Дальнейшее исследование показало, что злоумышленники использовали уязвимость в настройках PostgreSQL для получения первоначального доступа к системе. База данных была сконфигурирована с параметром trust для локальных подключений, что позволило атакующему выполнять произвольные команды от имени пользователя postgres.

Ликвидация: поэтапный план обезвреживания

Мы разработали многоэтапную стратегию ликвидации угрозы:

1. Немедленное сдерживание

  • Изолировали зараженный сервер от остальной инфраструктуры
  • Заблокировали исходящие соединения на портах, используемых майнером
  • Приостановили работу уязвимых сервисов

2. Глубокий анализ и удаление

  • Выявили и удалили все компоненты Kinsing:
  • Основной бинарник в /tmp/kinsing
  • Файлы конфигурации в /var/tmp/ и скрытых директориях
  • Модификации в /etc/ld.so.preload для сокрытия процессов
  • Cron-задачи для persistence
  • Просканировали систему на наличие бэкдоров и руткитов

3. Восстановление и усиление защиты

  • Восстановили базу данных из последней чистой резервной копии
  • Обновили все системные пакеты и приложения
  • Пересмотрели настройки безопасности:Закрыли ненужные портыНастроили корректную аутентификацию в PostgreSQLВнедрили систему мониторинга и alerting
  • Установили и настроили фаервол

4. Создание нового сервера

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

Проактивная защита: как предотвратить подобные атаки

На основе этого инцидента мы разработали комплекс рекомендаций по защите от подобных угроз:

🔍 Мониторинг и обнаружение угроз

  • Внедрите систему централизованного сбора и анализа логов (SIEM)
  • Настройте alerting на аномальную активность (высокую нагрузку CPU, подозрительные процессы)
  • Регулярно проводите сканирование уязвимостей
  • Используйте системы deception для раннего обнаружения атак 7

🔧 Безопасная конфигурация

  • Следуйте принципу наименьших привилегий для пользователей и сервисов
  • Регулярно обновляйте ПО и применяйте патчи безопасности
  • Отключайте неиспользуемые сервисы и закрывайте ненужные порты
  • Запрещайте слабые методы аутентификации (например, trust в PostgreSQL)

🚦 Сегментация и контроль доступа

  • Изолируйте критические системы от публичного интернета
  • Внедрите сегментацию сети для ограничения lateral movement
  • Используйте VPN и jump-хосты для доступа к внутренним ресурсам

🧪 Регулярные проверки

  • Проводите периодические penetration testы
  • Отрабатывайте сценарии реагирования на инциденты
  • Делайте и тестируйте резервные копии критических данных

Выводы и уроки, извлеченные из инцидента

Этот случай наглядно демонстрирует несколько важных аспектов современной кибербезопасности:

  1. Любая система уязвима — даже правильно настроенный сервер может быть скомпрометирован через цепочку из мелких упущений
  2. Раннее обнаружение критически важно — среднее время проникновения злоумышленника в инфраструктуру компании составляет всего 84 минуты
  3. Человеческий фактор остается ключевым — около 60% утечек данных происходят при участии "человеческого фактора"
  4. Необходим комплексный подход — точечные меры защиты недостаточны против современных угроз
  5. Проактивность лучше реактивности — инвестиции в профилактику и обнаружение значительно дешевле ликвидации последствий

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

Если вы столкнулись с подобной проблемой или хотите провести аудит безопасности вашей инфраструктуры — обращайтесь к нашим специалистам. Будем рады помочь сделать ваш бизнес безопаснее.

1
Начать дискуссию