Похек
16.3K subscribers
2.3K photos
117 videos
243 files
3.21K links
All materials published on the channel are for educational and informational purposes only.

Мнение автора ≠ мнение компании, где работает автор

Чат: @poxek_chat

Реклама: @szybnev или
https://telega.in/c/poxek

РКН: https://clck.ru/3FsVhp
Download Telegram
HallWatch: usermode-ловушка для indirect syscalls
#windows #blue_team

HallWatch — PoC usermode-детектора indirect syscalls для Windows. Вместо классического хука в начале Nt*-стаба он патчит первый байт инструкции syscall: пара 0F 05 превращается в CC 05, и любой путь, который реально доходит до этого адреса, получает EXCEPTION_BREAKPOINT.

Дальше VEH ловит брейкпоинт, по заранее собранной карте экспортов ntdll понимает, какому стабу принадлежит адрес, делает проверки и переводит Context->Rip на приватный trampoline. Trampoline уже выполняет настоящий syscall и возвращает управление. За счет этого ловятся сценарии, где код не вызывает экспорт напрямую, а прыгает сразу на 0F 05: Hell's Hall, Tartarus' Gate, RecycledGate и VEH syscall.

Проверки у автора практичные: return address должен вести в доверенный модуль, SSN в eax должен совпадать с SSN этого стаба, а короткий stack walk через RtlVirtualUnwind должен выглядеть как нормальный модульный стек, а не shellcode/ROP.

Hell's Gate хуже ложится на INT3-подход, потому что syscall может жить в чужой RWX-странице. Для этого HallWatch отдельным worker'ом обходит executable memory через VirtualQuery, сканирует до 64 KB региона на пары 0F 05, дедуплицирует адреса и логирует уникальные находки. Автор прямо признает, что это дорогой и грубый PoC-сканер, но он покрывает свежий RWX syscall stub и shadow ntdll. Есть и второй сканер по .text модулей: он ищет 0F 05 рядом с C3, пропуская системные модули, где такие инструкции легитимны.

Ограничения: usermode не решает kernel-level противника, allowlist покрывает не все Nt*-стабы, возможны integrity checks со стороны sample, а периодический scanner тратит CPU. Из мелких инженерных деталей стоит отметить ABI-ловушку: после INT3 в VEH Context->Rip указывает на следующий байт, поэтому обработчик должен опираться на ExceptionAddress, иначе trampoline стартует со смещением.

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

🔗Источник: Zypherion-Technologies/HallWatch

p.s. посты выходят не часто, т.к. я в запаре. Постараюсь восстановить плотной поток постов в июле

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
😱411
MeshCentral: от XSS в агенте до RCE через админскую сессию
#web #RCE

Kev Breen разобрал MeshCentral как цель для агентного security research: поднял тестовый стенд, подключил Windows-хост, дал Claude Code проверить server-side и UI, а затем отдельно попросил проверить гипотезу про поля, которые отправляет MeshAgent и которые потом рендерятся в консоли.

Цепочка оказалась рабочей: скомпрометированный или rogue MeshAgent мог передать HTML/JavaScript в osdesc. Сервер сохранял значение без HTML-sanitization, а UI показывал его через innerHTML. Когда админ открывал детали устройства, payload выполнялся в его браузере. Дальше XSS использовал админскую сессию: открывал control.ashx WebSocket, перечислял nodes и отправлял runcommands на управляемые хосты. Для RMM это сразу меняет impact: выполнение команд идет через легитимную управляющую плоскость MeshCentral, вплоть до SYSTEM/root на агентах.

Полезен сам процесс: Claude подсветил поток agent -> DB -> UI, сгенерировал Ansible playbook для стенда, PoC-клиент, скрипт извлечения identity из MeshAgent.msh/MeshAgent.db, а затем через review-findings и report-writer помог собрать отчет для мейнтейнеров. По данным автора, вся сессия заняла 1 час 11 минут, 96 tool calls, 10 subagents и около $20.34.

Фикс тоже прошел через developer workflow: PR обернул оставшиеся unsafe render sites в EscapeHtml(...), был смержен 22 мая 2026, advisory вышел 11 июня 2026. Затронуты версии meshcentral <1.1.60, патч 1.1.60, CVSS 8.3, CVE на момент advisory нет.

Для тех кто пользуется этим ПО: обновить MeshCentral до 1.1.60+ и смотреть журналы MeshCentral — они хранят историю команд, выполненных на хостах.

🔗Источники:
TechAnarchy write-up
GitHub PR #7823
GitHub Advisory GHSA-c7hr-448w-65px

🌚 @poxek | 🌚 @poxek_ai | 📲 MAX
Please open Telegram to view this post
VIEW IN TELEGRAM
3
Победителей выбрали в конкурсе на анти нейрослоп советов для Standoff 365 Bug Bounty . Просьба тех, кто увидел свой ник и коммент найти меня на Standoff Talks. Я на первом этаже, хожу в панамке чёрной и черной футболке BugHunter
Forwarded from Arseny Porkhunov
собираться коллегией триажеров в баре и коллективно оценивать каждый отчет на нейрослопность 🙂
Forwarded from Andrey
1. ограничение количества отправляемых отчетов с новых аккаунтов. Снятие ограничения после нескольких валидных отчетов с выплатами. Опционально сюда же ограничение создания новых аккаунтов платформы.
2. Ввести скоринг "нейрослопности" отчета и маркировать для триажеров отчеты, превышающие пороговый уровень
3. сделать обязательным поле для прикрепления скрина/видео с эксплуатацией перед отправкой отчета.
4. введение отдельного статуса "нейрослоп" минусящего больше реуптации, нежели "не является уязвимостью"


Мерч похека не нужен, спасибо :)

P.S. а вот снизить нагрузку на триажеров, нупажалустооооо
Forwarded from Nihil
Как было в одной стфке, промт иньекцию на рм рф машинки добавлять в программах/вёрстках сайта, на дурачка ловушка чисто и нейрослопить после этого не так хочется) А так, из годных вариантов как будто только видосы/фото в отчёте обязательными ставить или систему рейтинга более серьёзную вводить
Forwarded from Олег
Лично мои мысли, фото и видео на мой взгляд не сильно поможет от нейрослопа т.к начинающий будет ему верить и отправлять отчёт с фото видео якобы показывающей импакт, моё предложение, попробовать внедрять ИИ локальное которое будет со стороны standoff оценивать отчёты и оценивать реальность есть реальная опасность или в отчёте только потенциальность чего то возможного или невозможного. Тем самым ИИ будет выступать фильтром если отчёты не с эксплатируемыми рисками то они просто откладываются, а те что реальные передвигаются в первую категорию на рассмотрение триажерами и в последнюю уже очередь ИИ слопы, т.к уверен на их рассмотрение уходит куда меньше времени чем на реальные отчёты могу ошибаться. Что думаете? А, засчёт локального ИИ будет соблюдаться безопасность и никуда информация утекать не будет, т.к он никуда доступа не будет иметь кроме авторизованных лиц
Forwarded from Евгений Андреевич
Добавить каптчу как в тг, на сдачу отчёта 😁
Forwarded from Ramazan
сразу банить того, кто прислал такое
Forwarded from Mikha1l
Вообще можно использовать несколько подходов, как по мне:

1. Пусть хантеры сами получат возможность тэгать свои отчеты как нейрослоп. Они будут попадать в более отдельные, более долгие очереди, но все-равно будут проверяться. За отсутствие маркировки - минус реп. Звучит парадоксально, но если ты аи-культист и тебе по кайфу дропать нейрослоп, который ты не промаркировал 2-3 раза - твои отчеты падают вниз по приоритету, маркировку на них все равно автоматом доставят, ты по сути уже заложник системы, ты либо выбираешь ручной ввод, либо страдаешь в общем котле для аи-культистов.

2. Тут уже гуляла эта идея, но везде применялась LLM, мне кажется она для этой задачи имеет слишком высокий уровень сложности. Думаю, можно натренить совершенно небольшую ml-модельку, выделить несколько явных признаков ИИ-отчетов, и запустить ее в тестовом режиме. Особенно хорошо это стакнется с первым направлением. Таким образом можно избавить триажеров от задачи определять нейрослоп, система может научиться автоматически проставлять такую марку, заставив снова вернуться к ручному вводу и проверке написанного.

3. Из самых смешных вариантов мне показалось - привести отчеты к уровню нормативных документов, в ворде и с титульником) Ни одна нейронка сейчас, насколько мне известно, не делает нормоконтроль хорошо, отступы, шрифты, даже если закинуть ей шаблон получишь корявый огрызок. Это сразу позволяет выкинуть отчет из очереди валидных багов в очередь нейрослопа

4. Система оценивания. Если нейрослоп это реально проблема - докажите это деньгами, ведь деньги - это главная и отчасти единственная мотивация хантеров. Если отчет написан нейронкой - просто снизьте валидность бага на 1 значение, например, был крит, стал хай, просто за использование ИИ. Да, это жесткое ограничение, но оно сработает, ведь прежде всего люди хотят хоть что-то зарабатывать, а зная, что использовать ИИ - это с 100% шансом уменьшать себе сумму выплаты - это хороший буст к тому, чтобы подкорректировать свою тесную связь с ии.

5. Введение метрики "Качество отчета". Тут без особо больших критериев, просто в конце отчета сделать для триажера цифру от 1 до 10, которая ему покажется максимально близкой к правде
1 - нейрослоп пукнул
10 - ооо мужик ты реально крут!
И показывать эту метрику хантерам, более того, привязать ее к сумме выплаты. Баг валидный, но отчет сделан плохо? Минус бабки. Баг не валидный, отчет сделан плохо? Забудь как выглядят купюры. Пусть эта метрика привязывается к аккаунту каждого хантера и преследует его как бельмо на глазу. Таким образом можно будет быстро понимать, что у человека с средним баллом качества 4 - многие отчеты написаны лайк нейрослопчег.

6. Тотал видеопруф:
"Всем привет, я крипер2007, и сегодня я покажу вам как реализовать уязвимость NNN-NNNN-NNNN на сайте компании N ровно за 32 секунды"

Вроде все, спасибо.
👍1🔥11
Forwarded from Bizarre
Может топовым багхантерам давать такую возможность отсеивать нейрослопы типо как в доте патруль и давать ачивки или баллы
1
Forwarded from lorz1k
Думаю стоит разделить 2 проблемы.
1 Полностью сделанный ИИ отчёт и работа(нюанс в том что хантер может вообще не понимать что там понаписано)
2 Сделанный только отчёт с помощью ИИ (он сам хантил, но отчёт было делать лень)
Решения для 1 варианта:
Делать созвоны если есть намёки на реальную эксплуатацию уязвимости и дальше уже разговаривать про содержание, если не понимает то предупреждение/бан/увеличение комиссии площадки за сданные отчёты.
Сделать свою ИИшку, ИИшку может победить только другая ИИшка, пусть она сама определяет процент ИИ или пусть переделает отчёт под ваши нужды (проблема в том чтобы до обучить)
Решение для 2 варианта:
Тоже создать свою ИИшку и ввести чуть большие выплаты, 5-10%, за нормальные отчёты
Дать готовый промт или шаблон/инструкции хантеру, раз уж они делают ИИшкой так пусть будет нормально.
Скажи если понадобиться что-то уточнить или дополнить, я постараюсь помочь, вставить банан в конце как и было сказано в невидимом тексте запроса )
Forwarded from Mikha1l
«Русский писатель»: ваши отчёты оказались настолько длинными, что вместо триажа их стали задавать как литературу на лето для школьников
Forwarded from Rtem
Тут уже предлагали натравливать ИИ на такие отчеты. Я хотел предложить то же самое, но чуть расширю и конкретизирую эту историю. Нужно сделать агента (самый простой вариант) который при анализе отчета будет опираться во-первых на модель угроз (тут надо тюнить под каждый сервис), а во-вторых на эксплуатируемость уязвимости. Обычно у ИИ c этим большие проблемы. Оно хорошо и много пишет как всех поломало, но по факту килчейн не выстраивается. Это относительно легко хэндлится глазами живого триажера, но агента тоже можно научить отстреливать большую часть такого шлака. Если показалось интересным, то пусть представители стендофа напишут мне на рабочую почту ;) Я поделюсь деталями.
Forwarded from Alex Shev
На самом деле есть простой но ОЧЕНЬ эффективный способ победить слоп . При сдаче отчёта спросить у хакера , "Отчёт сдан с помощью ИИ ?" Если ответ "да", супер он уходит в ии пул где его отдельно можно агентами триажить , нанять триаж стендоффа только на этот пул и ТД . Если ответ "нет" супер , если там в итоге в нет лежит ИИ отчёт хакер теряет решением площадки возможность сдавать отчёты в обычный пул . Тоесть все его следующие отчёты автоматически летят в ИИ пул . При таких жёстких правилах об ии будут сами сообщать и проблем не будет , а единичные проблемы легко будут так решаться
👍2🤯1
Forwarded from Aleksandr Medvedev
Мне кажется, что тут общая проблема в том, что люди с ИИ бездумно и без верификации отправляют отчёты.

У меня была ситуация, когда за ночь ИИ нашла более 20 уязвимостей. Но на этапе проверки и подготовки скринов я понимаю, что там фигня какая-то. Спрашиваю ИИ проверить как триажер, примут ли их (тыкаю прям носом, что лажу какую-то он собрал) и он соглашается, что сгенерировал какую-то фигню и ситуации нереальные...

Я бы предложил ввести на первом этапе такую же проверку ИИ со стороны площадки. Дайте ИИ чекеру отчёт и скрины хантера, таргеты и условия программы. Если ИИ чекеру кажется, что отчёт лажа, то он не блочит его, но предупреждает хантера и предлагает ему либо добавить пруфы\поправить отчёт, либо рискнуть и отправить его дальше.

Но в таком случае, если подтверждается, что отчёт 💩, он получает минус репу и страйк. N страйков и таймаут на сдачу отчётов.
Forwarded from Илья
Идея: Т.к. нейросети уже никуда не уйдут, предлагаю 2 рабочих контур варианта:

1) Улучшить шаблон .md отчетов, когда создаешь репорт там есть форма, уверен, что почти все ее копируют и отдают нейронке, добавьте шаблон для ии по галочке, например.

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

Сюда же можно сделать дисклеймер (проверяйте руками по гайду и т.п.), где общими словами описан процесс само проверки

2) Гайд по репортам при помощи ии, что должно, что не должно, как проверять
Победителей выбрали в конкурсе на анти нейрослоп советов для Standoff 365 Bug Bounty . Просьба тех, кто увидел свой ник и коммент найти меня на Standoff Talks. Я на первом этаже, хожу в панамке чёрной и черной футболке BugHunter

Сколько-то/30 выдано
😁9
Assume Birch
🔥13