- Что такое reverse shell?
- Как работает reverse shell?
- Reverse shell и bind shell: в чем разница?
- Reverse shell и web shell: в чем разница?
- Какие веб-уязвимости могут привести к reverse shell?
- Структура типичного reverse shell payload с точки зрения защиты
- Признаки reverse shell: на что следует обращать внимание
- Распространенные шаблоны процессов reverse shell
- Как выявлять reverse shell в логах и телеметрии
- Лучшие практики предотвращения reverse shell
- Чек-лист защиты от reverse shell
- Что делать при обнаружении reverse shell
- Как снизить риск reverse shell с помощью Invicti
Активный reverse shell является одним из наиболее очевидных признаков того, что веб-уязвимость уже перешла из состояния потенциально пригодной для эксплуатации в действительно использованную и опасную.
Вместо ожидания входящего подключения скомпрометированная система, на которой запущен reverse shell, сама инициирует исходящее соединение с внешним хостом и предоставляет доступ к командной строке через канал, который может выглядеть как обычный сетевой трафик.
Этот материал о reverse shell предназначен для специалистов по защите, команд AppSec, аналитиков центров кибербезопасности (SOC), инженеров DevSecOps и других уполномоченных специалистов по безопасности. В нем рассматриваются принципы работы reverse shell, типичные шаблоны payload, признаки для обнаружения, меры предотвращения и веб-уязвимости, которые могут сделать reverse shell возможным.
Материал не содержит готовых к выполнению payload, команд для запуска listener, инструкций по улучшению оболочки, методов обфускации или указаний для получения несанкционированного доступа.
Что такое reverse shell?
Reverse shell — это техника удаленного доступа, при которой скомпрометированная система сама инициирует исходящее соединение с внешним хостом и предоставляет через него доступ к командной оболочке.
Злоумышленники часто пытаются получить reverse shell после эксплуатации уязвимостей, которые позволяют выполнять команды или код. К ним относятся инъекция команд операционной системы (OS command injection), удаленное выполнение кода (RCE), небезопасная загрузка файлов, инъекция в серверные шаблоны (SSTI), небезопасная десериализация и цепочки уязвимостей типа injection.
Ключевое слово здесь — «reverse», то есть обратное направление соединения.
В обычном сценарии удаленного доступа оператор подключается к системе извне. В случае reverse shell целевая система сама устанавливает исходящее соединение.
Это различие имеет принципиальное значение, поскольку большинство организаций намного строже ограничивают и контролируют входящие соединения, чем исходящие.
Сервер может быть недоступен напрямую из Интернета, но при этом иметь разрешение на исходящие соединения с API, службами обновления, платформами журналирования, репозиториями пакетов и другими внешними системами.
Reverse shell пытается использовать такой разрешенный канал исходящего трафика.
То есть, оно является техникой, применяемой после успешной эксплуатации уязвимости, а не самой исходной уязвимостью.
Оболочка является результатом успешной эксплуатации. Первопричиной обычно становится слабое место, которое позволило злоумышленнику выполнить код, запустить системную команду, загрузить исполняемое содержимое или получить доступ к другой службе, способной выполнить такие действия.
Инъекция команд операционной системы является классом уязвимостей, который обычно создает наиболее прямой путь от уязвимости к доступу к командной оболочке.
MITRE ATT&CK относит злоупотребление командными и скриптовыми интерпретаторами к технике T1059.
Она охватывает использование злоумышленниками командных оболочек и сред выполнения скриптов для запуска команд, скриптов или исполняемых файлов на разных платформах.
Как работает reverse shell?
Обычно reverse shell работает по простой концептуальной схеме:
- Злоумышленник находит уязвимость, которая позволяет выполнять команды или код.
- Уязвимая система инициирует исходящее соединение.
- Соединение устанавливается с внешним хостом, контролируемым злоумышленником.
- Через это соединение перенаправляются потоки ввода, вывода и сообщений об ошибках.
- Выполняются команды через удаленную оболочку до тех пор, пока сессия не будет завершена, прервана или обнаружена.
- После этого злоумышленник может попытаться получить учетные данные, закрепиться в системе, повысить привилегии, провести внутреннюю разведку или расширить атаку на другие системы.
С точки зрения защиты практическая модель обнаружения не должна сводиться к поиску конкретного запроса.
Запросы различаются в зависимости от операционной системы, интерпретатора, среды выполнения и доступных утилит.
Более надежный подход заключается в корреляции трех условий:
- Неожиданный родительский процесс, например веб-сервер или среда выполнения приложения.
- Командная оболочка, скриптовый интерпретатор или системная утилита, запущенные как дочерний процесс.
- Исходящее соединение, которое обычно не характерно для этой рабочей нагрузки.
Каждое из этих условий по отдельности может быть вполне нормальным.
Однако вместе, особенно если они возникают сразу после подозрительного веб-запроса или ошибки приложения, они формируют значительно более сильный сигнал.
Reverse shell и bind shell: в чем разница?
Reverse shell и bind shell при злоумышленном использовании обе обеспечивают удаленный доступ к командной оболочке, однако устанавливают соединение в противоположных направлениях.
| Reverse shell | Bind shell | |
| Направление соединения | Целевая система устанавливает исходящее соединение | Злоумышленник устанавливает входящее соединение |
| Зависимость от сетевого доступа | Требуется разрешение на исходящее соединение с целевой системы | Требуется возможность установить входящее соединение с целевой системой |
| Влияние правил файрвола | Может работать в средах, где основное внимание уделяется фильтрации входящего трафика | Непосредственно зависит от правил файрвола для входящих соединений |
| Типичная цель злоумышленника | Создать обратное подключение из среды с ограниченным доступом или без прямой адресации | Открыть на целевой системе канал для приема удаленных команд |
| Основные меры защиты | Фильтрация исходящего трафика, телеметрия процессов, определение нормального поведения рабочей нагрузки и предотвращение RCE | Фильтрация входящего трафика, выявление открытых служб и усиление защиты хоста |
| Основной риск | Несанкционированное удаленное выполнение команд | Несанкционированное удаленное выполнение команд |
Reverse shell привлекателен для злоумышленников, поскольку производственным серверам, контейнерам и облачным рабочим нагрузкам обычно требуется хотя бы определенный исходящий доступ даже тогда, когда входящие соединения строго ограничены.
Поэтому политики файрвола должны учитывать как входящие, так и исходящие соединения, а не сосредотачиваться только на сервисах, доступных из Интернета.
Reverse shell и web shell: в чем разница?
Web shell обычно представляет собой вредоносный серверный код или вредоносный файл, размещенный на веб-сервере после эксплуатации уязвимости. Он предоставляет функциональность, похожую на командную оболочку, и принимает входящие команды.
Reverse shell, напротив, представляет собой активную командную сессию, которая работает через исходящее соединение.
Эти два понятия связаны между собой, но не являются взаимозаменяемыми.
| Web shell | Reverse shell | |
| Форма | Вредоносный файл, скрипт или серверный код | Командная сессия, работающая через сетевое соединение |
| Типичное расположение | Корневой каталог веб-сервера, каталог загрузок, каталог плагинов, временный каталог или каталог приложения | Не требует постоянного артефакта в файловой системе; существует как запущенный процесс и активное сетевое соединение |
| Тригер | Обычно HTTP-запрос к вредоносному файлу или конечной точке | Исходящее обратное соединение со скомпрометированной системы |
| Взаимосвязь | Может обеспечивать выполнение команд или запускать reverse shell | Может быть запущено через web shell |
| Основное направление обнаружения | Контроль целостности файлов, веб-логи, подозрительное выполнение скриптов и неожиданные файлы | Исходящий трафик, деревья процессов, телеметрия конечных точек и данные о сетевых потоках |
| Основная задача AppSec | Предотвращать несанкционированную загрузку и выполнение серверного кода | Предотвращать выполнение команд и ограничивать злоупотребление исходящими соединениями |
Web shell сохраняется на сервере в виде файла и принимает входящие команды через HTTP, поэтому остается доступным до тех пор, пока этот файл существует.
Сессия reverse shell является временной и существует только пока активно соединение.
При этом злоумышленники часто комбинируют reverse shell с механизмами закрепления в системе, например заданиями cron, скриптами запуска или запланированными задачами, которые повторно инициируют исходящее соединение после перезагрузки системы или разрыва сессии.
Злоумышленник может сначала загрузить web shell, а затем использовать его для запуска reverse shell.
Другой вариант заключается в получении reverse shell напрямую через инъекцию команд или другой путь удаленного выполнения кода без размещения файла на сервере.
Какие веб-уязвимости могут привести к reverse shell?
Reverse shell редко является первой уязвимостью в цепочке атаки.
Обычно он становится результатом эксплуатации слабого места, которое позволяет злоумышленнику выполнить код или получить доступ к доверенной службе, способной это сделать.
Поэтому основная задача AppSec заключается в выявлении и устранении таких уязвимостей до того, как они приведут к доступу к командной оболочке.
| Уязвимость | Как она может привести к reverse shell | Приоритет защиты |
| Инъекция команд операционной системы | Вводимые пользователем данные попадают в механизм выполнения команд операционной системы | Устранить пути выполнения команд через оболочку, проверять входные данные, использовать более безопасные API и тестировать параметры, доступные извне |
| Удаленное выполнение кода | Приложение или уязвимый компонент выполняет код, контролируемый злоумышленником | Устанавливать исправления для уязвимых компонентов, усиливать защиту путей выполнения и приоритизировать подтвержденные уязвимости RCE, пригодные для эксплуатации |
| Небезопасная загрузка файлов | Загруженное содержимое попадает в расположение или процесс обработки, где его можно выполнить | Хранить загрузки вне каталогов с возможностью выполнения, проверять файлы на стороне сервера и блокировать выполнение скриптов в каталогах загрузок |
| Инъекция в серверные шаблоны | Выражения шаблонов обрабатывают контролируемые злоумышленником данные и могут привести к выполнению кода | Ограничивать возможности шаблонизатора, не использовать шаблоны, контролируемые пользователем, и тестировать обработку опасных выражений |
| Небезопасная десериализация | Вредоносные сериализованные данные запускают небезопасный путь выполнения кода | Избегать небезопасной десериализации, использовать белые списки разрешенных типов, а также подписывать или проверять сериализованные данные |
| SQL-инъекция с переходом к выполнению команд ОС | Функции базы данных, расширения или избыточные привилегии позволяют перейти от SQL-инъекции к выполнению системных команд | Устранять SQL-инъекции, ограничивать привилегии базы данных и отключать опасные функции или расширения |
| SSRF в сочетании с внутренними службами | SSRF может предоставить доступ к метаданным или учетным данным для дальнейшей компрометации либо обеспечить прямой доступ к доверенным внутренним службам, включая административные API, хранилища данных и конечные точки управления, через которые можно перейти к выполнению кода | Ограничивать исходящие запросы, блокировать доступ к службам метаданных, использовать белые списки разрешенных направлений, аутентифицировать внутренние службы и сегментировать сеть |
| Локальное или удаленное включение файлов | Уязвимости включения файлов могут привести к выполнению кода в зависимости от языка, сервера и конфигурации | Усиливать контроль путей включения, отключать удаленное включение, проверять ссылки на файлы и отслеживать подозрительное выполнение скриптов |
Именно здесь особенно важным становится динамическое тестирование безопасности приложений (DAST).
Сканер необязательно должен зафиксировать активный reverse shell, чтобы снизить риск его появления.
Его задача заключается в выявлении доступных извне уязвимостей, которые могут привести к выполнению команд, произвольному выполнению кода, небезопасной обработке файлов или созданию цепочки доступа к доверенным службам.
Устранение таких слабых мест снижает риск того, что reverse shell вообще будет запущен.
Структура типичного reverse shell payload с точки зрения защиты
Типичный reverse shell payload обычно сочетает три элемента:
- Исходящее сетевое соединение.
- Механизм, который связывает ввод и вывод команд с этим соединением.
- Командный интерпретатор или другой механизм выполнения команд.
Для распознавания такого поведения специалистам по защите не нужны готовые рабочие строки запросов.
Важно понимать, какой процесс создал соединение, какой дочерний процесс был запущен, какая учетная запись использовалась и является ли такая последовательность нормальной для соответствующей рабочей нагрузки.
Приведенные ниже примеры описывают общие категории запросов без синтаксиса, команд, настройки listener или практических инструкций по использованию.
| Категория запросов | Принцип роботы | На что следует обращать внимание специалистам по защите |
| Bash reverse shell payload | Процесс командной оболочки открывает исходящее соединение и перенаправляет через него ввод и вывод | Веб-процесс или процесс приложения запускает командную оболочку, после чего появляется неожиданный исходящий трафик |
| Netcat reverse shell payload | Сетевая утилита подключается к внешнему хосту и связывает это соединение с командным интерпретатором | Утилиты наподобие Netcat на серверах, особенно если их запускают веб-процессы, приложения, базы данных или скриптовые среды |
| Python reverse shell payload | Среда выполнения скриптов создает исходящий сокет, связывает его с вводом и выводом процесса и запускает командную оболочку | Python устанавливает прямые исходящие соединения и запускает дочернюю командную оболочку или системные команды |
| PowerShell reverse shell payload | Скриптовая среда Windows создает исходящую сессию, получает команды и возвращает результаты их выполнения | Сетевая активность PowerShell, необычные родительские процессы, закодированные или чрезмерно длинные командные строки и подозрительные дочерние процессы |
Названия языков и утилит могут быть полезными поисковыми признаками, однако механизмы обнаружения не должны зависеть от фиксированной сигнатуры payload.
Злоумышленники могут менять синтаксис, использовать другой интерпретатор, переименовывать утилиты или использовать встроенные возможности среды выполнения.
Поэтому корреляция поведенческих признаков является более устойчивым подходом.
Признаки reverse shell: на что следует обращать внимание
Наилучшие результаты обнаружения reverse shell дает корреляция сетевой телеметрии, данных конечных точек, процессов, учетных записей, облачной среды и приложений.
Отдельный подозрительный сигнал может потеряться среди других событий или оказаться недостаточным для реагирования.
Подозрительная последовательность событий значительно полезнее.
| Тип сигнала | Признак | Почему это важно |
| Сеть | Неожиданное исходящее соединение с веб-сервера или хоста приложения | Reverse shell обычно инициирует соединение наружу |
| Сеть | Исходящий трафик к редкому, новому или некатегоризированному адресу | Инфраструктура для обратного подключения может не соответствовать обычному поведению рабочей нагрузки |
| Сеть | Длительные или похожие на интерактивные сессии с сервера | Интерактивное управление может создавать трафик, который отличается от обычных API-запросов |
| Процесс | Веб-сервер или среда выполнения приложения запускает командную оболочку | Сервисы, доступные через веб, редко нуждаются в интерактивных командных интерпретаторах |
| Процесс | Среда выполнения приложения запускает системные утилиты | Это может указывать на выполнение команд через уровень приложения |
| Процесс | Процесс базы данных запускает внешние команды | Это может свидетельствовать о цепочке атаки через SQL-инъекцию, небезопасные расширения или компрометацию сервера |
| Логи | Подозрительные входные данные или ошибки непосредственно перед появлением исходящего трафика | Эксплуатация часто оставляет следы на уровне приложения еще до установления обратного соединения |
| Конечная точка | Временные файлы, неожиданные исполняемые файлы или измененные скрипты | Это может свидетельствовать о подготовке среды или активности после успешной эксплуатации |
| Учетная запись | Веб-сервер или сервисная учетная запись выполняет команды за пределами своей обычной роли | Учетные записи приложений должны иметь ограниченные привилегии и предсказуемое поведение |
| Облачная среда | Доступ к службе метаданных с последующим исходящим соединением | Это может указывать на получение учетных данных и дальнейшее расширение атаки в облачной среде |
| Контейнер | Запуск интерактивной командной оболочки внутри рабочей нагрузки | В производственных контейнерах интерактивные оболочки обычно требуются крайне редко |
| SIEM | Несколько некорректно сформированных или похожих на команды запросов, после которых изменяется поведение системы | Во время поиска пригодного для эксплуатации пути злоумышленники часто сначала генерируют ошибки |
Стратегия MITRE для обнаружения web shell обращает внимание на подозрительные цепочки событий, например неожиданное создание файла в веб-каталоге с последующим запуском командной оболочки или скриптового интерпретатора процессом веб-сервера.
Та же логика анализа связей между родительскими и дочерними процессами актуальна и при поиске признаков reverse shell, запущенных через систему, доступную из веба.
Распространенные шаблоны процессов reverse shell
Reverse shell может отличаться в зависимости от операционной системы, среды выполнения и доступных инструментов, однако взаимосвязи между процессами часто остаются узнаваемыми.
| Родительский процесс | Подозрительное поведение дочернего процесса |
| Веб-сервер | Неожиданно запускает командную оболочку или скриптовую среду |
| Среда выполнения приложения | Запускает процесс системной команды или сетевую утилиту |
| Процесс базы данных | Запускает внешнюю команду или скриптовый процесс |
| Скриптовая среда | Создает исходящий сокет и запускает дополнительные команды |
| Точка входа контейнера | Неожиданно запускает интерактивную командную оболочку |
| Запланированная задача | Выполняет команды, которые создают необъяснимый исходящий трафик |
| CI/CD runner | Выполняет действия, характерные для командной оболочки, за пределами ожидаемых этапов сборки или развертывания |
Чтобы отличить обычную активность от подозрительной, необходимо учитывать контекст.
Командная оболочка, запущенная администратором во время документированного окна технического обслуживания, может быть вполне допустимой.
Запуск командной оболочки веб-процессом, пулом приложения, процессом базы данных, библиотекой обработки изображений, шаблонизатором или компонентом загрузки файлов является гораздо более серьезным признаком.
Поэтому базовые профили поведения должны учитывать назначение рабочей нагрузки, среду, этап развертывания, утвержденную административную активность и известные процессы автоматизации.
Цель состоит не в том, чтобы создавать предупреждение на каждый запуск интерпретатора, а в том, чтобы надежно выявлять интерпретаторы и исходящие соединения в тех процессных контекстах, где их не должно быть.
Как выявлять reverse shell в логах и телеметрии
Ни один отдельный источник логов не позволяет надежно выявить каждый случай reverse shell.
Лучше всего рассматривать обнаружение как задачу корреляции: связать событие в приложении, которое позволило выполнить код, с запущенным процессом, учетной записью, от имени которой он работал, и сетевой сессией, возникшей после этого.
Сетевые логи
Начинать стоит с журналирования исходящего трафика.
Необходимо анализировать исходящие соединения из систем, которые не должны самостоятельно устанавливать произвольные внешние соединения, особенно с веб-серверов, серверов приложений, серверов баз данных, CI/CD-инфраструктуры, контейнеров и облачных рабочих нагрузок.
Стоит проверять:
- Новые, редкие, некатегоризированные адреса или направления с низкой репутацией.
- Соединения через порты или протоколы, которые обычно не используются этой рабочей нагрузкой.
- Длительные сессии с небольшим двунаправленным обменом трафиком.
- Исходящие соединения, которые начинаются сразу после ошибки приложения, подозрительного запроса или загрузки файла.
- Повторяющиеся попытки подключения с нескольких хостов.
- Прямые соединения по IP-адресу в средах, где рабочая нагрузка обычно использует именованные службы или утвержденные прокси.
- Исходящий трафик, который обходит ожидаемый прокси, service mesh или стандартный сетевой маршрут организации.
Неизвестный адрес сам по себе еще не является доказательством компрометации.
Наиболее убедительные сетевые признаки появляются тогда, когда необычный исходящий трафик коррелируется с контекстом процессов и приложения.
Логи веб-серверов и приложений
Логи приложений могут помочь определить исходную точку атаки.
Стоит обращать внимание на подозрительные параметры, необычную активность загрузки файлов, неожиданные ошибки шаблонов или десериализации, обращения к редко используемым конечным точкам и серии пробных запросов перед успешным выполнением.
Стоит проверять:
- Запрос, который непосредственно предшествовал исходящему соединению.
- Функции загрузки, рендеринга шаблонов, импорта, экспорта, диагностики, конвертации и администрирования.
- Повторяющиеся некорректно сформированные входные данные от одного клиента или в рамках одной сессии.
- Переход от видимых ошибок к тихому или успешному ответу.
- Обращения к забытым, устаревшим, отладочным или редко используемым конечным точкам.
- События аутентификации, которые не соответствуют обычному поведению пользователя или сервисной учетной записи.
- API-запросы к внутренним или недокументированным маршрутам.
- Запросы, после которых наблюдается необычно длительная обработка или внезапный перезапуск рабочего процесса.
Если это позволяет политика организации, следует сохранять полный контекст запроса, включая заголовки, параметры маршрута, учетную запись пользователя, информацию о сессии и correlation ID.
Отдельная запись в веб-логе может выглядеть обычно, однако ее время относительно запуска процесса и появления исходящего соединения может помочь восстановить путь атаки.
Телеметрия конечных точек и EDR
Телеметрия EDR часто является тем источником, где поведение reverse shell становится наиболее очевидным.
Следует анализировать создание процессов, связи между родительскими и дочерними процессами, сетевые соединения, активность командных интерпретаторов, запись файлов, доступ к учетным данным и изменения служб.
Стоит проверять:
- Какой процесс создал исходящее соединение.
- Его родительский и вышестоящий родительский процесс.
- Была ли запущена командная оболочка, скриптовый интерпретатор, сетевая утилита или системный инструмент.
- Какая пользовательская или сервисная учетная запись связана с процессом.
- Временные файлы, добавленные исполняемые файлы или измененные скрипты, созданные примерно в то же время.
- Доступ к переменным среды, конфигурационным файлам, облачным учетным данным, SSH-ключам или локальным секретам.
- Команды для разведки, перечисления учетных записей, проверки служб или вмешательства в работу средств защиты.
- Закрепление через запланированные задачи, службы, записи автозапуска или измененные файлы приложения.
Четкое представление дерева процессов является одним из ключевых элементов анализа сигналов reverse shell, поскольку оно связывает сетевую активность с приложением или службой, которая запустила процесс командной оболочки.
Телеметрия облачных сред и контейнеров
Облачные рабочие нагрузки добавляют контекст учетных записей и плоскости управления.
После запуска reverse shell в контейнере, виртуальной машине, build runner или serverless-нагрузке могут появиться обращения к метаданным, сканирование внутренних служб, использование учетных данных или необычные вызовы API плоскости управления.
Стоит проверять:
- Неожиданный доступ к службам метаданных инстансов или контейнеров.
- Внешние направления, которых нет в утвержденном списке зависимостей рабочей нагрузки.
- Интерактивные командные оболочки или выделение терминала в производственных контейнерах.
- Новые дочерние процессы в минимальных или distroless-образах, то есть минимальных образах без менеджера пакетов или командной оболочки.
- Активность сервисной учетной записи, которая начинается сразу после подозрительной сессии.
- Необычные обращения к менеджерам секретов, объектным хранилищам, сервисам учетных записей или API оркестрации.
- East-west трафик из затронутой рабочей нагрузки к внутренним службам.
- Изменения образа контейнера, модификации writable layer или появление новых смонтированных путей.
- Активность build runner или CI/CD за пределами обычных определений задач.
Облачные журналы аудита могут показать, что произошло после установления первоначальной shell-сессии, а телеметрия контейнера и хоста может показать, как именно эта сессия началась.
Для оценки масштаба компрометации необходимы оба типа данных.
Корреляция доказательств
Расследование reverse shell с высоким уровнем уверенности может включать такую последовательность сигналов:
- Подозрительный запрос поступает в веб-приложение или API.
- Процесс приложения запускает командную оболочку, интерпретатор или системную утилиту.
- Новый процесс инициирует необычное исходящее соединение.
- Учетная запись рабочей нагрузки получает доступ к файлам, секретам, метаданным или внутренним службам.
- Последующая активность появляется в логах конечной точки, облачной среды или учетных записей.
Правила SIEM должны отдавать приоритет таким последовательностям, а не отдельным изолированным индикаторам.
Точная командная строка может меняться, однако взаимосвязь между эксплуатацией уязвимости, запуском процесса и исходящим соединением скрыть значительно сложнее.
Лучшие практики предотвращения reverse shell
Предотвращение reverse shell требует многоуровневой защиты: устранения уязвимостей, позволяющих выполнение команд или кода, ограничения исходящих сетевых соединений, минимизации привилегий приложений и мониторинга поведения, которого не должно быть в производственных средах.
Снизить риск появления reverse shell помогают следующие меры:
- Выявление, устранение и предотвращение уязвимостей инъекции команд. Не следует передавать данные, контролируемые пользователем, напрямую в команды операционной системы. Предпочтение стоит отдавать API языка программирования или фреймворка, которые выполняют необходимую операцию без запуска командной оболочки. Если выполнения команд невозможно избежать, следует использовать фиксированные исполняемые файлы и аргументы, строгие белые списки, надежную изоляцию и сервисные учетные записи с минимально необходимыми правами.
- Предотвращение произвольного выполнения кода. Необходимо усиливать защиту шаблонизаторов, механизмов загрузки файлов, систем плагинов, логики десериализации, CI/CD hooks, конвертеров документов и точек расширения. Любая функция, которая оценивает, преобразует, импортирует или выполняет содержимое, контролируемое пользователем, требует дополнительного анализа архитектуры и тестирования.
- Ограничение исходящего сетевого трафика. Производственные серверы и контейнеры должны подключаться только к разрешенным адресам, службам и портам. Где это возможно, исходящий трафик следует направлять через контролируемые шлюзы или прокси и создавать предупреждения о попытках их обхода. Политики файрвола должны охватывать как входящий, так и исходящий трафик, а не только сервисы, доступные извне.
- Запуск приложений с минимальными привилегиями. Учетные записи приложений не должны быть привилегированными системными пользователями. Им не следует предоставлять широкий доступ к файлам, интерактивной командной оболочке, лишним облачным разрешениям или секретам, не связанным с их функцией. Это ограничивает возможности злоумышленника даже при успешном выполнении команд.
- Удаление ненужных интерпретаторов и утилит. Минимальные образы серверов и контейнеров уменьшают количество инструментов, доступных после компрометации. Если рабочая нагрузка не требует командных оболочек, компиляторов, менеджеров пакетов, сетевых утилит или инструментов отладки, их стоит удалить. Это ограничивает возможности после эксплуатации, но не заменяет устранение уязвимостей RCE.
- Усиление защиты загрузки и обработки файлов. Загруженные файлы следует хранить вне каталогов, где возможно выполнение кода, проверять на стороне сервера, переименовывать, ограничивать возможности парсеров и конвертеров и не позволять интерпретировать загруженное содержимое как код. Распаковку архивов, конвертацию документов и обработку медиафайлов стоит рассматривать как функции, непосредственно связанные с риском выполнения кода.
- Мониторинг подозрительных связей между родительскими и дочерними процессами. Предупреждения следует создавать, когда веб-серверы, среды выполнения приложений, службы баз данных, точки входа контейнеров или build agents запускают командные интерпретаторы, сетевые утилиты или неожиданные скриптовые процессы.
- Сегментация сред приложений. Скомпрометированное публично доступное приложение не должно иметь возможности произвольно обращаться к внутренним системам. Для уменьшения масштаба компрометации стоит использовать сегментацию сети, учетные записи рабочих нагрузок, авторизацию между сервисами, облачные средства контроля и аутентифицированные внутренние API.
- Защита служб метаданных и плоскости управления. Необходимо ограничивать доступ к облачным конечным точкам метаданных, использовать современные механизмы их защиты, где они доступны, минимизировать привилегии сервисных учетных записей и не позволять рабочим нагрузкам обращаться к административным интерфейсам, которые им не нужны.
- Совместное использование DAST и безопасного анализа кода. DAST помогает выявлять доступные извне уязвимости в работающих приложениях и API. Анализ кода и статическое тестирование безопасности приложений (SAST) помогают устранять небезопасные пути выполнения еще до развертывания. Эти методы дают разные типы доказательств и наиболее эффективно работают как взаимодополняющие средства контроля.
- Приоритизация подтвержденных и доступных для эксплуатации рисков. В первую очередь следует устранять уязвимости, которые доступны извне, пригодны для эксплуатации и связаны с чувствительными приложениями или привилегиями. Подтвержденные инъекции команд и RCE требуют немедленного внимания, поскольку могут напрямую привести к доступу к командной оболочке.
- Повторное тестирование после устранения уязвимостей. После исправления инъекций команд, RCE, небезопасной загрузки файлов, десериализации, включения файлов или SSRF необходимо повторно протестировать соответствующее приложение. Самого изменения кода недостаточно. Нужно подтвердить, что опасное поведение больше недоступно или не может быть воспроизведено в работающей среде.
Чек-лист защиты от reverse shell
Приведенный ниже краткий список можно использовать при первичном анализе, проверке средств контроля и планировании устранения уязвимостей.
| Задача специалиста по защите | Что проверить |
| Выявление уязвимостей с высоким риском | Инъекция команд, RCE, небезопасная загрузка файлов, SSTI, десериализация, цепочки SQL injection → RCE, цепочки SSRF и включение файлов |
| Проверка исходящего трафика | Неизвестные направления, необычные порты, длительные сессии, редкие внешние хосты и обратные подключения от рабочих нагрузок, доступных через веб |
| Проверка телеметрии процессов | Веб-сервер запускает командную оболочку, среда выполнения запускает системные утилиты, появляются необычные цепочки родительских и дочерних процессов |
| Проверка логов приложения | Подозрительные параметры, попытки загрузки файлов, ошибки парсеров или шаблонов, закодированные входные данные и необычный доступ к конечным точкам |
| Проверка учетных записей | Сервисные учетные записи выполняют команды, обращаются к не связанным с их функцией секретам или выполняют необычные вызовы облачных API |
| Усиление контроля исходящего трафика | Разрешать рабочим нагрузкам только утвержденные адреса и порты |
| Усиление защиты приложений | Избегать запуска оболочки, проверять входные данные, защищать загрузку файлов, ограничивать интерпретаторы и применять принцип минимальных привилегий |
| Усиление защиты контейнеров | Использовать минимальные образы, удалять ненужные capabilities, ограничивать права записи и удалять неиспользуемые инструменты |
| Проверка исправлений | Повторное тестирование с помощью DAST и разрешенного тестирования безопасности |
| Непрерывный мониторинг | Корреляция телеметрии SIEM, EDR, сети, учетных записей, облачной среды, приложений и контейнеров |
| Быстрое реагирование | Изоляция рабочей нагрузки, сохранение доказательств, определение начальной точки атаки, замена учетных данных и устранение первопричины |
Что делать при обнаружении reverse shell
Любой подозреваемый reverse shell следует рассматривать как активную компрометацию до тех пор, пока доказательства не указывают на обратное.
Первоочередные задачи заключаются в прекращении выявленной сессии без излишнего уничтожения доказательств, определении начальной точки атаки, оценке масштаба компрометации и предотвращении повторного использования того же пути.
Основные шаги реагирования и устранения последствий:
- Изоляция затронутого хоста, контейнера или рабочей нагрузки. Сетевой доступ следует ограничить, одновременно по возможности сохранив нестойкие данные, важные для расследования.
- Сохранение логов и телеметрии. Необходимо собрать деревья процессов, данные о сетевых потоках, логи веб-сервера и приложения, данные EDR, облачные журналы аудита, события учетных записей, при необходимости данные из оперативной памяти и релевантные события контейнеров.
- Отслеживание пути выполнения. Нужно проследить родительский процесс командной оболочки через недавние запросы, загрузки файлов, события аутентификации, доступные извне приложения и API, результаты сканирования уязвимостей и внутренние службы, которые могли быть частью цепочки.
- Замена потенциально скомпрометированных учетных данных. Следует исходить из того, что злоумышленник мог получить доступ к переменным среды, конфигурационным файлам, облачным токенам, учетным данным баз данных, API-ключам, локальным секретам и учетным записям рабочих нагрузок.
- Удаление механизмов закрепления и сдерживание дальнейшей активности. Необходимо проверить наличие новых учетных записей, запланированных задач, служб, записей автозапуска, измененных файлов приложений, установленных web shell и признаков расширения атаки на другие системы.
- Устранение или удаление уязвимого пути. Недостаточно просто заблокировать обнаруженный адрес, завершить процесс или добавить индикатор в черный список.
- Перестроение среды, если невозможно подтвердить ее целостность. Для скомпрометированных контейнеров и immutable workloads затронутые экземпляры следует заменить новыми, созданными из доверенных образов. Для хостов необходимо действовать в соответствии с внутренним стандартом реагирования на инциденты, который определяет процедуры устранения угрозы и восстановления.
- Повторное тестирование затронутого приложения. Необходимо подтвердить, что первоначальный путь выполнения и все связанные с ним цепочки уязвимостей больше не пригодны для эксплуатации.
- Создание устойчивых правил обнаружения. Данные инцидента следует преобразовать в правила обнаружения на уровне процессов, сети, приложений, учетных записей и облачной среды, ориентированные на поведение, а не только на конкретный payload или адрес, зафиксированные во время инцидента.
В playbook CISA по реагированию на инциденты и уязвимости подчеркивается важность скоординированных процедур выявления, устранения, восстановления и отслеживания мер по минимизации последствий киберинцидентов и уязвимостей.
Это важно, поскольку простое завершение reverse shell без устранения первопричины лишь временно прерывает атаку.
Если уязвимый путь остается доступным, сессия, скорее всего, появится снова.
Как снизить риск reverse shell с помощью Invicti
Снижение риска reverse shell начинается еще до того момента, когда злоумышленник получает доступ к командной оболочке.
Ключевая задача заключается в своевременном выявлении уязвимостей веб-приложений и API, которые могут стать исходной точкой атаки: инъекций команд, удаленного выполнения кода, небезопасной обработки файлов и других injection-уязвимостей.
Платформа Invicti помогает находить такие слабые места в работающих приложениях и проверять, могут ли они быть реально использованы в ходе атаки.
Технология Proof-based Scanning для поддерживаемых классов уязвимостей позволяет безопасно подтвердить возможность эксплуатации и предоставить доказательства ее наличия.
Это помогает отделить подтвержденные риски от находок, которые все еще требуют дополнительного анализа, точнее определять приоритеты исправления и сокращать объем ручной проверки, особенно для инъекций и уязвимостей выполнения кода.
При этом тестирование безопасности приложений не заменяет EDR, SIEM, сетевой мониторинг, средства обнаружения угроз в облачной среде или инструменты реагирования на инциденты.
Именно эти средства отвечают за выявление и расследование активного поведения reverse shell уже во время выполнения.
DAST работает на более раннем этапе и помогает находить и устранять уязвимости, из-за которых такой доступ вообще может стать возможным.
В рамках комплексной программы AppSec регулярное сканирование веб-приложений и API также позволяет выявлять повторное появление проблем после изменений в коде или конфигурации и передавать результаты в уже настроенные процессы устранения уязвимостей.
Таким образом, Invicti уменьшает количество доступных для эксплуатации точек входа на уровне приложения и дополняет средства защиты, которые во время выполнения контролируют процессы, сетевую активность и другие признаки компрометации.
Запрос на бесплатное тестирование Invicti
Оставьте контакты и мы с вами свяжемся
