Синяя шляпа
96 subscribers
24 photos
1 video
5 files
34 links
Заметки об инфобезе, инциденты, немного вредоносного кода, архитектура и разные интересные мне вещи.
По все вопросам - @st3l1n
Download Telegram
Сейчас я плотно занимаюсь изучением ИИ и экспериментами в разных областях: DFIR, reverse, Программирование, дизайн да и вообще много чего.

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

Сначала я проделал тест на обычных премпромтах + opencode. Далее я сам погружал агента в специфику и управлял его действиями (важно, использовались внутренние модели, которые, все же, хуже внешних, но достаточно хороши при правильном использовании)

Подход был очень простой:
1. Генерим гипотезы
2. Проверяем в артефактах
3. Записываем выводы в промежуточные файлы
4. Повторяем
5. Объединяем все в один отчет

Пример такого отчета я постил выше.

Такой подход - это автоматизация твоей работы, но не то чтобы прорыв. Считай, не ты грепаешь файл, а агент. Далее его выводы все равно ты интерпретируешь и ведешь его от и до, попутно борясь с его галлюцинациями и мислидами.

Конечно я захотел развить эту идею до автономного агента, провел ресерч, заложил туда методологии типа DFIQ и принципа Локара, использовал разные современные подходы, типа графа состояний и векторной инвентаризации артефактов и т.п.

Но, конечно, агент стал уходить в прострации, то есть начал слишком много "философствовать", при этом задачу свою не выполнял.

Отсюда я пришел к идее ограничений (прям как РКН, хаха). То есть нужно было придумать, как агента направлять в нужное русло и ограничивать его циклы по одному и тому же файлу, так как ни время ни контекст не резиновые.

Среди таких ограничений были, например:
1. Ограничение на бесконечный поиск.
2. Усиление валидации путей до артефактов.
3. Ограничение на количество гипотез и т.д.

И знаете что? С внедрением ограничений стало только ХУЖЕ.

Я не скажу, что это какой-то вау результат и что-то супер неожиданное, но тем не менее, агент стал нефункциональным.

Каждый guard, который блокирует, создаёт состояние «агент не может сделать ничего разумного — выбери из 5 неподходящих вариантов». LLM в такой ситуации либо повторяется (что блокирует следующий guard), либо галлюцинирует (что блокирует другой guard). Итого агент просто зависает или сразу завершается. И все твои умные и накрученные фичи просто не работают.

И вроде каждое из этих ограничений само по себе было разумным, но их комбинация сделала сильно хуже.

Короче говоря, мой небольшой эксперимент с симуляцией РКН провалился, агентов не нужно загонять в ограничения (во всяком случае в этом домене). Будем посмотреть дальше, что из этого получится.
🔥8🦄2
Немного слов по форензику контейнеров.

Сейчас часто публикуют свои приложения в 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 года будете сражаться с вооруженными топовыми ллм по взлому хакерами.
🦄2
tg_image_3187528330.png
83.9 KB
Иногда возникает вопрос, а как проанализировать большое массив данных?

Например, вот у нас есть 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 часа я нашел очень правдоподобный вектор эксплуатации уязвимости в большом бинаре. Впечатляет…
🔥9🦄1
Синяя шляпа
Столкнулся с интересным кейсом. Инцидент с шифровальщиком, точка входа известна но сама машина пошифрована на уровне esxi. На входной машине есть сервис, код закрыт, версия известна, но уязвимостей на него нет. Перед шифрованием на машине сохранились логи…
Самое смешное в этом кейсе, что окончательно докопавшись до правды, я выяснил, что пробив был такой:

1. Заход под сервисной учетной записью в вебку сервиса
2. С помощью встроенного функционала сервиса выполнение команд на хосте
Никакого 0day, никакой сложной эксплуатации. Как обычно: утекшие креды -> пробив.

Очередное напоминание, что чаще всего не нужно искать сложность, все на поверхности...
👍2🔥2🦄2
В последнее время я начал больше заниматься всякими штуками типа binary pwn, реверс всего и вся и ресерч разных интересных вещей.

Конечно, модели мне вставляли палки в колеса, Клод постоянно писал, что я что-то нарушаю и вообще это не по феншую.

Для того, чтобы такого было меньше можно попросить снять эти гарды.
Для OpenAI это Trusted Access for Cyber, для Anthropic - Cyber Verification Program.

Оказывается, получить это не так сложно. Для Антропика заполняем небольшую анкетку. В одном из пунктов вас спросят про ваши работы, баг баунти репорты или может ли кто-то за вас поручиться.

У меня не оказалось англоязычных статей, поэтому... Я просто вставил ссылки на google translate своих отчетов на русском и прокатило.

Ни в коем случае не гарантирую результат, но у меня сработало)
🔥4🦄1
«У меня локальная модель — значит, приватно». Не совсем.

Сейчас все больше людей играется с локальными ИИ моделями, и понятно почему. Приватные данные требуют локальной обработки, чтобы не отсылать данные наружу.

Но вот интересная история, где с одной стороны - приватность, с другой стороны - открытость. Представим, что такому экспериментатору заслали стиллер, что он найдет на его машине?

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

В то же время, для ребят с реагирования это становится очень ценным источником данных, где можно найти много разного контекста. Вот пример захода в эту сторону.

А вообще SANS уже давно все рассказали. Можно как минимум почитать syllabus.
1🔥1🦄1
Пришло приглашение на offzone, экзешник на маке не открывается, переслал друзьям, чтобы открыли. По любому приняли доклад
🍌6🦄3
Многие вокруг говорят, что обойти защиты ИИ не так сложно. В первые дни выпуска Fable от Anthropic соцсеть X (formerly twitter) так и пестрила о том, что почти все обошли гардрейлы.

Но это все хайп и написать можно что угодно. Один из исследователей решил провести эксперимент.

Суть эксперимента - вот вам мой openclaw на opus 4.6, обойдите его защиту через prompt injection в электронном письме (а по данным owasp - это самая опасная, простая и распространенная атака)

Так вот, тысячи попыток и ни одного пробива. Конечно, исследователь постарался и обвесил агента доп защитами, но тем не менее.

Этот кейс чем-то похож на бездумное внедрение сием системы. Да, вы можете поставить себе сием, но без настройки и персонала она вряд ли даст адекватный эффект. Так же здесь, если агента не обвесить ограничениями и защитой - он становится слабо контролируемым.

Конечно, сам по себе этот кейс мало что показывает глобально, так как поведение модели стохастическое и экстраполировать один эксперимент неразумно.

Следите за агентами и все будет хорошо)
🔥31🦄1
NIST 800-61 — это не про реальное внешнее реагирование

Если ты выбрал(а) тернистый путь DFIR, то, вероятно, на любом курсе по реагированию и почти на каждом собесе тебя спросят про фазы: подготовка, обнаружение и анализ, сдерживание, ликвидация, восстановление, выводы. NIST SP 800-61, SANS, ISO 27035, наш ГОСТ Р 59712 — все крутятся вокруг них. В современном DFIR сообществе это стало базой, нулевой точкой отсчета для кандидата.

Как всегда, есть нюанс. Все эти документы написаны для владельца инфраструктуры — того, кто заранее знает свои активы, настроил мониторинг и сидит на полной телеметрии. Для него фазы и правда работают.

А теперь ты приходишь внешней командой. Инфра незнакомая, журналирование настроено наполовину, часть данных уже затёрта, времени впритык. И фазы начинают плыть: сдерживание нередко стартует до того, как ты закончил анализ, сбор данных продолжается уже после начала восстановления, а иногда и после локализации. По факту работа идёт не фазами, а петлями: набросал гипотезы -> под них целенаправленно собрал данные-> подтвердил / опроверг / раздробил -> повторил. Фазовая модель этот цикл не описывает и не говорит, когда остановиться.

Интересно, что в 2025 сам NIST в редакции 800-61r3 убрал модель жизненного цикла и встроил реагирование в общий цикл управления рисками. Правда, ушёл в другую крайность — получился рамочный документ, по которому регламент работы команды тоже не построишь.

К чему это. Фазы — удобная рамка, больше про бумажную безопасность и "соответствие" мировым стандартам. Это хороший пример того, что вроде теория красивая и создана лидирующими экспертами, но жизнь немного сложнее...
👎2🦄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 провайдеров в контуре организации.
🍓2🦄1
Сейчас на просторах рунета активно работает RareWerewolf. Об этом уже писали в каналах, даже индикаторы постили. Я хочу просто рассказать про маленький хак, как анализировать вложение их писем.

Внутри их письма exe файл, собранный установщиком Smart Install Maker. Сейчас я провожу реверс через ИИ агента, но это как раз тот случай, когда быстрее сделать руками. Для распаковки этого установщика можно использовать утилиту. Несмотря на то, что она не поддерживается какое-то время - она отлично справляется со своей задачей. При ее использовании нужно докачать модуль sim_extract. Это делается из коробки, если есть интеренет - утилита сама скачает, если нет - то можно подложить файл. Сделано для людей.

На выходе у вас будут вложения в сам файл и конфиг инсталлятора. Основная логика зашита в конфиг инсталлятора installer.config. Это не самый удобный файл для чтения, но все команды оттуда можно вычленить.

Конкретно RareWerewolf пошли чуть хитрее, они не держат всю нагрузку внутри начального пейлоада, а докачивают ее через C2. Здесь по пунктам они заложили следующие файлы:
1 - decoy pdf
2 - текст адрес C2
3 - curl для windows

далее инсталлятор уже работает со скаченным payload. По техникам они крадут пароли и потом закрепляются через AnyDesk, особенно ничего нового.

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

В общем, кожаные мешки еще будут востребованы.
🔥2🍓1🦄1
Новый повод для радости❤️
🦄7👍3🍌2
Вчера была забавная история с ИИ (не опять, а снова).

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

Для контекста: в волейбол играет 6 человек на каждой стороне площадки, разделенный сеткой. На площадке есть 6 зон, пронумерованных от 1 до 6. В зависимости от тактики игры и умений команды можно придумывать много разных вариантов, как эту расстановку игроков формировать, так как у каждого игрока свое амплуа и можно по разному их расставлять. При этом игроки могут перемещаться между зонами во время розыгрыша. То есть начинает розыгрыш игрок в 4 зоне, а после подачи переходит в 3, например. Короче, много нюансов,
но не прям сложная математическая задача.

Я выбрал для этой задачи sonnet 5 в режиме high. Я не вдавался прям в подробности, но вкратце описал каждого игрока команды, слабые места команды и какое у кого амплуа и попросил сгенерировать расстановки на площадке с перемещениями в зависимости от амплуа (каждое амплуа, обычно, играет в определенной зоне).

В итоге ИИшка ушла в думы на 20 минут и не завершила ответ с первого раза. Было много комментариев про новый Sonnet, но чтобы на столько долго (да и токенов там улетело куча)... Это для меня было открытием. Я смотрел потом процесс рассуждений - Sonnet начал применять элементы комбинаторики к этой задаче, что, явно, было лишним.

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

В очередной раз, какой бы не казалась задача несложной и понятной, лучше обрисовать ее детально и подготовить нужные инструкции.
🔥3🦄1
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥1🦄1