Umbryx — Модуль Attacker SSH¶

Назначение¶

Workstations Модуль attacker SSH — это транспорт исполнения для инструментальных и операторских действий, которые выполняются на подконтрольной атакующему машине.

Он используется:

прямым выполнением команд атакующего
сканами вроде Nmap, Nuclei, NetExec
массовым выполнением
валидацией учётных данных
шагами плейбуков, зависящими от исполнения на стороне атакующего

Что это такое¶

Этот модуль — не просто экран настроек. Это runtime-зависимость для большой части слоя оркестрации.

На практике он выступает как:

транспорт исполнения + инвентарь целей атакующего + логика выбора фолбэка

Основные компоненты¶

Области бэкенда:

backend/app/routers/system_modules.py
backend/app/routers/attacker_exec.py
backend/app/routers/scans.py
backend/app/routers/bulk_actions.py
backend/app/core/ssh_exec.py
backend/app/plugins/state.py

Области фронтенда:

frontend/src/views/ConnectionsView.jsx (Infra → Connections; сама панель — frontend/src/components/AttackerSSHPanel.jsx)
frontend/src/views/ScansView.jsx
frontend/src/views/HostsView.jsx
frontend/src/views/CredsView.jsx
frontend/src/views/CheatsheetView.jsx

Хранение данных¶

Конфигурация хранится в global_settings под ключами конфигурации attacker SSH.

Сохраняемые цели включают:

глобальные цели
цели в рамках проекта
опциональные настройки транспорта proxy/jump-host
опциональные настройки контекста proxy/jump на слое исполнения
зашифрованные пароли и приватные ключи

Чувствительные поля шифруются через core/crypto.py.

Функциональное покрытие¶

Реализовано¶

управление SSH-целями атакующего администратором
видимость целей глобально и в рамках проекта
тестирование соединения
прямое выполнение команд
запуск сканов через цель атакующего
массовое выполнение через цель атакующего
валидация учётных данных через цель атакующего
создание задач для потоков исполнения
опциональный режим jump-прокси с отдельными учётными данными бастиона
опциональный режим socks5-прокси через SOCKS-транспорт на стороне бэкенда
отдельный сетевой контекст слоя исполнения для сканов и attacker-exec
автоматическая обёртка удалённого SOCKS для поддерживаемых потоков команд/сканеров через proxychains
экспортируемые переменные окружения jump/proxy исполнения для удалённых команд

Частично¶

исполнение работает как транспорт, но всё ещё зависит от нескольких обёрток, специфичных для эндпоинтов
отложенное (queued) исполнение поддерживается только для отдельных операций

Отсутствует¶

отдельный объект-сервис, единообразно потребляемый всеми эндпоинтами исполнения
более богатый мониторинг здоровья целей
сохранённые пресеты исполнения на уровне транспорта

Текущая логика выбора цели¶

Логика исполнения может резолвить из:

хоста атакующего проекта
связанного учётной записи на хосте атакующего
глобальной цели атакующего

Типичный приоритет:

явный хост проекта
явная глобальная цель
первый подходящий хост атакующего проекта с пригодным учётной записью
первая подходящая глобальная цель для проекта

Текущее улучшение:

когда поток использует глобальные цели атакующего и явная цель не выбрана, Umbryx может ранжировать подходящие цели по наблюдаемым pivot-маршрутам
ранжирование с учётом маршрутов сейчас использует активные pivot_observations.route_cidr
если маршрут пересекается с запрошенной целью скана или IP/CIDR, найденным в команде, цель этого коллектора предпочитается
если совпадения маршрута нет, выбор возвращается к прежнему порядку

Режимы прокси¶

SSH-цели атакующего теперь могут определять опциональный транспортный слой перед финальной SSH-целью.

Важно: Umbryx теперь различает два разных сетевых слоя.

Слой 1. Транспорт до атакующего¶

Управляет тем, как сам Umbryx достигает машины атакующего.

Поддерживаемые режимы:

none
прямой SSH до целевого хоста
jump
сначала SSH до бастиона/jump-хоста, затем -W %h:%p до финальной цели
поддерживаются отдельные учётные данные jump-хоста
socks5
финальное SSH-соединение использует SOCKS5-прокси-эндпоинт на стороне бэкенда
поддерживается опциональная аутентификация SOCKS5 username/password

Это предназначено для поддержки:

доступа внутрь через бастион
доступа по цепочке прокси в pivot-окружениях
интеграции с рабочим процессом pivot, где chisel/SOCKS уже развёрнут

Слой 2. Исполнение от атакующего¶

Источник исполнения для сканов больше не должен настраиваться глобально в настройках цели атакующего.

Текущее направление:

выбор источника исполнения в момент скана
attacker host
pivot listener
опции pivot listener берутся из активных pivot_observations с адресами привязки
поддерживаемые потоки сканов могут обёртывать удалённое исполнение через выбранный pivot-listener

Текущее ограничение:

этот селектор во время скана сейчас является правильным местом для решения, откуда должны запускаться сканы
он намеренно отделён от транспорта, используемого для достижения самого хоста атакующего

Роль в задачах и плейбуках¶

Модуль теперь участвует в задачах через:

connector_key="attacker_ssh"
операции вроде:
exec
bulk_exec
cred_validate

Он также используется в шагах плейбуков через шаблоны шагов.

Слабые места¶

логика выбора исполнения всё ещё дублируется в некоторых роутерах
отложенное (queued) исполнение пока поддерживается не для каждого потока на базе attacker SSH
результаты исполнения ещё не сгруппированы в отдельном представлении истории исполнения помимо задач и активностей хостов