|
https://forum.antichat.xyz/attachmen...352bd6d4ef.png
Когда меня дёргают на инцидент с формулировкой «пользователь жалуется на странное поведение браузера - редиректы, утечка сессий, несанкционированный доступ к корпоративным аккаунтам», первое, что я проверяю - не история посещений и не cookies. Я лезу в директорию расширений. Потому что именно аддоны оказываются причиной инцидента куда чаще, чем принято думать, а стандартные IR-плейбуки до сих пор обходят этот вектор стороной. Форензика браузерных расширений - дисциплина на стыке endpoint forensics и анализа веб-приложений. Расширение по сути - маленькое приложение с привилегированным доступом к браузерному контексту: DOM страниц, cookies, session tokens, буфер обмена. Если оно скомпрометировано - атакующий получает всё, что видит пользователь, и даже больше. Разберу конкретные артефакты, пути к файлам, инструменты и пошаговую методологию расследования инцидентов, связанных с вредоносными расширениями Chrome и Firefox. Почему расширения - слепая зона при расследовании инцидентов Большинство руководств по цифровой криминалистике браузеров крутятся вокруг классических артефактов: History, Cookies, Web Data, Cache. Расширения упоминаются вскользь - мол, «список установленных плагинов». Но расширение - это не статичный плагин. Это исполняемый код с собственным хранилищем, сетевыми соединениями и жизненным циклом. Масштаб проблемы хорошо иллюстрирует инцидент конца 2024 года: по данным Darktrace, атакующие скомпрометировали более 30 расширений Chrome, включая расширение компании Cyberhaven, затронув свыше 2,6 миллиона пользователей. Вредоносное обновление прилетело через штатный механизм автообновления Chrome - без какого-либо взаимодействия с пользователем. Параллельно, по анализу SecurityLab, всплыла кампания из 30 расширений с единой кодовой базой и общей инфраструктурой на домене Код:
tapnetic.proПри расследовании подобных инцидентов стандартный набор браузерных артефактов бесполезен - в истории посещений вы не увидите, что расширение в фоне сливает session cookies на C2-сервер. Нужен другой подход и другие артефакты. https://forum.antichat.xyz/attachmen...6705206101.png Карта артефактов расширений в Chrome Все данные Chrome на Windows лежат в Код:
%LocalAppData%\Google\Chrome\User Data\Default\Код:
~/.config/google-chrome/Default/Код:
~/Library/Application Support/Google/Chrome/Default/Manifest.json - паспорт каждого расширения Директория Код:
ExtensionsКод:
manifest.jsonНа что смотреть в manifest.json:
Файлы Код:
PreferencesКод:
Secure PreferencesКод:
extensions.settingsКод:
install_timeКод:
install_sourceКод:
granted_permissionsКод:
disable_reasonsЭто критически важный артефакт при анализе установленных расширений - он сохраняет информацию даже о расширениях, которые были отключены политикой или пользователем. Поле Код:
install_timeКод:
unix_ts = (int(install_time) - 11644473600000000) / 1000000Код:
Secure PreferencesLevelDB и Local Storage - данные расширений в хранилищах Расширения используют несколько хранилищ для оперативных данных. Код:
chrome.storage.localКод:
Local Extension Settings//Код:
chrome.storage.syncКод:
Sync Extension Settings//Код:
chrome.storage.managedКод:
Managed Extension Settings//Код:
chrome.storage.sessionКод:
localStorageКод:
Local Storage/leveldb/Код:
chrome-extension://LevelDB - key-value хранилище от Google, и его парсинг - одна из самых муторных задач в форензике расширений. Файлы Код:
.ldbКод:
.logКод:
plyvelКод:
leveldb-dumpКод:
.logИменно в Local Storage вредоносные расширения хранят конфигурацию C2-серверов, эксфильтрированные данные до отправки и промежуточные состояния. В кампании Cyberhaven, по данным Darktrace, расширение собирало session cookies и authentication tokens - эти данные транзитно проходили через локальное хранилище перед отправкой на Код:
cyberhavenext[.]proАртефакты браузерных аддонов в Firefox Firefox хранит данные расширений иначе. Профиль по умолчанию живёт в Код:
%AppData%\Roaming\Mozilla\Firefox\Profiles\.default-release\Ключевые файлы для анализа вредоносных расширений в Firefox:
MV2 против MV3: что меняется для анализа браузерных расширений Переход Chrome с Manifest V2 на Manifest V3 серьёзно влияет на то, какие артефакты остаются на диске. Для цифровой криминалистики браузера это различие - ключевое. MV2 (устаревший, но встречается на живых системах). Background page - полноценная HTML-страница с постоянным JavaScript-контекстом. Работает непрерывно, пока браузер открыт. Артефакты: файл background page в директории расширения, записи в Код:
chrome://extensions-internalsMV3 (текущий стандарт). Service worker заменяет background page. Он запускается по событию и завершается после 30 секунд бездействия. До Chrome 110 действовал жёсткий лимит в 5 минут с момента запуска SW, независимо от активности; с Chrome 110+ активные события (входящие сообщения, API-вызовы) сбрасывают idle-таймер, и SW может жить дольше. Через Код:
chrome.alarmsКод:
Service Worker/Практическое следствие: при MV3 вредоносное расширение сложнее поймать на горячем через анализ сетевых соединений. Зато в Код:
Service Worker/ScriptCache/Пошаговый анализ установленных расширений при инциденте Триаж за первые 15 минут При получении образа или доступе к живой машине первым делом снимаю снапшот расширений. Вот последовательность, которую я выполняю при каждом IR-кейсе, связанном с компрометацией через расширения браузера: Шаг 1. Копирую директорию профиля целиком с сохранением временных меток. На Windows: Код:
robocopy "%LocalAppData%\Google\Chrome\User Data" E:\evidence\chrome_profile /MIR /COPY:DAT /LOG:E:\evidence\copy.logКод:
/COPY:DATШаг 2. Вытаскиваю список расширений из Код:
PreferencesBash: Код:
catКод:
update_urlКод:
update_urlКод:
location != 1Код:
install_source != "webstore"Код:
PreferencesШаг 4. Проверяю Код:
permissionsКод:
cookiesКод:
webRequestКод:
Шаг 5. Фиксирую временные метки установки и последнего обновления, выстраиваю timeline. Глубокий анализ подозрительного расширения Когда триаж выявил подозрительное расширение, перехожу к полной декомпозиции. Открываю директорию расширения ( Код:
Extensions///Код:
js-beautifyВ кампании tapnetic.pro, описанной SecurityLab, ключевым индикатором был iframe, загружающий интерфейс с внешнего домена ( Код:
claude.tapnetic.proКод:
srcДальше - сетевые артефакты. На живой системе - Код:
chrome://net-exportКод:
chrome.exeКод:
cyberhavenext[.]proКод:
149.28.124[.]84Обнаружение вредоносных расширений Chrome и Firefox Для систематического обнаружения вредоносных расширений (а не только ручного ковыряния конкретного образца) есть несколько подходов. По данным Red Canary, использование фреймворка AssemblyLine в связке со статистическими методами - анализом энтропии и z-scores - позволяет автоматически детектировать подозрительные обновления расширений. В их эксперименте подход выявил 58% известных вредоносных расширений из выборки в 50 скомпрометированных образцов. Решение заточено на сокращение dwell time: поймать вредоносное обновление до того, как оно станет широко известным. Любопытная цифра от Red Canary: типичная корпоративная среда содержит порядка 30 расширений на пользователя, а в отдельных случаях - более 3000. Тридцать ещё можно проверить руками. Три тысячи - нет. Инвентаризация расширений через EDR - обязательный первый шаг. Маппинг на MITRE ATT&CK Вредоносное расширение покрывает сразу несколько тактик и техник MITRE ATT&CK, что делает его универсальным инструментом атакующего: ТактикаТехникаКак реализуется через расширениеPersistenceBrowser Extensions (T1176.001)Расширение переживает перезагрузку браузера и ОСCredential AccessSteal Web Session Cookie (T1539)Доступ к Код:
cookiesВ кейсе Cyberhaven цепочка выглядела так: T1176.001 (Browser Extensions) → T1539 (Steal Web Session Cookie) → T1185 (Browser Session Hijacking) → T1041 (Exfiltration Over C2 Channel - на Код:
cyberhavenext[.]prohttps://forum.antichat.xyz/attachmen...6707125369.png Кейс: компрометация Cyberhaven и массовые кампании через расширения Инцидент с Cyberhaven - эталонный пример supply chain атаки через расширения. 24 декабря 2024 года фишинговая атака скомпрометировала учётные данные сотрудника Cyberhaven, что позволило атакующим опубликовать вредоносную версию расширения. Момент выбран не случайно, рождественские каникулы - большинство сотрудников отсутствует. Вредоносная версия была активна 25–26 декабря. Механизм: расширение после обновления начинало скрытно собирать session cookies и authentication tokens, целясь в высокоценные аккаунты - Facebook Ads, AI-сервисы. По данным Darktrace, на стороне сети это выглядело как persistent beaconing на домен Код:
cyberhavenext[.]proКод:
cyberhaven[.]ioКод:
149.28.124[.]84Параллельно работала кампания вокруг Код:
tapnetic.proКод:
mail.google.comКод:
textContentКод:
fppbiomdkfbhgjjdmojlogeceejinadgКод:
gghdfkafnhfpaooiolhncejnlgglhkheСледы удалённых расширений: что остаётся после деинсталляции Один из самых частых вопросов на реальных расследованиях: «Расширение уже удалено, можно ли восстановить следы?» Короткий ответ - да, и нередко артефакты живут месяцами. При штатном удалении расширения через UI Chrome удаляет директорию из Код:
Extensions//
Код:
PreferencesКод:
disable_reasonsКлючевое различие: если пользователь сам удалил расширение - в Код:
PreferencesIncident response при компрометации через расширения браузера Когда компрометация подтверждена, IR-процесс для расширений имеет свою специфику. Containment. Немедленно блокируем расширение через групповую политику Chrome ( ). Если ID вредоносного расширения известен - в blocklist. Если подозрение на supply chain (легитимное расширение получило вредоносное обновление, как в кейсе Cyberhaven) - блокируем автообновление расширений до завершения расследования. На уровне сети - блокируем известные C2-домены и IP-адреса. Eradication. Удаляем расширение со всех endpoint через централизованное управление. Обязательно проверяем, не осталось ли persistence-механизмов вне браузера: некоторые расширения создают scheduled tasks или правят registry для автоматической переустановки. Recovery. Сбрасываем все сессии пользователей, чьи машины были скомпрометированы. Принудительная ротация паролей для сервисов, к которым расширение имело доступ. Если расширение имело permission Код:
cookiesLessons Learned. Внедряем инвентаризацию расширений через EDR. Настраиваем allowlist-политику: разрешить только проверенные расширения через Код:
ExtensionInstallAllowlistДля автоматизации анализа расширений в масштабе организации стоит посмотреть на Hindsight (есть на GitHub) - он парсит артефакты Chrome, включая данные расширений, и строит единый timeline. Для побитового анализа образов дисков - Autopsy с модулем Chrome Extensions. Вопрос к практикам В инфраструктуре с Chrome, управляемом через групповые политики, расширения контролируются через Код:
ExtensionInstallAllowlistКод:
ExtensionInstallBlocklistВопрос к читателям Коллеги, при разборе LevelDB-хранилищ расширений ( Код:
Local Extension Settings//Код:
plyvelКод:
plyvel.ErrorКод:
.logКод:
leveldb-dumpКод:
ldbКод:
leveldb-toolsКод:
chrome.storage.local |
| Время: 02:06 |