Столкнулся с интересным кейсом.
Инцидент с шифровальщиком, точка входа известна но сама машина пошифрована на уровне esxi.
На входной машине есть сервис, код закрыт, версия известна, но уязвимостей на него нет.
Перед шифрованием на машине сохранились логи auditd в коллекторе, по логам видно, что самый первый вредоносный процесс - это процесс сервиса, который торчал наружу, то есть классический внешний пробив и дальнейший RCE. Но публичных уязвимостей нет, логов тоже нет.
Происследовав сервис стало понятно, что за торчащие на внешку ручки отвечал один бинарник, более 10 МБ, C++, с символами.
И дальше начинается самое интересное, “а что если отдать ИИшке найти уязвимость” - подумал я…
И эта шайтан машина за 2 часа нашла мне два вектора эксплуатации heap overflow -> RCE через один механизм. За 2 часа бинарник в 10 МБ был препарирован и уязвимость найдена. Искал в Opus 4.8, заодно попробовал их новый механизм workflows, когда 15 агентов одновременно проверяли гипотезы.
По токенам, я ожидал, что он съест все лимиты, но нет, всего половину 5-часового лимита.
Конечно, конечный PoC генерировать мне он отказался, и несмотря на то, что весь флоу расписал, его, по хорошему, нужно провалидировать, но тем не менее.
За 2 часа я нашел очень правдоподобный вектор эксплуатации уязвимости в большом бинаре. Впечатляет…
Инцидент с шифровальщиком, точка входа известна но сама машина пошифрована на уровне esxi.
На входной машине есть сервис, код закрыт, версия известна, но уязвимостей на него нет.
Перед шифрованием на машине сохранились логи auditd в коллекторе, по логам видно, что самый первый вредоносный процесс - это процесс сервиса, который торчал наружу, то есть классический внешний пробив и дальнейший RCE. Но публичных уязвимостей нет, логов тоже нет.
Происследовав сервис стало понятно, что за торчащие на внешку ручки отвечал один бинарник, более 10 МБ, C++, с символами.
И дальше начинается самое интересное, “а что если отдать ИИшке найти уязвимость” - подумал я…
И эта шайтан машина за 2 часа нашла мне два вектора эксплуатации heap overflow -> RCE через один механизм. За 2 часа бинарник в 10 МБ был препарирован и уязвимость найдена. Искал в Opus 4.8, заодно попробовал их новый механизм workflows, когда 15 агентов одновременно проверяли гипотезы.
По токенам, я ожидал, что он съест все лимиты, но нет, всего половину 5-часового лимита.
Конечно, конечный PoC генерировать мне он отказался, и несмотря на то, что весь флоу расписал, его, по хорошему, нужно провалидировать, но тем не менее.
За 2 часа я нашел очень правдоподобный вектор эксплуатации уязвимости в большом бинаре. Впечатляет…