В прошедшую субботу был частью арт-ужина, на сей раз обсуждали искусство Возрождения.

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

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

#искусство

Мой коллега и друг Сарим, из нашей команды SOC Consulting, 23 декабря с 17 до 18 по Москве будет рассказывать методологические основы построения функции Detection Engineering-а на основе нашей практики проектов консалтинга по построению SOC.

Live webcast: From chaos to control: streamlining detection engineering in Security Operation Centers

Увидимся на мероприятии!

(язык вебинара - английский)

#MDR #vCISO #kaspersky

Ребята из A1 поделились видео о прошедшем мероприятии.

Всего две минуты прекрасно передают атмосферу A1 Tech Day. По-моему, на видео можно заметить всех докладчиков, в том числе и вашего покорного слугу.

В общем, предлагаю иметь в виду эту площадку для общения за пределами РФ, а если представится возможность - увидимся в Минске!

#vCISO

Непригодность нейросетей для решения задач нередко объясняется нашим "неумением их готовить". Поясню. У нас есть экспериментальный Волшебник Мерлин, который подсказывает аналитикам на что обратить внимание при расследовании алертов. О нем я упоминал в презентации на слайде 15. В качестве Подсказчика Мерлина используется обычная, не расширенная никакими RAG-ами и фью-шотами, развернутая в корпоративной инфраструктуре, LLM, в нашем случае - LLaMA. В ходе экспериментов было замечено, что если в Мерлина подать необработанный JSON алерта, то результат будет неудовлетворительным, однако, если JSON алерта переписать текстом, то результат будет вполне приемлемым. В нашем случае алерт - это совокупность событий, а каждому событию несложно поставить в соответствие его словесное описание (для этого не требуется никакой машобуч, там биективное соответствие)

Я уже писал о том, что конволюционные (по-русски, можно встретить термин "сверточные") нейросети (CNN), придуманные изначально для компьютерного зрения, стали пытаться применять для анализа связей в графах наряду с графовыми нейросетями (GNN).

Но вот эта публикация мне предсталяется более перспективной (абстракт, pdf). Здесь ребята извлекают фичи из образцов и преобразуют их в вид QR- и Aztec-кодов. Далее, полученные представления образца в виде QR/Aztec подают на вход CNN, классифицирующей малвару.

В целом, QR, как будто, хорошее представление входных данных для CNN, но под вопросом емкость такого представления, да и ограниченность на статистическом анализе малвары тоже не способствует универсальности метода. Но попытка засчитана!

Что ожидаю:
- повышение емкости входных данных для анализа. Если мы говорим о CNN, спроектированных для анализа изображений, то, может, кто-нибудь предложит трансформировать входные данные для анализа в изображение или видео.
- покрытие динамики. Динамика, на мой взгляд, более перспективна чем статика. Он закроет использование обфусцированной и полиморфной малвары, но, что еще более актуально, - сценарии Living-off-the-Land и поведенческое детектирование. Будем следить.

А еще, чем больше я изучаю различных прикладные применения нейросетей, невольно вспоминаю "Зенитные кодексы Аль-Эфесби" ... Нужно понимать, что новые функциональные возможности открывают новые сценарии атак.

#MDR #ml

В СССР были замечательные хард-рок команды, о которых, к сожалению, почти никто и не помнит. Одной из таких групп является - Стелла. Группа была создана в 1988 году из проекта "Иск" – дуэта, в который входили вокалист Александр Кирсанов и басист Владимир Ширяев. Директором и художественным руководителем коллектива стал Валерий Иванов.

В 1989 году, уже 35 лет назад, у ребят вышел второй, и самый успешный их альбом, "Лихорадка". Однако, после этого альбома как-то раширить свою популярность группе не удалось, не помогли даже поздние эксперементы с попсой.

Группа попыталась возродиться в 2010 году усилиями автора всех песен и вокалиста Александра Кирсанова и продюсера Валерия Иванова, но широкой известности снова не приобрела.

20 июля 2021 года Валерий Иванов скончался от последствий COVID-19, 15 октября 2023 года умер Александр Кирсанов, а вместе с ними и окончательно ушла в историю группа Стелла.

"Мост нашей встречи" - вещь с альбома "Лихорадка", наверно, самая известная, на нее даже есть клип. Клип невольно вызывает улыбку, так как вспоминаются и Bon Jovi (и по части картинки, и по части звучания), и Helloween, и Skid Row, и много кто еще. Я эту песню услышал на сборнике русского рока, когда учился в институте и, как это водится с понравившимися вещами, разучил и иногда пою до сих пор.

Предлагаемая запись, как и все остальные, записанные дома на мобильный телефон, очевидно, не идеальна, однако, здесь, кроме всего прочего, есть ощущение, что я и не совсем правильно ее подобрал, тогда, будучи студентом, в 1997-м. Будем считать, что это мое индивидуальное исполнение.

#музыка

Наиболее часто используемые уязвимости в 2023 были зеродеями

Такое заключение сделала американская CISA. В целом это ожидаемо, с учетом объема автоматизации (поверхности атаки), что даже сама NVD уже не успевает все учитывать. В целом, это еще один маленький гвоздик в гроб стремления запатчить все подряд, ибо результативность патчевания продолжает стремительно падать.

В качестве рекомендаций CISA выдает:
1. SDLC. Согласен, код надо писать лучше (слабо понимаю, как это относится к стандартному интерпрайзу, который едва ли пишет сам себе софт), однако, никто не отменял ошибки конфигурации, что в условиях широкой функциональности (следовательно, сложной конфигурации) становится все более актуально. Поэтому я бы добавил Управление конфигурациями во всех его проявлениях: создание стандартных профилей, постоянный аудит их безопасности и контроль, что эти профили используются в инфраструктуре.

2. Стимуляция ответственного раскрытия информации об уязвимостях. Тоже так себе рекомендация для CISO, ну допустим. Немало пролетало исследований про автоматизацию пентеста и поиск уязвимостей с использованием нейросетей, поэтому здесь напрашивается 100% эффективная рекомендация😁: надо чтобы все новомодные штуки освоили разработчики ПО и находили свои уязвимости быстрее, чем это делают злоумышленники. Остается только один момент - невозможность отличия уязвимости от закладки.

3. Использование EDR. Здесь тоже соглашусь, но добавлю, может, MDR, так как чем сложнее инструмент, тем большая квалификация требуется от пользователя.

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

#MDR #vCISO

Windows User Account Forensics

В каком-то из каналов пролетал неплохой документ. Сохраню его здесь. Материал больше напоминает шпаргалку аналитика SOC и содержит базовые вещи, которые надо помнить при анализе событий Windows.

#MDR

BPL injection

Кто слышал о языке программирования Borland Pascal, наверняка слышал и о его объектно-ориентированном варианте Borland Delphi (ваш покорный слуга имел счастье на них еще и писать, где-то в конце 90-х, и скажу, что Borland Delphi - огонь!). У программ на Delphi есть свои динамически подгружаемые запчасти, реализованные в виде BPL-файлов (BPL - Borland Package Library). Файлы BPL, в целом, мало отлчаются от DLL, и даже file выдаст, что это DLL:

 % file vcl120.bpl  
vcl120.bpl: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
 %  

Ну разве что только strings выдаст особенности:

% strings vcl120.bpl| grep -i Delphi | wc 
      88      88    8117
 %

Однако, среди приложений на Delphi есть те, которые подгружают такие BPL-файлы. И для таких приложений можно эксплуатировать BPL injection. Идея ровно такая же, как и в случае с DLL: вредоносный BPL зкгружается легитимным исполняемым файлом.

Одним из таких легитимных бинарей является 8aed681ad8d660257c10d2f0e85ae673184055a341901643f27afc38e5ef8473 (A2D70FBAB5181A509369D96B682FC641). Его реальное имя rtthlp.exe, описание: IObit RttHlp, однако мы в инцидентах его встречали под разными именами: set-up.exe, setup.exe, install.exe и пр. В этих же инцидентах мы фиксировали и использованием BPL injection, и в одном из первых расследований вышли на статью от Kroll, где описывается BPL-инжект ровно в наблюдаемый нами бинарь A2D70FBAB5181A509369D96B682FC641. Инжектилось вот это - 3cbd60759ca91f846fe69e067cbef15f481e3a0be31b756ee434b54df668b7d2 (92650FCDC20ED3CBEBB6378B45C2E67D), имя - vcl120.bpl, вердикт KES - Trojan.Win32.Loader.npf. Окончательное назначение инструмента, где одним из компонентов был вредоносный BPL, - инфостилер, то была не человекоуправляемая атака (в MDR был инцидент критичности Medium), наблюдали не в РФ.

Несмотря на то, что Borland это, как будто, из прошлого, BPL injection - это из настоящего и будущего. Соответствующей подтехники Hijack Execution Flow еще нет, но Kroll пишут, что подали заявку.

В заключение хочу поблагодарить нашего аналитика D*, который в рамках нашего процесса Periodic Retro Hunting в свое время нашел такой инцидент, по мотивам которого позже наделали хантов.

#MDR

На SOC Forum 2022 я рассказывал о том, как кейсы от SOC передаются в DFIR и что это достаточно частый сценарий. Как правило причины две:
- реагирование MDR ограничено техническими возможностями MDR, и их не всегда достаточно => нужны какие-то альтернативные сценарии реагирования
- огромная проблема MDR - это покрытие, как человек не видит там, где нет глаз, так и MDR не видит событий с хостов, не покрытых сенсорами (в нашем случае - единый агент EPP-EDR) => со слепых зон данные приходится собирать альтернативными MDR способами

На самом деле эти две проблемы причинно-следственно связаны. Для организации эффективного реагирования необходимо располагать информацией о действиях атакующего, а информация нами получается из телеметрии. Если хост не в мониторинге, то с него нет телеметрии, а, следовательно, что на нем происходит расследовать невозможно. В условиях, когда наблюдаемая активность - однозначно человекоуправляемая атака, и не все участвующие в инциденте хосты покрыты мониторингом, надо рекомендовать подключение команды DFIR, так как неполное расследование приведет к неправильным мерам по реагированию и последствия будут куда хуже, даже в сравнении с полным бездействием (и такие случаи встречались в практике). В нашем случае, если заказчик согласен, инцидент эскалируется в Глобальную команду реагирования (GERT). Кстати, последние посиделки на AM Live с участием Константина Сапронова, руководителя GERT, доступны для просмотра.

Об одном из таких расследований по эскалации из MDR мои коллеги и друзья из команды GERT подготовили материал, с которым полезно ознакомиться, в статье приведены TTP и IoC-и

#MDR #kaspersky

Как правильно: "SIEM" или "SOC"?

Некоторое время назад ЛК и К2К делали исследование о SOC-ах к подготовке которого немного приложился и ваш покорный слуга. Вот ссылка на пресс-релиз, а отчет будет доступен попозже.

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

Причин, почему не имеющие SIEM не планируют его внедрять, достаточно много, но я бы выделил две, как наиболее часто встречающиеся, по моему мнению.
- SIEM, как правило, является выдленной системой ИБ, тогда как собриать и обрабатывать журналы регистрации ИС – общая задача ИБ и ИТ. В компаниях со зрелыми подразделениями ИТ вопрос сбора журналов всех ИС, в том числе и с выделенных решений ИБ, таких как межсетевые экраны, системы защиты конечных точек (EPP-EDR) или сетевые системы обнаружения сетевых вторжений или NDR, традиционно решен. Поэтому, для подразделений ИБ значительно эффективнее переиспользовать LM-системы ИТ (LM – Log management), тем более, что современная LM-система позволяет покрыть все основные сценарии ИБ, а вместе с тем обеспечивает нилучшее покрытие, не ограничиваясь только системами ИБ и не стремясь остаться в рамках лицензионных ограничений EPS.
- В компаниях со зрелыми инженерными командами предпочитают свободно распростаняемые решения, что дает практически безграничную гибкость, а следовательно, безграничные возможности по адаптации. Выбор opensource еще более очевиден для компаний с большими возможностями по разработке собственного ПО.

Первый пункт принципиально важен. Что бы мы не говорили, но ИБ в компании обеспечивают подразделения ИТ! Именно ИТ разрабатывают, внедряют и обслуживают информационные системы с соблюдением требований безопасности, за ИБ остаются функции законодателя и контролера. Именно поэтому безопасность не может быть обеспечена там, где у ИБ и ИТ плохие отношения или ИТ - ленивые разгильдяи имеют низкий уровень зрелости. Уровень ИБ напрямую зависит от зрелости ИТ. Как правило, у зрелых ИТ вопрос управления журналами систем и приложений давно решен и, с точки зрения эффективности инвестиций, безопаснику логичнее подключиться к уже внедренным у ИТ системам LM, а не строить сбоку дорогостоящую городушку с кучей ограничений в виде SIEM. Собственно, когда где-то в 2006-2009 занимался созданием своего первого SOC, я ровно так и сделал. Правда, следует заметить, что позднее у меня появился и SIEM, но именно для корреляции на неполном объеме событий из-за ограничений по железу и EPS.
Если же в корпорации вопрос сбора логов не решен, то лучше это сразу решать совместо с ИТ: строить общий Data Lake, откуда ИТ будут брать данные для своего траблшутинга, а мы - для нашего обнаружения атак (какую-то их часть отправлять в SIEM для генерации алертов в SOC).

Итак, друзья мои, ответ на вопрос: "Можно ли построить SOC без SIEM?" - положительный, но с плотным вовлечением ИТ (повторюсь, что без плотного вовлечения ИТ безопасность обеспечить невозможно, именно ИТ делают безопасность!)

#vCISO #MDR #пятница

С другой стороны, если подумать, есть три книжки и как раз три участника. Так что встречайте победителей «Апофеоза кибервойны 2»:

— Кибертерроризм (Сергей Солдатов);
— Интервью с участником Народной CyberАрмии (Мария Коледа);
— Правительство обязало Минцифры разработать проекты постановлений о двух новых ГИС в рамках ЕАЭС (Валерий Коржов).

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

Однако, есть возможность различными методами, от примитивных - на основании портов, до более продвинутых статистических методов, попытаться классифицировать передаваемый трафик. Немного ознакомившись с методами становится очевидно, почему IPSec в туннельном режиме безопаснее, чем IPSec в транспортном режиме (когда заголовки не шифруются).

С широким распространением машобуча на смену архаичным статистическим методам пришли новые, в том числе и с использованием нейросетей - LSTM и CNN. Вот одна из таких работ: pdf, абстракт, код (на момент написания заметки код не опубликован, но обещают). Статья дает небольшое погружение в историю вопроса, содержит интересные ссылки на релевантные работы, а также приводит результаты описываемого метода классификации на различных датасетах в сравнении с ранее известными - вынужден заметить, что результаты впечатляющие (привел на картинке).

#crypto #ml

Время от времени мы проводим неформальные, но очень насыщенные встречи для тех, чьи интересы так или иначе затрагивают оффенсив (пентестеры, аппсекеры, аналитики). Эти митапы обычно состоят из трех-четырех докладов, после чего большинство участников перетекают в afterparty и живое общение.

О том, как попасть на очередное такое мероприятие, расскажем уже в следующем году. А пока – пример одного из докладов с последнего митапа: наш коллега Георгий Кигурадзе рассказал, как сдампить Lsass, оставаясь под радарами стандартных хантов. Было много запросов пошарить слайды этого доклада, и вот они – в приложенном файле.

TL;DR: Извлечение секретов из lsass – один из логичных шагов на этапе постэксплуатации в Windows-инфраструктурах. Однако большинство готовых решений гарантировано детектируется стандартными средствами. Наше решение: разработать свою реализацию дампа, на основе примитивов доверенного инструмента.

Основная идея в том, чтобы использовать прямое чтение физической памяти через подписанный Microsoft драйвер, который используется расследователями для снятия дампа оперативной памяти. Сканируя память, мы находим ядерную структуру EPROCESS для процесса lsass.exe. После парсинга этой структуры проходимся по всем VAD-ам, принадлежащим процессу, и ищем lsasrv.dll. Именно в этой библиотеке находятся необходимые нам ключи шифрования и контексты пользователей. Прочитав физическую память по нужным адресам, можно расшифровать контексты пользователей и получить их NTLM-хэши.

Всё это мы реализовали как BOF для Mythic C2 (про создание собственного Mythic-агента расскажем чуть позже).

Ну и полезный совет для стороны защиты: подобные атаки можно обнаружить по регистрации подозрительного драйвера для форензики (смотрите IoC на последнем слайде).

Я не люблю делать прогнозы, но, как я писал здесь:

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

Канал Sachok опубликовал мой прогноз под номером 2222 (видимо, это знак 😁)

В РФ делать прогнозы дело неблагодарное, однако, если их не делать - это означает не анализировать текущую ситуацию и не заниматься планированием, не говоря уж о стратегии. Будем менеджерами, будем анализировать происходящее и делать прогнозы!

Как всегда, ваше мнение относительно моих прогнозов приветствуется в комментариях.

#РФ #управление #vCISO

Когда безопасность побеждает безопасность -

- подумалось мне, когда после установки последних обновлений у меня отъехал токен => перестала работать двухфакторная аутентификация.

Спасибо, другу и коллеге Вадиму, починить удалось относительно быстро. Можно поставить пакет во вложении, а для гиков можно все собрать самому. Есть заметка с обсуждения, но в моем случае я пользовался просто последовательностью, описанной в INSTALL.md инсталляционного пакета.

Пока чинил вспомнил пару случаев неудачных обновлений. Один, ну конечно, с Crowdstrike, вот можно почитать их объяснения (без комментариев нет слов).

Другой же пример касается тоже принудительной установки обновлений, но на сей раз обновлений операционной системы Windows, дающих конфликт с прикладным ПО от КриптоПРО. При этом, видимо, КриптоПРО побеждает, поскольку после обновления, Windows более не поднимается . А пока лежат операционная система и все приложения, пользователи, которые должны приносить ценность предприятию, а вместо этого нарушают свои обязательства перед клиентами и личные КПЭ, нервно курят.

Решение по недопустимости - очевидное, но, поскольку на практике не всегда работает, приведу его здесь:
- инвентаризация активов: надо знать какие версии какого ПО установлены
- обновления перед принудительной установкой тестировать на всех конфигурациях, выявленных при инвентаризации
- даже протестированные обновления накатывать волнами, начиная с "менее значимых"\более простых в траблшутинге подразделений
- если хочется заинфорсить актуальность версий системного и прикладного ПО, то применять более мягкие сценарии, типа, не пускать в сеть на NAC, если патчлевел не тот, что нужен
- надо вести учет такого рукож**ого конфликтного ПО (в частности, КриптоПРО) и при инвентаризации и тестировании обновлений на это явно обращать внимание (~ любые ошибки должны делать нас лучше).

#пятница #vCISO