Обнаружение ransomware на Linux

Ransomware на Linux давно перестал быть редкостью. Современные операторы атакуют ESXi-хосты, backup-серверы, NAS-системы, CI-раннеры, application-серверы и любые Linux-машины, где есть ценные данные или где можно нанести заметный операционный ущерб.

Паттерн хорошо известен: получить доступ, переместиться по сети, найти важные данные, отключить механизмы восстановления, зашифровать файлы и оставить ransom note.

Когда человек впервые замечает ransom note, ущерб обычно уже нанесён. Детекция должна происходить раньше и на уровне самого хоста.

Что обычно делает ransomware

Хотя семейства ransomware отличаются инструментами, их поведение удивительно похоже:

• они переименовывают или переписывают большое количество файлов за короткий промежуток времени;
• они добавляют новые расширения, например .locked, .encrypted, .akira, .lockbit или .deadbolt;
• они создают ransom note-файлы вроде HOW_TO_DECRYPT.txt или README_FOR_RESTORE.html;
• они пытаются удалить бэкапы или остановить backup-софт ещё до начала шифрования.

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

Почему ransomware сложно ловить только сетевыми средствами

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

Именно поэтому для детекта ransomware на Linux нужны файловые события, контекст процесса и поведенческие rate-based сигналы прямо с endpoint.

Как SecureExec обнаруживает ransomware

В SecureExec есть встроенное правило ransomware.

Linux-агент собирает события, которые важнее всего для этой задачи:

• события создания файлов;
• события переименования файлов;
• события создания процессов с полным command line.

На сервере встроенное правило ransomware ищет несколько сильных индикаторов.

1. Файл переименован в известное ransomware-расширение

Правило срабатывает, когда файл переименовывается в расширение, характерное для реальных семейств ransomware, включая:

• .locked
• .encrypted
• .deadbolt
• .akira
• .lockbit
• .cl0p
• .ryuk

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

2. Создание ransom note

Правило также срабатывает при появлении файлов с именами, типичными для ransom note, например:

• HOW_TO_DECRYPT
• HOW_TO_RESTORE
• README_FOR_DECRYPT
• README_FOR_RESTORE
• YOUR_FILES_ENCRYPTED

Это сильный пост-шифровальный сигнал и часто первый артефакт, который аналитик видит во время triage.

3. Массовое переименование файлов

Многие семейства ransomware очень быстро трогают большое количество файлов. SecureExec отслеживает rename-активность по каждому процессу и поднимает алерт, если один процесс переименовывает много файлов за короткое окно времени.

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

4. Уничтожение механизмов восстановления

Перед шифрованием ransomware часто пытается усложнить восстановление. Правило ищет команды вроде:

• vssadmin delete shadows
• wmic shadowcopy delete
• rm -rf /backup
• systemctl stop veeam
• systemctl stop bacula

Это ценные pre-encryption сигналы, которые могут дать вашей команде время на изоляцию хоста до того, как потеря файлов станет массовой.

Почему такая детекция практична

Правило опирается на сильные host-side индикаторы, а не на расплывчатые эвристики:

• matching по расширению ловит семейства с предсказуемыми именами;
• ransom note filenames ловят явный артефакт оператора;
• mass rename detection покрывает семейства со случайными расширениями;
• backup-wipe команды ловят подготовительный этап ещё до шифрования.

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

Что даёт алерт

Когда SecureExec срабатывает по правилу ransomware, вы получаете процессный и файловый контекст, необходимый для быстрого расследования:

• имя процесса, который менял файлы;
• новый зашифрованный путь или имя ransom note;
• command line, использованный для остановки backup-софта или удаления recovery-данных;
• связанные события и process lineage по этому хосту.

Этого достаточно, чтобы быстро понять, нужно ли немедленно изолировать хост и запускать IR-процесс.

Встроено, а не прикручено сбоку

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

Если правило сработало, вы можете сразу перейти к расследованию и использовать изоляцию хоста для containment, не покидая платформу.

Попробуйте SecureExec

Если вам нужен встроенный детект ransomware на Linux-endpoint с видимостью на уровне файлов, процессов и поведения, в SecureExec это уже есть.

Попробуйте SecureExec, чтобы выявлять ransomware-активность на ранней стадии и реагировать до того, как шифрование распространится по вашей инфраструктуре.