А как собирать триаж на 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
На хабре увидел небольшую статью по атакам на mcp сервера и я решил поделиться, как я защищаю свои mcp от похожих атак.
У меня есть два класса mcp серверов:
- корпоративные
- личные
В качестве примера личного mcp я реализовал общий сервер памяти, теперь у меня все агенты из любого AI провайдера пишут аннотации чатов и сессий в общую память, которая сохраняется на моем сервере.
В качестве корпоративного mcp может быть сервер для работы с opensearch, postgresql, clickhouse и любыми другими системами, которые вы используете. Ваш агент сможет взаимодействовать с прод (или тест) системой по понятным правилам.
Для личного я использую связку url secret + oauth. url secret позволяет отрезать подавляющее большинство ботов, а oauth просто не даст сделать запрос без аутентификации на моей учетке. oauth я завожу через workos. Если вы не упорный параноик - то это решение очень хорошо подходит для личного пользования.
Для корпоративного контура все сложнее. Не смотря на то, что почти все mcp у вас будут внутренние встает масса других вопросов:
1. аудит доступа
2. разграничение прав
3. разрешение конкретных тулов
4. маршрутизация запросов и т.д.
Эта задача чуть сложнее и требует отдельной статьи но в качестве готового решения (нужно настраивать) можно использовать agentgateway. Он позволяет решить все эти задачи и кроме того сделать отдельный шлюз для AI провайдеров в контуре организации.
У меня есть два класса mcp серверов:
- корпоративные
- личные
В качестве примера личного mcp я реализовал общий сервер памяти, теперь у меня все агенты из любого AI провайдера пишут аннотации чатов и сессий в общую память, которая сохраняется на моем сервере.
В качестве корпоративного mcp может быть сервер для работы с opensearch, postgresql, clickhouse и любыми другими системами, которые вы используете. Ваш агент сможет взаимодействовать с прод (или тест) системой по понятным правилам.
Для личного я использую связку url secret + oauth. url secret позволяет отрезать подавляющее большинство ботов, а oauth просто не даст сделать запрос без аутентификации на моей учетке. oauth я завожу через workos. Если вы не упорный параноик - то это решение очень хорошо подходит для личного пользования.
Для корпоративного контура все сложнее. Не смотря на то, что почти все mcp у вас будут внутренние встает масса других вопросов:
1. аудит доступа
2. разграничение прав
3. разрешение конкретных тулов
4. маршрутизация запросов и т.д.
Эта задача чуть сложнее и требует отдельной статьи но в качестве готового решения (нужно настраивать) можно использовать agentgateway. Он позволяет решить все эти задачи и кроме того сделать отдельный шлюз для AI провайдеров в контуре организации.
Хабр
MCP и безопасность агентов: почему протокол, создал новую проблему безопасности. Проверям на практике
Model Context Protocol решил реальную и болезненную задачу — вместо того чтобы каждое AI-приложение изобретало свой способ подключения, разработчики получили один стандарт, который понимают все...
🍓2🦄1
Сейчас на просторах рунета активно работает RareWerewolf. Об этом уже писали в каналах, даже индикаторы постили. Я хочу просто рассказать про маленький хак, как анализировать вложение их писем.
Внутри их письма exe файл, собранный установщиком Smart Install Maker. Сейчас я провожу реверс через ИИ агента, но это как раз тот случай, когда быстрее сделать руками. Для распаковки этого установщика можно использовать утилиту. Несмотря на то, что она не поддерживается какое-то время - она отлично справляется со своей задачей. При ее использовании нужно докачать модуль sim_extract. Это делается из коробки, если есть интеренет - утилита сама скачает, если нет - то можно подложить файл. Сделано для людей.
На выходе у вас будут вложения в сам файл и конфиг инсталлятора. Основная логика зашита в конфиг инсталлятора installer.config. Это не самый удобный файл для чтения, но все команды оттуда можно вычленить.
Конкретно RareWerewolf пошли чуть хитрее, они не держат всю нагрузку внутри начального пейлоада, а докачивают ее через C2. Здесь по пунктам они заложили следующие файлы:
1 - decoy pdf
2 - текст адрес C2
3 - curl для windows
далее инсталлятор уже работает со скаченным payload. По техникам они крадут пароли и потом закрепляются через AnyDesk, особенно ничего нового.
Несмотря на то, что этот кейс сам по себе несложный, но для ИИ агента здесь прям много подводных камней в виде внешней тулзы распаковки (нестандартной), скачивания нагрузки с C2 и анализ килчейна с всеми элементами.
В общем, кожаные мешки еще будут востребованы.
Внутри их письма exe файл, собранный установщиком Smart Install Maker. Сейчас я провожу реверс через ИИ агента, но это как раз тот случай, когда быстрее сделать руками. Для распаковки этого установщика можно использовать утилиту. Несмотря на то, что она не поддерживается какое-то время - она отлично справляется со своей задачей. При ее использовании нужно докачать модуль sim_extract. Это делается из коробки, если есть интеренет - утилита сама скачает, если нет - то можно подложить файл. Сделано для людей.
На выходе у вас будут вложения в сам файл и конфиг инсталлятора. Основная логика зашита в конфиг инсталлятора installer.config. Это не самый удобный файл для чтения, но все команды оттуда можно вычленить.
Конкретно RareWerewolf пошли чуть хитрее, они не держат всю нагрузку внутри начального пейлоада, а докачивают ее через C2. Здесь по пунктам они заложили следующие файлы:
1 - decoy pdf
2 - текст адрес C2
3 - curl для windows
далее инсталлятор уже работает со скаченным payload. По техникам они крадут пароли и потом закрепляются через AnyDesk, особенно ничего нового.
Несмотря на то, что этот кейс сам по себе несложный, но для ИИ агента здесь прям много подводных камней в виде внешней тулзы распаковки (нестандартной), скачивания нагрузки с C2 и анализ килчейна с всеми элементами.
В общем, кожаные мешки еще будут востребованы.
🔥2🍓1🦄1
Вчера была забавная история с ИИ (не опять, а снова).
Я увлекаюсь волейболом и перед соревнованиями решил дать задачу ИИшке, чтобы она проанализировала расстановку команды на площадке с учетом слабых и сильных сторон игроков команды, а также в динамике визуализировать это через html.
Я выбрал для этой задачи sonnet 5 в режиме high. Я не вдавался прям в подробности, но вкратце описал каждого игрока команды, слабые места команды и какое у кого амплуа и попросил сгенерировать расстановки на площадке с перемещениями в зависимости от амплуа (каждое амплуа, обычно, играет в определенной зоне).
В итоге ИИшка ушла в думы на 20 минут и не завершила ответ с первого раза. Было много комментариев про новый Sonnet, но чтобы на столько долго (да и токенов там улетело куча)... Это для меня было открытием. Я смотрел потом процесс рассуждений - Sonnet начал применять элементы комбинаторики к этой задаче, что, явно, было лишним.
Волейбол, сравнительно, не самый популярный вид спорта и область знаний. Этот кейс подсветил интересную вещь, когда ты даешь сравнительно узкую задачу в небольшом домене знаний даже современным мощным моделям может снести крышу и они уходят в высокие материи.
В очередной раз, какой бы не казалась задача несложной и понятной, лучше обрисовать ее детально и подготовить нужные инструкции.
Я увлекаюсь волейболом и перед соревнованиями решил дать задачу ИИшке, чтобы она проанализировала расстановку команды на площадке с учетом слабых и сильных сторон игроков команды, а также в динамике визуализировать это через html.
Для контекста: в волейбол играет 6 человек на каждой стороне площадки, разделенный сеткой. На площадке есть 6 зон, пронумерованных от 1 до 6. В зависимости от тактики игры и умений команды можно придумывать много разных вариантов, как эту расстановку игроков формировать, так как у каждого игрока свое амплуа и можно по разному их расставлять. При этом игроки могут перемещаться между зонами во время розыгрыша. То есть начинает розыгрыш игрок в 4 зоне, а после подачи переходит в 3, например. Короче, много нюансов,но не прям сложная математическая задача.
Я выбрал для этой задачи sonnet 5 в режиме high. Я не вдавался прям в подробности, но вкратце описал каждого игрока команды, слабые места команды и какое у кого амплуа и попросил сгенерировать расстановки на площадке с перемещениями в зависимости от амплуа (каждое амплуа, обычно, играет в определенной зоне).
В итоге ИИшка ушла в думы на 20 минут и не завершила ответ с первого раза. Было много комментариев про новый Sonnet, но чтобы на столько долго (да и токенов там улетело куча)... Это для меня было открытием. Я смотрел потом процесс рассуждений - Sonnet начал применять элементы комбинаторики к этой задаче, что, явно, было лишним.
Волейбол, сравнительно, не самый популярный вид спорта и область знаний. Этот кейс подсветил интересную вещь, когда ты даешь сравнительно узкую задачу в небольшом домене знаний даже современным мощным моделям может снести крышу и они уходят в высокие материи.
В очередной раз, какой бы не казалась задача несложной и понятной, лучше обрисовать ее детально и подготовить нужные инструкции.
🔥3🦄1