Синяя шляпа


Гео и язык канала: не указан, не указан
Категория: не указана


Заметки об инфобезе, инциденты, немного вредоносного кода, архитектура и разные интересные мне вещи.
По все вопросам - @st3l1n

Связанные каналы

Гео и язык канала
не указан, не указан
Категория
не указана
Статистика
Фильтр публикаций


Что LLM умеет реверсить, уже не новость. Но что же она все-таки не умеет?

Сегодня на боевом примере разберем факапы, с которыми я столкнулся в процессе анализа достаточно непростого импланта. Модифицированный Mythic-агент, три стадии, payload зашифрован на имени хоста жертвы, куча техник защиты типа предикатов, резолва функций по хешам etc.

Стенд: IDA Pro + MCP, opencode, GLM 5.2 self-hosted, я оператор. Две сессии (у нас было 2 семпла): 5.5 ч. работы агента, 56 моих реплик, ~800 вызовов инструментов, ≈5 тыс ₽ (на Opus 5 вышло бы ≈$165).

1️⃣ Уверенно-неверно. Нашла в payload BeaconDataParse, BeaconOutput и написала "Cobalt Strike". Дальше я сказал модели, что это точно не cobalt и пусть идет ищет дальше. Ответ: "Моя предыдущая идентификация была ошибочной, принял Beacon API за доказательство, не проверив формат протокола". При этом формат ответа был с самого начала в разборе самой модели, но она все равно абсолютно уверено рапортовала про cobalt strike .

2️⃣ Тихий пропуск. Модель сформировала красивый структурированный отчет по функционалу, вытащила конфиг, C2 домен, функционал, но есть нюанс... В семпле было 2 зашитых домена. Второй домен я нашел уже из сетевой телеметрии хоста. После просьбы проверить точнее через 5 минут находит: домен разрезан на три 8-байтовых XOR-чанка. И модель успешно его пропустила, вместе с механизмом "резервирования" этих доменов.

3️⃣ Не бережёт контекст. После сжатия сессии или, был момент, когда у меня отвалился MCP, модель заново пытается "захавать" весь декомпилированный код. В итоге шлюз сразу вылетает на ошибке переполнения входного контекста.

4️⃣ Не справилась с задачей эмуляции. Попросил проэмулировать shellcode до открытия сокета, без реальной сети. На самом деле я уже проворачивал подобные вещи, но именно в этот раз модель 20 минут пыталась поставить правильный unicorn, в конечном итоге я просто отказался от этой идеи, потому что статика дала исчерпывающий ответ.

5️⃣ Пыталась уйти от вопроса. 10:13: "при каких условиях вызывается второй домен?" Модель ушла в структуры профилей и флаги. 10:27: "давай вернёмся, это важно". 11:35: "напоминаю, мы ищем условие". 11:37: "Вы правы, я ушёл в детали". Ответ пришёл в 12:16. Пришлось прям дожать модель в этом вопросе.

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

Если хотите побольше послушать про наши эксперименты, приходите, там будет много интересного.


#ttp #APT
Группировка GOFFEE отличается умом и сообразительностью.

Известно, что они используют модификацию Mythic для закрепления в инфраструктуре своих жертв. В ходе своих атак они расставляют свои импланты по инфраструктуре, в каждом таком импланте есть по несколько доменов (обычно два, но динамически их можно добавлять оператором). Вроде ничего интересного, но есть один нюанс...

Некоторые домены, которые они оставляют - еще не существуют. Cамое интересное, что в любой момент, когда они таки зарегают такой домен, имплант, который не был найден изначально, даст им сразу же канал в зараженную ранее инфраструктуру, пусть в результате прошлого IR были найдены все ДЕЙСТВУЮЩИЕ домены.

Причем этот прием они используют уже достаточно давно, года 2 как минимум.

На заметку всем заинтересованным


Вещаю сегодня про ИИшки в Питере, а уже в пятницу буду в Москве рассказывать про ИИ и кибербез на классном мероприятии MWS. Приходите слушать, общаться, обсуждать)


Интересный факт (спасибо моему коллеге)

Если взломать TrueConf и забрать значения из ключа HKEY_LOCAL_MACHINE\SOFTWARE\TrueConf\Server\Configuration (Shared Key, Shared Key With Prefix 3), то в будущем (даже после патча) можно зайти под любым юзером через веб (т. е. сделать себе токен доступа). Решение — установка TrueConf с нуля (на чистой виртуалке).

Передаю привет всем счастливым обладателям TrueConf!

UPD
Эти значения можно ротировать вручную через:
Панель управления → Настройки, блок «Приложение»
- Ключ для авторизации пользовательских подключений
- Ключ для авторизации гостевых подключений


Хочется поделиться своими впечатлениями о походе в горы и проложить некоторые параллели с жизнью.

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

2. Демократии не существует. Есть главный и он решает, что делать. Да, он может советоваться с другими, но конечное решение за ним. Финальное решение не обсуждается, даже если оно выглядит неверным.

3. Будь гибким. Подстраивайся под текущие условия. Не пытайся пробить стену головой, либо придумай другой способ (другой маршрут) либо отложи до лучших времен. Нет воды? Растопи снег. Нет дров? Зажги газовую горелку. Сложно приготовить еду? Ешь сухое.

4. Не спорь с объективным. Если природа тебе говорит, что ты туда не пойдешь - не пытайся с ней спорить.

5. Большая сила - большая ответственность. Команда двигается к общей цели, если у тебя больше ресурса - помоги всей команде достичь результата. Подними чужой рюкзак, разведай тропу, поставь палатку и так далее.

6. Не делай поспешных выводов. Перед выходом в поход прогноз погоды давал дождь каждый день. В результате, все дни похода светило яркое солнце. Оффтоп. На самом деле для этого у нас есть замечательная традиция выпивать по рюмочке горячительного перед следующим днем за погоду. За более чем 5 лет традиция сбоя не дала.

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

8. Будь решителен. В походе я часто уходил на разведку маршрута вперед группы. В один из дней мы решили дойти до непростой стоянки, которая была в районе 3000 метров над уровнем моря. Мы решили поделить группу на две части: побыстрее и помедленнее, чтобы разведать, что там вообще впереди. В результате 20 минут прыгания по камням я увидел лишь снежные поля. Тем временем на часах 19:30, опускается туман, а мы посреди снежной долины без воды и стоянки, еще и рации сбоили. В итоге пришлось развернуть всю группу, не смотря на то, что я не был старшим, он остался в более медленной группе. Именно там мы встретили туров (горные козлы), которые как бы предостерегли нас от дальнейшего восхождения.

9. Будь самостоятельным. Никто за тебя не разберет палатку, не помоет посуду, не унесет мусор, не укроет вещи от утренней росы. Конечно, в команде можно что-то делегировать и попросить, но ты отвечаешь за свой комфорт и результат и никто другой.

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

Если убрать специфичные для похода вещи, то все эти пункты очень хорошо ложатся на любую область жизни: работа, дом, хобби и так далее. Несмотря на банальность этих пунктов они сохраняют свою актуальность. Открывайте новое и будьте смелыми💪🏻


Пока админ шляется по горам всем хорошего лета и настроения🏕️




Вчера была забавная история с ИИ (не опять, а снова).

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

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

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

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

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

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


Новый повод для радости❤️


Сейчас на просторах рунета активно работает RareWerewolf. Об этом уже писали в каналах, даже индикаторы постили. Я хочу просто рассказать про маленький хак, как анализировать вложение их писем.

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

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

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

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

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

В общем, кожаные мешки еще будут востребованы.


На хабре увидел небольшую статью по атакам на mcp сервера и я решил поделиться, как я защищаю свои mcp от похожих атак.

У меня есть два класса mcp серверов:
- корпоративные
- личные

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

В качестве корпоративного mcp может быть сервер для работы с opensearch, postgresql, clickhouse и любыми другими системами, которые вы используете. Ваш агент сможет взаимодействовать с прод (или тест) системой по понятным правилам.

Для личного я использую связку url secret + oauth. url secret позволяет отрезать подавляющее большинство ботов, а oauth просто не даст сделать запрос без аутентификации на моей учетке. oauth я завожу через workos. Если вы не упорный параноик - то это решение очень хорошо подходит для личного пользования.

Для корпоративного контура все сложнее. Не смотря на то, что почти все mcp у вас будут внутренние встает масса других вопросов:
1. аудит доступа
2. разграничение прав
3. разрешение конкретных тулов
4. маршрутизация запросов и т.д.

Эта задача чуть сложнее и требует отдельной статьи но в качестве готового решения (нужно настраивать) можно использовать agentgateway. Он позволяет решить все эти задачи и кроме того сделать отдельный шлюз для AI провайдеров в контуре организации.




NIST 800-61 — это не про реальное внешнее реагирование

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

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

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

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

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


Многие вокруг говорят, что обойти защиты ИИ не так сложно. В первые дни выпуска Fable от Anthropic соцсеть X (formerly twitter) так и пестрила о том, что почти все обошли гардрейлы.

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

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

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

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

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

Следите за агентами и все будет хорошо)


Пришло приглашение на offzone, экзешник на маке не открывается, переслал друзьям, чтобы открыли. По любому приняли доклад


«У меня локальная модель — значит, приватно». Не совсем.

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

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

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

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

А вообще SANS уже давно все рассказали. Можно как минимум почитать syllabus.


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

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

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

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

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

Ни в коем случае не гарантирую результат, но у меня сработало)


Самое смешное в этом кейсе, что окончательно докопавшись до правды, я выяснил, что пробив был такой:

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

Очередное напоминание, что чаще всего не нужно искать сложность, все на поверхности...


Столкнулся с интересным кейсом.

Инцидент с шифровальщиком, точка входа известна но сама машина пошифрована на уровне esxi.

На входной машине есть сервис, код закрыт, версия известна, но уязвимостей на него нет.

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

Происследовав сервис стало понятно, что за торчащие на внешку ручки отвечал один бинарник, более 10 МБ, C++, с символами.

И дальше начинается самое интересное, “а что если отдать ИИшке найти уязвимость” - подумал я…

И эта шайтан машина за 2 часа нашла мне два вектора эксплуатации heap overflow -> RCE через один механизм. За 2 часа бинарник в 10 МБ был препарирован и уязвимость найдена. Искал в Opus 4.8, заодно попробовал их новый механизм workflows, когда 15 агентов одновременно проверяли гипотезы.

По токенам, я ожидал, что он съест все лимиты, но нет, всего половину 5-часового лимита.

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

За 2 часа я нашел очень правдоподобный вектор эксплуатации уязвимости в большом бинаре. Впечатляет…


tg_image_1894510463.png
75.2Кб
tg_image_3187528330.png
83.9Кб
Иногда возникает вопрос, а как проанализировать большое массив данных?

Например, вот у нас есть 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 для фильтрации событий и можем быстро просматривать большое количество событий, применяя удобную фильтрацию (фильтры можно делать любой сложности, в зависимости от уровня извращенности)

Таким образом достаточно удобно выявлять аномалии на больших объемах.

Показано 20 последних публикаций.