Статья Manifest V3 и безопасность расширений Chrome: что мониторить, как детектить и где MV3 не спасает

В январе 2025 года фишинговое письмо, замаскированное под уведомление Chrome Web Store о нарушении политик, скомпрометировало расширение Cyberhaven - DLP-продукт, который сам должен был предотвращать утечки данных. Ирония жирная, но механика ещё жирнее: атакующие перехватили OAuth-токен разработчика, опубликовали троянизированную версию 24.10.4 с файлами worker.js и content.js, и за несколько часов получили доступ к cookie и сессиям пользователей. По данным Pulsedive и FieldEffect, в рамках той же кампании легли 33 расширения с аудиторией более 2,6 миллиона человек. Все работали на Manifest V3 - архитектуре, которую Google позиционировала как "более безопасную". Ни один этап атаки не был заблокирован средствами самой архитектуры.

Вот об этом и поговорим: что реально изменилось в MV3 с точки зрения атакующего и защитника, какие техники по-прежнему работают, и что делать SOC-команде, чтобы не узнавать о компрометации расширений из новостей.

Бизнес-логика атаки: зачем малвари браузерные расширения​

Расширение браузера получает доступ к тому, что недоступно классической малвари: содержимому веб-страниц после аутентификации (SaaS-порталы, корпоративные CRM, облачные консоли), cookie, localStorage, буферу обмена, истории, загрузкам. Трафик расширения выглядит как стандартные запросы от процесса браузера - chrome.exe шлёт HTTPS, и всё. EDR-агенты и SWG не различают действия пользователя и действия расширения.

Вивек Рамачандран, основатель SquareX, на DEF CON 32 сформулировал это прямо: "Browser extensions are a blind spot for EDR/XDR and SWGs have no way to infer their presence.""Расширения браузера представляют собой «слепое пятно» для EDR/XDR, и у SWG нет возможности определить их наличие."

Для атакующего это означает: одна скомпрометированная сессия администратора через украденный cookie - полный доступ к корпоративным данным без срабатывания алертов на brute force или credential stuffing. Расширение работает как легитимный insider с привилегиями пользователя. Это напрямую ложится на OWASP A08:2021 (Software and Data Integrity Failures) - обновления расширений устанавливаются автоматически, без верификации целостности со стороны конечного пользователя. Ты даже не узнаешь, что версия сменилась.

Manifest V3 vs Manifest V2: отличия для атакующего и защитника​

Что убрали в MV3​

MV2 давал расширениям три возможности, которые активно эксплуатировала малварь:

Persistent background pages - непрерывно работающие скрипты, способные держать открытые соединения и обрабатывать данные в фоне. В MV3 заменены на event-driven service workers: активируются по событию, выгружаются после выполнения.

Blocking webRequest API - перехват, модификация и блокировка HTTP-запросов произвольным JS-кодом в реальном времени. В MV3 заменён на declarativeNetRequest - декларативный API, где правила фильтрации описываются заранее в JSON. Звучит как шаг вперёд, но дьявол в деталях (об этом ниже).

Удалённое выполнение кода - загрузка и исполнение JavaScript с внешних серверов (eval, remote script injection). В MV3 расширение обязано содержать весь исполняемый код в своём пакете.

Что осталось - и почему это проблема для SOC​

На бумаге - серьёзный прогресс. На практике картина другая.

Permissions model не изменилась принципиально. Расширение с комбинацией tabs + scripting + <all_urls> + cookies по-прежнему может читать и модифицировать содержимое любой веб-страницы. Content scripts инжектируются в DOM и получают полный доступ к HTML, формам, токенам в полях ввода.

webRequest API не удалён - стал read-only. Расширение всё ещё наблюдает за HTTP-запросами, включая URL, заголовки и тело запроса. EFF отмечала: "Manifest V3 will still allow extensions to observe the same data as before, including what URLs users visit and the contents of pages users visit.""Манифест V3 будет всё ещё разрешит расширениям отслеживать одинаковые данные, как раньше, включая URLы которые посещают пользователи и контент страниц просматривемых ими."

Content scripts работают как прежде. В кейсе Cyberhaven файл content.js инжектировался во все URL через "matches": ["<all_urls>"] с директивой document_start и собирал данные с целевых доменов. MV3 этому не препятствует - вообще никак.

declarativeNetRequest допускает динамические правила. Расширение может добавлять до 30 000 динамических правил в рантайме, включая правила удаления заголовков безопасности. Тридцать тысяч - это не опечатка.

Для SOC-команды вывод такой: MV3 убирает часть attack surface (нет eval, нет persistent background), но сохраняет все observational и data-access API. Обнаружить вредоносное поведение теоретически легче - код в пакете, доступен для статического анализа. Но расширение с легитимными permissions может делать всё то же, что делала малварь на MV2. Просто аккуратнее.

Обход ограничений MV3: техники из исследований 2025 года​

declarativeNetRequest как инструмент Defense Evasion​

Расширения из группировки Phoenix Invicta, обнаруженные в Chrome Web Store, использовали declarativeNetRequest для удаления заголовка Content-Security-Policy из HTTP-ответов целевых сайтов - техника T1685 (Disable or Modify Tools) в чистом виде. Без CSP браузер перестаёт блокировать инжекцию стороннего контента, и расширение спокойно внедряет произвольный HTML через content script.

Механика: расширение декларирует правило removeHeaders для Content-Security-Policy и Strict-Transport-Security на целевых доменах. После удаления заголовков - инжектирует рекламу, скрипты для шпионажа или фишинговые формы. По данным исследования 2021 года, 2485 расширений в Chrome перехватывали и изменяли как минимум один заголовок безопасности популярных сайтов.

Место в kill chain: пользователь устанавливает расширение -> Execution через JS в content scripts (T1059.007) -> Defense Evasion через удаление CSP (T1685) -> Collection со страниц (T1185, Browser Session Hijacking).

Detection: алерт на расширения с removeHeaders для CSP/HSTS в declarativeNetRequest rules. Для этого нужен парсинг manifest.json и JSON-файлов правил каждого установленного расширения. Руками - тоска, но автоматизируется за вечер.

Supply chain через аккаунт разработчика​

Кампания января 2025 года - T1195.001 (Compromise Software Dependencies and Development Tools) без примесей. По данным Pulsedive, вредоносная версия Cyberhaven содержала два добавленных файла: worker.js (service worker для связи с C2 и загрузки конфигурации) и content.js (content script, декодирующий base64-конфигурацию из config-block.txt с целевыми доменами и адресом C2). Обновления Chrome-расширений устанавливаются автоматически - пользователь получает троянизированную версию без каких-либо действий со своей стороны. Просыпаешься утром - а расширение уже другое.

По данным доклада Афанасиоса Гиатсоса на Kaspersky Security Analyst Summit 2025, помимо supply chain существуют ещё три сценария появления вредоносного расширения:

• Продажа легитимного расширения новому владельцу (The Great Suspender - классический пример)
• Публикация изначально вредоносного клона (десятки клонов AdBlock, которые блокируют рекламу, но попутно сливают историю)
• Отложенная активация - расширение работает честно несколько месяцев, набирает аудиторию, а затем получает вредоносное обновление (ChatGPT for Google)

Третий сценарий - самый коварный. Расширение уже в allowlist, уже прошло ревью, уже получило доверие. А потом - одно обновление, и оно стало другим.

Что показали лабораторные эксперименты​

Исследование на arxiv ("A Study on Malicious Browser Extensions in 2025") продемонстрировало, что на MV3 по-прежнему работают:

• Cookie stealing (T1539) - через chrome.cookies API
• Keylogging (T1056.001) - через addEventListener в content scripts
• Screenshot capture - через chrome.tabs.captureVisibleTab
• History tracking - через chrome.history API
• Camera access - через стандартный getUserMedia
• Content manipulation и ad injection - через DOM API в content scripts
• Email spying - через content scripts на почтовых веб-клиентах

Самое интересное: исследователи успешно опубликовали такие расширения и в Chrome Web Store, и в Mozilla Add-ons Store, обойдя автоматическую проверку. Автоматизированный ревью не справляется - и это в 2025 году.

Kill chain атаки через расширение: маппинг на MITRE ATT&CK​

Этап	Техника ATT&CK	Описание	Точка detection
Initial Access	Compromise Software Dependencies (T1195.001)	Фишинг разработчика, OAuth-абьюз, публикация вредоносного обновления	Мониторинг publisher changes, version pinning
Persistence	Browser Extensions (T1176.001)	Расширение установлено, обновляется автоматически	Инвентаризация через GPO / Chrome Enterprise
Execution	JavaScript (T1059.007)	Content scripts и service workers исполняют JS	Аудит manifest.json: content_scripts, permissions
Stealth	Obfuscated Files or Information (T1027)	Base64-конфигурации, минифицированный код	Entropy check JS-файлов расширений
Defense Evasion	Disable or Modify Tools (T1685)	Удаление CSP/HSTS через declarativeNetRequest	Мониторинг removeHeaders правил
Credential Access	Steal Web Session Cookie (T1539)	Чтение cookie через chrome.cookies API	Алерт на cookies + <all_urls>
Collection	Browser Session Hijacking (T1185)	Перехват сессий SaaS через content scripts	Аномальные запросы из browser process
Collection	Keylogging (T1056.001)	addEventListener на input-элементах	Исходящие запросы к нетипичным доменам

Detection вредоносных расширений в корпоративной среде​

Chrome Enterprise Reporting и инвентаризация​

Chrome Enterprise Reporting API передаёт данные об установленных расширениях на управляемых устройствах в Google Admin Console: ID расширения, версию, запрошенные permissions, хосты из content_scripts.matches. Эти данные экспортируются в SIEM.

Ключевые триггеры алертов:

• Установка расширения вне allowlist
• Изменение версии расширения (потенциальное вредоносное обновление)
• Расширение запрашивает новые permissions при обновлении
• Появление <all_urls> в host_permissions

Правила корреляции для SIEM​

Для MaxPatrol SIEM, Elastic SIEM 8.x+ или Splunk Enterprise Security - три правила, которые стоит внедрить первыми:

Правило 1: широкие permissions. Триггер - появление расширения с комбинацией tabs + scripting + <all_urls> + cookies. Уровень Medium, тикет на анализ manifest.json. Такая комбинация - красный флаг: расширению "для заметок" не нужен доступ ко всем URL и cookie.

Правило 2: изменение permissions при обновлении. Триггер - версия расширения сменилась, при этом в manifest добавлены новые permissions (diff предыдущего и текущего manifest). Уровень High, блокировка обновления через version pinning до ручной проверки.

Правило 3: DNS-аномалии из browser process. Триггер - chrome.exe / msedge.exe обращается к домену, не входящему в baseline корпоративных сервисов. Корреляция с timeline установки или обновления расширений.

Пример Sigma-правила для мониторинга файловых операций в каталоге расширений:

title: Chrome Extension JS Modified Outside Update
logsource:
  product: windows
  service: sysmon
detection:
  selection:
    EventID: 11
    TargetFilename|contains:
      - '\Google\Chrome\User Data\Default\Extensions\'
    TargetFilename|endswith:
      - '.js'
  condition: selection

На Elastic Defend 8.x+ дополнительно доступен мониторинг через file.path с паттерном пути к расширениям в сочетании с process.name: chrome.exe за пределами окна штатного обновления.

Ограничения: где detection буксует​

CrowdStrike Falcon, SentinelOne, Elastic Defend - видят файловые операции и сетевые соединения chrome.exe, но не атрибутируют запрос конкретному расширению. Это ключевая проблема: ты видишь, что chrome.exe полез на подозрительный домен, но какое именно из двадцати расширений это сделало - непонятно. Для атрибуции нужна телеметрия Chrome Enterprise или офлайн-анализ профиля расширений.

SWG / веб-прокси - видят URL и SNI, но не контекст расширения. Запрос расширения к C2 выглядит как обычный HTTPS-трафик. Ничем не отличается от того, как пользователь зашёл на сайт.

macOS и GNU/Linux - GPO недоступны, нужны MDM-профили (macOS) или JSON-политики в /etc/opt/chrome/policies/ (GNU/Linux). Это отдельный трек настройки, который часто пропускают. А зря - на маках разработчиков обычно стоит больше расширений, чем на корпоративных виндовсах.

Чеклист hardening Chrome-расширений​

Нумерованный список для передачи сисадмину или включения в отчёт:

1. Включить allowlist-режим через ExtensionInstallAllowlist в Chrome Enterprise policy. Всё, что не в списке, - заблокировано. Жёстко, но работает.
2. Заблокировать режим разработчика - DeveloperToolsAvailability = 2. Предотвращает установку unpacked-расширений.
3. Применить version pinning для каждого разрешённого расширения через ExtensionSettings:

{
  "extension_id_here": {
    "installation_mode": "force_installed",
    "update_url": "https://clients2.google.com/service/update2/crx",
    "minimum_version_required": "24.10.3"
  },
  "*": {
    "installation_mode": "blocked"
  }
}

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

MV3 упрощает мониторинг: код в пакете, нет persistent background pages, нет eval. Но фундаментальную проблему не устраняет. Исследователи из arxiv-публикации 2025 года прошли проверку и Chrome Web Store, и Mozilla Add-ons Store с расширениями, реализующими кейлоггинг, кражу cookie и захват скриншотов на MV3. Автоматизированный review не справляется.

Из моего опыта анализа вредоносных расширений: самый надёжный detection-сигнал - не статический анализ кода (его слишком много и он часто обфусцирован через T1027), а аномалия в сетевой активности. Когда расширение "для заметок" начинает отправлять POST-запросы с base64-данными на домен, зарегистрированный два дня назад, - это тот алерт, который должен срабатывать в первые минуты.

Проблема в том, что большинство SOC-команд не собирают browser telemetry как отдельный источник. Chrome для них - чёрный ящик, из которого видны только DNS и TLS-сертификаты. И пока это не изменится, никакая версия Manifest - третья, четвёртая, десятая - не закроет эту слепую зону.

Архитектура расширений - ответственность Google. Видимость того, что расширения делают на корпоративных endpoint, - ответственность SOC. Разделение этих зон и есть главная задача, которую стоит решить до следующего supply chain инцидента. Если ваш SIEM пока не парсит события Chrome Enterprise Reporting - на codeby.net в тематическом треде коллеги разбирают рабочие конфигурации интеграции browser telemetry с конкретными SIEM-стеками и подходы к корреляции extension-событий с сетевыми аномалиями.