-
Похожий контент
-
Автор KL FC Bot
Сейчас практически невозможно представить себе современную компанию, которая не рассказывает о применении искусственного интеллекта. Причем маркетологи далеко не всегда утруждают себя объяснением того, зачем ИИ в продукте нужен, а главное, как именно он там реализован, — им кажется, что самого факта применения достаточно для того, чтобы сделать продукт более ценным, инновационным и высокотехнологичным. Мы сторонники другого подхода — нам важно не просто сказать «у нас есть ИИ», а объяснить, как именно технологии машинного обучения и искусственного интеллекта применяются в наших решениях. Перечислять все наши ИИ-технологии в одном посте было бы слишком долго — у нас есть целый центр экспертизы AI Technology Research, который занимается различными аспектами ИИ. Поэтому в данном материале я сосредоточусь исключительно на технологиях, облегчающих жизнь SIEM-аналитика, работающего с Kaspersky Unified Monitoring and Analysis (KUMA).
SIEM AI Asset Risk Scoring
Традиционно одной из самых ресурсоемких задач аналитика SIEM является приоритизация алертов. Особенно если система только установлена и работает с дефолтными правилами корреляции из коробки, пока еще не подогнанными к реалиям конкретной компании. Помочь с этой проблемой могут технологии анализа больших данных и системы искусственного интеллекта — благодаря модулю SIEM AI Asset Risk Scoring команды мониторинга и реагирования могут определять приоритеты алертов и предотвращать потенциальный ущерб. Этот модуль служит для оценки рисков активов путем анализа исторических данных и тем самым помогает приоритизировать входящие оповещения, что, в свою очередь, ускоряет проведение триажа и позволяет генерировать гипотезы, которые можно использовать для проактивного поиска.
На базе информации об активируемых цепочках правил корреляции SIEM AI Asset Risk Scoring позволяет строить паттерны нормальной активности на конечных точках. Затем, сравнивая с этими паттернами повседневную активность, модуль выявляет аномалии (например, резкие скачки трафика или множественные обращения к сервисам), которые могут говорить о том, что происходит реальный инцидент и аналитику следует глубже изучить именно эти алерты. Это позволяет обнаружить проблему на ранней стадии, до того как будет нанесен ущерб.
View the full article
-
Автор KL FC Bot
В ходе атак на инфраструктуру различных компаний злоумышленники все чаще прибегают к манипуляции с модулями, взаимодействующими с процессом Local Security Authority (LSA). Это позволяет им получать доступ к учетным данным пользователей и закрепиться в системе, повысить свои привилегии или развить атаку на другие системы атакуемой компании. Поэтому при подготовке очередного ежеквартального обновления для нашей SIEM-системы Kaspersky Unified Monitoring and Analysis Platform мы добавили правила, служащие для детектирования таких попыток. По классификации MITRE ATT&CK, новые правила позволяют выявлять техники T1547.002, T1547.005 и T1556.002.
В чем суть техник T1547.002, T1547.005 и T1556.002?
Оба вышеупомянутых варианта техники T1547 подразумевают загрузку процессом LSA вредоносных модулей. Подтехника 002 описывает добавление вредоносных DLL-библиотек с пакетами проверки подлинности Windows (Windows Authentication Packages), а подтехника 005 — библиотек с пакетами поставщиков безопасности (Security Support Providers). Загрузка этих модулей позволяет злоумышленникам получить доступ к памяти процесса LSA, то есть к критическим данным, таким как учетные данные пользователей.
Техника T1556.002 описывает сценарий, когда атакующий регистрирует в системе вредоносные DLL-библиотеки фильтров паролей (Password Filter), которые по сути являются механизмом, принуждающим к исполнению парольных политик. Когда легитимный пользователь меняет пароль или же устанавливает новый, процесс LSA сверяет его со всеми зарегистрированными фильтрами, при этом он вынужден передавать фильтрам пароли в открытом, нешифрованном виде. То есть если злоумышленнику удается внедрить в систему свой вредоносный фильтр паролей, то он сможет собирать пароли при каждом запросе.
Все три техники подразумевают подкладывание вредоносных библиотек в директорию C:Windows\system32, а также их регистрацию в ветке системного реестра SYSTEM\CurrentControlSet\Control\LSA\ с ключами Authentication Packages для T1547.002, Security Packages для T1547.005 и Notification Packages для T1556.002.
View the full article
-
Автор KL FC Bot
В рамках регулярного исследования ландшафта угроз для России и СНГ наши эксперты изучили статистку анализа вредоносного программного обеспечения в Kaspersky Sandbox. Всего по итогам разбора миллионов самых распространенных вредоносных файлов, этой системой было выявлено 218 техник и подтехник с тысячами уникальных процедур. Мы, в свою очередь, тщательно изучили наиболее часто используемые атакующими техники и оперативно доработали или добавили в нашу SIEM-систему KUMA детектирующую логику для их выявления. В частности, в обновлении, вышедшем во втором квартале 2024 года мы дополнили и расширили логику для детектирования техники отключения/модификации локального межсетевого экрана (Impair Defenses: Disable or Modify System Firewall T1562.004 по классификации MITRE), которая входит в топ тактик, техник и процедур (TTPs), используемых злоумышленниками.
Как злоумышленники отключают или модифицируют локальный межсетевой экран
Техника T1562.004 позволяет злоумышленникам обойти средства защиты (defense evasion) и получить возможность соединяться по сети с серверами C2 или дать возможность нетипичному приложению иметь базовый доступ к сети.
Распространены два способа изменения или отключения хостового файервола: с помощью утилиты netsh или с помощью внесения изменений в параметры реестра Windows. Вот примеры популярных командных строк, используемых злоумышленниками для этих целей:
netsh firewall add allowedprogram netsh firewall set opmode mode=disable netsh advfirewall set currentprofile state off netsh advfirewall set allprofiles state off
Пример ветки реестра и значения, добавленного атакующими, разрешающего входящий UDP трафик для приложения C:\Users\<user>\AppData\Local\Temp\server.exe:
HKLM\SYSTEM\ControlSet001\services\SharedAccess\Parameters\FirewallPolicy\FirewallRules Registry_value_name: {20E9A179-7502-465F-99C4-CC85D61E7B23}
Registry_value:’v2.10|Action=Allow|Active=TRUE|Dir=In|Protocol=17|Profile=Public|App=C:\
Users\<user>\AppData\Local\Temp\server.exe|Name=server.exe|’}
Еще один способ, которым пользуются атакующие для отключения Windows FW — остановка сервиса mpssvc. Чаще всего они осуществляют ее с помощью утилиты net:
net stop mpssvc Как наше SIEM-решение выявляет T1562.004
Делается это с помощью добавленного правила R240, в частности за счет детектирования и корреляции следующих событий:
остановки злоумышленником сервиса локального межсетевого экрана для обхода его ограничений; отключения или модификации злоумышленником политики локального межсетевого экрана с целью его обхода (конфигурирование или отключение межсетевого экрана через netsh.exe); изменения злоумышленником правил на локальном межсетевом экране через реестр для обхода его ограничений (изменение правил через реестр Windows); отключения злоумышленником локального межсетевого экрана через реестр; манипуляций злоумышленника с локальным межсетевым экраном через модификации его политик С учетом этого обновления сейчас на платформе доступно более 605 правил, из них 474 правила с непосредственно детектирующей логикой. Также мы доработали 20 старых правил путем исправления или корректировки условий.
View the full article
-
Автор tread lightly
Добрый день
Мы заметили, что в агентах версии 12.6 появилась нативная интеграция с KUMA, позволяющая слать в него логи из журналов винды через агент KES. Сам KUMA нам неинтересен, но мы бы хотели отправлять логи в нашу собственную SIEM по UDP (соответственно, никакие дополнительные параметры, предназначенные для интеграции, кроме ip и порта нам не нужны, а это как раз возможно настроить в политике - что мы и сделали). Так как лицензия под интеграцию с KUMA отсутствует, ничего, очевидно, не работает (но ведь она нам по факту и не нужна - от агента требуется просто пересылать логи во внешнюю SIEM)
Возможно ли снятие этих ограничений, так как приобретение лицензии для такого кейса нецелесообразно? Да, нам ничего не мешает ставить агентов SIEM и собирать логи через них, но в некоторых сценариях хотелось бы реализовать это через единый агент
-
Автор KL FC Bot
Как мы уже писали в данном блоге, работа SIEM-системы теряет смысл без постоянной эволюции детектирующей логики. Ландшафт угроз непрерывно изменяется, а это значит, что для эффективного анализа данных приходится регулярно добавлять новые правила. Разумеется, львиная доля правил корреляции неизбежно дорабатывается на стороне внутренней ИБ-команды, однако для облегчения этого процесса важно иметь актуальные правила, поставляемые из коробки. Еще один важный момент: SIEM-система должна уметь адаптироваться к эволюции информационной инфраструктуры компании; быть готовой к работе с новыми источниками событий, каждому из которых зачастую требуется новый нормализатор (механизм приведения данных от произвольных источников к единому формату). Мы постоянно ведем работу по этим направлениям и добавляем в Kaspersky Unified Monitoring and Analysis Platform (KUMA) новые нормализаторы и правила корреляции. В этом посте рассказываем о том, что было добавлено в версии 3.0.3.
Новые и доработанные нормализаторы
С момента релиза KUMA 2.1 до релиза KUMA 3.0.3 мы выпустили 99 пакетов обновлений с новыми или улучшенными нормализаторами. Среди них 63 обновлений, обеспечивающих поддержку новых источников событий, и 38 — улучшающих текущие нормализаторы. В них была добавлена поддержка дополнительных типов событий, а также реализованы различные доработки и исправления.
Посмотреть статью полностью.
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти