Forwarded from Солдатов в Телеграм
Пароли в командных строчках
Пароли в командных строках – это небезопасно. Командные строчки логгируются в открытом виде (bash_history, powershell), в общем, не считаются конфиденциальной информацией, а, следовательно, операционные системы не обеспечивают для них должный уровень безопасности, как для пароля, поэтому наличие пароля в командных строках – это уязвимость, и в инфраструктурах с адекватными командами ИТ, скорее, аномалия. Тем не менее, по требованиям безопасности, можно ожидать пароли в командных строках, поэтому в решениях *DR может существовать какая-либо автоматика для маскирования паролей в командных строчках.
Понимая очевидную проблему безопасности в передаче пароля в командной строке, производители инструментов, тем не менее, предлагают такой функционал. И этим функционалом, в том числе, пользуются и злоумышленники, что позволяет их эффективно обнаруживать и расследовать, а иногда и нивелировать ущерб от их действий. Приведу пару случаев из практики.
Пароль атакующего для обнаружения скомпрометированных систем
В одном из инцидентов атакующий использовал подломанную сервисную УЗ(пароль, хороший, стойкий, случайный, в открытом виде был взят из конфигов) для сбора информации BloodHound-ом, команда выглядела примерно так:
В этом инциденте задачу обнаружения всех машинок присутствия атакующего я решил очень просто – поиском по командным строчкам, содержащим подломанный пароль. В целом, можно было искать и по подломанной УЗ, но находились еще и некоторые задачи по расписанию, куда пароль подсовывался более безопасным способом и поэтому не светился в командной строке, а вот пароль в открытом виде в строчку забивал только атакующий.
Описанный фокус работает и с другими излюбленными инструментами атакующих – psexec, paexec, impacket, rdesktop, evil-winrm и т.п.
Пароль атакующего для снятия последствий ущерба
Шифровальщики – тип инцидента №1 с которым приходят за расследованием. Про шифровальщики есть масса публикаций (ну..., можно Ладу послушать, например, там профиль SMB, но для общего понимания – то, что надо; и Канарейки про них постоянно пишут, ну больше всех публикаций, конечно же у ЛК, один из свежих), но надо понимать следующие современные особенности:
– Непосредственно работе шифровальщика предшествует человекоуправляемая атака
– Обычно начинают запускать шифровальщик, когда сеть уже поломана, например, взят домен и шифровальщика раскатывают групповыми политиками или через корпоративные системы инвентаризации и управления типа SCCM или какие-то управляющие сервера(для целей унижения любят использовать сервера управления систем безопасности, которые, очевидно, как и все, в домене, а следовательно, скомпрометированы)
– Часто шифруют легитимные инструментами, типа Bitlocker, VeraCrypt, Kryptor, DiskCryptor и т.п.
– Либо используют кастомизированные сборки популярных Babuk, Conti, LockBit, Chaos, Xorist и т.п., а если мешает EPP, то его выносят разными способами в рамках человекоуправляемости атаки (часто используются легитимные методы, так как нелегитимные - шумные и блокируются, поэтому пока вынесут, ребят успеют локализовать)
В одном из инцидентов злоумышленник для шифрования использовал Bitlocker, команда выглядела примерно так:
Пароль восстановления доступен непосредственно в командной строке...
#MDR
Пароли в командных строках – это небезопасно. Командные строчки логгируются в открытом виде (bash_history, powershell), в общем, не считаются конфиденциальной информацией, а, следовательно, операционные системы не обеспечивают для них должный уровень безопасности, как для пароля, поэтому наличие пароля в командных строках – это уязвимость, и в инфраструктурах с адекватными командами ИТ, скорее, аномалия. Тем не менее, по требованиям безопасности, можно ожидать пароли в командных строках, поэтому в решениях *DR может существовать какая-либо автоматика для маскирования паролей в командных строчках.
Понимая очевидную проблему безопасности в передаче пароля в командной строке, производители инструментов, тем не менее, предлагают такой функционал. И этим функционалом, в том числе, пользуются и злоумышленники, что позволяет их эффективно обнаруживать и расследовать, а иногда и нивелировать ущерб от их действий. Приведу пару случаев из практики.
Пароль атакующего для обнаружения скомпрометированных систем
В одном из инцидентов атакующий использовал подломанную сервисную УЗ
<...> Invoke-StandardCollector –c DcOnly –d domain.corp –prettyjson –nosavecache –ldapusername user_name –ldappassword user_passwordВ этом инциденте задачу обнаружения всех машинок присутствия атакующего я решил очень просто – поиском по командным строчкам, содержащим подломанный пароль. В целом, можно было искать и по подломанной УЗ, но находились еще и некоторые задачи по расписанию, куда пароль подсовывался более безопасным способом и поэтому не светился в командной строке, а вот пароль в открытом виде в строчку забивал только атакующий.
Описанный фокус работает и с другими излюбленными инструментами атакующих – psexec, paexec, impacket, rdesktop, evil-winrm и т.п.
Пароль атакующего для снятия последствий ущерба
Шифровальщики – тип инцидента №1 с которым приходят за расследованием. Про шифровальщики есть масса публикаций (ну..., можно Ладу послушать, например, там профиль SMB, но для общего понимания – то, что надо; и Канарейки про них постоянно пишут, ну больше всех публикаций, конечно же у ЛК, один из свежих), но надо понимать следующие современные особенности:
– Непосредственно работе шифровальщика предшествует человекоуправляемая атака
– Обычно начинают запускать шифровальщик, когда сеть уже поломана, например, взят домен и шифровальщика раскатывают групповыми политиками или через корпоративные системы инвентаризации и управления типа SCCM или какие-то управляющие сервера
– Часто шифруют легитимные инструментами, типа Bitlocker, VeraCrypt, Kryptor, DiskCryptor и т.п.
– Либо используют кастомизированные сборки популярных Babuk, Conti, LockBit, Chaos, Xorist и т.п., а если мешает EPP, то его выносят разными способами в рамках человекоуправляемости атаки (часто используются легитимные методы, так как нелегитимные - шумные и блокируются, поэтому пока вынесут, ребят успеют локализовать)
В одном из инцидентов злоумышленник для шифрования использовал Bitlocker, команда выглядела примерно так:
manage-bde -on C: -rp very_long_random_recovery_password -sk C:\ -s -used -RemoveVolumeShadowCopiesПароль восстановления доступен непосредственно в командной строке...
#MDR
👍15🔥3❤2👎1🤣1
И снова ловим вымогателей, использующих связку Lockbit и Babuk. В новом инциденте атакующие получили доступ во внутреннюю сеть жертвы (организация А) через атаку Trusted Relationship (T1199) и закрепили в сети уже известный нам инструмент для туннелирования трафика – localtonet. В процессе разведки инфраструктуры атакующие обнаружили в том же сетевом сегменте домены ещё двух организаций B и С, где домены оказались с доверительными отношениями. Так злоумышленники получили учётки из доменов организаций B и С.
Но атакующие не успели пошифровать организацию А: её защитники вовремя заметили подозрительную активность и экстренно отреагировали (погасили сетку). Заподозрив неладное, атакующие попытались развить атаку в другом направлении. В этом им помогли собранные учётки из домена организации B, а также VPN без второго фактора. Атакующие незаметно закрепили на одной системе организации B новые инструменты для туннелирования: cloudflared и gost.
Однако быстрые коммуникации между организациями A, B и С, а также знания об атаке на A и новые подробности из B и С позволили остановить атаку до импакта – то есть оперативно повыключать всё, что могло зашифроваться, и в рабочем режиме исправлять-защищать инфру. План шифровальщиков на этот раз не сработал.
А вы готовы к таким выкрутасам? Проверьте эти индикаторы:
Но атакующие не успели пошифровать организацию А: её защитники вовремя заметили подозрительную активность и экстренно отреагировали (погасили сетку). Заподозрив неладное, атакующие попытались развить атаку в другом направлении. В этом им помогли собранные учётки из домена организации B, а также VPN без второго фактора. Атакующие незаметно закрепили на одной системе организации B новые инструменты для туннелирования: cloudflared и gost.
Однако быстрые коммуникации между организациями A, B и С, а также знания об атаке на A и новые подробности из B и С позволили остановить атаку до импакта – то есть оперативно повыключать всё, что могло зашифроваться, и в рабочем режиме исправлять-защищать инфру. План шифровальщиков на этот раз не сработал.
А вы готовы к таким выкрутасам? Проверьте эти индикаторы:
argotunnel[.]com
*.argotunnel[.]com
🔥14👍4❤2
KRBUACBypass — это инструмент, позволяющий обходить механизм защиты User Account Control (UAC) в Windows, используя уязвимости в работе с билетами Kerberos. Атака основана на добавлении поддельной записи
Процесс эксплуатации включает:
1. Получение TGT пользователя через метод делегирования (Tgtdeleg).
2. Запрос сервисного билета с поддельным MachineID.
3. Использование этого билета для взаимодействия с SCM и создания службы, работающей с привилегиями SYSTEM.
Как детектировать атаку:
В нормальных условиях при доступе пользователя к локальным сервисам в Windows используется токен безопасности, связанный с его сеансом, а не Kerberos-билеты. Пользователь аутентифицируется при входе в систему, и система создаёт токен доступа, содержащий информацию об учётной записи, группах и привилегиях пользователя.
А теперь посмотрим, что запрашивается для повышения привилегий при использовании KRBUACBypass (см. скриншот). Здесь запрашивается пересланный TGS-билет для локального сервиса
Но такое действие является аномалией, потому что:
— Пользователи обычно не запрашивают билеты для доступа к локальным сервисам (см. выше про токен безопасности).
— Флаги билета, такие как
Поэтому обнаружение в кеше пользователя пересланного TGS-билета для локального сервиса
KERB-AD-RESTRICTION-ENTRY в сервисный билет, что позволяет получить привилегии уровня SYSTEM через доступ к службе диспетчера контроля служб (SCM) с использованием аутентификации Kerberos.Процесс эксплуатации включает:
1. Получение TGT пользователя через метод делегирования (Tgtdeleg).
2. Запрос сервисного билета с поддельным MachineID.
3. Использование этого билета для взаимодействия с SCM и создания службы, работающей с привилегиями SYSTEM.
Как детектировать атаку:
В нормальных условиях при доступе пользователя к локальным сервисам в Windows используется токен безопасности, связанный с его сеансом, а не Kerberos-билеты. Пользователь аутентифицируется при входе в систему, и система создаёт токен доступа, содержащий информацию об учётной записи, группах и привилегиях пользователя.
А теперь посмотрим, что запрашивается для повышения привилегий при использовании KRBUACBypass (см. скриншот). Здесь запрашивается пересланный TGS-билет для локального сервиса
HOST/gam-win10 от имени текущего пользователя, и этот билет помещается в кеш билетов. Это делается для обхода контроля учётных записей пользователей (UAC) и повышения привилегий без отображения UAC-подтверждения.Но такое действие является аномалией, потому что:
— Пользователи обычно не запрашивают билеты для доступа к локальным сервисам (см. выше про токен безопасности).
— Флаги билета, такие как
forwarded и forwardable, указывают на то, что билет был переслан. А сервис для этого билета "местный". Также отметим, что в TGT для сессии иные флаги. Для локальных сервисов это нехарактерно и может свидетельствовать о попытке обхода механизмов безопасности.Поэтому обнаружение в кеше пользователя пересланного TGS-билета для локального сервиса
HOST/gam-win10, особенно с флагами forwarded и forwardable, позволяет засечь использование KRBUACBypass или подобной техники для несанкционированного повышения привилегий.👍17🔥5
Как многократно подтверждено на практике, атакующие не меняют свои ТТР, если они сохраняют результативность. Поэтому, в рамках активного поиска угроз (Threat hunting) разумно в первую очередь проверять техники и инструменты, которыми атакующие пользовались ранее. А это, в свою очередь, определяется возможностями по анализу данных об угрозах (Threat Intelligence).
А кто именно будет атаковать? На этот вопрос тоже может ответить качественная TI. Ведь серьёзные атакующие, как правило, имеют специализацию. Поэтому, фокусируя Threat hunting на кластеры активности, релевантные заданной индустрии и географической локации, наш SOC имеет возможность значительно сократить объём хантинга, повышая его эффективность.
Вы тоже можете оценить такой подход, используя новый инструмент Threat Landscape, который появился на нашем портале сервисов киберразведки: собранные экспертами данные об угрозах разложены на применяемые TTP в нотации MITRE ATT&CK, в соответствии с профилями замеченных жертв. Подробнее о том, как этот инструмент помогает командам SOC, расскажем на вебинаре – 25 октября, 11:00 МСК.
А кто именно будет атаковать? На этот вопрос тоже может ответить качественная TI. Ведь серьёзные атакующие, как правило, имеют специализацию. Поэтому, фокусируя Threat hunting на кластеры активности, релевантные заданной индустрии и географической локации, наш SOC имеет возможность значительно сократить объём хантинга, повышая его эффективность.
Вы тоже можете оценить такой подход, используя новый инструмент Threat Landscape, который появился на нашем портале сервисов киберразведки: собранные экспертами данные об угрозах разложены на применяемые TTP в нотации MITRE ATT&CK, в соответствии с профилями замеченных жертв. Подробнее о том, как этот инструмент помогает командам SOC, расскажем на вебинаре – 25 октября, 11:00 МСК.
👍26🔥6
Однажды мы рассказывали, как повышают привилегии через Active Directory Certificate Services (ADCS). Тогда была атака ADCS ESC13, недавно появилась ADCS ESC15. Другие ESCx тоже интересные, но про них – в другой раз.
А в технике ADCS ESC15 главное: уязвимые шаблоны сертификатов 1-й версии схемы с возможностью указать subjectAltName (SAN) в CSR. Для эксплуатации нужна доменная учётка с правами Enroll на уязвимый шаблон.
Например, один из встроенных уязвимых шаблонов – WebServer (Version:1 и CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). По умолчанию, запрашивать сертификаты с этим шаблоном могут только Domain- и Enterprise- администраторы. Но по нашему опыту, пользователи часто меняют права на этот шаблон, и нередко можно встретить там даже Authenticated Users.
Суть эксплуатации: при наличии у сертификата расширения Application Policies и Extended Key Usage (EKU), домен-контроллер предпочтёт верить EKU из Application Policies. Это значит, что при запросе сертификата, используя уязвимый шаблон, атакующий может добавить EKU «Client Authentication» в поле Application Policies, добавить администратора домена в SAN и, получив сертификат, успешно запросить TGT для этого администратора. Получается очень похоже на технику атаки ESC1. Единственное ограничение – это возможность аутентификации только по schannel на LDAP.
Также атакующий может добавить EKU «Certificate Request Agent» в поле Application Policies и использовать полученный сертификат для запроса ещё одного, но уже на любого пользователя, как это реализовано в технике ESC3. Либо добавить "Code Signing" в Application Policies и использовать сертификат для подписи файлов.
Как детектировать уязвимые шаблоны и что делать после – читайте в статье Дмитрия Щетинина.
А в технике ADCS ESC15 главное: уязвимые шаблоны сертификатов 1-й версии схемы с возможностью указать subjectAltName (SAN) в CSR. Для эксплуатации нужна доменная учётка с правами Enroll на уязвимый шаблон.
Например, один из встроенных уязвимых шаблонов – WebServer (Version:1 и CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT). По умолчанию, запрашивать сертификаты с этим шаблоном могут только Domain- и Enterprise- администраторы. Но по нашему опыту, пользователи часто меняют права на этот шаблон, и нередко можно встретить там даже Authenticated Users.
Суть эксплуатации: при наличии у сертификата расширения Application Policies и Extended Key Usage (EKU), домен-контроллер предпочтёт верить EKU из Application Policies. Это значит, что при запросе сертификата, используя уязвимый шаблон, атакующий может добавить EKU «Client Authentication» в поле Application Policies, добавить администратора домена в SAN и, получив сертификат, успешно запросить TGT для этого администратора. Получается очень похоже на технику атаки ESC1. Единственное ограничение – это возможность аутентификации только по schannel на LDAP.
Также атакующий может добавить EKU «Certificate Request Agent» в поле Application Policies и использовать полученный сертификат для запроса ещё одного, но уже на любого пользователя, как это реализовано в технике ESC3. Либо добавить "Code Signing" в Application Policies и использовать сертификат для подписи файлов.
Как детектировать уязвимые шаблоны и что делать после – читайте в статье Дмитрия Щетинина.
🔥23👍5❤3
Групповые политики в Windows (Group Policy Objects, GPO) дают админам возможность контролировать настройки пользователей и компьютеров в доменной среде. Но эта же фича в руках злоумышленников позволяет проводить различные атаки. Самый распространенный сценарий, который мы наблюдали – массовый деплой шифровальщика на множество хостов.
Также групповые политики могут использоваться для скрытного закрепления в домене, после чего атакующие могут делать всё, что угодно. Например, инструмент SharpGPOAbuse позволяет через GPO создавать новые пользовательские задачи в планировщике (см. скриншот), повышать привилегии, добавлять скрипты автозапуска и т.д.
Главные модификации при этом происходят в шаблоне групповой политики (Group Policy Template, GPT), что расположен на SysVol – там изменяются атрибуты gPCMachineExtensionNames и gPCUserExtensionNames.
Если атакующий не может получить доступ к SysVol из-за отсутствия прав на изменение GPT, он может изменить атрибут gPCFileSysPath, указав путь до подконтрольного ему сетевого ресурса. Тогда все клиенты, на кого распространяется политика, будут идти на данный ресурс. Подобный функционал даёт инструмент GPOddity. Он поднимает собственный SMB-сервер, где создает вредоносные политики, после чего изменяет путь до GPT, а после применения политик восстанавливает старые из своего бэкапа.
Как детектировать: следите за модификацией атрибутов gPCMachineExtensionNames, gPCUserExtensionNames и gPCFileSysPath через событие 5136 на изменение объектов AD.
Подробности и SIGMA-правила для обнаружения вредоносных групповых политик – в статье Глеба Иванова.
Также групповые политики могут использоваться для скрытного закрепления в домене, после чего атакующие могут делать всё, что угодно. Например, инструмент SharpGPOAbuse позволяет через GPO создавать новые пользовательские задачи в планировщике (см. скриншот), повышать привилегии, добавлять скрипты автозапуска и т.д.
Главные модификации при этом происходят в шаблоне групповой политики (Group Policy Template, GPT), что расположен на SysVol – там изменяются атрибуты gPCMachineExtensionNames и gPCUserExtensionNames.
Если атакующий не может получить доступ к SysVol из-за отсутствия прав на изменение GPT, он может изменить атрибут gPCFileSysPath, указав путь до подконтрольного ему сетевого ресурса. Тогда все клиенты, на кого распространяется политика, будут идти на данный ресурс. Подобный функционал даёт инструмент GPOddity. Он поднимает собственный SMB-сервер, где создает вредоносные политики, после чего изменяет путь до GPT, а после применения политик восстанавливает старые из своего бэкапа.
Как детектировать: следите за модификацией атрибутов gPCMachineExtensionNames, gPCUserExtensionNames и gPCFileSysPath через событие 5136 на изменение объектов AD.
Подробности и SIGMA-правила для обнаружения вредоносных групповых политик – в статье Глеба Иванова.
🔥19✍2
В прошлом посте мы рассказали, как детектировать атаки на основе компрометации групповых политик (GPO). А теперь о том, как обеспечить проактивный мониторинг групповых политик в SOC.
Во-первых, не всегда попадаются хосты с включенным расширенным аудитом Windows. Там, где это возможно, используйте ETW-провайдеры. А где не получается обойтись одним ETW – расширяйте покрытие телеметрии.
К примеру, чтобы отвязаться от события 5136, что требует настройки аудита «Изменения в службе каталогов», наш эксперт Александр Родченко разработал утилиту GCNet. Этот инструмент работает на основе PoC по мониторингу изменения служб каталогов, описанным Microsoft.
Утилита GCNet биндится к базе LDAP, где надо указать поиск по определенному distinguishedName (в нашем случае это CN=Policies) и подписаться на любые его изменения. Данный функционал выступает триггером для того, чтобы запросить GPO, где выводится информация с GPC и GPT (см. скриншот выше).
Дальше событие прогоняется по детектирующим правилам. Одним из важных атрибутов политики являются опции GPLink и флаги политики. Политики с флагом Enforced имеют приоритет перед остальными и будут применены раньше, и они не могут быть переписаны другой политикой. Есть ещё несколько флагов, зная которые, можно понять, включена политика или нет.
Совокупность всех атрибутов также дает дополнительную информацию о том, сколько времени есть на реагирование, пока не применится групповая политика (по умолчанию политики обновляются каждые 90 минут, плюс-минус 30 минут с джиттером на клиентских машинах, и каждые 5 минут на домен-контроллере). Также по этим атрибутам можно увидеть, где и как политика применяется, что значительно расширяет картину расследования.
Во-первых, не всегда попадаются хосты с включенным расширенным аудитом Windows. Там, где это возможно, используйте ETW-провайдеры. А где не получается обойтись одним ETW – расширяйте покрытие телеметрии.
К примеру, чтобы отвязаться от события 5136, что требует настройки аудита «Изменения в службе каталогов», наш эксперт Александр Родченко разработал утилиту GCNet. Этот инструмент работает на основе PoC по мониторингу изменения служб каталогов, описанным Microsoft.
Утилита GCNet биндится к базе LDAP, где надо указать поиск по определенному distinguishedName (в нашем случае это CN=Policies) и подписаться на любые его изменения. Данный функционал выступает триггером для того, чтобы запросить GPO, где выводится информация с GPC и GPT (см. скриншот выше).
Дальше событие прогоняется по детектирующим правилам. Одним из важных атрибутов политики являются опции GPLink и флаги политики. Политики с флагом Enforced имеют приоритет перед остальными и будут применены раньше, и они не могут быть переписаны другой политикой. Есть ещё несколько флагов, зная которые, можно понять, включена политика или нет.
Совокупность всех атрибутов также дает дополнительную информацию о том, сколько времени есть на реагирование, пока не применится групповая политика (по умолчанию политики обновляются каждые 90 минут, плюс-минус 30 минут с джиттером на клиентских машинах, и каждые 5 минут на домен-контроллере). Также по этим атрибутам можно увидеть, где и как политика применяется, что значительно расширяет картину расследования.
👍23🤩1
Типичный инцидент нашего времени – утечка через облачный сервис. В ряде кейсов, которые расследовали наши эксперты, конфиденциальные документы клиентов утекали через популярное облачное хранилище Google Drive.
Реагирование на подобный инцидент требует собрать множество специфических артефактов. Нужно узнать, какие пользователи в сети клиента инсталлировали у себя приложение для работы с облачным хранилищем (Google Drive for Desktop, ранее Google Drive File Stream), в какие аккаунты они логинились, с какими файлами работали, какие данные можно собрать об удаленных файлах, и др.
Наш коллега Амжед Ваги (Amged Wageh) создал инструмент DriveFS Sleuth, который позволяет автоматизировать сбор артефактов при расследовании утечек или распространения малвары через Google Drive.
Утилиту можно скачать на Гитхабе, а также в виде Python-пакета на Pypi.org. Функционал утилиты включает:
– восстановление синхронизированных файлов с детальными метаданными, даже если файлы не остались в локальном кэше,
– выявление удалённых файлов, даже если они были удалены из базы,
– выявление подключенных устройств с их настройками и GUIDs,
– поиск по именам файлов и папок, по MD5-хэшам и регулярным выражениям (regex),
– генерацию подробных отчётов в формате HTML или CSV.
Более подробно о сборе артефактов использования Google Drive и о функционале DriveFS Sleuth автор утилиты расскажет на BlackHat MEA (Мальхам, Саудовская Аравия, 28 ноября).
Реагирование на подобный инцидент требует собрать множество специфических артефактов. Нужно узнать, какие пользователи в сети клиента инсталлировали у себя приложение для работы с облачным хранилищем (Google Drive for Desktop, ранее Google Drive File Stream), в какие аккаунты они логинились, с какими файлами работали, какие данные можно собрать об удаленных файлах, и др.
Наш коллега Амжед Ваги (Amged Wageh) создал инструмент DriveFS Sleuth, который позволяет автоматизировать сбор артефактов при расследовании утечек или распространения малвары через Google Drive.
Утилиту можно скачать на Гитхабе, а также в виде Python-пакета на Pypi.org. Функционал утилиты включает:
– восстановление синхронизированных файлов с детальными метаданными, даже если файлы не остались в локальном кэше,
– выявление удалённых файлов, даже если они были удалены из базы,
– выявление подключенных устройств с их настройками и GUIDs,
– поиск по именам файлов и папок, по MD5-хэшам и регулярным выражениям (regex),
– генерацию подробных отчётов в формате HTML или CSV.
Более подробно о сборе артефактов использования Google Drive и о функционале DriveFS Sleuth автор утилиты расскажет на BlackHat MEA (Мальхам, Саудовская Аравия, 28 ноября).
🔥20👍2👏2
В декабре принято публиковать разные итоговые обзоры и топы событий. Мы тоже решили составить свой топ, на основе практики расследований и реагирований на инциденты в 2024 году: НЕлучшие практики во время инцидента. Избегание этих ошибок сильно поможет и пострадавшим, и тем, кто будет расследовать.
(1) Использование потенциально скомпрометированных каналов связи.
Не спешите писать про инцидент в корпоративных каналах коммуникации (пока эта информация не стала общедоступной). Если злоумышленники могут читать вашу почту с перепиской про расследование, они будут на шаг впереди.
Это касается и мессенджера Telegram, клиент которого может быть установлен на рабочей машине в скомпрометированном домене. Даже если вы твёрдо уверены, что вашу телегу не читают, это ещё не значит, что злоумышленники не читают телеги всех 30+ человек из чата по инциденту.
Вообще, делиться данными по своим инцидентам – очень полезная практика для сообщества. Но лучше делать это после, а не время расследования.
(2) Поспешное удаление вредоносного ПО.
«Наш инцидент – это зловредный файл на компьютере. Удалили файл – забороли инцидент». Ошибочная логика. Вредонос конечно заслуживает наказания, но для начала нужно восстановить хронологию событий: как он попал в инфраструктуру, что он там делал, есть ли вредоносное ПО на других хостах сети.
Потому что инцидент ещё не исперчен: заметив потерю коннекта к одному вредносу, злоумышленники могут подключиться через другой. И даже если вы удалили все обнаруженные вредоносы, атакующие уже могли собрать креды – и теперь могут подключаться к вам по штатным каналам - RDP, VPN...
(3) Слишком быстрое восстановление бизнес-процессов.
Конечно, всем хочется поскорее вернуться в строй. Однако необходимо собрать артефакты: файлы, журналы и другие данные для расследования. Не знаете, что это? Снимите побитовую копию (FTK Imager, dd). Не сделали? Скорее всего придётся показывать эффективность в восстановлении бизнеса ещё раз, как минимум.
Поспешная переустановка поломанных систем – типичная ситуация, при которой уничтожаются артефакты, что мешает восстановлению картины инцидента.
Ещё более неприятные последствия влечёт за собой поспешное восстановление из бекапов, которые уже были скомпрометированы на момент создания (что было подтверждено много раз в инцидентах этого года). Бэкап может быть заражён, в нём могут быть те же уязвимости, которые ранее использовал злоумышленник, или старые пароли, которые не сменили. Если вы будете восстанавливаться до того, как выяснили детали инцидента – вы просто дадите атакующим инфру под повторное злодеяние (например, вас снова зашифруют).
(4) Непредсказуемое выполнение рекомендаций специалистов по реагированию.
Например, просьба выключить всю коммуникацию между внутренними корпоративными сетями и внешними сетями может подразумевать множество действий (отключить пользователей, отключить онлайн-сервисы организации, отключить удаленный доступ админов, подрядчиков и т.д.). Клиенты могут понять задачу по-разному – и выполнить только часть этих действий.
Плохо сформулирована рекомендация? Потребуйте переформулировать. Нет компетенций выполнить рекомендации? Попросите инструкцию. Нет времени? Попросите помощи. Не откладывайте в долгий ящик – он не такой уж долгий.
(5) Проведение пентеста для купирования инцидента попыткой обнаружить "путь" злоумышленника.
Пентест может внести много дополнительного шума (детекты СЗИ; файлы/персистенс и т.д.) и затереть полезные артефакты. Поэтому лучше сделайте расследование инцидента вместо анализа защищенности во время инцидента.
(1) Использование потенциально скомпрометированных каналов связи.
Не спешите писать про инцидент в корпоративных каналах коммуникации (пока эта информация не стала общедоступной). Если злоумышленники могут читать вашу почту с перепиской про расследование, они будут на шаг впереди.
Это касается и мессенджера Telegram, клиент которого может быть установлен на рабочей машине в скомпрометированном домене. Даже если вы твёрдо уверены, что вашу телегу не читают, это ещё не значит, что злоумышленники не читают телеги всех 30+ человек из чата по инциденту.
Вообще, делиться данными по своим инцидентам – очень полезная практика для сообщества. Но лучше делать это после, а не время расследования.
(2) Поспешное удаление вредоносного ПО.
«Наш инцидент – это зловредный файл на компьютере. Удалили файл – забороли инцидент». Ошибочная логика. Вредонос конечно заслуживает наказания, но для начала нужно восстановить хронологию событий: как он попал в инфраструктуру, что он там делал, есть ли вредоносное ПО на других хостах сети.
Потому что инцидент ещё не исперчен: заметив потерю коннекта к одному вредносу, злоумышленники могут подключиться через другой. И даже если вы удалили все обнаруженные вредоносы, атакующие уже могли собрать креды – и теперь могут подключаться к вам по штатным каналам - RDP, VPN...
(3) Слишком быстрое восстановление бизнес-процессов.
Конечно, всем хочется поскорее вернуться в строй. Однако необходимо собрать артефакты: файлы, журналы и другие данные для расследования. Не знаете, что это? Снимите побитовую копию (FTK Imager, dd). Не сделали? Скорее всего придётся показывать эффективность в восстановлении бизнеса ещё раз, как минимум.
Поспешная переустановка поломанных систем – типичная ситуация, при которой уничтожаются артефакты, что мешает восстановлению картины инцидента.
Ещё более неприятные последствия влечёт за собой поспешное восстановление из бекапов, которые уже были скомпрометированы на момент создания (что было подтверждено много раз в инцидентах этого года). Бэкап может быть заражён, в нём могут быть те же уязвимости, которые ранее использовал злоумышленник, или старые пароли, которые не сменили. Если вы будете восстанавливаться до того, как выяснили детали инцидента – вы просто дадите атакующим инфру под повторное злодеяние (например, вас снова зашифруют).
(4) Непредсказуемое выполнение рекомендаций специалистов по реагированию.
Например, просьба выключить всю коммуникацию между внутренними корпоративными сетями и внешними сетями может подразумевать множество действий (отключить пользователей, отключить онлайн-сервисы организации, отключить удаленный доступ админов, подрядчиков и т.д.). Клиенты могут понять задачу по-разному – и выполнить только часть этих действий.
Плохо сформулирована рекомендация? Потребуйте переформулировать. Нет компетенций выполнить рекомендации? Попросите инструкцию. Нет времени? Попросите помощи. Не откладывайте в долгий ящик – он не такой уж долгий.
(5) Проведение пентеста для купирования инцидента попыткой обнаружить "путь" злоумышленника.
Пентест может внести много дополнительного шума (детекты СЗИ; файлы/персистенс и т.д.) и затереть полезные артефакты. Поэтому лучше сделайте расследование инцидента вместо анализа защищенности во время инцидента.
👍33🔥4❤1🥰1
В прошлом посте мы собрали типичные ошибки, которые могут сделать пострадавшие от инцидента до завершения расследования. Оказалось, что аналогичный список «нелучших практик» есть у коллег из Solar 4rays – они делали такой доклад на SOC Forum (видео). Теперь вы можете сравнить эти два списка популярных косяков и составить из них общий анти-плейбук для своих клиентов.
А мы тем временем покажем вам топ ошибок с другой стороны. Ведь даже те, кто профессионально занимается реагированием, иногда ошибаются. Поэтому наш следующий список вредных советов – чего не нужно делать специалистам по реагированию на инцидент:
(1) Собирать данные с систем, которые не были изолированы. Злоумышленники могут обнаружить триаж и вытащить из него чувствительную информацию. Атакующие могут изменить состояние системы (например, добавить персистенс) после создания триажа.
(2) Запускать подозрительные файлы на виртуалках с доступом в Интернет: злоумышленники поймут, что их действия анализируют. А ещё к злоумышленникам может утечь содержимое примонтированных к виртуалке шар (а вдруг там файлы с другого инцидента?). Поэтому сначала лучше определить основной функционал файла в виртуалке без доступа к Интернету или путём проведения статического анализа.
(3) Загружать артефакты пострадавших в общедоступные сервисы: VirusTotal, сервисы для декодирования/расшифровки неизвестных данных. В файлах/данных может быть конфиденциальная информация (пароли, ключи, название пострадавшей компании и т.д.)
(4) Писать в отчет не подтвержденную расследователем информацию, которую излагает пострадавший. «Порт RDP никогда не был доступен из Интернета…». «Ну ладно, был доступен, но там было ограничение по IP...» У расследователя нет задачи доверять. Его задача – сделать собственные доказанные выводы. Категорически запрещается не проверять выводы из других источников.
(5) Анализировать только известные логи/типы событий. Если вы не нашли ничего в стандартных логах Windows, вам могут помочь кастомные логи какого-то специфического софта. Например, в логах утилит для туннелирования может сохраниться время и IP-адрес входящих/исходящих подключений.
(6) Игнорировать зашифрованные диски виртуальных машин. Зачастую для ускорения процесса шифрования, трояны-шифровальщики шифруют большие файлы (например, диски виртуальных машин) не полностью. Если собрать такой файл у клиента, иногда из него удается вытащить журналы событий, файлы реестра и другую полезную для расследования информацию.
(7) При расследовании взлома web-сайта без разрешения клиента и наличия исходных кодов пытаться проверять на сайте различные вектора атак. Такими действиями вы можете случайно затереть какие-то страницы сайта; добавить код, который блокирует работу скриптов на фронтэнде; нарушить структуру БД; израсходовать ресурсы сервера; стриггерить СЗИ.
Подробнее о том, как правильно вести себя при расследовании инцидентов, расскажет наш эксперт Константин Сапронов в онлайновом эфире AM Live 11 декабря, в 11:00 МСК (для просмотра нужна регистрация по ссылке)
А мы тем временем покажем вам топ ошибок с другой стороны. Ведь даже те, кто профессионально занимается реагированием, иногда ошибаются. Поэтому наш следующий список вредных советов – чего не нужно делать специалистам по реагированию на инцидент:
(1) Собирать данные с систем, которые не были изолированы. Злоумышленники могут обнаружить триаж и вытащить из него чувствительную информацию. Атакующие могут изменить состояние системы (например, добавить персистенс) после создания триажа.
(2) Запускать подозрительные файлы на виртуалках с доступом в Интернет: злоумышленники поймут, что их действия анализируют. А ещё к злоумышленникам может утечь содержимое примонтированных к виртуалке шар (а вдруг там файлы с другого инцидента?). Поэтому сначала лучше определить основной функционал файла в виртуалке без доступа к Интернету или путём проведения статического анализа.
(3) Загружать артефакты пострадавших в общедоступные сервисы: VirusTotal, сервисы для декодирования/расшифровки неизвестных данных. В файлах/данных может быть конфиденциальная информация (пароли, ключи, название пострадавшей компании и т.д.)
(4) Писать в отчет не подтвержденную расследователем информацию, которую излагает пострадавший. «Порт RDP никогда не был доступен из Интернета…». «Ну ладно, был доступен, но там было ограничение по IP...» У расследователя нет задачи доверять. Его задача – сделать собственные доказанные выводы. Категорически запрещается не проверять выводы из других источников.
(5) Анализировать только известные логи/типы событий. Если вы не нашли ничего в стандартных логах Windows, вам могут помочь кастомные логи какого-то специфического софта. Например, в логах утилит для туннелирования может сохраниться время и IP-адрес входящих/исходящих подключений.
(6) Игнорировать зашифрованные диски виртуальных машин. Зачастую для ускорения процесса шифрования, трояны-шифровальщики шифруют большие файлы (например, диски виртуальных машин) не полностью. Если собрать такой файл у клиента, иногда из него удается вытащить журналы событий, файлы реестра и другую полезную для расследования информацию.
(7) При расследовании взлома web-сайта без разрешения клиента и наличия исходных кодов пытаться проверять на сайте различные вектора атак. Такими действиями вы можете случайно затереть какие-то страницы сайта; добавить код, который блокирует работу скриптов на фронтэнде; нарушить структуру БД; израсходовать ресурсы сервера; стриггерить СЗИ.
Подробнее о том, как правильно вести себя при расследовании инцидентов, расскажет наш эксперт Константин Сапронов в онлайновом эфире AM Live 11 декабря, в 11:00 МСК (для просмотра нужна регистрация по ссылке)
🔥22👍7❤3👏2⚡1
Один из самых популярных инструментов для реверса – программа IDA Pro от компании Hex-Rays. Наши эксперты из команды GREAT много лет использовали этот инструмент для анализа вредоносного ПО. И даже разработали собственный плагин hrtng, который значительно расширяет функционал IDA Pro – особенно в части анализа таких образцов, где используется обфускация и шифрование.
И теперь коллеги выложили свой плагин на Гитхабе, так что все желающие могут им пользоваться.
А как работает эта тулза, можно посмотреть на примере реверса хитрого вредоноса FinSpy. В этой истории плагин hrtng используется для расшифровки шеллкодов, для поиска хэшей имён API-функций в декомпилированном коде, с последующим восстановлением имён API-вызовов, а также для декомпиляции обфусцированного кода.
И теперь коллеги выложили свой плагин на Гитхабе, так что все желающие могут им пользоваться.
А как работает эта тулза, можно посмотреть на примере реверса хитрого вредоноса FinSpy. В этой истории плагин hrtng используется для расшифровки шеллкодов, для поиска хэшей имён API-функций в декомпилированном коде, с последующим восстановлением имён API-вызовов, а также для декомпиляции обфусцированного кода.
👍25❤4🤨3
LSaasDumper.pdf
2 MB
Время от времени мы проводим неформальные, но очень насыщенные встречи для тех, чьи интересы так или иначе затрагивают оффенсив (пентестеры, аппсекеры, аналитики). Эти митапы обычно состоят из трех-четырех докладов, после чего большинство участников перетекают в afterparty и живое общение.
О том, как попасть на очередное такое мероприятие, расскажем уже в следующем году. А пока – пример одного из докладов с последнего митапа: наш коллега Георгий Кигурадзе рассказал, как сдампить Lsass, оставаясь под радарами стандартных хантов. Было много запросов пошарить слайды этого доклада, и вот они – в приложенном файле.
TL;DR: Извлечение секретов из lsass – один из логичных шагов на этапе постэксплуатации в Windows-инфраструктурах. Однако большинство готовых решений гарантировано детектируется стандартными средствами. Наше решение: разработать свою реализацию дампа, на основе примитивов доверенного инструмента.
Основная идея в том, чтобы использовать прямое чтение физической памяти через подписанный Microsoft драйвер, который используется расследователями для снятия дампа оперативной памяти. Сканируя память, мы находим ядерную структуру EPROCESS для процесса lsass.exe. После парсинга этой структуры проходимся по всем VAD-ам, принадлежащим процессу, и ищем lsasrv.dll. Именно в этой библиотеке находятся необходимые нам ключи шифрования и контексты пользователей. Прочитав физическую память по нужным адресам, можно расшифровать контексты пользователей и получить их NTLM-хэши.
Всё это мы реализовали как BOF для Mythic C2 (про создание собственного Mythic-агента расскажем чуть позже).
Ну и полезный совет для стороны защиты: подобные атаки можно обнаружить по регистрации подозрительного драйвера для форензики (смотрите IoC на последнем слайде).
О том, как попасть на очередное такое мероприятие, расскажем уже в следующем году. А пока – пример одного из докладов с последнего митапа: наш коллега Георгий Кигурадзе рассказал, как сдампить Lsass, оставаясь под радарами стандартных хантов. Было много запросов пошарить слайды этого доклада, и вот они – в приложенном файле.
TL;DR: Извлечение секретов из lsass – один из логичных шагов на этапе постэксплуатации в Windows-инфраструктурах. Однако большинство готовых решений гарантировано детектируется стандартными средствами. Наше решение: разработать свою реализацию дампа, на основе примитивов доверенного инструмента.
Основная идея в том, чтобы использовать прямое чтение физической памяти через подписанный Microsoft драйвер, который используется расследователями для снятия дампа оперативной памяти. Сканируя память, мы находим ядерную структуру EPROCESS для процесса lsass.exe. После парсинга этой структуры проходимся по всем VAD-ам, принадлежащим процессу, и ищем lsasrv.dll. Именно в этой библиотеке находятся необходимые нам ключи шифрования и контексты пользователей. Прочитав физическую память по нужным адресам, можно расшифровать контексты пользователей и получить их NTLM-хэши.
Всё это мы реализовали как BOF для Mythic C2 (про создание собственного Mythic-агента расскажем чуть позже).
Ну и полезный совет для стороны защиты: подобные атаки можно обнаружить по регистрации подозрительного драйвера для форензики (смотрите IoC на последнем слайде).
🔥26❤3
Современный автомобиль — это не только способ привлечь внимание противоположного пола. Это ещё и продвинутая компьютерная сеть, насчитывающая до сотни электронных блоков управления, связанных между собой через Controller Area Network (CAN).
Производители уверяют, что самые критичные узлы этой сети надёжно изолированы от доступа через другие компоненты. Но в реальности всё бывает иначе. Чтобы, например, открыть электронный замок двери автомобиля, иногда достаточно всего лишь открутить фару. А управлять тормозами чужой машины на ходу можно через беспроводной доступ к системе инфотейнмента.
Учитывая такие удивительные возможности, наши эксперты провели анализ защищённости системы инфотейнмента Mercedes-Benz Head Unit (MBUX). В работе использовали реальный автомобиль Mercedes B180, а также собственную платформу для тестирования аппаратного и программного обеспечения.
Обнаруженные в этих тестах уязвимости позволяют человеку, получившему доступ к стандартному USB-порту автомобиля, управлять медиа-системой MBUX по своему усмотрению. Например, владелец автомобиля может разблокировать некоторые платные функции, не заплатив за них.
Кроме того, были найдены уязвимости, которые злоумышленник может использовать, когда исследует этот модуль на стенде, сняв его с угнанного автомобиля. В частности, существует возможность отключить систему защиты от угона, которая с помощью специальной аутентификации через CAN должна блокировать несанкционированный доступ к системе MBUX в реальном автомобиле.
Обо всех выявленных проблемах мы, конечно же, сообщили производителю. Подробности читайте в нашем отчёте "Обзор защищенности головного устройства Mercedes-Benz".
Производители уверяют, что самые критичные узлы этой сети надёжно изолированы от доступа через другие компоненты. Но в реальности всё бывает иначе. Чтобы, например, открыть электронный замок двери автомобиля, иногда достаточно всего лишь открутить фару. А управлять тормозами чужой машины на ходу можно через беспроводной доступ к системе инфотейнмента.
Учитывая такие удивительные возможности, наши эксперты провели анализ защищённости системы инфотейнмента Mercedes-Benz Head Unit (MBUX). В работе использовали реальный автомобиль Mercedes B180, а также собственную платформу для тестирования аппаратного и программного обеспечения.
Обнаруженные в этих тестах уязвимости позволяют человеку, получившему доступ к стандартному USB-порту автомобиля, управлять медиа-системой MBUX по своему усмотрению. Например, владелец автомобиля может разблокировать некоторые платные функции, не заплатив за них.
Кроме того, были найдены уязвимости, которые злоумышленник может использовать, когда исследует этот модуль на стенде, сняв его с угнанного автомобиля. В частности, существует возможность отключить систему защиты от угона, которая с помощью специальной аутентификации через CAN должна блокировать несанкционированный доступ к системе MBUX в реальном автомобиле.
Обо всех выявленных проблемах мы, конечно же, сообщили производителю. Подробности читайте в нашем отчёте "Обзор защищенности головного устройства Mercedes-Benz".
🔥17❤3👍1
В середине января Belsen Group выложила в публичный доступ архив с файлами конфигурации и учётными данными для более 15 тысяч устройств FortiGate (межсетевые экраны производства Fortinet). Сама утечка произошла в конце 2022 года через уязвимость CVE-2022-40684, которая позволяет обходить аутентификацию в программном обеспечении FortiOS, FortiProxy и FortiSwitchManager.
Про эту утечку уже написали многие — но не написали, что делать. А между тем, слитый дамп может дать атакующим много ценной информации о потенциальных жертвах. Данные в архиве упорядочены по IP-адресам устройств (TLD-TARGET_IP), для каждого адреса там содержится файл конфигурации и учётные данные VPN с паролями в открытом текстовом виде.
Чтобы узнать, стали ли вы (или станете) жертвой атаки на основе этой уязвимости и последующей утечки, рекомендуем проделать следующие телодвижения:
(1) Проверить, есть ли адрес вашего устройства в списке скомпрометированных IP-адресов. Также стоит посмотреть список контактных почтовых адресов, которые найдены в слитых конфигах (вдруг ваш емейл там тоже засветился).
(2) Проверить наличие CVE-2022-40684 на ваших устройствах. Этой уязвимости подвержены FortiOS — версии от 7.2.0 до 7.2.1, версии от 7.0.0 до 7.0.6; FortiProxy — версии 7.2.0, версии от 7.0.0 до 7.0.6; FortiSwitchManager — версии 7.2.0 и 7.0.0. Уязвимость исправлена в версиях FortiOS 7.2.2 и выше, 7.0.7 и выше; FortiProxy 7.2.1 и выше, 7.0.7 и выше; FortiSwitchManager 7.2.1 и выше, 7.0.1 и выше.
(3) Выяснить, эксплуатировалась ли эта уязвимость на вашем устройстве. Для этого производитель советует провести аудит конфигураций и учётных записей. Особенно полезно посмотреть, появлялся ли в логах вашего устройства “
Ну и кстати, если в ваших устройствах от Fortinet не нашлась вышеописанная уязвимость, не спешите расслабляться – за последнее время в этих устройствах найдена куча других интересных уязвимостей, которые активно эксплуатируются злоумышленниками.
Про эту утечку уже написали многие — но не написали, что делать. А между тем, слитый дамп может дать атакующим много ценной информации о потенциальных жертвах. Данные в архиве упорядочены по IP-адресам устройств (TLD-TARGET_IP), для каждого адреса там содержится файл конфигурации и учётные данные VPN с паролями в открытом текстовом виде.
Чтобы узнать, стали ли вы (или станете) жертвой атаки на основе этой уязвимости и последующей утечки, рекомендуем проделать следующие телодвижения:
(1) Проверить, есть ли адрес вашего устройства в списке скомпрометированных IP-адресов. Также стоит посмотреть список контактных почтовых адресов, которые найдены в слитых конфигах (вдруг ваш емейл там тоже засветился).
(2) Проверить наличие CVE-2022-40684 на ваших устройствах. Этой уязвимости подвержены FortiOS — версии от 7.2.0 до 7.2.1, версии от 7.0.0 до 7.0.6; FortiProxy — версии 7.2.0, версии от 7.0.0 до 7.0.6; FortiSwitchManager — версии 7.2.0 и 7.0.0. Уязвимость исправлена в версиях FortiOS 7.2.2 и выше, 7.0.7 и выше; FortiProxy 7.2.1 и выше, 7.0.7 и выше; FortiSwitchManager 7.2.1 и выше, 7.0.1 и выше.
(3) Выяснить, эксплуатировалась ли эта уязвимость на вашем устройстве. Для этого производитель советует провести аудит конфигураций и учётных записей. Особенно полезно посмотреть, появлялся ли в логах вашего устройства “
User=Local_Process_Access”, а также проверить существование аккаунта 'fortigate-tech-support' с правами супер-админа (он создаётся атакующими, см. скриншот). Ну и кстати, если в ваших устройствах от Fortinet не нашлась вышеописанная уязвимость, не спешите расслабляться – за последнее время в этих устройствах найдена куча других интересных уязвимостей, которые активно эксплуатируются злоумышленниками.
🔥10👍3
Метод обхода защитных средств под названием BYOVD (Bring your own vulnerable driver) заключается в использовании легитимного (но уязвимого) либо самописного драйвера с высокими привилегиями, который работает на уровне ядра ОС – что позволяет такому драйверу прерывать или подменять процессы, запущенные продуктами безопасности. Один из вариантов этой техники работает так:
– Атакующий находит легитимный драйвер, который при запуске создаёт в файловой системе файл с определенным именем (назовём его
– Этот драйвер должен загружаться в boot-сектор раньше, чем драйвер продукта защиты.
– Определяется путь к процессу драйвера защиты (назовём его
– В файловой системе создаётся символическая ссылка (symbolic link) с именем
– При перезагрузке ОС, когда загружается легитимный драйвер, он должен обратиться для записи на адрес
Как детектировать атаку?
Нужно отслеживать создание ссылок на любые компоненты продуктов защиты:
1) Собираем события создания жестких (hard) ссылок штатными средствами операционки: 4664(S): An attempt was made to create a hard link.
2) Создание символических ссылок не логируется системой, поэтому используем EDR-like телеметрию.
3) При сборе командных строк или событий создания процессов иногда можно отловить создание ссылок по аргументам: 'mklink', 'New-HardLink', 'New-SymLink', 'symboliclink', ...
– Атакующий находит легитимный драйвер, который при запуске создаёт в файловой системе файл с определенным именем (назовём его
<driver_filepath>).– Этот драйвер должен загружаться в boot-сектор раньше, чем драйвер продукта защиты.
– Определяется путь к процессу драйвера защиты (назовём его
<sectool_filepath>).– В файловой системе создаётся символическая ссылка (symbolic link) с именем
<driver_filepath>, которая ведёт на драйвер продукта защиты <sectool_filepath>.– При перезагрузке ОС, когда загружается легитимный драйвер, он должен обратиться для записи на адрес
<driver_filepath>; однако символическая ссылка переадресует все модификации на адрес <sectool_filepath>; таким образом, метод позволяет перезаписать и повредить файл защитного продукта.Как детектировать атаку?
Нужно отслеживать создание ссылок на любые компоненты продуктов защиты:
1) Собираем события создания жестких (hard) ссылок штатными средствами операционки: 4664(S): An attempt was made to create a hard link.
2) Создание символических ссылок не логируется системой, поэтому используем EDR-like телеметрию.
3) При сборе командных строк или событий создания процессов иногда можно отловить создание ссылок по аргументам: 'mklink', 'New-HardLink', 'New-SymLink', 'symboliclink', ...
👍20🆒5🤔4🤯2
Летом наши эксперты расследовали целый ряд атак, основанных на эксплуатации уязвимости CVE-2023-48788 в продуктах FortiClient EMS. Попробуем разобраться, как ловить подобные атаки по пост-активностям на хосте.
Суть атаки сводится к эксплуатации SQL-инъекции в контексте Microsoft SQL Server. Таким образом атакующий может применить любой удобный способ для выполнения команд ОС из запросов SQL, с последующей загрузкой своего вредоносного ПО. Одним из наиболее частых примеров является использование хранимой процедуры xp_cmdshell.
На что смотреть защитникам:
1) Включение xp_cmdshell. EventID 15457. Обязательно к включению. Везде.
2) Application лог MSSQL с EventID 15281 с фильтром на компонент xp_cmdshell. Там будут заблокированные попытки использования еще выключенного xp_cmdshell.
3) Смотреть в старты необычных процессов от MSSQL: cmd, powershell, lolbins, ... И конечно, поведение дочерних объектов, инициирующих внешние коммуникации. Такие активности на практике отлавливаются довольно часто, это могут быть:
3.1) дискавери (whoami, tasklist, net)
3.2) закрепление (schtasks)
3.3) дженерик-тактики с использованием cmd и powershell.
4) Ну и в целом, рекомендуем настроить ваши аудиты MSSQL на детектирование подозрительных активностей.
Суть атаки сводится к эксплуатации SQL-инъекции в контексте Microsoft SQL Server. Таким образом атакующий может применить любой удобный способ для выполнения команд ОС из запросов SQL, с последующей загрузкой своего вредоносного ПО. Одним из наиболее частых примеров является использование хранимой процедуры xp_cmdshell.
На что смотреть защитникам:
1) Включение xp_cmdshell. EventID 15457. Обязательно к включению. Везде.
2) Application лог MSSQL с EventID 15281 с фильтром на компонент xp_cmdshell. Там будут заблокированные попытки использования еще выключенного xp_cmdshell.
3) Смотреть в старты необычных процессов от MSSQL: cmd, powershell, lolbins, ... И конечно, поведение дочерних объектов, инициирующих внешние коммуникации. Такие активности на практике отлавливаются довольно часто, это могут быть:
3.1) дискавери (whoami, tasklist, net)
3.2) закрепление (schtasks)
3.3) дженерик-тактики с использованием cmd и powershell.
4) Ну и в целом, рекомендуем настроить ваши аудиты MSSQL на детектирование подозрительных активностей.
👍15🗿3❤1
В анализе безопасности мобильных и веб-приложений одной из первых задач является сбор информации об API-эндпоинтах и о формате HTTP-запросов для взаимодействия с ними.
В случае с веб-приложениями можно найти доступную OpenAPI-спецификацию или извлечь данные о запросах из JavaScript-файлов. Однако для мобильных приложений эта задача усложняется: HTTP-запросы могут формироваться из множества внутренних классов, а сам код часто бывает обфусцирован.
Наш эксперт Сергей Бобров написал на основе jadx-декомпилятора утилиту BFScan, которая помогает решать такие задачи при анализе JAR/WAR/APK приложений. Скачать эту тулзу можно здесь:
https://github.com/klsecservices/BFScan
Утилита BFScan формирует сырые HTTP-запросы и OpenAPI-спецификацию по конфиг-файлам и аннотациям классов и методов. При этом поддерживаются как клиентские библиотеки (например, Retrofit), используемые в APK для взаимодействия с бэкендом, так и серверные технологии, такие как Spring-аннотации. Это облегчает тестирование API в тех случаях, когда тело HTTP-запроса необходимо сформировать из множества вложенных классов.
Дополнительно BFScan анализирует строковые константы в Java-классах и ресурсах приложения для поиска строк, похожих на URL, пути или захардкоженные секреты.
Пример работы утилиты с классом, использующим Spring-аннотации:
В результате утилита формирует такой запрос:
Утилиту BFScan удобно использовать как для анализа клиентских мобильных приложений, так и в случае, если вы получили скомпилированный JAR/WAR от серверного приложения, для поиска в нём захардкоженных секретов или дальнейшего анализа API-эндпоинтов, которые обрабатываются в приложении.
А если приложение обфусцировано, то используя jadx, можно легко сформировать mapping-файлы для переименования обфусцированных классов и корректного формирования HTTP-запросов.
В случае с веб-приложениями можно найти доступную OpenAPI-спецификацию или извлечь данные о запросах из JavaScript-файлов. Однако для мобильных приложений эта задача усложняется: HTTP-запросы могут формироваться из множества внутренних классов, а сам код часто бывает обфусцирован.
Наш эксперт Сергей Бобров написал на основе jadx-декомпилятора утилиту BFScan, которая помогает решать такие задачи при анализе JAR/WAR/APK приложений. Скачать эту тулзу можно здесь:
https://github.com/klsecservices/BFScan
Утилита BFScan формирует сырые HTTP-запросы и OpenAPI-спецификацию по конфиг-файлам и аннотациям классов и методов. При этом поддерживаются как клиентские библиотеки (например, Retrofit), используемые в APK для взаимодействия с бэкендом, так и серверные технологии, такие как Spring-аннотации. Это облегчает тестирование API в тех случаях, когда тело HTTP-запроса необходимо сформировать из множества вложенных классов.
Дополнительно BFScan анализирует строковые константы в Java-классах и ресурсах приложения для поиска строк, похожих на URL, пути или захардкоженные секреты.
Пример работы утилиты с классом, использующим Spring-аннотации:
@RestController
@RequestMapping("/api")
public class UserController {
@PostMapping("createUser")
public String create(@RequestParam Optional<String> someParamName, @RequestBody User user) {
return "response";
}
В результате утилита формирует такой запрос:
POST /api/createUser?someParamName=value HTTP/1.1
Host: localhost
Connection: close
Content-Type: application/json
{
"name": "name",
"age": 1
}
Утилиту BFScan удобно использовать как для анализа клиентских мобильных приложений, так и в случае, если вы получили скомпилированный JAR/WAR от серверного приложения, для поиска в нём захардкоженных секретов или дальнейшего анализа API-эндпоинтов, которые обрабатываются в приложении.
А если приложение обфусцировано, то используя jadx, можно легко сформировать mapping-файлы для переименования обфусцированных классов и корректного формирования HTTP-запросов.
🔥24👏5👍2🤔1
В прошлом году в популярной программе для виртуализации Parallels Desktop для Mac OS на базе процессоров Intel была найдена уязвимость CVE-2024-34331, позволяющая запускать вредоносные файлы с высокими привилегиями.
Уязвимость связана с отсутствием проверки подписи в ходе выполнения сценария
Компания-производитель несколько раз патчила эту дыру, но потом оказывалось, что исправления можно обойти – и снова эксплуатировать. И не исключено, что в вашем софте от Parallels такая возможность до сих пор есть.
Подробности о том, в чём состоит уязвимость CVE-2024-34331 и почему её не смогли исправить сразу – читайте в новой статье Дмитрия Лифанова. А мы здесь процитируем только выводы: как ловить такую атаку в вашей инфраструктуре? Нужно отслеживать:
– Попытки открытия файлов через консоль с использованием Parallels Desktop. Команда может выглядеть, например, так: “
– Создание символьных ссылок на объекты, расположенные в пользовательских каталогах и tmp-каталогах.
– Действия над файлами
– Активности, связанные с использованием переменных DYLD_* с целью загрузки подозрительных динамических библиотек. В частности, DYLD_INSERT_LIBRARIES позволяет произвести загрузку динамической библиотеки в процессе выполнения приложения, а DYLD_LIBRARY_PATH позволяет переопределить путь поиска динамических библиотек.
– Загрузку подозрительных динамических библиотек в процесс, например, с использованием события ESF ES_EVENT_TYPE_NOTIFY_MMAP.
– Создание директорий и файлов в них, содержащих в пути .app, похожих на приложение и его контент, но расположенных в нетиповых локациях для приложений и пакетов.
Уязвимость связана с отсутствием проверки подписи в ходе выполнения сценария
repack_osx_install_app.sh. Это даёт возможность атакующему запустить утилиту createinstallmedia с правами root без проверки принадлежности файла к дистрибутиву macOS.Компания-производитель несколько раз патчила эту дыру, но потом оказывалось, что исправления можно обойти – и снова эксплуатировать. И не исключено, что в вашем софте от Parallels такая возможность до сих пор есть.
Подробности о том, в чём состоит уязвимость CVE-2024-34331 и почему её не смогли исправить сразу – читайте в новой статье Дмитрия Лифанова. А мы здесь процитируем только выводы: как ловить такую атаку в вашей инфраструктуре? Нужно отслеживать:
– Попытки открытия файлов через консоль с использованием Parallels Desktop. Команда может выглядеть, например, так: “
open /tmp/proof.app -a /Applications/Parallels Desktop.app”. Таким способом атакующий может вызвать сценарии переупаковки, не дожидаясь легитимного запуска от пользователя.– Создание символьных ссылок на объекты, расположенные в пользовательских каталогах и tmp-каталогах.
– Действия над файлами
createinstallmedia, boot.efi, systemversion.plist, platfromsupport.plist и basesystem.dmg, которые не связаны с дистрибутивом macOS Install OS X и самой системой.– Активности, связанные с использованием переменных DYLD_* с целью загрузки подозрительных динамических библиотек. В частности, DYLD_INSERT_LIBRARIES позволяет произвести загрузку динамической библиотеки в процессе выполнения приложения, а DYLD_LIBRARY_PATH позволяет переопределить путь поиска динамических библиотек.
– Загрузку подозрительных динамических библиотек в процесс, например, с использованием события ESF ES_EVENT_TYPE_NOTIFY_MMAP.
– Создание директорий и файлов в них, содержащих в пути .app, похожих на приложение и его контент, но расположенных в нетиповых локациях для приложений и пакетов.
🔥12👍5🆒3
Традиционный недостаток котиков в нашей ленте мы традиционно компенсируем выпуском годовых аналитических отчётов наших команд, которые занимаются мониторингом (MDR) и реагированием на инциденты (IR).
Мы понимаем, что все вы давно ждёте от нас этих весёлых картинок, а вовсе не сухой статистики по типам инцидентов, популярным техникам атак и методам защиты от них. Поэтому – вот вам драконы, русалки и прочие страшные твари с рогами и когтями. И конечно, смелые парни на боевых конях, которые с этими тварями борются:
IR Report 2024 // MDR Report 2024
А кто хочет послушать комментарии наших экспертов по этой аналитике или даже задать им каверзные вопросы – приходите на вебинар 3 апреля в 11:00 МСК:
https://www.kaspersky.ru/go/ru-mdr-report-2024
Мы понимаем, что все вы давно ждёте от нас этих весёлых картинок, а вовсе не сухой статистики по типам инцидентов, популярным техникам атак и методам защиты от них. Поэтому – вот вам драконы, русалки и прочие страшные твари с рогами и когтями. И конечно, смелые парни на боевых конях, которые с этими тварями борются:
IR Report 2024 // MDR Report 2024
А кто хочет послушать комментарии наших экспертов по этой аналитике или даже задать им каверзные вопросы – приходите на вебинар 3 апреля в 11:00 МСК:
https://www.kaspersky.ru/go/ru-mdr-report-2024
👍15😁5❤4🤔1
В одном из прошлых постов мы рассказывали, что с помощью интерфейса MS-NRPC можно без авторизации производить перебор доменных пользователей, если уже получен сетевой доступ к контроллеру домена. И делается это гораздо менее заметно, чем при использовании преаутентификации в Kerberos: атака через MS-NRPC не оставляет какого-либо специального типа событий в журнале безопасности Windows.
А теперь представляем вашему вниманию вторую часть исследования безопасности интерфейсов MS-NRPC. В этом материале наш эксперт Хайдар Кабибо объясняет, почему Windows допускает такие небезопасные действия, и как детектировать подобные атаки. В частности:
– Групповая политика "Restrict Unauthenticated RPC Clients" в теории могла бы быть использована для контроля таких активностей. Но на практике, даже при установке этой политики в режим "Authenticated" атакующие всё равно могут использовать небезопасные функции MS-NRPC-интерфейса. В случае выбора режима "Authenticated without exceptions" сбор данных о домене без авторизации будет заблокирован – но такая политика одновременно вырубает некоторые функции доменного контроллера.
– Детектировать сбор данных о домене можно с использованием системы Event Tracing for Windows, которая логирует события, связанные с RPC. Однако такой способ даёт большой поток событий по RPC-активностям, и среди них трудно выловить нужные.
– Для детектирования атаки можно применить инструмент с открытым кодом RPC-Firewall. Эта тулза мониторит все удаленные RPC-вызовы, позволяя фильтровать их по адресу источника, и при необходимости блокировать (см. скриншот). Правда, это сторонний инструмент.
Остальные подробности анализа безопасности MS-RPC-интерфейсов – в полной версии исследования Хайдара.
А теперь представляем вашему вниманию вторую часть исследования безопасности интерфейсов MS-NRPC. В этом материале наш эксперт Хайдар Кабибо объясняет, почему Windows допускает такие небезопасные действия, и как детектировать подобные атаки. В частности:
– Групповая политика "Restrict Unauthenticated RPC Clients" в теории могла бы быть использована для контроля таких активностей. Но на практике, даже при установке этой политики в режим "Authenticated" атакующие всё равно могут использовать небезопасные функции MS-NRPC-интерфейса. В случае выбора режима "Authenticated without exceptions" сбор данных о домене без авторизации будет заблокирован – но такая политика одновременно вырубает некоторые функции доменного контроллера.
– Детектировать сбор данных о домене можно с использованием системы Event Tracing for Windows, которая логирует события, связанные с RPC. Однако такой способ даёт большой поток событий по RPC-активностям, и среди них трудно выловить нужные.
– Для детектирования атаки можно применить инструмент с открытым кодом RPC-Firewall. Эта тулза мониторит все удаленные RPC-вызовы, позволяя фильтровать их по адресу источника, и при необходимости блокировать (см. скриншот). Правда, это сторонний инструмент.
Остальные подробности анализа безопасности MS-RPC-интерфейсов – в полной версии исследования Хайдара.
👍12🔥7🤷♂1👾1