Во многих коммерческих и 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
В репозиторий awesome_dfir добавлен общий документ по Linux
https://github.com/st3l1n/awesome_dfir/blob/main/linux.md
заканчиваю формировать скелет репозитория, совсем скоро приведу его в нормальный вид и начнем структурировать информацию по техникам, процедурам, инструментам, добавлять интересные эвристики и примеры "с полей".
Подключайтесь, зовите друзей, адекватный фидбек привествуется.
https://github.com/st3l1n/awesome_dfir/blob/main/linux.md
заканчиваю формировать скелет репозитория, совсем скоро приведу его в нормальный вид и начнем структурировать информацию по техникам, процедурам, инструментам, добавлять интересные эвристики и примеры "с полей".
Подключайтесь, зовите друзей, адекватный фидбек привествуется.
🍓5🔥1
Поговорим про собеседования и отбор кандидатов.
Внимание! Указанные мысли являются имхо автора, могут не совпадать с пониманием прекрасного читателя.
Фаза 0. А зачем нам этот человек. Какие функции он будет выполнять. Что он должен привнести в команду. Закрыть дыры в SLA? Быть архитектором нового направления? Быть частью сформированной команды? Какие результаты мы от него ждем и как это поможет команде достичь целей, а бизнесу заработать? Со стороны собеседующего хорошо бы подготовить хотя бы тезисы ответов на эти вопросы, так будет проще на всех этапах дальше.
Когда человек проходит собеседование в компанию (не важно, на какую позицию, должность, грейд, вилку и иже с ними) хорошо бы, чтобы он поставил себя на места собеседующего, услышал его доводы, спросил “а зачем вам такой спец, какие задачи хотите решать”. Это сильно поможет в дальнейшем диалоге.
Фаза 0.1. Составление плана собеседования.
Очень важная вещь. Вообще человек существо субъективное. Вот хоть тресни, но если кандидат тебе понравился, то даже если он провалил интервью, все равно ты будешь говорить, что он неплох. Здесь варианта 2: либо собеседовать очень много людей и вырабатывать устойчивость к этому эффекту, либо составить план собеседования. Я для себя разбил его на блоки, взвесил каждый блок по важности для меня и разбил каждый блок на субблоки. Для каждого субблока оценка от 1 до 5. Далее мы считаем среднее по каждому блоку, взвешиваем и снова считаем среднее. Очень помогает убрать искажение, так как оценка 1 вопроса - это не сложно. А вот удержать все ответы в голове еще и говоря при этом - задача не из простых. Это не значит, что для всех флоу собеседования будет одинаковый - нет. Просто все вопросы будут так или иначе сводится к одним категориям, и по ним будут формальные оценки. Таким образом сравнивать кандидатов между собой становится проще, да и определить формальную границу прошел/не прошел тоже.
Фаза 1. Опыт.
Как правило на всех собеседованиях тебя спросят, а какой у тебя опыт. Если в резюме есть что-то интересное для собеседующего и для целей вакансии, то вопросы могут быть достаточно подробные. Далее все зависит от позиции. Если идешь на позиции синьор-помидор+, то важно фокусироваться на процессах, методологиях, результатах. Если позиция пониже - то тут фокус смещается на техническую глубину, понимание своей зоны ответственности и здравого смысла. Особенно важно не говорить лишнего, это быстро вскрывается и сильно понижает очки.
Фаза 2. Интервью
И снова это сословное неравенство. Все-таки от сеньоров ожидается больше, чем “я круто разбираюсь в этом”. Как делаю я - из опыта переходим в базовые знания -> оттуда чуть глубже -> сразу реальный (или смоделированный) кейс с одинаковым вопросом в конце “что делать?”. В целом такую же схему можно взять для менее опытных кандидатов, но процент негативных ответов может быть очень большим.
Для вопросов, где ответ может быть разный (например, схема реагирования на конкретный кейс), я всегда задаю вопрос, а как можно еще, сильный кандидат всегда должен придержать козырь в рукаве. Наигравшись в моделирование сразу становится понятно реальный опыт кандидата, сколько пороху понюхал и видов повидал. Отсюда можно переходить в архитектуру (если еще релевантно😈). Для меня сеньор - это архитектор, человек, который может проектировать рабочие системы. Приведу примеры: для реверса - это процесс анализа ВПО с автоматизациями, для DFIR - прикладной процесс реагирования и обогащение с других направлений, для SOC - как построить процесс третхантинга без мильона фолсов и пропусков и так далее. Если человек не умеет проектировать процесс хотя бы верхнеуровнево - то это middle+, не выше (а может и ниже). Продолжение 👇.
Внимание! Указанные мысли являются имхо автора, могут не совпадать с пониманием прекрасного читателя.
Фаза 0. А зачем нам этот человек. Какие функции он будет выполнять. Что он должен привнести в команду. Закрыть дыры в SLA? Быть архитектором нового направления? Быть частью сформированной команды? Какие результаты мы от него ждем и как это поможет команде достичь целей, а бизнесу заработать? Со стороны собеседующего хорошо бы подготовить хотя бы тезисы ответов на эти вопросы, так будет проще на всех этапах дальше.
Когда человек проходит собеседование в компанию (не важно, на какую позицию, должность, грейд, вилку и иже с ними) хорошо бы, чтобы он поставил себя на места собеседующего, услышал его доводы, спросил “а зачем вам такой спец, какие задачи хотите решать”. Это сильно поможет в дальнейшем диалоге.
Фаза 0.1. Составление плана собеседования.
Очень важная вещь. Вообще человек существо субъективное. Вот хоть тресни, но если кандидат тебе понравился, то даже если он провалил интервью, все равно ты будешь говорить, что он неплох. Здесь варианта 2: либо собеседовать очень много людей и вырабатывать устойчивость к этому эффекту, либо составить план собеседования. Я для себя разбил его на блоки, взвесил каждый блок по важности для меня и разбил каждый блок на субблоки. Для каждого субблока оценка от 1 до 5. Далее мы считаем среднее по каждому блоку, взвешиваем и снова считаем среднее. Очень помогает убрать искажение, так как оценка 1 вопроса - это не сложно. А вот удержать все ответы в голове еще и говоря при этом - задача не из простых. Это не значит, что для всех флоу собеседования будет одинаковый - нет. Просто все вопросы будут так или иначе сводится к одним категориям, и по ним будут формальные оценки. Таким образом сравнивать кандидатов между собой становится проще, да и определить формальную границу прошел/не прошел тоже.
Фаза 1. Опыт.
Как правило на всех собеседованиях тебя спросят, а какой у тебя опыт. Если в резюме есть что-то интересное для собеседующего и для целей вакансии, то вопросы могут быть достаточно подробные. Далее все зависит от позиции. Если идешь на позиции синьор-помидор+, то важно фокусироваться на процессах, методологиях, результатах. Если позиция пониже - то тут фокус смещается на техническую глубину, понимание своей зоны ответственности и здравого смысла. Особенно важно не говорить лишнего, это быстро вскрывается и сильно понижает очки.
Фаза 2. Интервью
И снова это сословное неравенство. Все-таки от сеньоров ожидается больше, чем “я круто разбираюсь в этом”. Как делаю я - из опыта переходим в базовые знания -> оттуда чуть глубже -> сразу реальный (или смоделированный) кейс с одинаковым вопросом в конце “что делать?”. В целом такую же схему можно взять для менее опытных кандидатов, но процент негативных ответов может быть очень большим.
Для вопросов, где ответ может быть разный (например, схема реагирования на конкретный кейс), я всегда задаю вопрос, а как можно еще, сильный кандидат всегда должен придержать козырь в рукаве. Наигравшись в моделирование сразу становится понятно реальный опыт кандидата, сколько пороху понюхал и видов повидал. Отсюда можно переходить в архитектуру (если еще релевантно😈). Для меня сеньор - это архитектор, человек, который может проектировать рабочие системы. Приведу примеры: для реверса - это процесс анализа ВПО с автоматизациями, для DFIR - прикладной процесс реагирования и обогащение с других направлений, для SOC - как построить процесс третхантинга без мильона фолсов и пропусков и так далее. Если человек не умеет проектировать процесс хотя бы верхнеуровнево - то это middle+, не выше (а может и ниже). Продолжение 👇.
🍓2
Про грейды ниже здесь все немного проще (хотя кому как). Спрашиваем техническую глубину, крайние случаи и исключения, проверяем простые ситуации, как поведет себя кандидат. На позициях jun/middle, на мой взгляд, важно уметь сказать, что я это эскалирую. Многие не любят признавать свое незнание и пытаются предстать лучше, чем они есть на самом деле. Беда в том, что такое может случится, когда в пятницу вечером через GPO будут разливать шифровальщика, а человек пойдет в сиеме искать первопричину, вместо эскалации (утрирую, но мысль понятна). Умейте признавать, что чего-то не знаете - это нормально.
Время от времени буду публиковать свои заметки об интервью. Может показаться, что это все банально и понятно, но так про многие вещи кажется =).
Если у комьюнити будет интерес - расскажу больше про методику оценок, как разбить интервью и как взвешивать его разные блоки.
Время от времени буду публиковать свои заметки об интервью. Может показаться, что это все банально и понятно, но так про многие вещи кажется =).
Если у комьюнити будет интерес - расскажу больше про методику оценок, как разбить интервью и как взвешивать его разные блоки.
👍2🍓2🦄1
Forwarded from Backconnect
Дорогие друзья!
Рады сообщить вам о выходе очередной новостной сводки за февраль
В этот раз мы максимально сжали материал, сохранив качество и нашу фирменную подачу !
Лайки, репосты, комменты обязательны!
(Ставь Гарри Поттера, если хочешь слушать уже подкасты, а не читать буквы)
Рады сообщить вам о выходе очередной новостной сводки за февраль
В этот раз мы максимально сжали материал, сохранив качество и нашу фирменную подачу !
Лайки, репосты, комменты обязательны!
(Ставь Гарри Поттера, если хочешь слушать уже подкасты, а не читать буквы)
Здесь уважаемые люди рассказывают про примерно те же тезисы, которые я описывал здесь, но для другого направления. Тенденция становится все более явной.
Telegram
Синяя шляпа
Интересная история связанная с нашумевшим Claude Code Security. В последние полгода модели взлетели колоссально по уровню работы. У меня есть свои пет проекты, и мне есть с чем сравнить. То что делают модели сегодня, было просто невозможно еще в сентябре…
Forwarded from Пост Лукацкого
Интересная статья о будущем реверс-инжиниринга вредоносного ПО. Ее автор, Томас Рочча (Thomas Roccia), рассказывает о том, как он годами строил "персональный конвейер" для исследования угроз и почему он считает, что классический реверс ВПО быстро перестает быть ремеслом, становясь почти целиком автоматизируемой историей (с оговорками, конечно).
Он начинает с рассказа об одном своем выступлении, где вместо слайдов была... тишина (так пишет автор). Он расшарил экран своего ноута, взял неизвестный образец вредоноса, который он сам еще не анализировал, и отправил его в свою систему и пошел выступать. Пока он продолжал выступление, "команда ИИ-агентов" в фоне автономно делала всю работу: статический анализ, реверс, обогащение через CTI/OSINT, пивоты по артефактам, извлечение IOC, проверку YARA, маппинг на MITRE ATT&CK и сборку отчета с диаграммами. Через ~30 минут он возвратился к демо – и все готово. Он явно подчеркивает контраст: раньше неделя на реверс и неделя на отчет, теперь – десятки минут на все.
Дальше Томас рассказывает свой 15-тилетний путь реверсера и как он пришел к текущей системе на базе ИИ-агентов. Финальный тезис достаточно двусмысленный. С одной стороны он пишет о концу реверса, а с другой отрицает это. Да – потому что основная масса рутины стремительно автоматизируется и становится дешевой. Нет – потому что без глубокого понимания реверса он бы такую систему не построил, и потому что редкие пограничные случаи все еще держатся на человеческой экспертизе. Но он считает, что окно закрывается быстро: ценность специалиста смещается от ручного разбора кода на ассемблере к архитектуре/оркестрации агентских систем, качеству инструментов, мониторингу, безопасности и контролю процесса.
Совет Томаса коллегам прямой: не ждать. Учить MCP/RAG/агентов и начинать строить свои пайплайны сейчас, иначе через год-два рынок догонит, и "чистый реверсер" окажется в роли ремесленника, чью работу выполняет конвейер.
#malware #ии
Он начинает с рассказа об одном своем выступлении, где вместо слайдов была... тишина (так пишет автор). Он расшарил экран своего ноута, взял неизвестный образец вредоноса, который он сам еще не анализировал, и отправил его в свою систему и пошел выступать. Пока он продолжал выступление, "команда ИИ-агентов" в фоне автономно делала всю работу: статический анализ, реверс, обогащение через CTI/OSINT, пивоты по артефактам, извлечение IOC, проверку YARA, маппинг на MITRE ATT&CK и сборку отчета с диаграммами. Через ~30 минут он возвратился к демо – и все готово. Он явно подчеркивает контраст: раньше неделя на реверс и неделя на отчет, теперь – десятки минут на все.
Дальше Томас рассказывает свой 15-тилетний путь реверсера и как он пришел к текущей системе на базе ИИ-агентов. Финальный тезис достаточно двусмысленный. С одной стороны он пишет о концу реверса, а с другой отрицает это. Да – потому что основная масса рутины стремительно автоматизируется и становится дешевой. Нет – потому что без глубокого понимания реверса он бы такую систему не построил, и потому что редкие пограничные случаи все еще держатся на человеческой экспертизе. Но он считает, что окно закрывается быстро: ценность специалиста смещается от ручного разбора кода на ассемблере к архитектуре/оркестрации агентских систем, качеству инструментов, мониторингу, безопасности и контролю процесса.
Совет Томаса коллегам прямой: не ждать. Учить MCP/RAG/агентов и начинать строить свои пайплайны сейчас, иначе через год-два рынок догонит, и "чистый реверсер" окажется в роли ремесленника, чью работу выполняет конвейер.
#malware #ии
👍1
В тему предыдущего поста. Решил попробовать, как поведет себя AI на реальных семплах. Сегодня в программе два подопотных:
1. ReverseShell laplas от Sylent Lynx
2. PartisanDNS от киберпартизан
Что я сделал?
1. Подписка Claude MAX
2. CLI claude code с привязанной подпиской + Opus 4.6.
3. IDA Pro 9.0
4. MCP plugin https://github.com/taida957789/ida-mcp-server-plugin
После всех настроек мы получаем агента, который может общаться с ida pro и проводить там манипуляции по изучению семплов. Здесь очень важное отличие от того же Gepetto, Он именно компаньон в исследовании, но не агент. То есть мы не можем через него автоматизировать процесс анализа, а через наш инструмент можем.
Также важно что подписку claude можно купить без иностранной карты, а вот с openai такое не прокатывает.
Кейс 1.
Скрин 1.
Первый кейс был достаточно тривиальным. Я отдал открытый в ida семпл и Клоду понадобилось 3 минуты (3 минуты, Карл!) для анализа семпла: Иоки, тактики, детекты... Это уже очень круто, но семпл действительно простой, и c2, например, вытаскивается через обычный strings. Поэтому я пошел чуть дальше
Кейс 2.
И вот тут просто крышеснос. Я писал об этом семпле без глубоких деталей здесь. На его анализ я потратил действительно много времени. А до конца его проанализировать смог только с помощью коллеги по цеху (и то, там остались пробелы). И вот я отдаю клоду семпл, за 8 минут он дает очень качественный верхнеуровневый обзор функциональности (семпл полностью обфусцирован, библиотеки вызываются по хешам и все такое) Скрин 2. Но все интересное осталось зашифровано и я просто сказал ему это расшифровать. Далее Claude думал "целых" 30 минут, и за это время он разобрал вообще все. Ключ шифрования, алгоритм, строки, алгоритм DGA, методы инъекции и т.д. Скрин 3. И это без каких либо claude.md, без скиллов, без туллинга, просто обычная статика.
Дальше - больше. Мы можем его попросить все это свести в готовый документ, а отдельным документом попросить оформить алгоритм анализа и расшифрования строк. То есть у нас а) готовый отчет об анализе и б) готовый алгоритм верификации на очень сложном семпле. За 38 минут. Дальше можно было просить писать автоматизации и yara, но уже на этом моменте у меня отвисла челюсть.
Выводы.
Давайте поговорим про стоимость этого всего удовольствия. Скрин 4. 159 тысяч токенов контекста использовано на всю сессию, то есть и вход и выход (речь только про кейс 2). Возьмем расценки API для Opus 4.6 и получаем что-то между 0.8$ и 4$. Но можно даже еще дешевле. В рамках подписки лимиты очень приятные, поэтому можно анализировать достаточно таких семплов, даже на подписке в 20$/месяц, не говоря уже про MAX тарифы. А теперь представьте, сколько стоит аналитик, который будет также щелкать такие образцы.
Если вы все еще не тестили агентские системы в своем окружении - пробуйте, используйте то, что уже слито на virustotal или не имеет какой-то конфиденциальности. Сенситив данные всегда можно вычленить из выборки, если сам ее анализровал.
Лично я в полном восторге от этого.
1. ReverseShell laplas от Sylent Lynx
2. PartisanDNS от киберпартизан
Что я сделал?
1. Подписка Claude MAX
2. CLI claude code с привязанной подпиской + Opus 4.6.
3. IDA Pro 9.0
4. MCP plugin https://github.com/taida957789/ida-mcp-server-plugin
После всех настроек мы получаем агента, который может общаться с ida pro и проводить там манипуляции по изучению семплов. Здесь очень важное отличие от того же Gepetto, Он именно компаньон в исследовании, но не агент. То есть мы не можем через него автоматизировать процесс анализа, а через наш инструмент можем.
Также важно что подписку claude можно купить без иностранной карты, а вот с openai такое не прокатывает.
Кейс 1.
Скрин 1.
Первый кейс был достаточно тривиальным. Я отдал открытый в ida семпл и Клоду понадобилось 3 минуты (3 минуты, Карл!) для анализа семпла: Иоки, тактики, детекты... Это уже очень круто, но семпл действительно простой, и c2, например, вытаскивается через обычный strings. Поэтому я пошел чуть дальше
Кейс 2.
И вот тут просто крышеснос. Я писал об этом семпле без глубоких деталей здесь. На его анализ я потратил действительно много времени. А до конца его проанализировать смог только с помощью коллеги по цеху (и то, там остались пробелы). И вот я отдаю клоду семпл, за 8 минут он дает очень качественный верхнеуровневый обзор функциональности (семпл полностью обфусцирован, библиотеки вызываются по хешам и все такое) Скрин 2. Но все интересное осталось зашифровано и я просто сказал ему это расшифровать. Далее Claude думал "целых" 30 минут, и за это время он разобрал вообще все. Ключ шифрования, алгоритм, строки, алгоритм DGA, методы инъекции и т.д. Скрин 3. И это без каких либо claude.md, без скиллов, без туллинга, просто обычная статика.
Дальше - больше. Мы можем его попросить все это свести в готовый документ, а отдельным документом попросить оформить алгоритм анализа и расшифрования строк. То есть у нас а) готовый отчет об анализе и б) готовый алгоритм верификации на очень сложном семпле. За 38 минут. Дальше можно было просить писать автоматизации и yara, но уже на этом моменте у меня отвисла челюсть.
Выводы.
Давайте поговорим про стоимость этого всего удовольствия. Скрин 4. 159 тысяч токенов контекста использовано на всю сессию, то есть и вход и выход (речь только про кейс 2). Возьмем расценки API для Opus 4.6 и получаем что-то между 0.8$ и 4$. Но можно даже еще дешевле. В рамках подписки лимиты очень приятные, поэтому можно анализировать достаточно таких семплов, даже на подписке в 20$/месяц, не говоря уже про MAX тарифы. А теперь представьте, сколько стоит аналитик, который будет также щелкать такие образцы.
Если вы все еще не тестили агентские системы в своем окружении - пробуйте, используйте то, что уже слито на virustotal или не имеет какой-то конфиденциальности. Сенситив данные всегда можно вычленить из выборки, если сам ее анализровал.
Лично я в полном восторге от этого.
🔥9