incident_report_final.pdf
656.5 KB
Подписчики канала заметят, что я немного хайплю на теме LLM. И не просто так. Давеча я уже писал про применение llm в реверсе (статическом анализе). Но в этой сфере я не эксперт, поэтому пойдем далее.
А что если научить LLM в DFIR, подумал я. Как мы знаем, dfir - область чувствительная и с достаточно большим (огромным) контекстом. И просто так натравить LLM на артефакты не выйдет. Здесь нет простого решения вроде IDA Pro, которая подходит для большинства бинарных файлов, все артефакты разные, системы разные, все разное.
К этому всему еще добавляется опыт, методологии, фреймворки и бла бла бла...
Но если всем этим не заморачиваться и дать YOLO mode для llm, что у нас получится?
Недавно, один из заокеанских экспертов выложил челендж по linux форензике. Про него мне рассказала моя знакомая, за что ей спасибо (Аня, передаю привет, я в телевизоре). Так как челендж уже закончен, можно кидать спойлеры. Внутри архив с UAC+memory dump.
Я сделал мультиагентную систему, которая провела полное расследование кейса, среди ролей были: дфир спец, реверс, verifier и report writer. Все это было через внутренние модели, без frontier opus 4.6 (уже 4.7) или GPT Pro.
В приложении я прикладываю финальный отчет агента по этому кейсу. Этот анализ не претендует на полноту или на абсолютную точность. Но можно согласиться, что выглядит очень круто.
У этой системы есть очень много узких мест, в которые она упиралась и упирается, над чем я сейчас и работаю.
Как доведу до какого-то персистентного состояния - обязательно расскажу.
А что если научить LLM в DFIR, подумал я. Как мы знаем, dfir - область чувствительная и с достаточно большим (огромным) контекстом. И просто так натравить LLM на артефакты не выйдет. Здесь нет простого решения вроде IDA Pro, которая подходит для большинства бинарных файлов, все артефакты разные, системы разные, все разное.
К этому всему еще добавляется опыт, методологии, фреймворки и бла бла бла...
Но если всем этим не заморачиваться и дать YOLO mode для llm, что у нас получится?
Недавно, один из заокеанских экспертов выложил челендж по linux форензике. Про него мне рассказала моя знакомая, за что ей спасибо (Аня, передаю привет, я в телевизоре). Так как челендж уже закончен, можно кидать спойлеры. Внутри архив с UAC+memory dump.
Я сделал мультиагентную систему, которая провела полное расследование кейса, среди ролей были: дфир спец, реверс, verifier и report writer. Все это было через внутренние модели, без frontier opus 4.6 (уже 4.7) или GPT Pro.
В приложении я прикладываю финальный отчет агента по этому кейсу. Этот анализ не претендует на полноту или на абсолютную точность. Но можно согласиться, что выглядит очень круто.
У этой системы есть очень много узких мест, в которые она упиралась и упирается, над чем я сейчас и работаю.
Как доведу до какого-то персистентного состояния - обязательно расскажу.
🔥4🍓1🦄1
Немного DFIR staff
А вы знали, что в 2026 все еще ломают через ProxyShell?
Если вы тоже столкнетесь с такой ситуацией, то, вероятно, увидите не один и не два веб шела.
В этом случае интересно восстановить, с какой интенсивностью и как часто пробивали сервер.
Но многих файлов может уже не быть, логи затерты, следов не осталось. В таком случае можно пойти и посмотреть:
-
Внутри будет либо скомпилированный код, либо просто кеш используемых NET модулей. Важно, что здесь данные появятся только при исполнении кода, в случае с веб-шеллом - при первом обращении к нему.
Так, я смог восстановить информацию, что шелы были и в 2022 году на этом сервере, хотя ни логов, ни самих шелов уже давно нет.
А вы знали, что в 2026 все еще ломают через ProxyShell?
Если вы тоже столкнетесь с такой ситуацией, то, вероятно, увидите не один и не два веб шела.
В этом случае интересно восстановить, с какой интенсивностью и как часто пробивали сервер.
Но многих файлов может уже не быть, логи затерты, следов не осталось. В таком случае можно пойти и посмотреть:
-
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\e22c2559\92c7e946\Внутри будет либо скомпилированный код, либо просто кеш используемых NET модулей. Важно, что здесь данные появятся только при исполнении кода, в случае с веб-шеллом - при первом обращении к нему.
Так, я смог восстановить информацию, что шелы были и в 2022 году на этом сервере, хотя ни логов, ни самих шелов уже давно нет.
👍3🦄1
Заметки на полях вайбкодинга.
Вообще я по жизни не программист, но в ходе своего профессионального и личного развития часто сталкивался с написанием скриптов, автоматизациями и в целом анализом кода (было время - фаззил PostgreSQL даже и анализировал уязвимости в ядре Linux). В итоге это сформировало общее понимание написания хорошего кода и устойчивых систем без самого навыка, ну может быть чуть-чуть.
Начиная с момента, когда я начал программировать, я написал сам десятки-сотни тысяч строк различного кода, но начиная с начала 2026 года я отдал мейнтейнить свои системы агентам. Где-то это открытые ллм, где-то внутри контура, но код я сам писать перестал вообще, кроме каких-то узких ситуаций.
Опущу свои восторженные нахваливания ИИ в этом вопросе (поверьте, если ставить правильно задачу и вы не senior software engineer - то LLM пишет код лучше вас), и остановлюсь на своем опыте использования двух frontier продуктов Codex и Claude Code с точки зрения человека, разрабатывающего различные продукты и в ИБ и в ИТ сейчас, но не являющегося программистом.
Мои впечатления
Codex
Сразу бросается в глаза что Codex - это продукт для масс. Очень много коннекторов, графический интерфейс, мини браузер прям в приложении, возможность выбора темы, интеграция с приложениями на десктопе и так далее. Это все создает очень большую вариативность по сценариям использования и выглядит понятно для обывателя.
Вместе с тем есть и огрехи: отображение оставшегося количества токенов не всегда интуитивное, иногда вообще неясно, что делает llm с кодом (как-то непонятно, какие изменения вносятся), иногда модель тупит с просто чтением веб страницы, пытается выполнить скрепинг через curl или urllib. Контекста только 256 тысяч, но сохраняет его неплохо между переполнением. Не очень хорошо работает со скиллами и агентами. Для их применения нужно прямо напрямую просить, сам агент до этого не доходит (может нужно усилить общий промт для проекта).
По качеству кода у меня нет вопросов. Еще мне не хватило, чтобы модель сама автоматом распознала, когда нужно переключиться в режим плана, а когда сразу делать.
Еще минус что в Codex нельзя использовать Pro модель Chatgpt ни при каких подписках, это немного расстроило, потому что иногда хочется натравить Pro модель на какое-то исследование в рамках твоей кодовой базы (или реального инцидента😀 ).
Claude Code
Интерфейс чат бота внутри IDE либо TUI в терминале. Явно не для массового пользователя, а для тех, кто хоть когда-то писал код. Коннекторов из коробки не так много, компьютером управлять не умеет, песочница по умолчанию у него менее ограничения, чем в Codex. Все это компенсируется очень чутким пониманием структуры агентских инструкций и использованием MCP. Мне как человеку, кто писал код и видел код зрелый, сразу понятно, как нужно разложить файлики, что туда написать, какие скилы удобно делать. Сам агент очень удачно распознает, когда какой скил взять и сам предлагает это.
С агентами та же история, что в кодекс, если не вызвать explicit, то их не будет. Код пишет хорошо. Отдельная киллер-фича - контекст на миллион токенов, это просто круто. Иногда у меня создается впечатление, что он все-таки где-то в фоне сжимается, но может я не прав.
По интерфейсу мне все нравится, причем агент именно заточен на написание скиллов по умолчанию и часто сам предлагает такие вещи.
Выводы
Если у вас хороший технический бекграунд (а тут большинство таких, я думаю) - начинайте с Claude Code. Такой подход опасен тем, что к Codex потом не привыкнуть (как вышло у меня в итоге).
Если вы чувствуете себя больше художником - попробуйте Codex, кажется, что для таких задач он более удобен.
А вообще лучше взять и сравнить самому.
Вообще я по жизни не программист, но в ходе своего профессионального и личного развития часто сталкивался с написанием скриптов, автоматизациями и в целом анализом кода (было время - фаззил PostgreSQL даже и анализировал уязвимости в ядре Linux). В итоге это сформировало общее понимание написания хорошего кода и устойчивых систем без самого навыка, ну может быть чуть-чуть.
Начиная с момента, когда я начал программировать, я написал сам десятки-сотни тысяч строк различного кода, но начиная с начала 2026 года я отдал мейнтейнить свои системы агентам. Где-то это открытые ллм, где-то внутри контура, но код я сам писать перестал вообще, кроме каких-то узких ситуаций.
Опущу свои восторженные нахваливания ИИ в этом вопросе (поверьте, если ставить правильно задачу и вы не senior software engineer - то LLM пишет код лучше вас), и остановлюсь на своем опыте использования двух frontier продуктов Codex и Claude Code с точки зрения человека, разрабатывающего различные продукты и в ИБ и в ИТ сейчас, но не являющегося программистом.
Мои впечатления
Codex
Сразу бросается в глаза что Codex - это продукт для масс. Очень много коннекторов, графический интерфейс, мини браузер прям в приложении, возможность выбора темы, интеграция с приложениями на десктопе и так далее. Это все создает очень большую вариативность по сценариям использования и выглядит понятно для обывателя.
Вместе с тем есть и огрехи: отображение оставшегося количества токенов не всегда интуитивное, иногда вообще неясно, что делает llm с кодом (как-то непонятно, какие изменения вносятся), иногда модель тупит с просто чтением веб страницы, пытается выполнить скрепинг через curl или urllib. Контекста только 256 тысяч, но сохраняет его неплохо между переполнением. Не очень хорошо работает со скиллами и агентами. Для их применения нужно прямо напрямую просить, сам агент до этого не доходит (может нужно усилить общий промт для проекта).
По качеству кода у меня нет вопросов. Еще мне не хватило, чтобы модель сама автоматом распознала, когда нужно переключиться в режим плана, а когда сразу делать.
Еще минус что в Codex нельзя использовать Pro модель Chatgpt ни при каких подписках, это немного расстроило, потому что иногда хочется натравить Pro модель на какое-то исследование в рамках твоей кодовой базы (или реального инцидента
Claude Code
Интерфейс чат бота внутри IDE либо TUI в терминале. Явно не для массового пользователя, а для тех, кто хоть когда-то писал код. Коннекторов из коробки не так много, компьютером управлять не умеет, песочница по умолчанию у него менее ограничения, чем в Codex. Все это компенсируется очень чутким пониманием структуры агентских инструкций и использованием MCP. Мне как человеку, кто писал код и видел код зрелый, сразу понятно, как нужно разложить файлики, что туда написать, какие скилы удобно делать. Сам агент очень удачно распознает, когда какой скил взять и сам предлагает это.
С агентами та же история, что в кодекс, если не вызвать explicit, то их не будет. Код пишет хорошо. Отдельная киллер-фича - контекст на миллион токенов, это просто круто. Иногда у меня создается впечатление, что он все-таки где-то в фоне сжимается, но может я не прав.
По интерфейсу мне все нравится, причем агент именно заточен на написание скиллов по умолчанию и часто сам предлагает такие вещи.
Выводы
Если у вас хороший технический бекграунд (а тут большинство таких, я думаю) - начинайте с Claude Code. Такой подход опасен тем, что к Codex потом не привыкнуть (как вышло у меня в итоге).
Если вы чувствуете себя больше художником - попробуйте Codex, кажется, что для таких задач он более удобен.
А вообще лучше взять и сравнить самому.
Please open Telegram to view this post
VIEW IN TELEGRAM
🦄1
Всем доброго послепраздничного утра!
Если вы до сих пор думаете, как красиво обосновать свои KPI перед руководством или ломаете голову, а как же измерять наш результат - вот вам бест практис от регулятора.
Если вы до сих пор думаете, как красиво обосновать свои KPI перед руководством или ломаете голову, а как же измерять наш результат - вот вам бест практис от регулятора.
🦄1
Forwarded from kolomychenko:~$ access_granted
🎯Роскомнадзор должен добиться 92%-й эффективности блокировки VPN – что бы это ни значило =)
Мы уже привыкли, что российские власти особо не утруждают себя даже формальной юридической упаковкой блокировок в Рунете. Например, на каком основании блокируют YouTube или “замедляют” Telegram? Их нет в реестре запрещённых сайтов, публичных решений судов или приказов органов власти тоже нет. С VPN – та же история. Нет ни одного официального документа, в котором бы шла речь о необходимости массовой блокировки VPN.
Но кое-что любопытное я все же нашла.
На сайте Роскомнадзора есть PDF от января этого года – это формальный документ о порядке выдачи субсидии “Главному радиочастотному центру” (ГРЧЦ, подведомственное предприятие РКН). Деньги выделяются “на обеспечение функционирования автоматизированной системы обеспечения безопасности российского сегмента интернета” (АСБИ).
АСБИ — это система, которая управляет ТСПУ, то есть теми самыми техническими средствами противодействия угрозам, с помощью которых Роскомнадзор блокирует любые сайты и сервисы в Рунете.
💸И сам этот документ по сути формальность – он описывает порядок выдачи субсидии, которая уже заложена в бюджете. Согласно закону о федеральном бюджете, на работу АСБИ предусмотрено около 20 млрд рублей в 2026 году и еще столько же в 2027–2028 году суммарно.
А теперь главное – любую субсидию дают на конкретные цели, и результат достижения этих целей нужно как-то измерять. Поэтому при утверждении порядка предоставления субсидии заранее согласовывают конкретные показатели, которых получателю субсидии нужно достичь. И что мы видим в этом документе? К 2030 году ГРЧЦ должен:
И это одна из всего лишь трех задач, под достижение которых выделены все эти деньги. Две остальные - это добиться от ТСПУ скорости обработки трафика в 831 Тбит/с и пропускать через них 98% всего трафика в Рунете.
Не до конца понятно, что именно означают эти 92% эффективности блокировки VPN. Может, процент от всех существующих в магазинах приложений VPN или, например, долю российских пользователей, которые не используют VPN. Остается лишь вопрос, как эти проценты считать - но, думаю, чиновники, которые порой рассуждают о “деградации Telegram на 30%”, справятся=)
При этом четко обозначу сам факт: это первый официальный документ, где прямо зафиксировано, что у подведа Роскомнадзора стоит государственная задача по ограничению VPN — с конкретными KPI и десятками миллиардов рублей на реализацию.
@kolomychenko
Мы уже привыкли, что российские власти особо не утруждают себя даже формальной юридической упаковкой блокировок в Рунете. Например, на каком основании блокируют YouTube или “замедляют” Telegram? Их нет в реестре запрещённых сайтов, публичных решений судов или приказов органов власти тоже нет. С VPN – та же история. Нет ни одного официального документа, в котором бы шла речь о необходимости массовой блокировки VPN.
Но кое-что любопытное я все же нашла.
На сайте Роскомнадзора есть PDF от января этого года – это формальный документ о порядке выдачи субсидии “Главному радиочастотному центру” (ГРЧЦ, подведомственное предприятие РКН). Деньги выделяются “на обеспечение функционирования автоматизированной системы обеспечения безопасности российского сегмента интернета” (АСБИ).
АСБИ — это система, которая управляет ТСПУ, то есть теми самыми техническими средствами противодействия угрозам, с помощью которых Роскомнадзор блокирует любые сайты и сервисы в Рунете.
💸И сам этот документ по сути формальность – он описывает порядок выдачи субсидии, которая уже заложена в бюджете. Согласно закону о федеральном бюджете, на работу АСБИ предусмотрено около 20 млрд рублей в 2026 году и еще столько же в 2027–2028 году суммарно.
А теперь главное – любую субсидию дают на конкретные цели, и результат достижения этих целей нужно как-то измерять. Поэтому при утверждении порядка предоставления субсидии заранее согласовывают конкретные показатели, которых получателю субсидии нужно достичь. И что мы видим в этом документе? К 2030 году ГРЧЦ должен:
— Достичь “среднего уровня эффективности ограничения доступа к средствам обхода блокировок VPN за счёт сигнатур” в 92%.
И это одна из всего лишь трех задач, под достижение которых выделены все эти деньги. Две остальные - это добиться от ТСПУ скорости обработки трафика в 831 Тбит/с и пропускать через них 98% всего трафика в Рунете.
Не до конца понятно, что именно означают эти 92% эффективности блокировки VPN. Может, процент от всех существующих в магазинах приложений VPN или, например, долю российских пользователей, которые не используют VPN. Остается лишь вопрос, как эти проценты считать - но, думаю, чиновники, которые порой рассуждают о “деградации Telegram на 30%”, справятся=)
При этом четко обозначу сам факт: это первый официальный документ, где прямо зафиксировано, что у подведа Роскомнадзора стоит государственная задача по ограничению VPN — с конкретными KPI и десятками миллиардов рублей на реализацию.
@kolomychenko
А как собирать триаж на MacOS?
Я как-то делал ресерч на эту тему, но там тема была скорее "что собрать", а не "как"?
А тут появилась прикладная задача, да еще и не первый раз, избежать ее было трудно)
У меня на столе оказалось меню из двух позиций:
- Популярный velociraptor
- Нативный aftermath
Я использовал velociraptor для Windows и Linux, и там я привык, что конфиг просто вшивается внутрь бинарника и ты спокойно раскидываешь по инфре и собираешь дабл кликом от админа (или судо в терминале).
С MacOS все оказалось не так просто. Как известно, в MacOS есть своя система подписей бинарей. И если у бинаря нет официальной подписи, то он просто так не запустится на вашем компьютере. Это несложно обойти на одной конкретной машине, но обходить это можно только руками (особенно на последних версиях).
Итого как создается сборщик для MacOS в velociraptor?
1️⃣ Генерируем конфиг и запускаем GUI для генерации нового артефакта сбора
2️⃣ Собираем новый артефакт (а что там будет - оставлю для остальных, лишь напомню про репо)
3️⃣ При генерации сборщика выбираем MacOS и тут интересно, что на выходе будет файл в районе 50-90 килобайт. Что это за файл?
Для запуска дабл кликом в velociraptor вшивается аргумент автозапуска
Таким образом Velociraptor придумали обходное решение - создается shell обвязка с встроенным конфигом в бинарном виде. Внутри файла есть маркер ###<Begin Embedded Config>.
При этом velociraptor, получив
Таким образом, для запуска velociraptor нужно 3 сущности.
1. Дефолтный Бинарь velociraptor с валидной подписью MACH-O файла от Rapid-7
2. autoexec скрипт, который сгенерировал сервер velociraptor для MacOS
3. Скрипт-обвязка, которая запустит это все вместе.
Но и это еще не все!)
В MacOS есть механизм FDA (Full Disk Access). Если это разрешение не дану терминалу, в котором вы его запускаете, то некоторые системные артефакты просто не соберутся. Выставить это можно тоже только руками или через MDM решения Системные настройки → Конфиденциальность и безопасность → Доступ к диску и там переключить кнопку для терминала, где будем запускать velociraptor.
Таким образом процесс слегка сложнее, чем на других ОС, и на больших объемах может быть не таким простым.
Ну а aftermath...
У меня он вообще не заработал, хотя штука прикольная. Просто вылетал с exit code 133. У меня не то, чтобы много ресурсов для теста, может мой конкретный сетап системы не подходит.
Я как-то делал ресерч на эту тему, но там тема была скорее "что собрать", а не "как"?
А тут появилась прикладная задача, да еще и не первый раз, избежать ее было трудно)
У меня на столе оказалось меню из двух позиций:
- Популярный velociraptor
- Нативный aftermath
Я использовал velociraptor для Windows и Linux, и там я привык, что конфиг просто вшивается внутрь бинарника и ты спокойно раскидываешь по инфре и собираешь дабл кликом от админа (или судо в терминале).
С MacOS все оказалось не так просто. Как известно, в MacOS есть своя система подписей бинарей. И если у бинаря нет официальной подписи, то он просто так не запустится на вашем компьютере. Это несложно обойти на одной конкретной машине, но обходить это можно только руками (особенно на последних версиях).
Итого как создается сборщик для MacOS в velociraptor?
./velociraptor --config server.config.yaml guiДля запуска дабл кликом в velociraptor вшивается аргумент автозапуска
autoexec.argv. В PE файл это вшивается в секцию PE, в ELF файле добавляется в конец файла, а если мы добавим это в MACH-O файл, то integrity нарушится и файл не запустится.Таким образом Velociraptor придумали обходное решение - создается shell обвязка с встроенным конфигом в бинарном виде. Внутри файла есть маркер ###<Begin Embedded Config>.
При этом velociraptor, получив
--embedded_config /path/to/script.sh, открывает этот же файл, ищет маркер ###<Begin Embedded Config>, читает байты после него и парсит как embedded config. Это конфиг - это просто сжатый zlib валидный yaml, который читает velociraptor.Таким образом, для запуска velociraptor нужно 3 сущности.
1. Дефолтный Бинарь velociraptor с валидной подписью MACH-O файла от Rapid-7
2. autoexec скрипт, который сгенерировал сервер velociraptor для MacOS
3. Скрипт-обвязка, которая запустит это все вместе.
Но и это еще не все!)
В MacOS есть механизм FDA (Full Disk Access). Если это разрешение не дану терминалу, в котором вы его запускаете, то некоторые системные артефакты просто не соберутся. Выставить это можно тоже только руками или через MDM решения Системные настройки → Конфиденциальность и безопасность → Доступ к диску и там переключить кнопку для терминала, где будем запускать velociraptor.
Таким образом процесс слегка сложнее, чем на других ОС, и на больших объемах может быть не таким простым.
Ну а aftermath...
У меня он вообще не заработал, хотя штука прикольная. Просто вылетал с exit code 133. У меня не то, чтобы много ресурсов для теста, может мой конкретный сетап системы не подходит.
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - Velocidex/velociraptor: Digging Deeper....
Digging Deeper.... Contribute to Velocidex/velociraptor development by creating an account on GitHub.
👍3🦄1
Сейчас я плотно занимаюсь изучением ИИ и экспериментами в разных областях: DFIR, reverse, Программирование, дизайн да и вообще много чего.
В последнее время я углубился в создание агента, который помогал бы мне исследовать триажи и подсказывать разные гипотезы, находить то, что я проглядел, автоматизировать большие объемы.
Сначала я проделал тест на обычных премпромтах + opencode. Далее я сам погружал агента в специфику и управлял его действиями (важно, использовались внутренние модели, которые, все же, хуже внешних, но достаточно хороши при правильном использовании)
Подход был очень простой:
1. Генерим гипотезы
2. Проверяем в артефактах
3. Записываем выводы в промежуточные файлы
4. Повторяем
5. Объединяем все в один отчет
Пример такого отчета я постил выше.
Такой подход - это автоматизация твоей работы, но не то чтобы прорыв. Считай, не ты грепаешь файл, а агент. Далее его выводы все равно ты интерпретируешь и ведешь его от и до, попутно борясь с его галлюцинациями и мислидами.
Конечно я захотел развить эту идею до автономного агента, провел ресерч, заложил туда методологии типа DFIQ и принципа Локара, использовал разные современные подходы, типа графа состояний и векторной инвентаризации артефактов и т.п.
Но, конечно, агент стал уходить в прострации, то есть начал слишком много "философствовать", при этом задачу свою не выполнял.
Отсюда я пришел к идее ограничений (прям как РКН, хаха). То есть нужно было придумать, как агента направлять в нужное русло и ограничивать его циклы по одному и тому же файлу, так как ни время ни контекст не резиновые.
Среди таких ограничений были, например:
1. Ограничение на бесконечный поиск.
2. Усиление валидации путей до артефактов.
3. Ограничение на количество гипотез и т.д.
И знаете что? С внедрением ограничений стало только ХУЖЕ.
Я не скажу, что это какой-то вау результат и что-то супер неожиданное, но тем не менее, агент стал нефункциональным.
Каждый guard, который блокирует, создаёт состояние «агент не может сделать ничего разумного — выбери из 5 неподходящих вариантов». LLM в такой ситуации либо повторяется (что блокирует следующий guard), либо галлюцинирует (что блокирует другой guard). Итого агент просто зависает или сразу завершается. И все твои умные и накрученные фичи просто не работают.
И вроде каждое из этих ограничений само по себе было разумным, но их комбинация сделала сильно хуже.
Короче говоря, мой небольшой эксперимент с симуляцией РКН провалился, агентов не нужно загонять в ограничения (во всяком случае в этом домене). Будем посмотреть дальше, что из этого получится.
В последнее время я углубился в создание агента, который помогал бы мне исследовать триажи и подсказывать разные гипотезы, находить то, что я проглядел, автоматизировать большие объемы.
Сначала я проделал тест на обычных премпромтах + opencode. Далее я сам погружал агента в специфику и управлял его действиями (важно, использовались внутренние модели, которые, все же, хуже внешних, но достаточно хороши при правильном использовании)
Подход был очень простой:
1. Генерим гипотезы
2. Проверяем в артефактах
3. Записываем выводы в промежуточные файлы
4. Повторяем
5. Объединяем все в один отчет
Пример такого отчета я постил выше.
Такой подход - это автоматизация твоей работы, но не то чтобы прорыв. Считай, не ты грепаешь файл, а агент. Далее его выводы все равно ты интерпретируешь и ведешь его от и до, попутно борясь с его галлюцинациями и мислидами.
Конечно я захотел развить эту идею до автономного агента, провел ресерч, заложил туда методологии типа DFIQ и принципа Локара, использовал разные современные подходы, типа графа состояний и векторной инвентаризации артефактов и т.п.
Но, конечно, агент стал уходить в прострации, то есть начал слишком много "философствовать", при этом задачу свою не выполнял.
Отсюда я пришел к идее ограничений (прям как РКН, хаха). То есть нужно было придумать, как агента направлять в нужное русло и ограничивать его циклы по одному и тому же файлу, так как ни время ни контекст не резиновые.
Среди таких ограничений были, например:
1. Ограничение на бесконечный поиск.
2. Усиление валидации путей до артефактов.
3. Ограничение на количество гипотез и т.д.
И знаете что? С внедрением ограничений стало только ХУЖЕ.
Я не скажу, что это какой-то вау результат и что-то супер неожиданное, но тем не менее, агент стал нефункциональным.
Каждый guard, который блокирует, создаёт состояние «агент не может сделать ничего разумного — выбери из 5 неподходящих вариантов». LLM в такой ситуации либо повторяется (что блокирует следующий guard), либо галлюцинирует (что блокирует другой guard). Итого агент просто зависает или сразу завершается. И все твои умные и накрученные фичи просто не работают.
И вроде каждое из этих ограничений само по себе было разумным, но их комбинация сделала сильно хуже.
Короче говоря, мой небольшой эксперимент с симуляцией РКН провалился, агентов не нужно загонять в ограничения (во всяком случае в этом домене). Будем посмотреть дальше, что из этого получится.
Telegram
Синяя шляпа
Подписчики канала заметят, что я немного хайплю на теме LLM. И не просто так. Давеча я уже писал про применение llm в реверсе (статическом анализе). Но в этой сфере я не эксперт, поэтому пойдем далее.
А что если научить LLM в DFIR, подумал я. Как мы знаем…
А что если научить LLM в DFIR, подумал я. Как мы знаем…
🔥8🦄2
Немного слов по форензику контейнеров.
Сейчас часто публикуют свои приложения в docker. Это вполне понятный и логичный подход, сам так делаю. Отсюда для злодеев это становится лакомой точкой пробива и закреплений. Но как нам провести форензику контейнера?
Для этого нужно сначала зафиксировать его состояние:
1.
2.
3.
4.
Важно, что мы не собираем так рантайм информацию о процессах и сетевых соединениях.
Далее мы можем смотреть внутрь контейнера. Контейнер состоит из "слоев", которые создаются при сборке. Здесь также нужно вспомнить про логику работы с контейнерами.
Обычно, внутри них никто файлы не правит, кроме каких-то срочных случаев. Если нужно что-то поменять - правят исходную конфигурацию и пересобирают контейнер. Это дает очень классную особенность, что время модификации всех файлов близко к моменту старта контейнера. И если, вдруг, мы находим файл, который отличается по этому времени - это хорошая эвристика, куда обратить внимание (конечно, кроме всяких логов).
Сейчас часто публикуют свои приложения в docker. Это вполне понятный и логичный подход, сам так делаю. Отсюда для злодеев это становится лакомой точкой пробива и закреплений. Но как нам провести форензику контейнера?
Для этого нужно сначала зафиксировать его состояние:
1.
docker ps -a - узнаем что за контейнер2.
docker inspect <id> - забираем метаинформацию о контейнере3.
docker commit <id> forensic_snapshot_$(date +%Y%m%) - фиксируем состояние контейнера4.
docker save forensic_snapshot_$(date +%Y%m%d) > forensic_image_ <id>.tar - выгружаем tar архива.Важно, что мы не собираем так рантайм информацию о процессах и сетевых соединениях.
Далее мы можем смотреть внутрь контейнера. Контейнер состоит из "слоев", которые создаются при сборке. Здесь также нужно вспомнить про логику работы с контейнерами.
Обычно, внутри них никто файлы не правит, кроме каких-то срочных случаев. Если нужно что-то поменять - правят исходную конфигурацию и пересобирают контейнер. Это дает очень классную особенность, что время модификации всех файлов близко к моменту старта контейнера. И если, вдруг, мы находим файл, который отличается по этому времени - это хорошая эвристика, куда обратить внимание (конечно, кроме всяких логов).
👍5🦄2
Хочется сделать заметку на полях новой новости о Mythos от Антропик. Оригинал новости.
Представьте, что через пару лет со стороны хакеров будет модель не то чтобы сопоставимая по возможностям, но не сильно далекая. Появятся открытые аналоги, которы будут хоститься как RaaS, и давать нападающим очень мощные возможности.
В кейсах, с которыми я встречался, я видел, как злодеи получали админа домена за 20 минут и менее с момента, как они первый раз зашли в инфру, без использования ллм (вероятно). И это в инфраструктурах, где все еще не так плохо.
В теории, да и на практике, с этой точки злодей может уничтожить большую часть инфраструктуры, где-то больше, где-то меньше.
То есть, представим, что теперь злодеям будет достаточно полчаса для нанесения реального ущерба в инфраструктурах, где допущен хотя бы один просчет (это важно, достаточно одного).
Если поискать бест практисы по SLA таймингу информирования в SOC на смене мониторинга, то мы получим оценки около, как раз, тех же 20-30 минут на критичные сработки, и примерно до двух часов на средней тяжести.
Цифры интересные, как мне кажется, нынешняя операционная модель SOC морально устарела, в перспективе пары лет, она станет не эффективной вовсе. Уже сейчас нужно думать, как вы через 2-3 года будете сражаться с вооруженными топовыми ллм по взлому хакерами.
Представьте, что через пару лет со стороны хакеров будет модель не то чтобы сопоставимая по возможностям, но не сильно далекая. Появятся открытые аналоги, которы будут хоститься как RaaS, и давать нападающим очень мощные возможности.
В кейсах, с которыми я встречался, я видел, как злодеи получали админа домена за 20 минут и менее с момента, как они первый раз зашли в инфру, без использования ллм (вероятно). И это в инфраструктурах, где все еще не так плохо.
В теории, да и на практике, с этой точки злодей может уничтожить большую часть инфраструктуры, где-то больше, где-то меньше.
То есть, представим, что теперь злодеям будет достаточно полчаса для нанесения реального ущерба в инфраструктурах, где допущен хотя бы один просчет (это важно, достаточно одного).
Если поискать бест практисы по SLA таймингу информирования в SOC на смене мониторинга, то мы получим оценки около, как раз, тех же 20-30 минут на критичные сработки, и примерно до двух часов на средней тяжести.
Цифры интересные, как мне кажется, нынешняя операционная модель SOC морально устарела, в перспективе пары лет, она станет не эффективной вовсе. Уже сейчас нужно думать, как вы через 2-3 года будете сражаться с вооруженными топовыми ллм по взлому хакерами.
Anthropic
Project Glasswing: An initial update
An early update on what we've learned from Project Glasswing.
🦄2
tg_image_3187528330.png
83.9 KB
Иногда возникает вопрос, а как проанализировать большое массив данных?
Например, вот у нас есть 100 триажей с хостов, которые мы не знаем, скомпромитированы или нет.
Даже если у нас есть зацепки в виде отрезка времени действий, все равно очень много что нужно проверить:
- А если злодей приходил под другой учеткой
- А если использовал другие исполняемые файлы
- А если он ...
Задача не всегда тривиальная. На такой случай можно применить эвристики, и в случае с windows, это может быть hayabusa. Конечно, это не рокет сайнс, но что делать дальше? Вот у нас 100 триажей с логами Windows, вот hayabusa, и дальше тишина...
На самом деле можно сделать так:
1. Главное иметь все данные централизовано. Обычно, триаж - это просто набор файлов тем или иным способом сгруппированный. В этом наборе файлов по известной нам схеме лежат сырые события windows (обычно их собирают все).
2. вытаскиваем все журналы в одну директорию.
3. Запускаем hayabusa. Пример запуска
4. Дальше самое интересное, на сотне машин мы получим файл в десятки гигабайт, плюс-минус, если включать info и low правила (я сторонник включать). Открывать такой файл даже timeline explorer будет неприятно. Внимательный читатель наверняка заметил флаг timesketch-verbose в hayabusa. Подробнее об этом здесь.
5. Плюс такого подхода в том, что мы получаем удобный UI для фильтрации событий и можем быстро просматривать большое количество событий, применяя удобную фильтрацию (фильтры можно делать любой сложности, в зависимости от уровня извращенности)
Таким образом достаточно удобно выявлять аномалии на больших объемах.
Например, вот у нас есть 100 триажей с хостов, которые мы не знаем, скомпромитированы или нет.
Даже если у нас есть зацепки в виде отрезка времени действий, все равно очень много что нужно проверить:
- А если злодей приходил под другой учеткой
- А если использовал другие исполняемые файлы
- А если он ...
Задача не всегда тривиальная. На такой случай можно применить эвристики, и в случае с windows, это может быть hayabusa. Конечно, это не рокет сайнс, но что делать дальше? Вот у нас 100 триажей с логами Windows, вот hayabusa, и дальше тишина...
На самом деле можно сделать так:
1. Главное иметь все данные централизовано. Обычно, триаж - это просто набор файлов тем или иным способом сгруппированный. В этом наборе файлов по известной нам схеме лежат сырые события windows (обычно их собирают все).
2. вытаскиваем все журналы в одну директорию.
3. Запускаем hayabusa. Пример запуска
hayabusa.exe csv-timeline -d .\ -o timesketch-import.csv -p timesketch-verbose --ISO-8601. Меняем .\ на реальный путь к логам. После этого получим файл csv.4. Дальше самое интересное, на сотне машин мы получим файл в десятки гигабайт, плюс-минус, если включать info и low правила (я сторонник включать). Открывать такой файл даже timeline explorer будет неприятно. Внимательный читатель наверняка заметил флаг timesketch-verbose в hayabusa. Подробнее об этом здесь.
5. Плюс такого подхода в том, что мы получаем удобный UI для фильтрации событий и можем быстро просматривать большое количество событий, применяя удобную фильтрацию (фильтры можно делать любой сложности, в зависимости от уровня извращенности)
Таким образом достаточно удобно выявлять аномалии на больших объемах.
👍5🦄1
Столкнулся с интересным кейсом.
Инцидент с шифровальщиком, точка входа известна но сама машина пошифрована на уровне 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 часа я нашел очень правдоподобный вектор эксплуатации уязвимости в большом бинаре. Впечатляет…
🔥9🦄1
Синяя шляпа
Столкнулся с интересным кейсом. Инцидент с шифровальщиком, точка входа известна но сама машина пошифрована на уровне esxi. На входной машине есть сервис, код закрыт, версия известна, но уязвимостей на него нет. Перед шифрованием на машине сохранились логи…
Самое смешное в этом кейсе, что окончательно докопавшись до правды, я выяснил, что пробив был такой:
1. Заход под сервисной учетной записью в вебку сервиса
2. С помощью встроенного функционала сервиса выполнение команд на хосте
Никакого 0day, никакой сложной эксплуатации. Как обычно: утекшие креды -> пробив.
Очередное напоминание, что чаще всего не нужно искать сложность, все на поверхности...
1. Заход под сервисной учетной записью в вебку сервиса
2. С помощью встроенного функционала сервиса выполнение команд на хосте
Никакого 0day, никакой сложной эксплуатации. Как обычно: утекшие креды -> пробив.
Очередное напоминание, что чаще всего не нужно искать сложность, все на поверхности...
👍2🔥2🦄2
В последнее время я начал больше заниматься всякими штуками типа binary pwn, реверс всего и вся и ресерч разных интересных вещей.
Конечно, модели мне вставляли палки в колеса, Клод постоянно писал, что я что-то нарушаю и вообще это не по феншую.
Для того, чтобы такого было меньше можно попросить снять эти гарды.
Для OpenAI это Trusted Access for Cyber, для Anthropic - Cyber Verification Program.
Оказывается, получить это не так сложно. Для Антропика заполняем небольшую анкетку. В одном из пунктов вас спросят про ваши работы, баг баунти репорты или может ли кто-то за вас поручиться.
У меня не оказалось англоязычных статей, поэтому... Я просто вставил ссылки на google translate своих отчетов на русском и прокатило.
Ни в коем случае не гарантирую результат, но у меня сработало)
Конечно, модели мне вставляли палки в колеса, Клод постоянно писал, что я что-то нарушаю и вообще это не по феншую.
Для того, чтобы такого было меньше можно попросить снять эти гарды.
Для OpenAI это Trusted Access for Cyber, для Anthropic - Cyber Verification Program.
Оказывается, получить это не так сложно. Для Антропика заполняем небольшую анкетку. В одном из пунктов вас спросят про ваши работы, баг баунти репорты или может ли кто-то за вас поручиться.
У меня не оказалось англоязычных статей, поэтому... Я просто вставил ссылки на google translate своих отчетов на русском и прокатило.
Ни в коем случае не гарантирую результат, но у меня сработало)
🔥4🦄1
«У меня локальная модель — значит, приватно». Не совсем.
Сейчас все больше людей играется с локальными ИИ моделями, и понятно почему. Приватные данные требуют локальной обработки, чтобы не отсылать данные наружу.
Но вот интересная история, где с одной стороны - приватность, с другой стороны - открытость. Представим, что такому экспериментатору заслали стиллер, что он найдет на его машине?
Похожим вопросом задались ребята из исследования. Я уверен, что многие дают llm прямой доступ прямо на какие-то сервера, дают какие-то токены, креды, вызывают инструменты для отладки и все такое (я вот так иногда делаю). Плюс, в ответах остается какой-то бизнес контекст, который может быть приватный. И далее стиллер забирает всю эту информацию с вашей машины и узнает все ваши секреты (и секреты работодателя, или, например, конфиг впн из промта😉).
В то же время, для ребят с реагирования это становится очень ценным источником данных, где можно найти много разного контекста. Вот пример захода в эту сторону.
А вообще SANS уже давно все рассказали. Можно как минимум почитать syllabus.
Сейчас все больше людей играется с локальными ИИ моделями, и понятно почему. Приватные данные требуют локальной обработки, чтобы не отсылать данные наружу.
Но вот интересная история, где с одной стороны - приватность, с другой стороны - открытость. Представим, что такому экспериментатору заслали стиллер, что он найдет на его машине?
Похожим вопросом задались ребята из исследования. Я уверен, что многие дают llm прямой доступ прямо на какие-то сервера, дают какие-то токены, креды, вызывают инструменты для отладки и все такое (я вот так иногда делаю). Плюс, в ответах остается какой-то бизнес контекст, который может быть приватный. И далее стиллер забирает всю эту информацию с вашей машины и узнает все ваши секреты (и секреты работодателя, или, например, конфиг впн из промта😉).
В то же время, для ребят с реагирования это становится очень ценным источником данных, где можно найти много разного контекста. Вот пример захода в эту сторону.
А вообще SANS уже давно все рассказали. Можно как минимум почитать syllabus.
arXiv.org
Forensic Implications of Localized AI: Artifact Analysis of...
The proliferation of local Large Language Model (LLM) runners, such as Ollama, LM Studio and llama.cpp, presents a new challenge for digital forensics investigators. These tools enable users to...
⚡1🔥1🦄1
Многие вокруг говорят, что обойти защиты ИИ не так сложно. В первые дни выпуска Fable от Anthropic соцсеть X (formerly twitter) так и пестрила о том, что почти все обошли гардрейлы.
Но это все хайп и написать можно что угодно. Один из исследователей решил провести эксперимент.
Суть эксперимента - вот вам мой openclaw на opus 4.6, обойдите его защиту через prompt injection в электронном письме (а по данным owasp - это самая опасная, простая и распространенная атака)
Так вот, тысячи попыток и ни одного пробива. Конечно, исследователь постарался и обвесил агента доп защитами, но тем не менее.
Этот кейс чем-то похож на бездумное внедрение сием системы. Да, вы можете поставить себе сием, но без настройки и персонала она вряд ли даст адекватный эффект. Так же здесь, если агента не обвесить ограничениями и защитой - он становится слабо контролируемым.
Конечно, сам по себе этот кейс мало что показывает глобально, так как поведение модели стохастическое и экстраполировать один эксперимент неразумно.
Следите за агентами и все будет хорошо)
Но это все хайп и написать можно что угодно. Один из исследователей решил провести эксперимент.
Суть эксперимента - вот вам мой openclaw на opus 4.6, обойдите его защиту через prompt injection в электронном письме (а по данным owasp - это самая опасная, простая и распространенная атака)
Так вот, тысячи попыток и ни одного пробива. Конечно, исследователь постарался и обвесил агента доп защитами, но тем не менее.
Этот кейс чем-то похож на бездумное внедрение сием системы. Да, вы можете поставить себе сием, но без настройки и персонала она вряд ли даст адекватный эффект. Так же здесь, если агента не обвесить ограничениями и защитой - он становится слабо контролируемым.
Конечно, сам по себе этот кейс мало что показывает глобально, так как поведение модели стохастическое и экстраполировать один эксперимент неразумно.
Следите за агентами и все будет хорошо)
Simon Willison’s Weblog
What happened after 2,000 people tried to hack my AI assistant
Fernando Irarrázaval ran a challenge on hackmyclaw.com to see if anyone could leak secrets held by his OpenClaw test instance by sending it email. Surprisingly, after 6,000 attempts (and $500 …
🔥3⚡1🦄1
NIST 800-61 — это не про реальное внешнее реагирование
Если ты выбрал(а) тернистый путь DFIR, то, вероятно, на любом курсе по реагированию и почти на каждом собесе тебя спросят про фазы: подготовка, обнаружение и анализ, сдерживание, ликвидация, восстановление, выводы. NIST SP 800-61, SANS, ISO 27035, наш ГОСТ Р 59712 — все крутятся вокруг них. В современном DFIR сообществе это стало базой, нулевой точкой отсчета для кандидата.
Как всегда, есть нюанс. Все эти документы написаны для владельца инфраструктуры — того, кто заранее знает свои активы, настроил мониторинг и сидит на полной телеметрии. Для него фазы и правда работают.
А теперь ты приходишь внешней командой. Инфра незнакомая, журналирование настроено наполовину, часть данных уже затёрта, времени впритык. И фазы начинают плыть: сдерживание нередко стартует до того, как ты закончил анализ, сбор данных продолжается уже после начала восстановления, а иногда и после локализации. По факту работа идёт не фазами, а петлями: набросал гипотезы -> под них целенаправленно собрал данные-> подтвердил / опроверг / раздробил -> повторил. Фазовая модель этот цикл не описывает и не говорит, когда остановиться.
Интересно, что в 2025 сам NIST в редакции 800-61r3 убрал модель жизненного цикла и встроил реагирование в общий цикл управления рисками. Правда, ушёл в другую крайность — получился рамочный документ, по которому регламент работы команды тоже не построишь.
К чему это. Фазы — удобная рамка, больше про бумажную безопасность и "соответствие" мировым стандартам. Это хороший пример того, что вроде теория красивая и создана лидирующими экспертами, но жизнь немного сложнее...
Если ты выбрал(а) тернистый путь DFIR, то, вероятно, на любом курсе по реагированию и почти на каждом собесе тебя спросят про фазы: подготовка, обнаружение и анализ, сдерживание, ликвидация, восстановление, выводы. NIST SP 800-61, SANS, ISO 27035, наш ГОСТ Р 59712 — все крутятся вокруг них. В современном DFIR сообществе это стало базой, нулевой точкой отсчета для кандидата.
Как всегда, есть нюанс. Все эти документы написаны для владельца инфраструктуры — того, кто заранее знает свои активы, настроил мониторинг и сидит на полной телеметрии. Для него фазы и правда работают.
А теперь ты приходишь внешней командой. Инфра незнакомая, журналирование настроено наполовину, часть данных уже затёрта, времени впритык. И фазы начинают плыть: сдерживание нередко стартует до того, как ты закончил анализ, сбор данных продолжается уже после начала восстановления, а иногда и после локализации. По факту работа идёт не фазами, а петлями: набросал гипотезы -> под них целенаправленно собрал данные-> подтвердил / опроверг / раздробил -> повторил. Фазовая модель этот цикл не описывает и не говорит, когда остановиться.
Интересно, что в 2025 сам NIST в редакции 800-61r3 убрал модель жизненного цикла и встроил реагирование в общий цикл управления рисками. Правда, ушёл в другую крайность — получился рамочный документ, по которому регламент работы команды тоже не построишь.
К чему это. Фазы — удобная рамка, больше про бумажную безопасность и "соответствие" мировым стандартам. Это хороший пример того, что вроде теория красивая и создана лидирующими экспертами, но жизнь немного сложнее...
👎2🦄1
Интересный репозиторий и интересный подход к делу, дропаем новые 0day cve никого об этом не предупреждая, и все довольны
https://github.com/bikini/exploitarium
https://github.com/bikini/exploitarium
GitHub
GitHub - bikini/exploitarium: A single archive of public exploit PoCs and vulnerability research writeups. At the time I post these…
A single archive of public exploit PoCs and vulnerability research writeups. At the time I post these, none have been reported. Feel free to report them yourself and take credit for the CVE if hand...
⚡3🦄1