Forwarded from RedTeam brazzers (Pavel Shlundin)
"Как новый год встретишь, так его и проведешь!"
Все началось на новогодние праздники... В начале 2025 года (да, пост немного задержался))) ...
Ко мне в гости приехал мой хороший друг и программист @octet8 (спасибо тебе!). И в один прекрасный день я показал ему свой ldap_shell, рассказал про боль и главную проблему инструмента: инструмент изначально создавался как автономная версия модуля ntlmrelayx, и все написанные командлеты были методами класса LdapShell. Было очень легко просто скопировать готовый метод и перенести его в ntlmrelayx и получить больше опций при проведении ntlm relay атаки...
Но это несло и целую кучу проблем: контрибьютерам было сложно и непонятно, куда дописывать свои атаки, код разрастался... и один класс занимал уже тысячи строк кода, каждый раз при добавлении нового функционала приходилось вручную менять вывод команды help. В какой-то момент это все вышло из-под контроля, и так продолжаться дальше не могло. Поэтому мой друг помог мне переписать ядро инструмента и построить по-настоящему модульную архитектуру. В таком виде инструмент увидел свет в апреле этого года!
В конце 2025 года я не знаю людей, которые не используют в своей работе ИИ - новая архитектура как нельзя лучше подошла для интеграции с ИИ при разработке своих модулей.
Все модули аккуратно лежат в папке ldap_modules, каждый модуль имеет общий шаблон, в котором описываются основные составляющие модуля (такие как справка, пример использования модуля, класс ModuleArgs, использующий pydantic для описания и валидации аргументов модуля и его типов, а также метод
Если у вас возникает проблема с написанием модуля - вы можете посмотреть, как описаны подобные модули.
А теперь давайте поговорим про ИИ и его роль. ИИ очень любит понятный и небольшой контекст, а также любит делать небольшие файлики с кодом. Например, вам захотелось сделать модуль, который меняет конкретные биты в UAC - сделать это можно достаточно удобно из PowerShell, но если под рукой только Linux, то данная задача уже не выглядит так просто. Но на самом деле все проще, чем может показаться). В Cursor у меня уже был загружен проект ldap_shell, я открыл новый чат, перетащил ему в контекст папку и описал, что мне надо редактировать побитово атрибут userAccountControl, и о чудо! С первого раза и без единой ошибки был сгенерирован модуль uac_modify, который сразу работал и делал то, что я хочу. Данный модуль я решил оставить в неизменном виде именно так, как мне его сгенерил ИИ с первого раза :)
Теперь вы видите, как это стало легко и понятно, теперь вы можете очень удобно перенести свои костыли в аккуратный интерфейс ldap_shell или автоматизировать то, что выглядело ранее сложно и требовало пляски с бубном вокруг LDAP. Создавайте свои модули, делитесь ими и становитесь контрибьютерами!!! Лучшие модули я буду добавлять в инструмент.
Все началось на новогодние праздники... В начале 2025 года (да, пост немного задержался))) ...
Ко мне в гости приехал мой хороший друг и программист @octet8 (спасибо тебе!). И в один прекрасный день я показал ему свой ldap_shell, рассказал про боль и главную проблему инструмента: инструмент изначально создавался как автономная версия модуля ntlmrelayx, и все написанные командлеты были методами класса LdapShell. Было очень легко просто скопировать готовый метод и перенести его в ntlmrelayx и получить больше опций при проведении ntlm relay атаки...
Но это несло и целую кучу проблем: контрибьютерам было сложно и непонятно, куда дописывать свои атаки, код разрастался... и один класс занимал уже тысячи строк кода, каждый раз при добавлении нового функционала приходилось вручную менять вывод команды help. В какой-то момент это все вышло из-под контроля, и так продолжаться дальше не могло. Поэтому мой друг помог мне переписать ядро инструмента и построить по-настоящему модульную архитектуру. В таком виде инструмент увидел свет в апреле этого года!
В конце 2025 года я не знаю людей, которые не используют в своей работе ИИ - новая архитектура как нельзя лучше подошла для интеграции с ИИ при разработке своих модулей.
Все модули аккуратно лежат в папке ldap_modules, каждый модуль имеет общий шаблон, в котором описываются основные составляющие модуля (такие как справка, пример использования модуля, класс ModuleArgs, использующий pydantic для описания и валидации аргументов модуля и его типов, а также метод
__call__, содержащий основную логику модуля и т.п.).Если у вас возникает проблема с написанием модуля - вы можете посмотреть, как описаны подобные модули.
А теперь давайте поговорим про ИИ и его роль. ИИ очень любит понятный и небольшой контекст, а также любит делать небольшие файлики с кодом. Например, вам захотелось сделать модуль, который меняет конкретные биты в UAC - сделать это можно достаточно удобно из PowerShell, но если под рукой только Linux, то данная задача уже не выглядит так просто. Но на самом деле все проще, чем может показаться). В Cursor у меня уже был загружен проект ldap_shell, я открыл новый чат, перетащил ему в контекст папку и описал, что мне надо редактировать побитово атрибут userAccountControl, и о чудо! С первого раза и без единой ошибки был сгенерирован модуль uac_modify, который сразу работал и делал то, что я хочу. Данный модуль я решил оставить в неизменном виде именно так, как мне его сгенерил ИИ с первого раза :)
Теперь вы видите, как это стало легко и понятно, теперь вы можете очень удобно перенести свои костыли в аккуратный интерфейс ldap_shell или автоматизировать то, что выглядело ранее сложно и требовало пляски с бубном вокруг LDAP. Создавайте свои модули, делитесь ими и становитесь контрибьютерами!!! Лучшие модули я буду добавлять в инструмент.
GitHub
GitHub - PShlyundin/ldap_shell: AD ACL abuse
AD ACL abuse . Contribute to PShlyundin/ldap_shell development by creating an account on GitHub.
www.opennet.ru
Представлен capsudo, вариант sudo с разделением полномочий на уровне объектов
Ариадна Конилл (Ariadne Conill), создатель музыкального проигрывателя Audacious и композитного сервера Wayback, инициатор разработки протокола IRCv3 и лидер команды по обеспечению безопасности Alpine Linux, развивает инструментарий capsudo для выполнению…
🔗Ссылка:
https://opennet.ru/64420/
https://opennet.ru/64420/
www.opennet.ru
Уязвимость в утилите smb4k, позволяющая получить права root в системе
В утилите smb4k, применяемой в KDE для обнаружения и монтирования SMB-разделов, выявлены уязвимости, позволяющие получить root-доступ к системе. Проблемы устранены в выпуске Smb4K 4.0.5. Проверить состояние новой версии пакета или подготовки исправления в…
🔗Ссылка:
https://opennet.ru/64422/
https://opennet.ru/64422/
www.opennet.ru
Объявлены устаревшими 11 методов верификации доменов для TLS-сертификатов
Ассоциация CA/Browser Forum, выступающая площадкой для совместного принятия решений с учётом интересов производителей браузеров и удостоверяющих центров, утвердила новые требования к организациям, выдающим сертификаты для HTTPS. В новых требованиях объявлены…
🔗Ссылка:
https://opennet.ru/64426/
https://opennet.ru/64426/
Forwarded from purple shift
Уязвимость React2Shell (CVE-2025-55182) была раскрыта в начале декабря и наделала немало шума — поскольку затрагивает серверные компоненты React (RSC), которые используются во многих веб-приложениях.
Уязвимость оценивается как максимально опасная (CVSS 10.0) и уже активно эксплуатируется в дикой природе злоумышленниками, в том числе APT-группами.
React2Shell позволяет атакующему незамысловатым http-запросом получить удаленное выполнение кода на уязвимых серверах без всякой аутентификации. Минимально жизнеспособный эксплойт:
Эта уязвимость особенно критична из-за практически полного отсутствия артефактов. React не фиксирует происходящее, а у большинства из доступного будет лишь набор HTTP-логов, собираемых прокси.
Теоретически можно попытаться анализировать память процесса в поисках характерных сигнатур, но соотношение TP/FP будет крайне низким. В реальности в основном будем видеть нерелевантный трафик от сканеров и автоматических ботов, вместо того чтобы получать чёткие индикаторы эксплуатации уязвимости.
Сейчас атакующие активно перебирают весь спектр механизмов запуска процессов в Node.js:
Отсутствие единых стандартов журналирования в современных фронтенд-фреймворках создаёт дополнительные трудности для расследований. В результате успешная эксплуатация может оставаться незамеченной до тех пор, пока не проявятся косвенные признаки: аномальное поведение Node.js-процессов или подозрительные сетевые соединения.
На практике после успешной эксплуатации мы фиксируем один из вариантов (см. скриншот в начале поста):
— однострочная последовательность команд,
— закодированный в Base64 reverse shell,
— есть вариант in memory shell, встречали и его.
В основном фиксируем вариации команд для установок различных майнеров и приложений удаленного управления (RMM).
Что делать?
С точки зрения защиты:
— Пропатчить все уязвимые React / Next.js приложения до безопасных версий (19.0.1, 19.1.2, 19.2.1 и выше; Next.js с обновлённым RSC).
— Включить правила по обнаружению и предотвращению эксплуатации модифицированных RSC HTTP-запросов на периметре (WAF/IDS).
С точки зрения мониторинга:
— Отслеживать аномальные процессы от node.
— Отслеживать сработки WAF/IDS-решений на попытки эксплуатации этой уязвимости.
— Ретроспективно проверить активность на хостах с node.
Уязвимость оценивается как максимально опасная (CVSS 10.0) и уже активно эксплуатируется в дикой природе злоумышленниками, в том числе APT-группами.
React2Shell позволяет атакующему незамысловатым http-запросом получить удаленное выполнение кода на уязвимых серверах без всякой аутентификации. Минимально жизнеспособный эксплойт:
{
0: {
status: "resolved_model",
reason: -1,
_response: {
_prefix: "console.log('RCE')//",
_formData: { get: "$1:then:constructor" },
},
then: "$1:then",
value: '{"then":"$B"}',
},
1: "$@0",
} Эта уязвимость особенно критична из-за практически полного отсутствия артефактов. React не фиксирует происходящее, а у большинства из доступного будет лишь набор HTTP-логов, собираемых прокси.
Теоретически можно попытаться анализировать память процесса в поисках характерных сигнатур, но соотношение TP/FP будет крайне низким. В реальности в основном будем видеть нерелевантный трафик от сканеров и автоматических ботов, вместо того чтобы получать чёткие индикаторы эксплуатации уязвимости.
Сейчас атакующие активно перебирают весь спектр механизмов запуска процессов в Node.js:
- exec()
- spawn()
- execSync()
- spawnSync()
Отсутствие единых стандартов журналирования в современных фронтенд-фреймворках создаёт дополнительные трудности для расследований. В результате успешная эксплуатация может оставаться незамеченной до тех пор, пока не проявятся косвенные признаки: аномальное поведение Node.js-процессов или подозрительные сетевые соединения.
На практике после успешной эксплуатации мы фиксируем один из вариантов (см. скриншот в начале поста):
— однострочная последовательность команд,
— закодированный в Base64 reverse shell,
— есть вариант in memory shell, встречали и его.
В основном фиксируем вариации команд для установок различных майнеров и приложений удаленного управления (RMM).
Что делать?
С точки зрения защиты:
— Пропатчить все уязвимые React / Next.js приложения до безопасных версий (19.0.1, 19.1.2, 19.2.1 и выше; Next.js с обновлённым RSC).
— Включить правила по обнаружению и предотвращению эксплуатации модифицированных RSC HTTP-запросов на периметре (WAF/IDS).
С точки зрения мониторинга:
— Отслеживать аномальные процессы от node.
— Отслеживать сработки WAF/IDS-решений на попытки эксплуатации этой уязвимости.
— Ретроспективно проверить активность на хостах с node.