Предположим, что у вас есть образ 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