- Що таке 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, типові шаблони корисного навантаження, ознаки для виявлення, засоби запобігання та вебвразливості, які можуть зробити зворотнє підключення можливим.
Матеріал не містить готових до виконання корисних навантажень, команд для запуску слухача, інструкцій із покращення оболонки, методів обфускації чи вказівок для отримання несанкціонованого доступу.
Що таке reverse shell?
Reverse shell – це техніка віддаленого доступу, за якої скомпрометована система сама ініціює вихідне з’єднання із зовнішнім хостом і надає через нього доступ до командного підключення.
Зловмисники часто намагаються отримати reverse shell після експлуатації вразливостей, які дозволяють виконувати команди або код. До них належать ін’єкція команд операційної системи (OS command injection), віддалене виконання коду (RCE), небезпечне завантаження файлів, ін’єкція в серверні шаблони (SSTI), небезпечна десеріалізація та ланцюжки вразливостей типу injection.
Ключове слово тут – «reverse», тобто зворотний напрямок з’єднання.
У типовому сценарії віддаленого доступу оператор підключається до системи ззовні. У випадку reverse shell цільова система сама встановлює вихідне з’єднання.
Ця відмінність має принципове значення, оскільки більшість організацій значно суворіше обмежують і контролюють вхідні з’єднання, ніж вихідні. Сервер може бути недоступним безпосередньо з Інтернету, але водночас мати дозвіл на вихідні з’єднання з API, службами оновлення, платформами журналювання, репозиторіями пакетів та іншими зовнішніми системами.
Зворотнє підключення намагається використати такий дозволений канал вихідного трафіку.
Тобто, воно є технікою, що застосовується після успішної експлуатації вразливості, а не самою початковою вразливістю.
Оболонка є наслідком успішної експлуатації. Першопричиною зазвичай є вразливість, яка дозволила зловмиснику виконати код, запустити системну команду, завантажити виконуваний вміст або отримати доступ до іншої служби, здатної виконати такі дії.
Ін’єкція команд операційної системи є класом вразливостей, який зазвичай створює найбільш прямий шлях від вразливості до доступу до командної оболонки.
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 зазвичай поєднують три елементи:
- Вихідне мережеве з’єднання.
- Механізм, який прив’язує введення та виведення команд до цього з’єднання.
- Командний інтерпретатор або інший механізм виконання команд.
Для розпізнавання такої поведінки фахівцям із захисту не потрібні готові робочі рядки запитів.
Важливо розуміти, який процес створив з’єднання, який дочірній процес було запущено, який обліковий запис використовувалася та чи є така послідовність нормальною для відповідного робочого навантаження.
Наведені нижче приклади описують загальні категорії запитів без синтаксису, команд, налаштування слухача або практичних інструкцій із використання.
| Категорія запитів | Принцип роботи | На що слід звертати увагу фахівцям із захисту |
| Bash reverse shell payload | Процес командної оболонки відкриває вихідне з’єднання та перенаправляє через нього введення і виведення | Вебпроцес або процес застосунку запускає командну оболонку, після чого з’являється неочікуваний вихідний трафік |
| Netcat reverse shell payload | Мережева утиліта підключається до зовнішнього хоста та пов’язує це з’єднання з командним інтерпретатором | Утиліти на кшталт Netcat на серверах, особливо якщо їх запускають вебпроцеси, застосунки, бази даних або скриптові середовища |
| Python reverse shell payload | Середовище виконання скриптів створює вихідний сокет, пов’язує його з введенням і виведенням процесу та запускає командну оболонку | Python встановлює прямі вихідні з’єднання та запускає дочірню командну оболонку або системні команди |
| PowerShell reverse shell payload | Скриптове середовище Windows створює вихідну сесію, отримує команди та повертає результати їх виконання | Мережева активність PowerShell, незвичні батьківські процеси, закодовані або надзвичайно довгі командні рядки та підозрілі дочірні процеси |
Назви мов і утиліт можуть бути корисними пошуковими ознаками, однак механізми виявлення не повинні залежати від фіксованої сигнатури запитів.
Зловмисники можуть змінювати синтаксис, використовувати інший інтерпретатор, перейменовувати утиліти або покладатися на вбудовані можливості середовища виконання.
Тому кореляція поведінкових ознак є більш стійким підходом.
Ознаки 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 у контейнері, віртуальній машині, середовище збірки або serverless-навантаженні можуть з’явитися звернення до метаданих, сканування внутрішніх служб, використання облікових даних або незвичні виклики API площини керування.
Варто перевіряти:
- Неочікуваний доступ до служб метаданих інстансів або контейнерів.
- Зовнішні напрямки, яких немає у затвердженому списку залежностей робочого навантаження.
- Інтерактивні командні оболонки або виділення термінала у робочих контейнерах.
- Нові дочірні процеси у мінімальних або distroless-образах, тобто мінімальних образах без менеджера пакетів або командної оболонки.
- Активність сервісного облікового запису, яка починається одразу після підозрілої сесії.
- Незвичні звернення до менеджерів секретів, об’єктних сховищ, сервісів облікових записів або API оркестрації.
- East-west трафік з ураженого робочого навантаження до внутрішніх служб.
- Зміни образу контейнера, модифікації writable layer або поява нових змонтованих шляхів.
- Активність середовища збірки або 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 |
| Посилення контролю вихідного трафіку | Дозволяти робочим навантаженням лише затверджені адреси та порти |
| Посилення захисту застосунків | Уникати запуску оболонки, перевіряти вхідні дані, захищати завантаження файлів, обмежувати інтерпретатори та застосовувати принцип мінімальних привілеїв |
| Посилення захисту контейнерів | Використовувати мінімальні образи, видаляти непотрібні привілеї, обмежувати права запису та видаляти невикористовувані інструменти |
| Перевірка виправлень | Повторне тестування за допомогою 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 зменшує кількість доступних для експлуатації точок входу на рівні застосунку, доповнюючи засоби захисту, які вже під час виконання контролюють процеси, мережеву активність і ознаки компрометації.
