D2
Администратор
- Регистрация
- 19 Фев 2025
- Сообщения
- 4,380
- Реакции
- 0
Продолжая наше последнее исследование, мы продолжили изучение поверхности атаки решения EDR, находящегося под нашим пристальным вниманием, STRANGETRINITY. В прошлый раз мы сосредоточились на выявлении исключений в конфигурации EDR, которые позволяли нам выполнять действия, которые в противном случае были бы невозможны. На этот раз наше внимание будет сосредоточено на канале связи между агентом EDR и его тенантом.
Для тех, кто не знаком с общей архитектурой EDR, в большинстве случаев агентам, которые будут развернуты в системах, в конечном итоге потребуется взаимодействовать с централизованным тенантом. Обычно это делается потому, что агентам EDR необходимо:
- Получить политики от централизованного клиента и примените новые политики.
- Отправить телеметрию обратно в центральный экземпляр
Как вы можете себе представить, этот компонент особенно важен, и любое вмешательство потенциально может иметь разрушительные последствия. Как и в прошлый раз, мы начнем с формулировки гипотезы, которая будет проверена на протяжении всей статьи.
В данном случае, как было объявлено в этом разделе, наша гипотеза заключалась в следующем:
Сможет ли злоумышленник, находящийся в выгодном положении в сети, перехватить и искажать связь клиент-сервер EDR? И если да, то какой вред это может причинить?
Уязвимость
В общем, чтобы перехватить и подделать сетевую связь от одного хоста к другому, должно быть выполнено одно из следующих условий:
- Вы находитесь в той же локальной подсети, что и хост-жертва, и вы также можете использовать уязвимости в соединении TLS для перехвата зашифрованного трафика. Это был менее вероятный сценарий, поскольку мы редко (если вообще когда-либо) оказываемся в подобной ситуации.
- У вас есть точка опоры на хосте-жертве. Вероятно, для этого потребуются административные привилегии, чтобы либо изменить конфигурацию сети, либо каким-либо образом перенаправить трафик привилегированных процессов (в данном случае EDR).
Поскольку второй сценарий является наиболее реалистичным, мы предположили, что мы получили административный доступ к хосту и каким-то образом хотим:
- Вмешаться в решение, чтобы выполнить наши вредоносные инструкции.
- Препятствовать функционированию EDR и не давать ему делать то, что он должен делать.
Выполнение команд всегда интересно, однако мы также знали, что граница между административным доступом и снятием с охраны EDR также весьма актуальна, поскольку поставщики, похоже, обеспокоены тем, что пользователи с правами администратора могут удалить свое программное обеспечение без одобрения централизованного арендатора. Эта цель показалась нам более достижимой с учетом времени, которое мы выделили на этот исследовательский спринт, и наш прошлый опыт работы с этим поставщиком показал, что ошибка в этом компоненте потенциально может принести нам приличную выплату.
Для читателей, которые не знакомы с этими концепциями, EDR, в конце концов, представляют собой такое же программное обеспечение, как и многие другие. Это означает, что их нужно как-то установить и в какой-то момент удалить. Раньше можно было удалить EDR с хоста с помощью тех же команд, которые вы использовали бы для удаления любого другого типа установленной программы. Доказательством того, что это возможно, является опубликованный некоторое время назад атомный тест по удалению CrowdStrike - https://atomicredteam.io/defense-ev...-21---uninstall-crowdstrike-falcon-on-windows. Прошло совсем немного времени, прежде чем злоумышленники поняли, что это действительно так, и внедрили это в свой арсенал. Более того, появился целый класс атак, направленных на прекращение работы защитных продуктов, и в настоящее время для достижения этой цели довольно часто используется множество стратегий: от ненужных BAT-скриптов до эксплуатации уязвимых драйверов. С другой стороны, поставщики начали внедрять класс функций, обычно называемый «защитой от несанкционированного доступа», чтобы не допустить, чтобы любая несанкционированная программа остановила запуск защитного программного обеспечения. Часть этих знаний MITRE воплотила в проекте ATT&CK: Ослабление защиты: отключение или изменение инструментов, подметодика T1562.001. Эта граница казалась глупой многим людям в ИТ, и за время нашей работы в качестве консультантов нам неоднократно говорили: «Это невозможный сценарий, мы не предоставляем административный доступ нашим пользователям». Несмотря на то, что это справедливое заявление, доказательства снова важнее, чем убеждения и предубеждения, поскольку существует бесчисленное количество отчетов об угрозах, в которых документировано, как злоумышленники могут использовать действительные учетные данные, использовать ресурсы с выходом в Интернет и многое другое, чтобы оказаться в таком положении; это, даже не считая того, что в большинстве организаций было тривиально повысить привилегии путем злоупотребления функциями Active Directory, это, как правило, очень веский контраргумент, который вряд ли можно оспорить. Весь этот абзац, по сути, должен был подтвердить идею о том, что эта граница считается важной, и это справедливо.
Вообще, чтобы изменить конфигурацию чего-либо, нужно сначала уметь это прочитать (или в худшем случае эмпирически определить изменения, взаимодействуя с конкретным компонентом). В оставшейся части этого раздела будет описано, как была извлечена конфигурация нашего EDR.
Извлечение конфигурации
Техническая деятельность началась с тщательного изучения поверхности атаки, открытой для продукта, с первоначального анализа, были ли зарегистрированы какие-либо COM-серверы. К счастью для нас, предположение подтвердилось, и EDR создает экземпляры двух COM-классов, которые мы назовем COMTRINITY_A и COMTRINITY_B.
После тщательного изучения классов были проанализированы предоставляемые ими методы с целью обнаружения наличия какой-либо функциональности, которую можно было бы использовать в наших интересах. К сожалению, многие методы оказались непригодными для использования из-за ограничений, примененных на уровне ACL, позволяющих использовать их только учетной записью виртуального сервиса, принадлежащей решению NT SERVICE\\STRANGETRINITYService.
Однако нам удалось найти исключение, и конкретный метод, который мы будем вызывать, StrangeTrinityAgentStatus()был доступен каждому пользователю из группы «Администраторы».
Вызов метода возвращает состояние агента, включенные функции безопасности и URL-адрес удаленного клиента.
Ниже приведен пример содержимого:
Как можно видеть из приведенного выше фрагмента, присутствовало поле с названием «анти-тамперинг». Это укрепило нашу гипотезу о том, что настройку можно каким-то образом настроить. Более того, поскольку это была исследовательская работа, а не тест «черного ящика», для проверки этого был использован клиент облака EDR.
Очень краткое исследование веб-функций EDR показало, что действительно можно отключить функции защиты от несанкционированного доступа с облачной консоли. Следующим шагом, который мы сделали, был перехват связи от агента EDR с арендатором, попытка перепроектировать протокол связи и, в конечном итоге, попытка вручную активировать функцию защиты от несанкционированного доступа.
Перехват трафика
К счастью для нас, связь от агента к тенанту осуществлялась по протоколу HTTPS, что позволило нам полагаться на очень хорошо зарекомендовавший себя набор инструментов для тестирования. Поскольку выяснилось, что трафик зашифрован обычным HTTPS (это было проверено с помощью Wireshark), наша идея заключалась в том, чтобы установить rogue CA на хост и выполнить проверку SSL и манипулирование трафиком. Это довольно распространенный метод, который предприятия постоянно используют для мониторинга трафика в своей сети. Большинство поставщиков полагаются на установку доверенного центра сертификации на конечных точках пользователя, чтобы обеспечить перехват SSL. Для простоты атака была осуществлена с использованием перехватывающего прокси, такого как BurpSuite или Zed Attack Proxy, понятно, что нет необходимости подчеркивать, что все это можно легко использовать в качестве оружия без установки дополнительного программного обеспечения.
Шаги, которые мы предприняли для настройки, были следующими:
1. Добавьте новую запись в файл хостов, разрешая DNS-запись тенанта управления в адрес локального хоста.
2. Запустите прокси на порту 443, включив невидимое проксирование.
3. Дождитесь регистрации агента
Более подробное объяснение того, как настроить Burp (программное обеспечение, которое мы на самом деле использовали) для этого конкретного сценария можно найти здесь: https://portswigger.net/burp/documentation/desktop/tools/proxy/invisible . Использование невидимого прокси было необходимо, поскольку агент EDR не знал о прокси-сервере.
Через несколько секунд агент зарегистрировался и отправил несколько HTTP-запросов арендатору управления через REST API.
Используемый механизм связи представлял собой типичную архитектуру опроса клиент-сервер, в которой датчик EDR перезванивал через регулярные промежутки времени, чтобы запросить обновления у арендатора и в то же время отправлять периодические телеметрические данные, что неудивительно похоже на систему управления и контроля корпоративного уровня.
В ответ он получил еще один JSON, содержащий список дополнительных настроек и конфигураций.
Теперь осталось только подделать запрос и вручную изменить настройки параметров через прокси, установив в anti-tampering поле значение false.
Как уже упоминалось, функция защиты от несанкционированного доступа обычно включает меры по защите программного обеспечения EDR и его компонентов от несанкционированных модификаций. Это может включать в себя такие методы, как проверки целостности кода, защита на уровне PPL, шифрование конфиденциальных данных и средства контроля для предотвращения несанкционированных изменений настроек конфигурации. Цель функции защиты от несанкционированного доступа — гарантировать, что решение EDR остается работоспособным и устойчивым к атакам, которые могут попытаться поставить под угрозу его функциональность.
На этом этапе конфигурация агента была получена еще раз, чтобы подтвердить, оказали ли наши действия какой-либо эффект. К нашему огромному удивлению, такое небольшое изменение фактически отключило функцию защиты от несанкционированного доступа, и это даже отразилось на конфигурации, полученной динамически.
В качестве заключительного теста мы создали высоконадежную командную строку, которая успешно остановила работу нескольких компонентов продукта. Мы также изменили ключи реестра, гарантируя, что при следующей перезагрузке решение будет полностью отменено. Для этого мы в основном полагались на sc.exe двоичный файл, используемый для остановки служб, и другие утилиты, используемые для приостановки запущенных процессов.
Доказательство концепции
Следующий код Powershell использовался для получения конфигурации агента:
В раскрытие также включен код для специального HTTP-прокси, однако, учитывая, что тот же эффект можно получить с помощью таких инструментов, как BurpSuite, публикация, которая не добавит никакой ценности этому исследованию.
Заключение
Как мы можем сделать вывод из анализа, связь между тенантом и агентом представляет собой ключевой аспект любого решения EDR. Такая связь не только позволяет собирать и передавать данные телеметрии от конечных точек в централизованное облако для дальнейшего анализа, но также обеспечивает быструю реализацию изменений конфигурации, которые необходимо каскадно распространить по всей среде.
С точки зрения злоумышленника, возможность перехватывать и произвольно изменять такие параметры, безусловно, может обеспечить тактические и оперативные преимущества. Это позволяет им получить достаточный временной интервал для выполнения действий после эксплуатации без срабатывания оповещений от решения и впоследствии быстро восстановить связь, вернув среду в нормальное состояние. Фактически, путем вмешательства в канал связи можно обнаружить различные ошибки. Из того, что можно было сделать вывод, разработка этого конкретного компонента не была должным образом смоделирована и не было проведено соответствующее тестирование.
При этом, как и в первой части этой серии статей, поставщик положительно отреагировал на раскрытие информации и применил исправления, чтобы выполнение той же атаки больше не было тривиальным.
Если вы обеспокоены тем, что с продуктами, которые вы используете, может возникнуть аналогичная проблема, рекомендуется повторить шаги, описанные в этом исследовании, и технически подтвердить это. Поставщикам следует внедрить более строгие меры контроля и проверки целостности, чтобы гарантировать, что полученные сообщения не были изменены при передаче.
Переведено специально для XSS.IS
Автор перевода: yashechka
Источник: https://riccardoancarani.github.io/2023-09-14-attacking-an-edr-part-2/
Для тех, кто не знаком с общей архитектурой EDR, в большинстве случаев агентам, которые будут развернуты в системах, в конечном итоге потребуется взаимодействовать с централизованным тенантом. Обычно это делается потому, что агентам EDR необходимо:
- Получить политики от централизованного клиента и примените новые политики.
- Отправить телеметрию обратно в центральный экземпляр
Как вы можете себе представить, этот компонент особенно важен, и любое вмешательство потенциально может иметь разрушительные последствия. Как и в прошлый раз, мы начнем с формулировки гипотезы, которая будет проверена на протяжении всей статьи.
В данном случае, как было объявлено в этом разделе, наша гипотеза заключалась в следующем:
Сможет ли злоумышленник, находящийся в выгодном положении в сети, перехватить и искажать связь клиент-сервер EDR? И если да, то какой вред это может причинить?
Уязвимость
В общем, чтобы перехватить и подделать сетевую связь от одного хоста к другому, должно быть выполнено одно из следующих условий:
- Вы находитесь в той же локальной подсети, что и хост-жертва, и вы также можете использовать уязвимости в соединении TLS для перехвата зашифрованного трафика. Это был менее вероятный сценарий, поскольку мы редко (если вообще когда-либо) оказываемся в подобной ситуации.
- У вас есть точка опоры на хосте-жертве. Вероятно, для этого потребуются административные привилегии, чтобы либо изменить конфигурацию сети, либо каким-либо образом перенаправить трафик привилегированных процессов (в данном случае EDR).
Поскольку второй сценарий является наиболее реалистичным, мы предположили, что мы получили административный доступ к хосту и каким-то образом хотим:
- Вмешаться в решение, чтобы выполнить наши вредоносные инструкции.
- Препятствовать функционированию EDR и не давать ему делать то, что он должен делать.
Выполнение команд всегда интересно, однако мы также знали, что граница между административным доступом и снятием с охраны EDR также весьма актуальна, поскольку поставщики, похоже, обеспокоены тем, что пользователи с правами администратора могут удалить свое программное обеспечение без одобрения централизованного арендатора. Эта цель показалась нам более достижимой с учетом времени, которое мы выделили на этот исследовательский спринт, и наш прошлый опыт работы с этим поставщиком показал, что ошибка в этом компоненте потенциально может принести нам приличную выплату.
Для читателей, которые не знакомы с этими концепциями, EDR, в конце концов, представляют собой такое же программное обеспечение, как и многие другие. Это означает, что их нужно как-то установить и в какой-то момент удалить. Раньше можно было удалить EDR с хоста с помощью тех же команд, которые вы использовали бы для удаления любого другого типа установленной программы. Доказательством того, что это возможно, является опубликованный некоторое время назад атомный тест по удалению CrowdStrike - https://atomicredteam.io/defense-ev...-21---uninstall-crowdstrike-falcon-on-windows. Прошло совсем немного времени, прежде чем злоумышленники поняли, что это действительно так, и внедрили это в свой арсенал. Более того, появился целый класс атак, направленных на прекращение работы защитных продуктов, и в настоящее время для достижения этой цели довольно часто используется множество стратегий: от ненужных BAT-скриптов до эксплуатации уязвимых драйверов. С другой стороны, поставщики начали внедрять класс функций, обычно называемый «защитой от несанкционированного доступа», чтобы не допустить, чтобы любая несанкционированная программа остановила запуск защитного программного обеспечения. Часть этих знаний MITRE воплотила в проекте ATT&CK: Ослабление защиты: отключение или изменение инструментов, подметодика T1562.001. Эта граница казалась глупой многим людям в ИТ, и за время нашей работы в качестве консультантов нам неоднократно говорили: «Это невозможный сценарий, мы не предоставляем административный доступ нашим пользователям». Несмотря на то, что это справедливое заявление, доказательства снова важнее, чем убеждения и предубеждения, поскольку существует бесчисленное количество отчетов об угрозах, в которых документировано, как злоумышленники могут использовать действительные учетные данные, использовать ресурсы с выходом в Интернет и многое другое, чтобы оказаться в таком положении; это, даже не считая того, что в большинстве организаций было тривиально повысить привилегии путем злоупотребления функциями Active Directory, это, как правило, очень веский контраргумент, который вряд ли можно оспорить. Весь этот абзац, по сути, должен был подтвердить идею о том, что эта граница считается важной, и это справедливо.
Вообще, чтобы изменить конфигурацию чего-либо, нужно сначала уметь это прочитать (или в худшем случае эмпирически определить изменения, взаимодействуя с конкретным компонентом). В оставшейся части этого раздела будет описано, как была извлечена конфигурация нашего EDR.
Извлечение конфигурации
Техническая деятельность началась с тщательного изучения поверхности атаки, открытой для продукта, с первоначального анализа, были ли зарегистрированы какие-либо COM-серверы. К счастью для нас, предположение подтвердилось, и EDR создает экземпляры двух COM-классов, которые мы назовем COMTRINITY_A и COMTRINITY_B.
После тщательного изучения классов были проанализированы предоставляемые ими методы с целью обнаружения наличия какой-либо функциональности, которую можно было бы использовать в наших интересах. К сожалению, многие методы оказались непригодными для использования из-за ограничений, примененных на уровне ACL, позволяющих использовать их только учетной записью виртуального сервиса, принадлежащей решению NT SERVICE\\STRANGETRINITYService.
Однако нам удалось найти исключение, и конкретный метод, который мы будем вызывать, StrangeTrinityAgentStatus()был доступен каждому пользователю из группы «Администраторы».
Вызов метода возвращает состояние агента, включенные функции безопасности и URL-адрес удаленного клиента.
Ниже приведен пример содержимого:
Как можно видеть из приведенного выше фрагмента, присутствовало поле с названием «анти-тамперинг». Это укрепило нашу гипотезу о том, что настройку можно каким-то образом настроить. Более того, поскольку это была исследовательская работа, а не тест «черного ящика», для проверки этого был использован клиент облака EDR.
Очень краткое исследование веб-функций EDR показало, что действительно можно отключить функции защиты от несанкционированного доступа с облачной консоли. Следующим шагом, который мы сделали, был перехват связи от агента EDR с арендатором, попытка перепроектировать протокол связи и, в конечном итоге, попытка вручную активировать функцию защиты от несанкционированного доступа.
Перехват трафика
К счастью для нас, связь от агента к тенанту осуществлялась по протоколу HTTPS, что позволило нам полагаться на очень хорошо зарекомендовавший себя набор инструментов для тестирования. Поскольку выяснилось, что трафик зашифрован обычным HTTPS (это было проверено с помощью Wireshark), наша идея заключалась в том, чтобы установить rogue CA на хост и выполнить проверку SSL и манипулирование трафиком. Это довольно распространенный метод, который предприятия постоянно используют для мониторинга трафика в своей сети. Большинство поставщиков полагаются на установку доверенного центра сертификации на конечных точках пользователя, чтобы обеспечить перехват SSL. Для простоты атака была осуществлена с использованием перехватывающего прокси, такого как BurpSuite или Zed Attack Proxy, понятно, что нет необходимости подчеркивать, что все это можно легко использовать в качестве оружия без установки дополнительного программного обеспечения.
Шаги, которые мы предприняли для настройки, были следующими:
1. Добавьте новую запись в файл хостов, разрешая DNS-запись тенанта управления в адрес локального хоста.
2. Запустите прокси на порту 443, включив невидимое проксирование.
3. Дождитесь регистрации агента
Более подробное объяснение того, как настроить Burp (программное обеспечение, которое мы на самом деле использовали) для этого конкретного сценария можно найти здесь: https://portswigger.net/burp/documentation/desktop/tools/proxy/invisible . Использование невидимого прокси было необходимо, поскольку агент EDR не знал о прокси-сервере.
Через несколько секунд агент зарегистрировался и отправил несколько HTTP-запросов арендатору управления через REST API.
Используемый механизм связи представлял собой типичную архитектуру опроса клиент-сервер, в которой датчик EDR перезванивал через регулярные промежутки времени, чтобы запросить обновления у арендатора и в то же время отправлять периодические телеметрические данные, что неудивительно похоже на систему управления и контроля корпоративного уровня.
В ответ он получил еще один JSON, содержащий список дополнительных настроек и конфигураций.
Теперь осталось только подделать запрос и вручную изменить настройки параметров через прокси, установив в anti-tampering поле значение false.
Как уже упоминалось, функция защиты от несанкционированного доступа обычно включает меры по защите программного обеспечения EDR и его компонентов от несанкционированных модификаций. Это может включать в себя такие методы, как проверки целостности кода, защита на уровне PPL, шифрование конфиденциальных данных и средства контроля для предотвращения несанкционированных изменений настроек конфигурации. Цель функции защиты от несанкционированного доступа — гарантировать, что решение EDR остается работоспособным и устойчивым к атакам, которые могут попытаться поставить под угрозу его функциональность.
На этом этапе конфигурация агента была получена еще раз, чтобы подтвердить, оказали ли наши действия какой-либо эффект. К нашему огромному удивлению, такое небольшое изменение фактически отключило функцию защиты от несанкционированного доступа, и это даже отразилось на конфигурации, полученной динамически.
В качестве заключительного теста мы создали высоконадежную командную строку, которая успешно остановила работу нескольких компонентов продукта. Мы также изменили ключи реестра, гарантируя, что при следующей перезагрузке решение будет полностью отменено. Для этого мы в основном полагались на sc.exe двоичный файл, используемый для остановки служб, и другие утилиты, используемые для приостановки запущенных процессов.
Доказательство концепции
Следующий код Powershell использовался для получения конфигурации агента:
В раскрытие также включен код для специального HTTP-прокси, однако, учитывая, что тот же эффект можно получить с помощью таких инструментов, как BurpSuite, публикация, которая не добавит никакой ценности этому исследованию.
Заключение
Как мы можем сделать вывод из анализа, связь между тенантом и агентом представляет собой ключевой аспект любого решения EDR. Такая связь не только позволяет собирать и передавать данные телеметрии от конечных точек в централизованное облако для дальнейшего анализа, но также обеспечивает быструю реализацию изменений конфигурации, которые необходимо каскадно распространить по всей среде.
С точки зрения злоумышленника, возможность перехватывать и произвольно изменять такие параметры, безусловно, может обеспечить тактические и оперативные преимущества. Это позволяет им получить достаточный временной интервал для выполнения действий после эксплуатации без срабатывания оповещений от решения и впоследствии быстро восстановить связь, вернув среду в нормальное состояние. Фактически, путем вмешательства в канал связи можно обнаружить различные ошибки. Из того, что можно было сделать вывод, разработка этого конкретного компонента не была должным образом смоделирована и не было проведено соответствующее тестирование.
При этом, как и в первой части этой серии статей, поставщик положительно отреагировал на раскрытие информации и применил исправления, чтобы выполнение той же атаки больше не было тривиальным.
Если вы обеспокоены тем, что с продуктами, которые вы используете, может возникнуть аналогичная проблема, рекомендуется повторить шаги, описанные в этом исследовании, и технически подтвердить это. Поставщикам следует внедрить более строгие меры контроля и проверки целостности, чтобы гарантировать, что полученные сообщения не были изменены при передаче.
Переведено специально для XSS.IS
Автор перевода: yashechka
Источник: https://riccardoancarani.github.io/2023-09-14-attacking-an-edr-part-2/