Солдатов в Телеграм Telegram 帖子

На разного рода эфирах и интервью я не раз говорил, что наступательная кибербезопасность - хороший инструмент проверки эффективности нашей операционной ИБ (SOC-а с технологиями, процессами и командой). Но, как любой хороший инструмент (практика показывает, что чем большую эффективность от инструмента мы хотим, тем на более узком объеме его следует рассматривать), пентест (в этой заметке для простоты буду использовать "пентест", но понимать буду более широкий спектр различных активностей по анализу защищенности) для проверки SOC годится лишь отчасти, так как:
- в задачи пентеста, как правило, не входит необходимость действовать скрытно, поэтому они шумны и обнаруживаются. Безусловно, все зависит от задач на пентест, но если поставить цель действовать скрытно, то такие работы растянутся на долгие месяцы и будут экономически нерентабельные (решение есть - иметь внутреннюю команду)
- упомянутая выше ограниченность во времени влияет и на глубину проработки. Я не раз рассказывал случай, когда на одном из моих проектов пентестеры нашли потенциальную RCE в Sendmail на HP-UX, однако, ввиду не особой популярности ОС, доступного эксплоита не было, а нечеловеческие усилия не позволили разработать эксплоит самостоятельно в рамках работ на проекте.
- связанная проблема - ограниченность подготовки. На пентесте будут использоваться какие-то старые собственные заготовки, либо вообще публично доступные инструменты, никакие полностью кастомизированные, разработанные исключительно для этой конкретной атаки тулы использоваться не будут.

В общем, пентест существенно отличается от реальной атаки. Ну а обнаруживать-то хочется реальную атаку! И здесь нам на помощь придет Compromise Assessment (например, этот, или этот, или какой другой), который как раз и направлен на обнаружение пропущенных в прошлом атак. По сути CA выдаст список прошлых инцидентов, относительно которых можно далее заглянуть в историю работы своего SOC и посмотреть что там было видно, почему не видно и наметить какие-то улучшения.

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

Маленькая очевидная ремарка: если у нас операционная безопасность обеспечивается решениями одного вендора, то СА надо брать от другого вендора. Подобная кросс-валидация решений одного вендора решениями другого позволит и конкуренцию усилить, и, как следствие, повысит качество предложения на рынке.

Итак, CA - отличный инструмент для заказчика, чтобы проверить результативность его SOC: инструментов (NDR, EDR, MDR, MXDR), процессов и профессионализма команды, а также, чтобы наметить дальнейшие планы развития бизнес-функции операционной безопасности.

#vCISO #MDR #управление

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

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

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

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

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

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

#пятница #vCISO

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

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

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

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

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

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

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

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

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

#crypto #ml

Продолжу рассказ о нашем путешествии по р. Умба в августе 2024.

Порог Падун, 3+ категории сложности, на мой взгляд, самый красивый на маршруте. Длина порога - около 1 км. Порог проходили в первый день, поэтому, можно сказать, им открылось наше путешествие. В основном видеоматериалы касаются первой ступени, где падение составляет около двух метров. Слив с первой ступени разделен симпатичным и легко узнаваемым островом. После первой ступени, река сужается, поток сильно разгоняется, однако, с крутого левого берега можно удобно наблюдать проходящих. Вторая ступень, скорее, шивера с обилием камней и крупными валами до полуметра. Третья ступень - на S-образном изгибе, у правого берега сливы до 1 метра с камнями, по центру и ближе к левому берегу - расположенные под углом к основной струе две бочки с валами.

Просмотр порога обязателен, мы просматривали по левому берегу, там есть протоптанная тропинка, - по ней же можно выполнить обнос. На нашем огромном K4 Raftmaster порог прошелся без проблем, основная сложность для меня, неумелого любителя, - попадать носом в сливы, чтобы кат не развернуло боком, так как в этом случае есть риск перевернуться, уперевшись балоном в камень.

#здоровье

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

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

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

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

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

#MDR #kaspersky

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

Windows User Account Forensics

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

#MDR

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

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

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

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

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

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

#MDR #vCISO