Fsecurity | HH

🔗Ссылка: https://opennet.ru/63489/

🥠 Cookie Tossing: когда поддомен подбрасывает «левую» cookie Cookie Tossing — малоизвестная, но серьёзная атака. Атакующий, контролирующий поддомен (например evil.example.com), устанавливает в браузере атакуемого cookie так, чтобы она применялась ко всему родительскому домену .example.com. Когда атакуемый открывает account.example.com или любой другой поддомен, браузер автоматически отправляет поддельную cookie, и сервер может обработать именно её. Так можно, например, привязать OAuth-токен к учётной записи атакующего, сбросить настройки или подменить сессию. 📌Как это работает Атака опирается на два параметра cookie: * Domain определяет, на какие хосты отправляется cookie. Если указать Domain=example.com, она уйдёт на все поддомены. * Path задаёт, к каким URL-ам применяется cookie. Более узкий путь (/settings/account) даёт ей приоритет над cookie с общим путём (/). 📌Как браузер выбирает cookie Если в браузере есть две cookie с одинаковым именем, он включает обе в заголовок Cookie, а порядок определяется так: 1. Сначала идут cookie, чей Path точнее совпадает с путём запроса. 2. При одинаковом пути первой идёт более старая cookie. Пример:

# cookie в браузере
session_cookie=<attacker>; Domain=example.com; Path=/settings/account
session_cookie=<victim>;   Domain=example.com; Path=/

# запрос к /settings/account
Cookie: session_cookie=<attacker>; session_cookie=<victim>

Большинство приложений используют первое значение, поэтому действие выполняется от имени атакующего. 📌Когда проверять на Cookie tossing * У сайта есть поддомены, и на них можно внедрить пользовательский JS/HTML. * Сессионная cookie выдаётся на весь домен (Domain=.example.com). * Важные эндпоинты (/auth/callback, /settings/account, /billing) не защищены CSRF-токеном. * Аутентификация основана только на cookie, без дополнительного заголовка или токена. 📌Как протестировать 1. Найдите XSS на поддомене. 2. Установите cookie с нужным Domain и «узким» Path:

document.cookie = "session_cookie=attacker_val; Domain=example.com; Path=/settings/account";

3. Если атакуемый переходит на account.example.com/settings/account и приложение выполняет действие в контексте атакующего либо подменяет сессию — уязвимость подтверждена. Удачной охоты! #техники #clientside

🔗Ссылка: https://opennet.ru/63487/

🔗Ссылка: https://specterops.io/blog/2025/06/26/misconfiguration-manager-still-overlooked-still-overprivileged/

🔗Ссылка: https://www.huntress.com/blog/recutting-the-kerberos-diamond-ticket

Сразу две статьи от SpecterOps, можно считать, одна - продолжение другой. В блоге разбирают атаки на трасты AD, но с упором на BloodHound CE. 1. Good Fences Make Good Neighbors: New AD Trusts Attack Paths in BloodHound 2. Untrustworthy Trust Builders: Account Operators Replicating Trust Attack (AORTA) Даже если не собираетесь погружаться в BHCE, стоит просто бегло почитать)) #pentest #redteam #ad #trust #lateralmovement #bloodhound

🔗Ссылка: https://www.securitylab.ru/news/560744.php

🔗Ссылка: https://www.securitylab.ru/news/560746.php

<продолжение> 🔥Проблема 3. Outlook и картинки Письмо уходит, всё работает. Верстаем шаблон, отправляем и…

❗ Для защиты вашей конфиденциальности изображения не загружены

Наши картинки не отображаются. Почему? Outlook по умолчанию блокирует все внешние изображения. 💡Что делаем: Первое, что можно попробовать - Base64:

<img src="data:image/png;base64,iVBORw...">

Способ хороший и отработает на большинстве современных почтовых клиентах. Однако Outlook все равно посчитает это внешним ресурсом и заблокирует. Второй способ - Content-ID (CID). Картинку прикладываем к письму как вложение, а в HTML пишем:

<img src="cid:image.jpg">

⸻ На этом все друзья! 🙂 А с какими проблемами сталкивались вы ? Делитесь в комментариях, обсудим вместе. 🤗 Ну и по традиции не забудьте подписаться на канал, если еще этого не сделали. И до новых встреч! #redteam

Всем привет! ❤️ Немного про социалочку. Когда проводишь проекты по социотехническому тестированию, нередко сталкиваешься с кучей технических нюансов. ❗️Это и попадание в списки подозрительных ресурсов, если вы случайно выкинули GoPhish наружу. ❗️И фильтрация писем почтовыми шлюзами. ❗️И особенности отображения у разных почтовых клиентов. Сегодня поговорим о том, с чем реально можно сталкнуться на практике. Особенно это актуально, если вы делаете такое впервые. 🔥Проблема 1. Как не попасть в списки злых хацкеров Если просто открыть GoPhish в интернет, то через какое-то время ваш IP будет помечен как подозрительный. 💡Что делаем: Используем связку из нескольких Nginx-прокси: • наружу отдаётся только IP внешнего прокси; • весь трафик уходит по VPN на внутренний сервер с GoPhish; • админка доступна только из VPN. Если не хочется поднимать VPN: На сервере с GoPhish закрываем 443 порт снаружи, кроме ip нашего прокси:

sudo iptables -I DOCKER-USER -p tcp --dport 443 ! -s <proxy_ip> -j DROP

В конфиге Nginx дополнительно прописываем кому можно обращаться к нашей фишинговой странице:

allow <proxy_ip>;
deny all;

Админку вешаем на 127.0.0.1 и подключаемся так:

ssh -L 8080:127.0.0.1:8080 user@server_with_gophish

Остается только настроить SSL для нашего фишингового домена. Теперь GoPhish не светится наружу, и мы спим спокойно. 🔥Проблема 2. Спам-фильтры и почтовые шлюзы Немного теории: • SPF — указывает, какие IP могут отправлять письма от имени домена. • DKIM — добавляет цифровую подпись к письмам. • DMARC — объединяет SPF и DKIM, говорит, что делать с письмами, которые не проходят проверки. Если вы некорректно настроите данные dns записи, то письма просто не дойдут до адресата. 💡Что делаем: Используем SMTP-сервисы с хорошей репутацией. Например, VK WorkSpace. Схема такая: • Подключаем фишинговый домен; • Сервис формирует SPF/DKIM/DMARC; • Копируем записи в DNS. Теперь письма проходят по всем стандартам (но это не точно). Но даже если всё идеально настроено, то ваши фишинговые письма могут быть заблокированы на почтовых шлюзах. Причина - Email-заголовки. Далее рассмотрим на примере с GoPhish: Еще немного теории. Сильно не пинайте - это важно для понимания: • Message-ID - уникальный идентификатор письма, формируется клиентом или сервером, помогает отслеживать сообщения и выстраивать цепочки переписки. • X-Mailer - указывает на почтовую платформу или внутренний ID отправителя. Именно они могут стать причиной того, что ваши фишинговы письма не дойдут до цели.

X-Mailer: gophish
Message-ID: <1743...@hostname>

X-Mailer палит GoPhish сразу. Message-ID генерируется с hostname контейнера или вашего сервера на котором крутиться GoPhish. Почтовые шлюзы могут блокировать письма, если видят несоответствие между Message-ID и доменами из SPF, DKIM, DMARC. 💡Что делаем: SMTP Relay с Postfix. GoPhish остаётся «тупым». Он просто отправляет письмо. А контейнер с Postfix: 1. Принимает письмо; 2. Переписывает заголовки; 3. Отправляет дальше на сторонний SMTP - сервис (в нашем случае VK Workspace) Файл smtp_header_checks:

/^Message-ID:/ REPLACE Message-ID: <CAFEBABE.20250324T1830@your_domain>

PS: X-Mailer можно убрать и через GUI GoPhish. А вот Message-ID просто так не убрать. Письма доходят, заголовки чистые. Все счастливы. #redteam

🔗Ссылка: https://habr.com/ru/companies/yandex/articles/911866/

PERSISTENCE Идея — использовать мало-заметный WinAPI-вызов RegisterApplicationRestart, который штатно предназначен для перезапуска «упавших» приложений, но в связке с «правильным» завершением системы можно превратить его в механизм персистентности. Для срабатывания перезапуска необходимо, чтобы перед выключением или рестартом был вызван ExitWindowsEx с флагом EWX_RESTARTAPPS (или InitiateShutdown c SHUTDOWN_RESTARTAPPS) — обычное «клик-по-Shutdown» этого не делает. Признаки: Появление ключей HKCU\Software\Microsoft\Windows\CurrentVersion\RunOnce\Application Restart #<n> сразу после начала выключения. Наличие структуры WER_PEB_HEADER_BLOCK в PEB процесса. https://blog.phantomsec.tools/phantom-persistence "Phantom Persistence | PhantomSec Blog"

CVE-2025-49144 * Notepad++ v8.8.1 * SYSTEM-level POC #win #lpe

🔗Ссылка: https://habr.com/ru/articles/920250/

Друзья, всем привет! Я наконец-то созрел и конвертировал текст своего выступления на CyberWave в статью. Любуйтесь злоупотреблением символическими ссылками на medium : ) https://cicada-8.medium.com/were-going-the-wrong-way-how-to-abuse-symlinks-and-get-lpe-in-windows-0c598b99125b

🔗Ссылка: https://opennet.ru/63464/

🔗Ссылка: https://slcyber.io/assetnote-security-research-center/novel-ssrf-technique-involving-http-redirect-loops/

AdaptixC2 v0.6 is out https://github.com/Adaptix-Framework/AdaptixC2 * Обновленная консоль агента с гибкими настройками * Оповещения в Telegram * OTP для синхронизации файлов и команд * Новая тема Dracula * Обновление до Golang 1.24.4 Полная информация по обновлению: https://adaptix-framework.gitbook.io/adaptix-framework/changelog/v0.5-greater-than-v0.6

🔗Ссылка: https://www.bleepingcomputer.com/news/security/bitopro-exchange-links-lazarus-hackers-to-11-million-crypto-heist/

А помните, мы рассказывали, как злоумышленники могут без авторизации производить перебор доменных пользователей через интерфейс MS-NRPC? На самом деле, это часть большого исследования нашего эксперта Хайдара Кабибо. Исследование посвящено одной из самых сложных технологий в ОС Windows: многоуровневой системе коммуникации Inter-Process Communication (IPC). Частью этой системы является и протокол RPC (Remote Procedure Call), который используется в упомянутой выше атаке. Недавно Хайдар начал публиковать полную версию своего исследования в виде серии блоговых постов, и вы уже можете ознакомиться с некоторыми из них. Первая часть представляет общий план исследования: оно покрывает все четыре уровня организации IPC, от самого высокого (DCOM) до технологий уровня ядра (Named Pipes, ALPC). Во второй части автор разбирает интерфейс RPC и показывает, как создавать собственные RPC-серверы и клиенты. Третья часть посвящена дескрипторами привязки (Binding Handles), которые используются в RPC для управления соединениями между сервером и клиентом. А в четвёртой части вы узнаете, как организована безопасность RPC. Здесь и объясняется, почему некоторые действия в этом протоколе можно выполнять с более низким уровнем аутентификации, чем вы ожидали; в частности, интерфейсы многих RPC-северов разрешают доступ безо всякой авторизации вообще. И это ещё не всё! Продолжение исследования – читайте в блоге Хайдара по мере публикации.