Reverse shell в инциденте: признаки, TTY-артефакты и сдерживание

Этот разбор только про защитную сторону: как заметить подозрительную интерактивность, сохранить артефакты и закрыть класс рисков. Инструкций по созданию или улучшению shell-доступа здесь нет.

Сигналы в системе

• Неожиданные исходящие TCP-соединения от web-процесса, cron-задачи или служебного пользователя.
• Интерпретаторы и shell-процессы в дереве там, где должны быть только application workers.
• Следы псевдотерминала, необычные parent process и команды, запущенные не через штатный deploy.
• Пики DNS-запросов, внешних callbacks и сетевых ошибок после подозрительного HTTP-запроса.

ss -tpn
ps -eo pid,ppid,user,tty,stat,cmd --forest
journalctl --since "2 hours ago" | less

Containment

Первое действие - не героически чинить процесс на живом сервере, а ограничить управление атакующего и сохранить следы.

• Закрыть лишний egress: приложению обычно не нужен произвольный исходящий интернет.
• Изолировать host или namespace, если есть признаки активного управления.
• Снять process tree, сетевые соединения, логи reverse proxy, auditd/eBPF и дамп подозрительных файлов.
• Проверить секреты: env, service accounts, deploy keys, tokens, cloud credentials.

Профилактика

Практичный baseline: deny-by-default для исходящих соединений, минимальные права web-user, запрет записи в каталоги с кодом, отдельные service accounts и алерты на shell/interpreter под application user.