Когда меня дёргают на инцидент с формулировкой «пользователь жалуется на странное поведение браузера - редиректы, утечка сессий, несанкционированный доступ к корпоративным аккаунтам», первое, что я проверяю - не история посещений и не 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 расширений с единой кодовой базой и общей инфраструктурой на домене
, набравших суммарно более 260 000 установок. Часть этих расширений даже получила статус Featured в Chrome Web Store (ага, вот так и живём).
При расследовании подобных инцидентов стандартный набор браузерных артефактов бесполезен - в истории посещений вы не увидите, что расширение в фоне сливает session cookies на C2-сервер. Нужен другой подход и другие артефакты.
Карта артефактов расширений в Chrome
Все данные Chrome на Windows лежат в
Код:
%LocalAppData%\Google\Chrome\User Data\Default\
. На Linux -
Код:
~/.config/google-chrome/Default/
, на macOS -
Код:
~/Library/Application Support/Google/Chrome/Default/
. Внутри профиля есть несколько ключевых точек, относящихся к расширениям.
Manifest.json - паспорт каждого расширения
Директория
содержит поддиректории по ID расширения (32-символьная строка из букв a–p, получаемая маппингом первых 16 байт SHA-256 хеша публичного ключа: каждый hex-символ 0–f преобразуется в a–p), внутри - папки по версиям. В каждой версии лежит
- первый файл, который я открываю при анализе браузерных расширений.
На что смотреть в manifest.json:
- Поле
- уровень доступа. Если, например, расширение-калькулятор запрашивает
,
,
,
- это красный флаг. В кампании tapnetic.pro все 30 расширений имели идентичный набор широких разрешений, несмотря на разные заявленные функции.
- Поле
с
- расширение инжектирует код во все страницы.
- Поле
- в MV2 указывает на background page (persistent), в MV3 - на service worker. Подробнее о разнице ниже.
- Поле
Код:
externally_connectable
- список доменов, которые могут обмениваться сообщениями с расширением.
- Поле
- откуда приходят обновления. Если это не
Код:
https://clients2.google.com/service/update2/crx
(стандартный URL Chrome Web Store), расширение обновляется из стороннего источника.
Preferences и Secure Preferences - реестр установленных аддонов
Файлы
и
в корне профиля Chrome - JSON-файлы с полным реестром всех расширений. Секция
хранит для каждого расширения: время установки (
), источник (
), предоставленные разрешения (
), состояние (включено/отключено/заблокировано), URL обновления и причину отключения (
).
Это критически важный артефакт при анализе установленных расширений - он сохраняет информацию даже о расширениях, которые были отключены политикой или пользователем. Поле
хранит время в формате Chrome/WebKit (микросекунды с 1 января 1601 года) в виде строки - перед арифметикой конвертируйте в int. Формула:
Код:
unix_ts = (int(install_time) - 11644473600000000) / 1000000
.
содержит HMAC-подписи настроек, что защищает от ручной модификации. Для форензики это плюс: если подпись не совпадает - файл был изменён вне браузера, и это само по себе артефакт.
LevelDB и Local Storage - данные расширений в хранилищах
Расширения используют несколько хранилищ для оперативных данных.
Код:
chrome.storage.local
лежит в
Код:
Local Extension Settings//
(отдельная LevelDB на каждое расширение).
- в
Код:
Sync Extension Settings//
(локальный LevelDB-кэш; при включённом Chrome Sync данные синхронизируются с аккаунтом Google, при отключённом - API работает в локальном режиме).
Код:
chrome.storage.managed
(настройки от корпоративных политик) - в
Код:
Managed Extension Settings//
.
Код:
chrome.storage.session
живёт только в RAM и на диск не пишется. Если расширение использует
в своих extension pages, данные попадают в
Код:
Local Storage/leveldb/
с ключом
.
LevelDB - key-value хранилище от Google, и его парсинг - одна из самых муторных задач в форензике расширений. Файлы
и
содержат записи в бинарном формате. Для извлечения я использую Python-библиотеку
или утилиту
. Проблема в том, что LevelDB-записи часто оказываются corrupted на живой системе из-за незавершённых транзакций - тогда помогает прямой парсинг
-файлов, где лежат последние незафиксированные записи.
Именно в Local Storage вредоносные расширения хранят конфигурацию C2-серверов, эксфильтрированные данные до отправки и промежуточные состояния. В кампании Cyberhaven, по данным Darktrace, расширение собирало session cookies и authentication tokens - эти данные транзитно проходили через локальное хранилище перед отправкой на
.
Артефакты браузерных аддонов в Firefox
Firefox хранит данные расширений иначе. Профиль по умолчанию живёт в
Код:
%AppData%\Roaming\Mozilla\Firefox\Profiles\.default-release\
на Windows.
Ключевые файлы для анализа вредоносных расширений в Firefox:
- - полный реестр расширений с метаданными: ID, версия, путь установки, время, источник, активность.
- - дополнительные метаданные: описание, автор, homepage.
- - пользовательские настройки, включая параметры расширений. Бывает, что вредоносные аддоны правят
для подмены поисковой системы или homepage.
Код:
storage/default/moz-extension+++/
- IndexedDB-хранилище данных расширения (UUID рандомизирован per-profile; соответствие UUID ↔ extension ID лежит в
в ключе
Код:
extensions.webextensions.uuids
). Для
Код:
browser.storage.local
данные в
Код:
browser-extension-data//
. Firefox использует SQLite для IndexedDB, что упрощает парсинг - хватит DB Browser for SQLite.
- Директория
- XPI-файлы (по сути ZIP-архивы) установленных расширений.
Преимущество Firefox для форензики: XPI-файл распаковывается обычным архиватором - получаете полный исходный код расширения, включая все JS-файлы. В Chrome расширения тоже хранятся в распакованном виде, но Firefox дополнительно сохраняет оригинальный архив.
MV2 против MV3: что меняется для анализа браузерных расширений
Переход Chrome с Manifest V2 на Manifest V3 серьёзно влияет на то, какие артефакты остаются на диске. Для цифровой криминалистики браузера это различие - ключевое.
MV2 (устаревший, но встречается на живых системах). Background page - полноценная HTML-страница с постоянным JavaScript-контекстом. Работает непрерывно, пока браузер открыт. Артефакты: файл background page в директории расширения, записи в
Код:
chrome://extensions-internals
, постоянное соединение с C2 видно в сетевых логах как длительная сессия.
MV3 (текущий стандарт). Service worker заменяет background page. Он запускается по событию и завершается после 30 секунд бездействия. До Chrome 110 действовал жёсткий лимит в 5 минут с момента запуска SW, независимо от активности; с Chrome 110+ активные события (входящие сообщения, API-вызовы) сбрасывают idle-таймер, и SW может жить дольше. Через
(минимальный интервал 30 сек) SW периодически пробуждается - это позволяет поддерживать близкое к постоянному присутствие, хотя полностью persistent-режим MV2 недостижим. Артефакты: service worker регистрируется в
директории профиля, но его состояние эфемерно. Сетевая активность становится прерывистой - короткие всплески вместо постоянного beaconing. Для расследования инцидентов это значит, что окно для поимки активной коммуникации с C2 сужается.
Практическое следствие: при MV3 вредоносное расширение сложнее поймать на горячем через анализ сетевых соединений. Зато в
Код:
Service Worker/ScriptCache/
остаются кэшированные версии service worker-скрипта, включая предыдущие - а там может быть вредоносный код даже после обновления расширения до «чистой» версии. Я начинаю именно с этого кэша, когда работаю с MV3-расширениями.
Пошаговый анализ установленных расширений при инциденте
Триаж за первые 15 минут
При получении образа или доступе к живой машине первым делом снимаю снапшот расширений. Вот последовательность, которую я выполняю при каждом IR-кейсе, связанном с компрометацией через расширения браузера:
Шаг 1. Копирую директорию профиля целиком с сохранением временных меток. На Windows:
Код:
robocopy "%LocalAppData%\Google\Chrome\User Data" E:\evidence\chrome_profile /MIR /COPY:DAT /LOG:E:\evidence\copy.log
. Ключ
обязателен - без него timestamps поплывут.
Шаг 2. Вытаскиваю список расширений из
. Однострочник на jq:
Bash:
Код:
cat
Preferences
|
jq
'.extensions.settings | to_entries[] | {id: .key, name: .value.manifest.name, version: .value.manifest.version, install_time: .value.install_time, permissions: .value.manifest.permissions, update_url: (.value.update_url // .value.manifest.update_url), location: .value.location, install_source: .value.install_source}'
>
extensions_inventory.json
Шаг 3. Сверяю каждый ID расширения с Chrome Web Store. Если расширение удалено из магазина - сигнал копать глубже. Если
указывает не на стандартный Google endpoint - немедленный красный флаг. Но для расширений из Chrome Web Store поле
часто отсутствует в манифесте - его отсутствие не означает sideload. Надёжнее смотреть на
или
Код:
install_source != "webstore"
в
.
Шаг 4. Проверяю
каждого расширения на избыточный доступ: комбинация
+
+
у расширения, не связанного с безопасностью или разработкой - аномалия.
Шаг 5. Фиксирую временные метки установки и последнего обновления, выстраиваю timeline.
Глубокий анализ подозрительного расширения
Когда триаж выявил подозрительное расширение, перехожу к полной декомпозиции.
Открываю директорию расширения (
) и изучаю JS-файлы. Обфусцированный код - не обязательно признак вредоносности (многие легитимные расширения минифицируют JS), но в сочетании с избыточными permissions это повод для деобфускации. Прогоняю через
для форматирования и дальше - ручной анализ.
В кампании tapnetic.pro, описанной SecurityLab, ключевым индикатором был iframe, загружающий интерфейс с внешнего домена (
). Такой паттерн - когда core-логика расширения приходит не из локального кода, а подгружается с внешнего сервера - один из самых надёжных маркеров обнаружения вредоносных расширений. В коде это выглядит как динамическое создание iframe с
, указывающим на левый домен.
Дальше - сетевые артефакты. На живой системе -
для захвата сетевой активности браузера. На уровне хоста - Sysmon Event ID 22 (DNS Query) с фильтрацией по процессу
, EDR-телеметрия или network capture с корреляцией по времени. Сопоставление выявленных доменов с C2-индикаторами (например,
или
из кейса Cyberhaven) - прямое доказательство компрометации.
Обнаружение вредоносных расширений 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)Доступ к
API для кражи сессийCredential AccessCredentials from Web Browsers (T1555.003)Чтение сохранённых паролей через DOM или APICollectionBrowser Session Hijacking (T1185)Перехват активной сессии через инжектированный скриптCollectionData from Local System (T1005)Чтение DOM страниц, включая email-перепискуCollection / Credential AccessKeylogging (T1056.001)Перехват ввода через content scriptDiscoveryBrowser Information Discovery (T1217)Сбор данных о профиле, установленных расширенияхExfiltrationExfiltration Over C2 Channel (T1041)Отправка данных на C2 через HTTP POST
В кейсе Cyberhaven цепочка выглядела так: T1176.001 (Browser Extensions) → T1539 (Steal Web Session Cookie) → T1185 (Browser Session Hijacking) → T1041 (Exfiltration Over C2 Channel - на
). Darktrace зафиксировала 27 уникальных устройств, подключавшихся к C2 начиная с 3 декабря, а за двухдневный период два устройства передали 5,57 ГиБ входящих и 859,37 МиБ исходящих данных. Немало для «расширения-помощника».
Кейс: компрометация Cyberhaven и массовые кампании через расширения
Инцидент с Cyberhaven - эталонный пример supply chain атаки через расширения. 24 декабря 2024 года фишинговая атака скомпрометировала учётные данные сотрудника Cyberhaven, что позволило атакующим опубликовать вредоносную версию расширения. Момент выбран не случайно, рождественские каникулы - большинство сотрудников отсутствует. Вредоносная версия была активна 25–26 декабря.
Механизм: расширение после обновления начинало скрытно собирать session cookies и authentication tokens, целясь в высокоценные аккаунты - Facebook Ads, AI-сервисы. По данным Darktrace, на стороне сети это выглядело как persistent beaconing на домен
, замаскированный под легитимный
. Подключения шли к IP
, ассоциированному с двумя SSL-hostname, включая вредоносный домен.
Параллельно работала кампания вокруг
: 30 расширений с разными названиями и ID, но единой кодовой базой. Расширения маскировались под AI-ассистентов (Claude, ChatGPT, Gemini, Grok) и помощников для Gmail. Отдельный модуль для Gmail запускался на
, использовал MutationObserver для отслеживания DOM и многократно вытягивал содержимое переписки через
. Операторы быстро восстанавливали удалённые расширения: расширение с ID
Код:
fppbiomdkfbhgjjdmojlogeceejinadg
, удалённое 6 февраля 2025 года, появилось копией с ID
Код:
gghdfkafnhfpaooiolhncejnlgglhkhe
уже 20 февраля - с идентичным кодом, разрешениями и серверной инфраструктурой. Гидра, а не кампания.
Следы удалённых расширений: что остаётся после деинсталляции
Один из самых частых вопросов на реальных расследованиях: «Расширение уже удалено, можно ли восстановить следы?» Короткий ответ - да, и нередко артефакты живут месяцами.
При штатном удалении расширения через UI Chrome удаляет директорию из
, но следы остаются в нескольких местах:
- и
- запись о расширении может быть помечена как удалённая, но не стёрта из файла. Grep по ID в этих файлах часто даёт результат.
Код:
Local Extension Settings//
- директория
Код:
chrome.storage.local
обычно удаляется вместе с расширением, но может быть восстановлена из NTFS-артефактов (
, unallocated space).
Код:
Local Storage/leveldb/
- записи
extension pages с ключом
физически удаляются из LevelDB, но до компактификации базы остаются в
-файлах как tombstone-записи. Прямой парсинг бинарных файлов (через
или hex-редактор) может выявить остатки данных.
- - SQLite-база с иконками расширений. Записи остаются после удаления.
- Sync-метаданные - если был включен Chrome Sync, информация о расширении может сохраняться в
.
- Windows: файлы в NTFS могут быть восстановлены из
, если не были перезаписаны. FTK Imager позволяет вытащить удалённые директории расширений из нераспределённого пространства.
При форсированном удалении (через групповую политику или EDR-remediation) картина отличается: директория удаляется, но
обновляется с записью
, содержащей флаг принудительного отключения. Это позволяет установить, что расширение было удалено административно, а не пользователем.
Ключевое различие: если пользователь сам удалил расширение - в
остаётся минимум информации. Если расширение заблокировано политикой или Safe Browsing - записывается причина блокировки, и это само по себе доказательный артефакт.
Incident response при компрометации через расширения браузера
Когда компрометация подтверждена, IR-процесс для расширений имеет свою специфику.
Containment. Немедленно блокируем расширение через групповую политику Chrome (
). Если ID вредоносного расширения известен - в blocklist. Если подозрение на supply chain (легитимное расширение получило вредоносное обновление, как в кейсе Cyberhaven) - блокируем автообновление расширений до завершения расследования. На уровне сети - блокируем известные C2-домены и IP-адреса.
Eradication. Удаляем расширение со всех endpoint через централизованное управление. Обязательно проверяем, не осталось ли persistence-механизмов вне браузера: некоторые расширения создают scheduled tasks или правят registry для автоматической переустановки.
Recovery. Сбрасываем все сессии пользователей, чьи машины были скомпрометированы. Принудительная ротация паролей для сервисов, к которым расширение имело доступ. Если расширение имело permission
- считаем все активные сессии скомпрометированными. Без вариантов.
Lessons Learned. Внедряем инвентаризацию расширений через EDR. Настраиваем allowlist-политику: разрешить только проверенные расширения через
Код:
ExtensionInstallAllowlist
. Мониторим аномальную сетевую активность браузерных процессов - persistent beaconing к rare domains, как в случае с Cyberhaven, должен генерировать алерт.
Для автоматизации анализа расширений в масштабе организации стоит посмотреть на Hindsight (есть на GitHub) - он парсит артефакты Chrome, включая данные расширений, и строит единый timeline. Для побитового анализа образов дисков - Autopsy с модулем Chrome Extensions.
Вопрос к практикам
В инфраструктуре с Chrome, управляемом через групповые политики, расширения контролируются через
Код:
ExtensionInstallAllowlist
и
Код:
ExtensionInstallBlocklist
. Но на практике поддерживать allowlist на сотнях машин - боль, особенно когда бизнес-подразделения постоянно просят добавить «ещё одно расширение для Jira/Confluence/Figma». Кто из вас автоматизировал аудит запрашиваемых расширений перед добавлением в allowlist - через CRXcavator, кастомные скрипты парсинга manifest.json из CWS, или как-то иначе? Покажите конкретную связку: источник метаданных расширения, критерии accept/reject (например, максимальный набор permissions), и куда встроен этот чек - в тикет-систему, CI или ручной процесс?
Вопрос к читателям
Коллеги, при разборе LevelDB-хранилищ расширений (
Код:
Local Extension Settings//
) на живой системе часто встречаются corrupted-записи из-за незавершённых транзакций. Какой тулчейн вы используете для надёжного извлечения данных в таких случаях:
с перехватом
и fallback на прямой парсинг
-файлов, или что-то вроде
/
из пакета
? Если работали с расширениями из кампании tapnetic.pro или аналогичными MV3-аддонами - какие ключи в
Код:
chrome.storage.local
оказались информативны для реконструкции C2-конфигурации? Поделитесь конкретным jq-фильтром или Python-сниппетом с флагами открытия БД - особенно интересен опыт с образами, снятыми без предварительного graceful shutdown браузера.
Древовидный вид