npm debug and chalk packages compromised

Очередной эпичный supply chain через node.js

Разборы доступны здесь:
раз
два

История

а вот совсем недавно рассуждали 😢

#dev #vCISO #MDR

Картинка того, как выглядит в телеметрии MDR эмуляция обсуждаемой вчера эксплуатации

eventtype_str - название события
file_path, filecmdline - потомок
processfilepath, processcmdline - родитель
parentprocessfilepath, parentprocesscmdline - родитель родителя

Главный вектор атаки – выполнение вредоносного кода на этапе preinstall. Здесь стандартный мониторинг EPP/EDR (рабочих станций разработчиков и CI/CD-серверов) позволит обнаружить любой подозрительный по поведению процесс, инициированный из node_modules/.bin или напрямую из пакета NPM. В этом случае задача сводится к стандартной – контроль запусков подозрительных процессов с плохой или неопределенной репутацией.

На картинке запускали powershell.

Сухой остаток: supply chain звучит страшно, но стандартные инструменты мониторинга это прекрасно обнаруживают, ну а то, что мы всегда уязвимы, мы знали и ранее.

#MDR

Машинное обучение в обнаружении

Есть масса применений машобуча в ИБ и нередко на маркетинговых мероприятиях можно услышать об успехах применения машинного обучения без учителя для обнаружения: есть некоторый движок, выполняющий профилирование, который затем выдает статистические отклонения. Проблема тут в том, что "статистическое отклонение" - это не всегда "инцидент", и окончательное решение принимает человек. Понятие инцидента - не простое, поэтому построить классификатор, который будет выдавать не статистическое отклонение, а инцидент невозможно без анализа обратной связи от пользователя (варианты решения этой задачи с помощью LLM пока не будем рассматривать, но и там проблем немало, ибо закономерность сохраняется: чем сложнее система, тем сложнее ей пользоваться). А это уже вопрос, решаемый в рамках машинного обучения с учителем, однако, в этом случае, для получения удовлетворительных результатов, нам нужны размеченные данные, типа, вот это статистическое отклонение - инцидент, а вот это статистическое отклонение - не инцидент. Кроме того, на практике нередки и false negative (пропуски), т.е. Модель надо подкрутить так, чтобы в сценариях прошлых промахов она, таки, выдавала статистическое отклонение, которое будет интерпретировано пользователем как инцидент. Чем размеченных данных будет больше, тем лучше, а если данных будем мало, построение такого классификатора под большим вопросом.

Таким образом, налицо двухходовочка:
- Unsupervised ML поможет найти статистическое отклонение - здесь будет много False positives, но практика показывает, что будут и False negative (собственно, этот объем False* и является основным аргументов скептиков относительно пригодности ML в ИБ вообще, сравнивающих ML-вердикты с выдачей ГПСЧ)
- Supervised ML теоретически можно обучить распознавать среди статистических отклонений инциденты, но в этом случае нужны большие размеченные данные, как например, в случае Автоаналитика

В нашем случае упомянутая двухходовочка для обнаружения горизонтальных перемещений в сети реализована одной Моделью без учителя. Но для поддержания удовлетворительного качества работы, все ее False* разбираются с участием аналитиков команды SOC, после чего Модель дорабатывается: начинает ловить прошлые пропуски и не генерить статистическое отклонение в определенных сценариях, не являющихся инцидентом.

Итого, нам всем нужно понимать:
1. Статистическое отклонение, выдаваемое Моделью без учителя - это еще не Инцидент
2. Для того, чтобы Модель научилась выдавать не статистические отклонения, а инциденты, обязательна обратная связь от пользователя, разметка данных пользователями
3. Чтобы обучить Модель на размеченных данных, их должно быть много
4. Нужно заниматься постоянным тюнингом Модели без учителя, выдающей статистические отклонения, чтобы она выдавала бизнес-значимые статистические отклонения, т.е. инциденты
5. В "коробочных" on prem решениях есть проблемы с получением обратной связи от пользователя и ее анализом, чтобы подстраивать и переобучать Модель, т.е. пп. 2-4 нереализуемы

В итоге получаем, что более-менее рабочим сценарием является портирование обученных моделей из облачных сервисов в on prem решения. Как, в частности, мы и сделаем с моделью обнаружения горизонтальных перемещений, которая из MDR когда-то станет доступна в KUMA. В этом случае постоянство качества Модели будет обеспечиваться ее постоянным тюнингом в рамках сервиса в предположении, что в пользовательской инфраструктуре демонстрируемые ею статистические отклонения будут интерпретировать как инциденты по тем же правилам, что и в MDR. Это очередная прекрасная демонстрация как правильно выкристаллизовывать облака в on prem, а никак не наоборот!

#MDR #vCISO #ml

Расписание против аналитика: когда график диктует ошибки

На PHD в 2023 году я немного коснулся темы метрик, используемых в нашем SOC. За годы работы мы накопили массу статистик и значений метрик, которые также можно анализировать и обнаруживать интересные и полезные зависимости, помимо стандартной задачи - предсказания загрузки команды в зависимости от объема. Отрадно, что молодому поколению аналитиков тема анализа тенденций в работе операционного подразделения также интересна как и мне, и мы имеем в некотором смысле продолжение моего достаточно общего доклада про метрики, но на сей раз от моего коллеги - Даниила Малий. Даниил взял не все собираемые нами показатели, а только те, что используются в KPI для оценки эффективности и результативности работы ребят, с фокусом именно на ошибки и попытался найти зависимости количества ошибок от режима работы аналитика при сменном графике и времени суток, от уже обработанного объема (от продолжительности работы в смене), от скорости расследования алертов и их критичности, и многого другого.

Формальное описание доклада:

Название: Расписание против аналитика: когда график диктует ошибки
Краткое описание: График работы напрямую влияет на то, как SOC-аналитики принимают решения. Ошибки распределяются неравномерно: они зависят от времени суток, сменности и даже от последовательности задач. Исследуя долгосрочные выгрузки, можно выявить чёткие закономерности и использовать их для оптимизации процессов.

Доклад был подан на SOC Forum (логично, ибо доклад про SOC, от аналитика SOC) , попал в секцию "ИБ и бизнес", но не прошел отбор. С одной стороны, немного жаль, что крутой (на мой субъективный взгляд) доклад не войдет в программу, а, с другой стороны, это должно означать, что в программу вошли еще более крутые докалды доклады! Ну, как минимум, в эту секцию. Поэтому, для себя я уже решил однозначно выделить время и посмотреть, надеюсь, запись будет.

Я тоже член Экспертного комитета, правда, в секциях "SOC-практикум", "Defence" и "Тренды и аналитика угроз", и мой выбор, моя оценка докладов - это отражение меня. Фактически, то, что попадет в программу характеризует экспертность Экспертного комитета, конечно же, с субъективной точки зрения зрителя.

Ах да, забыл, доклад Даниила Малий мы подали в итоге на Zero Nights, посмотрим, получится ли попасть в программу там. Если никуда не пройдет, запишем вебинар и поделимся им в этом канале :) Так сказать, сами себе оркестр 🤣

#MDR #vCISO

ENISA THREAT LANDSCAPE 2025

Агентство Европейского союза по кибербезопасности (ENISA) опубликовало отчет "Обзор угроз ENISA 2025". В отчете анализируется почти 4900 киберинцидентов, коснувшихся европейских организаций в период с июля 2024 года по июнь 2025 года.

Основные тенденции:
1. Фишинг — главный вектор атаки (60%): Остается основным методом первоначального проникновения. Эволюционирует за счет таких техник, как ClickFix, фишинг-as-a-service (PhaaS, например, Darcula), и квишинг (QR-код фишинг).
2. Цепочки поставок и доверительные отношения. Злоумышленники все чаще атакуют сторонних поставщиков услуг (IT-компании, Телекомы) и цепочки поставок (вредоносные пакеты npm, расширения браузеров) для усиления эффекта атак.
3. Атаки на мобильные устройства: угрозы для Android-устройств растут, включая шпионские программы (KoSpy, BoneSpy), банковские трояны (Medusa) и эксплуатацию уязвимостей в телекоммуникационной инфраструктуре (SS7, Diameter).
4. Конвергенция групп угроз: Стираются границы между хактивизмом, киберпреступностью и спонсируемыми государствами группировками.
5. Ожидаемое использование ИИ: ИИ активно используется для создания более убедительных фишинговых писем (более 80% фишинга используют ИИ), генерации качественных подделок (deepfakes), разработки вредоносного ПО и обхода обнаружения. Также наблюдаются атаки на сам ИИ - джейлбрейки, отравление модели и атаки на цепочку поставок моделей ИИ.

Чаще всего ломают:
- Государственное управление - 38,2%
- Транспорт - 7,5%
- Цифровая инфраструктура и услуги - 4,8%
- Финансы - 4,5%
- Производство - 2,9%

Основные типы угроз:
1. Киберпреступность - 13,4% инцидентов
2. Государственные группы - 7,2%
3. Хактивизм - 79%
4. Манипулирование информацией (Foreign information manipulation and interference, FIMI) - остальное


Оригинальная ссылка на документ

Суммаризацию можно также почитать здесь:
State-aligned cyber threats against EU intensify, ENISA warns

Many Attacks Aimed at EU Targeted OT, Says Cybersecurity Agency

#MDR #vCISO

В продолжении темы DLL-Hijacking, спешу поделиться статьей по теме, для тех, кто не хочет смотреть видео (или здесь)

Также интересный материал от коллег, но уже более прикладной.

#ml #MDR

Forrester об MDR
(вложение, reprint)

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

Forrester пишет, что MDR - это еще не прошлое и что он продолжает эволюционировать, и если раньше провайдеры больше фокусировались (и мерились этим) на реагировании, то сегодня мы должны быть максимально проактивными и нести доказательную бизнес-пользу для корпоративной безопасности:

An MDR provider’s ability to positively influence the security of its customers now matters as much as its ability to find threats

Вот на что стоит обращать внимание при выборе MDR-услуг в 2025 году:

1. Detection as Code — основа масштабирования
Скорость и качество обнаружения угроз теперь определяются подходом "обнаружение как код" (Detection as Code), что означает:
- Использование программных методов для создания и развёртывания детекторов
- Автоматизированное тестирование для повышения точности и снижения "шума"
- Возможность быстро адаптироваться к новым тактикам злоумышленников
Примеры: Red Canary, CrowdStrike.

2. Улучшение корпоративной безопасности (Security Posture) - новая задача MDR
Клиенты ожидают, что MDR-провайдеры будут не только искать угрозы, но и помогать улучшать корпоративную ИБ:
- Обнаружение проблемных мест в ИБ
- Максимальная контекстная адаптация под технологический стек, индустрию, регион заказчика и предоставление бенчмаркинг для возможности сравнения (а, может, и самосравнения)
- Предоставление рекомендаций по улучшению программ корпоративной ИБ
Примеры: eSentire, Arctic Wolf.

3. Генеративный ИИ: выгода не только для провайдера, но и для заказчика
Провайдеры активно внедряют GenAI для повышения эффективности своей работы, но важно понимать: транслирует ли провайдер выгоду от ИИ клиентам, например, в виде улучшенных процессов или снижения стоимости, или просто MDR становится более маржинальным. Если честно, мне удивительно видеть намеки от глобального агенства, что автоматизация (ИИ - это именно автоматизация!) должна снижать стоимость😂
Пример: ReliaQuest (использует ИИ-агенты).

4. Широта покрытия (Detection Surface)
Современный провайдер должен обнаруживать угрозы не только на эндпоинтах, но и: в облачных средах, контролировать идентификационные данные (Identity), собирать данные из множества источников, ну, видимо, как минимум, из сети (упоминается XDR)
Пример: CrowdStrike, Expel.

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

6. Экосистемность и гибкость. Здесь имеется в виду возможность интеграции MDR с используемом у заказчика стеком технологий.

7. Гибкость ценообразования и комплектации услуг (например, Falcon Flex от CrowdStrike).

Лидеры (Leaders): Expel, CrowdStrike, Red Canary.
Сильные игроки (Strong performers): ReliaQuest, Binary Defense, eSentire.
Претенденты (Contenders): Arctic Wolf, Secureworks, SentinelOne, Rapid7.

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

#MDR #vCISO

Как эффективно управлять инцидентами ИБ?

21.10.2025 в 11:00 MSK
Зарегистрироваться!

Безопасность - это процесс, операционный процесс обеспечения уровня ИБ. Можно много говорить о необходимости проактивных подходов к управлению ИБ, и даже стремиться интегрировать проактивность в операционные сервисы, управлять поверхностью атаки и вообще заниматься анализом рисков, однако, в Darkest hour рядом должны оказаться профессионалы, которые спасут ситуацию. Управление инцидентами - базовый процесс операционной безопасности и в предстоящем стриме 21.10.2025 в 11:00 MSK о нем будут рассуждать самые что ни на есть истинные практики, мои замечательные коллеги, чьим знакомством я горжусь, - Вадим Нерсесов и Сергей Голованов.

Вадим - руководитель операционной команды анатиков, отвечающей за delivery MDR, чья команда каждый день обнаруживает инциденты по всему миру. Благодаря усилиям команды Вадима инциденты не доходят до этапа ущерба корпоративным бизнес-процессам (поэтому статистика инцидентов MDR сильно отличается от статистик инцидентов, построенных, например, на данных проектов по реагировнию на инциденты, DFIR, - но об этом поговорим в другой раз), поэтому предприятия заказчиков продолжают работать в штатном режиме.

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

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

Подключайтесь на стрим, будет интересно!

#vCISO #MDR

Обнаружение техник ESC9–15 ADCS

Мои коллеги и друзья, Андрей и Дима, из нашей команды SOC Research поделились хантами, используемыми в MDR, для обнаружения атак на Удостоверяющий центр, интегрированный в MS AD.

Слайды во вложении
Все материалы на Git
Видеозапись доклада
Заметка в канале Purple shift

#MDR

Gartner об MDR: AI - это замечательно, но люди - основа!

Гартнер опубликовал свое руководство по рынку MDR (репринт во вложении, ссылка на него). Ранее мы уже обсуждали мнение Forrester, пришло время посмотреть что же пишет Gartner.

Обязательный состав сервисных компонент:
- Удаленно предоставляемый технологический стек (но есть случаи использования уже развернутых решений) для обнаружения и реагирования на угрозы в реальном времени.
- Круглосуточная работа аналитиков, взаимодействие с заказчиком.
- Возможность немедленного удаленного реагирования и сдерживания угроз (например, изоляция хостов), а не просто оповещения.
- Мониторинг поверхности атаки (совсем недавно касались, и, в целом, все что приобретает свойство "Continuous" может, и, полагаю, должно предоставляться в рамках MDR)
- Проактивный Threat hunting.
- Поддержка облачных инфраструктур, как минимум, популярных Amazon, Google, я нас актуально - Yandex (тем боле, что ребят полно сервисов для автоматизации)

Популярные дополнения:
- Мониторинг Identity.
- Поддержка IoT и технологических сетей (OT).
- Услуги цифровой криминалистики и реагирования на инциденты (DFIR).
- Анализ защищенности, как минимум, на уровне BAS😂, но можно и шире.

Тенденции на рынке:
- Смещение фокуса на проактивность: покупатели хотят не только реагировать на угрозы, но и проактивно выявлять и устранять уязвимости (Threat Exposure Management).
- Рост популярности: расходы на MDR растут быстрее, чем на другие управляемые сервисы безопасности.
- Расширение покрытия: ключевыми областями становятся облачные сервисы (IaaS, SaaS), Identity и мониторинг приложений.
- Влияние ИИ: ИИ и автоматизация повышают эффективность MDR, но не заменяют человеческий анализ, "Автономный SOC" - это миф.
- заказчики хотят большей адаптации, чтобы MDR был не просто инструментом (~ системой обнаружения), а приносил обосновываемую ценность в контексте копании (кстати, простой способ принести ценность - подхватить на мониторинг on-prem развернутые решения).
- обязательные широкие возможности по интеграции в корпоративные процессы обеспечения ИБ, тем более, что MDR не заменяет внутренние процессы безопасности компании, и заказчикам надо:
-- Иметь собственные отработанные процессы реагирования на инциденты,
-- Интегрировать MDR с внутренними системами управления обращениями и инцидентами,
-- Наладить взаимодействие между внутренними командами и провайдером MDR,
(замечу, что это повторяет мой старый тезис, что любой SOC - гибридный)
- MDR подходит для всех:
-- у кого нет SOC - MDR хороший старт, а также может быть временным решением, пока строится свой SOC,
-- у кого есть - усиление внутренней команды (оптимальный сценарий).

#MDR #vCISO

Gartner: Automated Exposure Management и Zero Trust должны быть частью предложения MDR

Гартнер выпустил документ "Emerging Tech: Future-Proof MDR With Automated Exposure Management and Zero Trust" (вложение), согласно которому автоматический контроль поверхности атаки и подходы нулевого доверия должны стать частью MDR в ближайшее время.

Что касается контроля поверхности атаки, то об этом не раз писали и Forrester и Gartner , и вопросов здесь не возникает, то про ZT и контроль Identity стоит поговорить поподробнее.

Чтобы не испытывать ограничения формата заметки в Telegram, подготовил статью.

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

#vCISO #MDR #dev

How to build AI agents into your SOC

Одним из положительных моментов путешествий является избыток свободного времени в аэропорту. На этот раз, по пути домой в столицу, мне наконец-то удалось закончить ознакомление с замечательным гайдом от Red Canary по созданию надежных и эффективных AI-агентов для интеграции в операционную работу SOC. Тема мне небезразлична, поэтому поделюсь мыслями из доки. Сразу замечу, что если вы уже имеете хоть какой-то практический опыт написания агентов, хотя бы на уровне упомянутого здесь курса, то дока покажется вам скучной, но для начинающих джедаев материал может стать неплохой базой, упорядочивающей понимание и перечисляющей очевидные грабли, которые можно обойти.

Мы все немного скептически относимся к формализации процессов, и я сам нередко пропагандирую fuckup-driven management, однако, в случае передачи чего-либо программному болвану AI-агенту, никакая формализация не может быть лишней. Основной тезис документа: надежность важнее новизны, поэтому ключ к успеху лежит не в использовании самой передовой модели, а в построении детерминированных рабочих процессов, строгих ограничений и постоянном измерении результатов. Документ содержит не только теоретические основы, но и практические примеры на Git, а кто любит за трапезой посмотреть что-то полезное есть видео на Youtube Elevate and empower your SOC with AI.

Ключевые принципы построения надежных AI-агентов
1. Структура и Детерминизм. Большие языковые модели по своей природе вероятностны и могут давать разные результаты при одних и тех же входных данных. Для SOC это недопустимо, так как критически важна повторяемость, поэтому Канарейки рекомендуют использовать детерминированную оркестрацию в сочетании с ограниченным рассуждением агентов: задачи разбиваются на явные, небольшие шаги, а агенты используются только там, где их вероятностная природа может приносить пользу (например, для анализа и корреляции), а не для принятия ключевых решений.

2. Дизайн системы, а не одной модели. Ценность извлекается из взаимодействия дизайна workflow, защитных механизмов и выбора моделей, т.е. вместо одного "универсального" агента следует строить сложные системы из простых, узкоспециализированных компонентов. Четкое выделение простых детерменированных шагов для агента прекрасно бьется и с мнением моих друзей, съевших не одну собаку на автоматизации SOC с помощью AI-агентов.

Документ разбирает кейс автоматизации анализа данных OSQuery с конечных точек. В частности, Аналитик может тратить 30+ минут на полуручной разбор десятков JSON-файлов, тогда как AI-агенты могут сократить это время до 2 мин. Для этого создаются несколько узкоспециализированных агентов, каждый из которых отвечает за свою категорию данных OSQuery, например, агент программного обеспечения, агент файловой системы, агент пользователей и групп, агент WMI-событий, и т.п. Для оркестрации используются специализированные агенты, запускаемые параллельно, а их результаты затем агрегируются в единый отчет. Для управления таким workflow используются фреймворки вроде LangGraph.

В документе также освещаются вопросы выбора и оптимизации моделей и безопасности. Интересно почитать о том, как Канарейки пишут об использовании агентов у себя, конечно, по возможности, счищая весь налет маркетинга. В целом, ребята не испытывают беспокойства, используя доступные из облака LLM, поэтому клиентам Red Canary, возможно, имеет смысл обратить внимание на то, что их данные доступны помимо MSSP (Канарейки) и IaaS (Microsoft), но и провайдерам LLM (OpenAI, Google), в общем, поверхность атаки расширяется.

#ml #MDR