(QR) Кодирование моего выхода отсюда: C2 в среде изоляции браузера
  • Изоляция браузера - это технология обеспечения безопасности, при которой просмотр веб-страниц осуществляется отдельно от локального устройства пользователя путем запуска браузера в защищенной среде, такой как облачный сервер или виртуальная машина, а затем потоковой передачи визуального контента на устройство пользователя.
  • Изоляция браузера часто используется организациями для борьбы с фишинговыми угрозами, защиты устройства от атак с использованием браузера и предотвращения использования злоумышленниками типичных тактик управления (C2 или C&C).
  • В этом сообщении в блоге APT0 демонстрирует новую технологию, которая может быть использована для обхода всех трех существующих типов изоляции браузера (удаленной, локальной и локальной) с целью управления вредоносным ПО через C2. APT0 показывает, как злоумышленники могут использовать машиночитаемые QR-коды для отправки команд с веб-сайта. сервер, контролируемый злоумышленником, подключается к устройству-жертве.
Если вы знакомы с технологией, листайте дальше
Общие сведения об изоляции браузера
Ранее в этом году замечательные специалисты из SpecterOps опубликовали сообщение в блоге, посвященное изоляции браузера и тому, как тестировщики на проникновение и операторы red team могут работать со сценариями изоляции браузера для передачи инструментов входа, данных выхода и общих методов обхода. Таким образом, изоляция браузера защищает пользователей от веб-атак, помещая веб-браузер в изолированную среду (локальную или удаленную) и передавая визуальный контент обратно в локальный браузер пользователя. В идеале работа с браузером полностью прозрачна для конечного пользователя. Согласно большинству документов, существует три типа изоляции браузера:

  1. Удаленная изоляция браузера (RBI), наиболее безопасный и распространенный вариант, изолирует браузер в облачной среде.
  2. Локальная изоляция браузера аналогична RBI, но при этом локально запускается изолированный браузер. Преимущество этого подхода заключается в том, что к локальным веб-приложениям можно получить доступ, не требуя сложного подключения из облака в локальную сеть.
  3. Локальная изоляция браузера, или изоляция браузера на стороне клиента, запускает изолированный браузер в локальной контейнерной среде или среде виртуальной машины (например, Docker или Windows Sandbox).

Удаленный браузер обрабатывает все, от отображения страницы до выполнения JavaScript. Локальному браузеру пользователя передается только визуальный вид веб-страницы (поток пикселей). Нажатия клавиш и щелчки в локальном браузере перенаправляются в удаленный браузер, позволяя пользователю взаимодействовать с веб-приложением. Организации часто используют прокси-серверы для обеспечения того, чтобы весь веб-трафик обрабатывался с помощью технологии изоляции браузера, тем самым ограничивая исходящий сетевой трафик и возможности злоумышленника обойти изоляцию браузера.
В SpecterOps подробно описаны некоторые проблемы, с которыми сталкиваются специалисты по кибербезопасности при работе в условиях изоляции браузера. Они описывают возможные подходы к обходу изоляции браузера путем неправильных настроек, таких как использование HTTP-заголовков, файлов cookie или параметров аутентификации для обхода функций изоляции.
До недавнего времени, утверждение было верно
Изоляция браузера предотвращает обычный процесс управления
Управление (C2 или C&C) - это способность злоумышленника удаленно управлять скомпрометированными системами с помощью вредоносных имплантатов. Наиболее распространенным каналом для отправки команд на устройство-жертву и с него являются HTTP-запросы:

  1. Имплантат запрашивает команду у сервера C2, контролируемого злоумышленником, посредством HTTP-запроса (например, в параметрах HTTP, заголовках или теле запроса).
  2. Сервер C2 возвращает команду для выполнения в HTTP-ответе (например, в заголовках или теле ответа).
  3. Имплантат расшифровывает HTTP-ответ и выполняет команду.
  4. Имплантат отправляет вывод команды обратно на сервер C2 с другим HTTP-запросом.
  5. Имплантат некоторое время “спит”, затем цикл повторяется.

Однако этот подход создает проблемы при использовании изоляции браузера — при выполнении HTTP-запросов через систему изоляции браузера HTTP-ответ, возвращаемый локальному браузеру, содержит только механизм потоковой передачи для визуализации содержимого страницы удаленного браузера. Исходный HTTP-ответ (от веб-сервера) доступен только в удаленном браузере. HTTP-ответ отображается в удаленном браузере, а в локальный браузер отправляется только поток пикселей для визуального отображения веб-страницы. Это предотвращает типичный C2 на основе HTTP, поскольку локальное устройство не может декодировать HTTP-ответ (шаг 3).
Рисунок 1: Схема последовательности выполнения HTTP-запроса в изоляции браузера в течение жизненного цикла
В этом сообщении в блоге мы рассмотрим другой подход к достижению C2 с помощью скомпрометированных систем в среде изоляции браузера, полностью работающий в контексте изоляции браузера.
Самое интересное начинается
Отправка данных C2 через пиксели
Вместо того, чтобы возвращать данные C2 в заголовках или теле HTTP-запроса, сервер C2 возвращает действительную веб-страницу, на которой визуально отображается QR-код. Затем имплантат использует локальный автономный браузер (например, Selenium) для отображения страницы, делает снимок экрана и считывает QR-код для извлечения встроенных данных. Используя преимущества машиночитаемых QR-кодов, злоумышленник может отправлять данные с сервера, контролируемого злоумышленником, на вредоносный имплантат, даже если веб-страница отображается в удаленном браузере.
Рисунок 2: Схема последовательности C2 с помощью QR-кодов
Вместо того, чтобы расшифровывать HTTP-ответ для выполнения команды, имплантат визуально отображает веб-страницу (с помощью движка pixel streaming в браузере isolation) и расшифровывает команду по QR-коду, отображаемому на странице. Новый цикл C2 выглядит следующим образом:
Имплантат управляет локальным автономным браузером по протоколу DevTools.
Имплантат получает веб-страницу с сервера C2 через автономный браузер. Этот запрос перенаправляется удаленному (изолированному) браузеру и в конечном итоге попадает на сервер C2.
Сервер C2 возвращает действительную веб-страницу в формате HTML с данными команды, закодированными в QR-коде (визуально отображаемом на странице).
Удаленный браузер возвращает механизм потоковой передачи пикселей обратно в локальный браузер, запуская визуальный поток, показывающий отрисованную веб-страницу, полученную с сервера C2.
Имплантат ожидает полного отображения страницы, затем делает снимок экрана локального браузера. Этот снимок экрана содержит QR-код.
Имплантат использует встроенную библиотеку сканирования QR-кодов для считывания данных QR-кода со снимка экрана, тем самым получая встроенные данные.
Имплантат выполняет команду на скомпрометированном устройстве.
Имплантат (опять же через локальный браузер) переходит на новый URL-адрес, который содержит вывод команды, закодированный в параметре URL. Этот параметр передается удаленному браузеру и, в конечном счете, серверу C2 (в конце концов, в допустимых случаях параметры URL могут потребоваться для возврата правильной веб-страницы).Сервер C2 может декодировать вывод команды, как и в традиционном C2 на основе HTTP.
Имплантат некоторое время “спит”, затем цикл повторяется.
Компания Mandiant разработала экспериментальный имплантат (PoC), используя Puppeteer и браузер Google Chrome в автономном режиме (хотя можно использовать любой современный браузер). Мы даже пошли еще дальше и интегрировали имплантат с внешней функцией C2 Cobalt Strike, что позволило использовать имплантат Cobalt Strike BEACON для обмена данными с помощью HTTP-запросов и ответов с помощью QR-кода.
This website has compromised your session tokens
I like to take risks