Предположим, что у вас есть образ Linux машины (это может быть raw образ или образ виртуалки) и мы хотим его быстро посмотреть в графике, прошерстить папки и файлы, не зная изначально, что ищем. При этом поднимать macos, linux, wsl или платный софт для этого не хочется.
Для этого можно использовать старый добрый total commander и плагин diskinternals (скачивать дают через впн).
1. Ставим бесплатную версию total commander
2. Устанавливаем плагин
3. Получаем простой и лаконичный результат, без установки драйверов и проприетарного ПО.
Для этого можно использовать старый добрый total commander и плагин diskinternals (скачивать дают через впн).
1. Ставим бесплатную версию total commander
2. Устанавливаем плагин
3. Получаем простой и лаконичный результат, без установки драйверов и проприетарного ПО.
🍓2
Во многих коммерческих и inhose SOC есть правила, которые триггерятся при заходе RDP на какие-то критичные хосты, тем более в нерабочее время. Если говорить про событие 4624 тип 7 (переподключение RDP сессии), то оно может вызываться при небольшом сбое сети: мигнул wifi, отвалился VPN, сменился маршрут и так далее.
Таким образом, если админ оставил в облачной инфре активную rdp сессию, потом мигнула сеть, а потом восстановилась, то мы увидим восстановление сессии, события 4624, 4778 и предыдущий тип RDP сессии.
Такую активность лучше всегда коррелировать с чем-то еще.
Таким образом, если админ оставил в облачной инфре активную rdp сессию, потом мигнула сеть, а потом восстановилась, то мы увидим восстановление сессии, события 4624, 4778 и предыдущий тип RDP сессии.
Такую активность лучше всегда коррелировать с чем-то еще.
❤1🔥1
Занятная история с трендом по initial access.
А именно trusted relationship (T1199).
1. Отчет Positive Technologies - 28% атак за неполный 2025 год
2. Отчет Kaspersky за 2024 год (рост г/г в два раза)
3. Отчет F6 говорит о том, что этот вектор является одним из самых активных
4. Исследование BI.Zone говорит, что как минимум 10 кластеров активности использует этот вектор и что он активно используется
5. Solar говорит про 27%
6. RED Security дает оценку в 33%
Так о чем это я. Рядом с уже привычным фишингом и пробивом периметра появляется третий столп в виде атаки на доверительные отношения (появился он давно, но по процентам вышел на уровень совсем недавно). И, порой, этот вектор становится наиболее сложным для обнаружения, потому что к нему относятся не так трепетно (хотя казалось бы). Я часто встречал, что у сопряжений с подрядчиком нет мониторинга, нет нормальных ACLов, повышенные права, потому что "ну очень нужно было для пилота".
Важно знать про этот вектор и помнить, что он решается не только технически, но и организационно на уровне договоров и политик. Stay safe.
А именно trusted relationship (T1199).
1. Отчет Positive Technologies - 28% атак за неполный 2025 год
2. Отчет Kaspersky за 2024 год (рост г/г в два раза)
3. Отчет F6 говорит о том, что этот вектор является одним из самых активных
4. Исследование BI.Zone говорит, что как минимум 10 кластеров активности использует этот вектор и что он активно используется
5. Solar говорит про 27%
6. RED Security дает оценку в 33%
Так о чем это я. Рядом с уже привычным фишингом и пробивом периметра появляется третий столп в виде атаки на доверительные отношения (появился он давно, но по процентам вышел на уровень совсем недавно). И, порой, этот вектор становится наиболее сложным для обнаружения, потому что к нему относятся не так трепетно (хотя казалось бы). Я часто встречал, что у сопряжений с подрядчиком нет мониторинга, нет нормальных ACLов, повышенные права, потому что "ну очень нужно было для пилота".
Важно знать про этот вектор и помнить, что он решается не только технически, но и организационно на уровне договоров и политик. Stay safe.
👍1🔥1
Интересно, а как с этим трендом обстоит в международном сегменте.
Международные команды не так щедры на прямые цифры, но выделить тренды все равно можно
1. SecurityScorecard говорят об общем росте доли атак через этот вектор до 35,5%. При этом, в некоторых отраслях процент доходит до 50%.
2. Verizon отмечают рост 15%->30% за 2024->2025 год.
3. Checkpoint не приводит каких-то прямых цифр, но за 2024 год отмечен активный рост атак.
4. Gartner прогнозирует, что в 2025 году с Supply Chain атаками (да не совсем то, но близко) столкнется около 45% организаций.
Резюмируя, здесь общемировые тренды схожи с нашими, поэтому вполне можно и нужно рассматривать опыт зарубежных коллег.
Международные команды не так щедры на прямые цифры, но выделить тренды все равно можно
1. SecurityScorecard говорят об общем росте доли атак через этот вектор до 35,5%. При этом, в некоторых отраслях процент доходит до 50%.
2. Verizon отмечают рост 15%->30% за 2024->2025 год.
3. Checkpoint не приводит каких-то прямых цифр, но за 2024 год отмечен активный рост атак.
4. Gartner прогнозирует, что в 2025 году с Supply Chain атаками (да не совсем то, но близко) столкнется около 45% организаций.
Резюмируя, здесь общемировые тренды схожи с нашими, поэтому вполне можно и нужно рассматривать опыт зарубежных коллег.
Подниму не самую популярную в ру комьюнити тему - DFIR на macOS
Решил вместе с Claude систематизировать свои заметки на эту тему, получилось неплохо. Почитать здесь.
Пару заметок на полях про macOS.
1. Хорошее вводное видео, рекомендую
2. Классный ресурс на почитать про устройство macOS и безопасность
3. Инструменты с чего начать:
- небезызвестный UAC
- нативный проект с MDM интеграцией
- Классика и не очень для анализа таймлайна
Я вместе с моим бро из @b4ckc0nn3ct решили сделать публичные и понятные доки по этой теме. Так что stay tuned, будет много интереcного.
Решил вместе с Claude систематизировать свои заметки на эту тему, получилось неплохо. Почитать здесь.
Пару заметок на полях про macOS.
1. Хорошее вводное видео, рекомендую
2. Классный ресурс на почитать про устройство macOS и безопасность
3. Инструменты с чего начать:
- небезызвестный UAC
- нативный проект с MDM интеграцией
- Классика и не очень для анализа таймлайна
Я вместе с моим бро из @b4ckc0nn3ct решили сделать публичные и понятные доки по этой теме. Так что stay tuned, будет много интереcного.
🔥7
Forwarded from Nick
Сегодня разберем интересный кейс "с полей". Есть такая группировка silent lynx aka Cavalry Werewolf.
У ребят широкая география работы и богатый на вариативность инструментарий.
На просторах интернета (ага, конечно ) я нашел их семпл, с незатейливым названием a.exe (скрин 1).
Мне стало интересно, а что они туда запаковали, и как известно, python можно разложить обратно в исходник как интерпретируемый язык (но есть нюансы).
Pyinstaller распаковывается легко, вот проект, там все нативно и понятно. Самое интересное впереди.
На выходе получаем вот такую структуру (скрин 2). По ней уже можно дернуть файлы конфигураций, файлы модулей, прикинуть функционал.
Естественно нас привлекает файл main.pyc. Это байткод, который получается при компиляции исходного кода через CPython. Основной нюанс, то что версий питона (хейтеры скажут пАЙтон) очень много, и байткод разный в зависимости от версий. Есть много проектов, которые "обращают" байткод обратно, самый популярный uncompyle. Но сейчас это уже более ресерческий проект, так как поддержка остановилась примерно на версии 3.9 (а сейчас уже есть rc 3.15). Таким образом, те декомпиляторы, которые не подходят по версии, нам не подойдут тоже. И здесь как раз тот кейс (скрин 3). Нам нужен python 3.13.
Если поресерчить эту тему дальше наткнемся на проект. Разработчик заявляет поддержку python 3.13. Как мы выясним далее, это не совсем так. Проект нужно собрать руками и запустить на желаемый pyc. И вот все, что мы получим здесь (скрин 4). Выглядит не очень круто.
Дальнейший ресерч привел меня к двум статьям
1
2
Если опустить всю теорию (ее вы можете почитать по ссылкам) нам нужно дописать свои обработчики при парсинге AST дерева опкодов. Как мы видим начать нам нужно с MAKE_FUNCTION. По второй ссылке можно найти подробнее, как это делается.
Тут важный момент, нам не нужно точное восстановление кода, нам нужно понимание семантики. А это значит что некоторые ошибки и несостыковки мы можем игнорировать, если понимаем код на выходе декомпилятора.
У меня ушло примерно 10 итераций с дописыванием своих обработчиков, потому что когда ты дописал один, возникает ошибка в другом.
На выходе получаем приличный читаемый код (скрин 6). На последнем скриншоте видно, что восстанавливается не все. Это связано с причиной описаной выше. Но если вам достаточно - не нужно упарываться и тратить часы/дни на перфекционизм.
Интересный кейс, хоть и само ВПО оказалось без каких-то сюрпризов - обертка над запускам code tunnels с захардкоженными доступами.
У ребят широкая география работы и богатый на вариативность инструментарий.
На просторах интернета (
Мне стало интересно, а что они туда запаковали, и как известно, python можно разложить обратно в исходник как интерпретируемый язык (но есть нюансы).
Pyinstaller распаковывается легко, вот проект, там все нативно и понятно. Самое интересное впереди.
На выходе получаем вот такую структуру (скрин 2). По ней уже можно дернуть файлы конфигураций, файлы модулей, прикинуть функционал.
Естественно нас привлекает файл main.pyc. Это байткод, который получается при компиляции исходного кода через CPython. Основной нюанс, то что версий питона (хейтеры скажут пАЙтон) очень много, и байткод разный в зависимости от версий. Есть много проектов, которые "обращают" байткод обратно, самый популярный uncompyle. Но сейчас это уже более ресерческий проект, так как поддержка остановилась примерно на версии 3.9 (а сейчас уже есть rc 3.15). Таким образом, те декомпиляторы, которые не подходят по версии, нам не подойдут тоже. И здесь как раз тот кейс (скрин 3). Нам нужен python 3.13.
Если поресерчить эту тему дальше наткнемся на проект. Разработчик заявляет поддержку python 3.13. Как мы выясним далее, это не совсем так. Проект нужно собрать руками и запустить на желаемый pyc. И вот все, что мы получим здесь (скрин 4). Выглядит не очень круто.
Дальнейший ресерч привел меня к двум статьям
1
2
Если опустить всю теорию (ее вы можете почитать по ссылкам) нам нужно дописать свои обработчики при парсинге AST дерева опкодов. Как мы видим начать нам нужно с MAKE_FUNCTION. По второй ссылке можно найти подробнее, как это делается.
Тут важный момент, нам не нужно точное восстановление кода, нам нужно понимание семантики. А это значит что некоторые ошибки и несостыковки мы можем игнорировать, если понимаем код на выходе декомпилятора.
У меня ушло примерно 10 итераций с дописыванием своих обработчиков, потому что когда ты дописал один, возникает ошибка в другом.
На выходе получаем приличный читаемый код (скрин 6). На последнем скриншоте видно, что восстанавливается не все. Это связано с причиной описаной выше. Но если вам достаточно - не нужно упарываться и тратить часы/дни на перфекционизм.
Интересный кейс, хоть и само ВПО оказалось без каких-то сюрпризов - обертка над запускам code tunnels с захардкоженными доступами.
⚡2
Всех с праздником защитника отечества!
А так как DFIR - это тоже защита цифровых рубежей отечественных информационных систем, то выкладываю апдейт по awesome_dfir для Windows.
Совсем скоро начнем делать разделение для удобства по топикам, пока сводим всю информацию в едино. Посмотреть тут.
А так как DFIR - это тоже защита цифровых рубежей отечественных информационных систем, то выкладываю апдейт по awesome_dfir для Windows.
Совсем скоро начнем делать разделение для удобства по топикам, пока сводим всю информацию в едино. Посмотреть тут.
⚡2🍓2🦄1
Интересная история связанная с нашумевшим Claude Code Security. В последние полгода модели взлетели колоссально по уровню работы. У меня есть свои пет проекты, и мне есть с чем сравнить. То что делают модели сегодня, было просто невозможно еще в сентябре 2025.
Но пост не про поклонение AI и SkyNet, а про то, что же делать обычному деревнскому AppSec инженеру Васе при таких раскладах. Ведь хайп хайпом, а security-review действительно уже можно проводить llm, если не паритесь за конфиденциальность кода.
1. Очевидно, что конкурировать с llm моделями в одной конкретной задаче не получится. Это не получается даже у ведущих физиков и математиков. Таким образом для всех специалистов (и я тут не только про AppSec) умение пользователься AI инструментами становится очень важным скиллом.
2. "Сдвиг по фазе". Этот сдвиг уже произошел в разработке и сейчас будет происходить в ИБ. Нам нужно не просто писать конкретную фичу или внедрять конкретный механизм безопасности, а понимать, как работает система в целом и как связать разные функциональные блоки. Приводя аналогию с разработкой, теперь тебе нужно не уметь программировать на KOBOL, а уметь понимать логику продукта, его сильные и слабые стороны и уметь превращать это все в бизнес ценность (хоть и частично это можно решить с помощью CLAUDE.md).
3. Продолжая тему с бизнес ценностью. Пока уровень внедрения и контекста AI моделей не позволяет вкладывать туда ВЕСЬ контекст продукта/инфраструктуры/орг. особенностей. Именно здесь человек выигрывает. При этом оценка бизнес влияния с помощью модели пока сильно ограничена. То есть мы переходим от более операционных целей к более стратегическим.
4. Глубина исследования. Несмотря на мощь LLM, пока модели не могут учитывать все окружение работы продукта. Таким образом верификация/разбор наиболее глубоких кейсов/интеграция также остается на человеке. Чем меньше домен знаний - тем слабее там будет модель. Таким образом наиболее узкие и глубокие специальности будут востребованы еще продолжительное время. Особенно это относится к наиболее закрытым доменам: Реагирование на инциденты, переговорные треки, сложные технические интеграции и т.п.
5. А если LLM проверяет нас, то кто проверяет ее/его/их? Область безопасности ИИ в России пока зарождается, и заходить туда самое время.
6. Зона ответственности. Перекладывать ответственность на AI пока готовы далеко не все. Поэтому область, где высокая доля ответственности также не будет заменятся в ближайшем будущем.
7. Реальный наступательный опыт. Все-таки человеческая творческая жилка уникальна. Иногда хакеры могут найти такие подходы, что ни одна llm модель бы не придумала такого. Такой нестандартный подход пока тоже не всегда доступен llm (и будет ли?).
Короче, варианты есть, просто заскакивать на волне хайпа в технологичные сферы будет все сложнее, и включать голову придется чаще.
Но пост не про поклонение AI и SkyNet, а про то, что же делать обычному деревнскому AppSec инженеру Васе при таких раскладах. Ведь хайп хайпом, а security-review действительно уже можно проводить llm, если не паритесь за конфиденциальность кода.
1. Очевидно, что конкурировать с llm моделями в одной конкретной задаче не получится. Это не получается даже у ведущих физиков и математиков. Таким образом для всех специалистов (и я тут не только про AppSec) умение пользователься AI инструментами становится очень важным скиллом.
2. "Сдвиг по фазе". Этот сдвиг уже произошел в разработке и сейчас будет происходить в ИБ. Нам нужно не просто писать конкретную фичу или внедрять конкретный механизм безопасности, а понимать, как работает система в целом и как связать разные функциональные блоки. Приводя аналогию с разработкой, теперь тебе нужно не уметь программировать на KOBOL, а уметь понимать логику продукта, его сильные и слабые стороны и уметь превращать это все в бизнес ценность (хоть и частично это можно решить с помощью CLAUDE.md).
3. Продолжая тему с бизнес ценностью. Пока уровень внедрения и контекста AI моделей не позволяет вкладывать туда ВЕСЬ контекст продукта/инфраструктуры/орг. особенностей. Именно здесь человек выигрывает. При этом оценка бизнес влияния с помощью модели пока сильно ограничена. То есть мы переходим от более операционных целей к более стратегическим.
4. Глубина исследования. Несмотря на мощь LLM, пока модели не могут учитывать все окружение работы продукта. Таким образом верификация/разбор наиболее глубоких кейсов/интеграция также остается на человеке. Чем меньше домен знаний - тем слабее там будет модель. Таким образом наиболее узкие и глубокие специальности будут востребованы еще продолжительное время. Особенно это относится к наиболее закрытым доменам: Реагирование на инциденты, переговорные треки, сложные технические интеграции и т.п.
5. А если LLM проверяет нас, то кто проверяет ее/его/их? Область безопасности ИИ в России пока зарождается, и заходить туда самое время.
6. Зона ответственности. Перекладывать ответственность на AI пока готовы далеко не все. Поэтому область, где высокая доля ответственности также не будет заменятся в ближайшем будущем.
7. Реальный наступательный опыт. Все-таки человеческая творческая жилка уникальна. Иногда хакеры могут найти такие подходы, что ни одна llm модель бы не придумала такого. Такой нестандартный подход пока тоже не всегда доступен llm (и будет ли?).
Короче, варианты есть, просто заскакивать на волне хайпа в технологичные сферы будет все сложнее, и включать голову придется чаще.
Anthropic
Making frontier cybersecurity capabilities available to defenders
Claude Code Security is one step towards our goal of more secure codebases and a higher security baseline across the industry.
🍓2👎1