Статья Защита от вредоносных расширений браузера: Chrome Enterprise политики, allowlisting и detection в SIEM

24 декабря 2024 года расширение Cyberhaven - ИБ-инструмент, установленный у порядка 400 000 пользователей и наверняка включённый в корпоративный allowlist сотен организаций - получило обновление с вредоносным кодом. Канун Рождества, половина SOC на каникулах, а фишинговое письмо, замаскированное под уведомление Chrome Web Store, уже лежит в ящике сотрудника Cyberhaven. В тот же день он авторизовал OAuth-приложение "Privacy Policy Extension", которое получило права на публикацию в Chrome Web Store, полностью обойдя MFA. Около 20:32 UTC вышла вредоносная версия 24.10.4, заточенная на кражу сессионных данных Facebook Ads (cookies, access tokens) и ряда других сервисов через C2-домен cyberhavenext[.]pro. Автоматическая модерация Google пропустила обновление. По данным Secure Annex, в рамках той же кампании были предположительно скомпрометированы десятки расширений с суммарной аудиторией в миллионы пользователей. EDR на эндпоинтах не сгенерировал ни одного алерта - расширение работало внутри легитимного процесса браузера. Вдумайтесь: ИБ-продукт стал вектором атаки, и ни один защитный инструмент на хосте этого не заметил.

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

Расширение Chrome - это JavaScript-приложение с доступом к cookies, localStorage, содержимому страниц, истории браузера, а в зависимости от permissions - к буферу обмена, геолокации и захвату экрана. При этом 99% корпоративных сотрудников имеют хотя бы одно расширение, а 52% используют более десяти. По данным "Лаборатории Касперского", с января 2020 по июнь 2022 года были предотвращены загрузки более 6 миллионов вредоносных и нежелательных расширений. Шесть миллионов - и это только то, что поймали.

В матрице MITRE ATT&CK расширения описаны как техника Software Extensions (T1176) в тактике Persistence, подтехника Browser Extensions (T1176.001). Место в kill chain:

1. Initial Access: атакующий компрометирует аккаунт разработчика через OAuth-фишинг (как в кейсе Cyberhaven), публикует собственное расширение или покупает легитимное с аудиторией. Кейс Great Suspender: расширение с более чем 2 миллионами пользователей было продано неизвестному покупателю, который внедрил трекинг и URL-hijacking через штатные обновления. Просто купил и залил обновление - всё легально с точки зрения Chrome Web Store.
2. Persistence (T1176): расширение устанавливается или обновляется автоматически через Chrome Web Store. После перезагрузки ОС продолжает работать. В post-compromise сценарии атакующие с доменным доступом устанавливают расширение через GPO на все машины домена - прямая реализация insider/compromised host вектора.
3. Credential Access / Collection: через chrome.cookies API и перехват содержимого страниц расширение собирает сессионные токены, учётные данные, данные форм. Отдельный класс расширений занимается cryptojacking и генерацией нелегитимного рекламного трафика.
4. Exfiltration: данные уходят на C2 через HTTPS от процесса chrome.exe. Файрвол видит легитимный исходящий трафик. EDR не создаёт событий process start для расширений - они не являются отдельными процессами. Вот тут и кроется проблема: для любого средства защиты это просто Chrome ходит в интернет.

Финансовые последствия конкретны. Утечка сессионных cookie OAuth-сервисов означает компрометацию SSO-токенов и доступ ко всем подключённым SaaS. В контексте ФЗ-152 и оборотных штрафов (до 3% выручки за повторное нарушение) инцидент с массовым похищением ПДн через расширение может стоить десятки миллионов рублей.

Блокировка расширений Chrome через GPO: ExtensionInstallBlocklist и allowlisting​

Требования к окружению​

• Windows Server 2016+ с Active Directory Domain Services (для GPO). Для cloud-only: Microsoft Intune или Google Admin Console с лицензией Chrome Enterprise
• Chrome Enterprise ADMX/ADML-шаблоны актуальной версии (support.google.com/chrome/a)
• Chrome 90+ на эндпоинтах (поддержка ExtensionSettings с version pinning)
• Linux: директория /etc/opt/chrome/policies/managed/ для JSON-файлов политик
• macOS: управляемые профили через MDM или .plist в /Library/Managed Preferences/

Стратегия: заблокировать всё, разрешить по списку​

Единственный рабочий подход - ExtensionInstallBlocklist с wildcard * и явное разрешение конкретных расширений через ExtensionInstallAllowlist. Обратная модель (разрешить всё, блокировать известные вредоносные) нежизнеспособна: в Chrome Web Store более 100 000 активных расширений, новые появляются ежедневно. Пытаться вести чёрный список - как вычерпывать море ведром.

В редакторе Group Policy путь: Computer Configuration -> Administrative Templates -> Google -> Google Chrome -> Extensions. Ключевые политики:

• ExtensionInstallBlocklist = * - запрет установки любых расширений для всех пользователей в области действия GPO
• ExtensionInstallAllowlist - ID одобренных расширений (32-символьная строка из URL Chrome Web Store, например cjpalhdlnbpafiamejdnhcphjbkeiagm для uBlock Origin)
• ExtensionInstallForcelist - расширения, устанавливаемые автоматически без возможности удаления (корпоративный пароль-менеджер, DLP-агент)
• DeveloperToolsAvailability = 2 (DeveloperToolsDisallowed) - полностью отключает DevTools, включая возможность установки распакованных расширений в Developer Mode. С Chrome 128+ доступна более точная политика ExtensionDeveloperModeSettings
• ExtensionSettings - JSON-политика для version pinning: фиксация конкретной версии одобренного расширения. Обновление не установится, пока ИБ-служба не протестирует и не изменит pinned version

Для Intune: Settings Catalog -> Windows 10 and later -> Settings catalog. Настройка Configure extension installation blocklist = Enabled, ID = *, затем Configure extension installation allowlist с перечислением ID.

Ограничения GPO-подхода​

Ограничение	Последствие	Компенсирующая мера
GPO действует только на managed-профили	Личный профиль Chrome на рабочей машине не контролируется политикой GPO	Мониторинг через osquery (запрашивает все профили)
Portable-браузеры не подчиняются GPO	Arc, Comet, portable Chrome - вне контроля	Блокировка через AppLocker или WDAC
macOS/Linux без Active Directory	GPO неприменим	JSON-файлы через MDM/конфигурационный менеджмент
Скомпрометированное расширение из allowlist	GPO не блокирует обновление одобренного расширения	Version pinning + detection pipeline

Последний пункт - самый неприятный. Корпоративный пароль-менеджер или DLP-агент всегда будут в allowlist. Если именно это расширение скомпрометировано (как в кейсе Cyberhaven), GPO бесполезна. Отсюда необходимость мониторинга и detection.

Мониторинг расширений браузера: от инвентаризации до корреляции в SIEM​

Между применением политики и реальным состоянием парка всегда есть зазор: legacy-машины без GPO, BYOD, личные профили. Без continuous monitoring SOC не ответит на вопрос "установлено ли расширение X на наших эндпоинтах" за приемлемое время. А когда прилетает алерт в 3 ночи - "приемлемое время" это минуты, не часы.

Инвентаризация: вендор-специфика osquery, MDE и CrowdStrike​

Инструмент	Источник данных	Платформы	Лицензия	Покрытие профилей
osquery + Elastic 8.x+	Таблица chrome_extensions	Windows, macOS, GNU/Linux	Basic (бесплатно)	Все профили через JOIN
Microsoft Defender XDR	DeviceTvmBrowserExtensions	Только Windows	Defender Vulnerability Management (standalone или add-on к MDE P2)	Managed и personal
CrowdStrike Falcon	Exposure Management	Windows	Falcon Insight XDR	По документации вендора

osquery - самый гибкий вариант (описан командой Elastic Infosec). Запрос для полной инвентаризации по всем профилям:

SELECT u.username, ce.name, ce.identifier,
       ce.version, ce.permissions, ce.path, ce.profile
FROM users u JOIN chrome_extensions ce USING (uid)
-- NB: JOIN USING(uid) возвращает расширения всех профилей пользователя; для агрегации по профилю используйте GROUP BY profile

Результаты поступают в индекс logs-osquery_manager.result* и доступны в Kibana для поиска и визуализации. Рекомендуемый интервал - каждые 6 часов. Ключевые поля для анализа: osquery.identifier (ID расширения), osquery.permissions (запрашиваемые права), osquery.version, osquery.profile (профиль для multi-profile покрытия).

Microsoft Defender for Endpoint - пример KQL для поиска аномалий по количеству расширений:

DeviceTvmBrowserExtensions
| summarize ExtCount = dcount(ExtensionId),
  Exts = make_set(ExtensionName) by DeviceId
| join (DeviceInfo | summarize arg_max(Timestamp, *) by DeviceId) on DeviceId
| project DeviceName, ExtCount, Exts
| top 50 by ExtCount

Колонка PermissionsRisk (Low/Medium/High/Critical) и запрашиваемые permissions позволяют фильтровать по уровню риска без ручного ковыряния manifest.json. Ресурс extensiontotal.com (упоминается Jeffrey Appel) отслеживает скомпрометированные расширения и может использоваться как TI-фид для пополнения blocklist.

Sigma-правила и detection rules для контроля расширений Chrome​

В репозитории SigmaHQ (SigmaHQ/sigma) по тегам T1176 / T1176.001 доступны три правила:

Sigma-правило	Что детектирует
proc_creation_win_browsers_chromium_load_extension.yml	Запуск Chromium-браузера с флагом --load-extension - вектор sideloading
proc_creation_win_browsers_chromium_susp_load_extension.yml	Загрузка расширений из нетипичных директорий (%TEMP%, %APPDATA%)
proc_creation_win_malware_chrome_loader_execution.yml	Паттерны ChromeLoader - вредоносного ПО, подменяющего ярлыки Chrome

Правила отслеживают process_creation и ловят ситуации, когда chrome.exe запускается с --load-extension из нестандартного пути. По данным Angara Security, атакующие подменяют LNK-файл Chrome, добавляя --load-extension="C:\Temp\my-extension". Старый трюк, но работает до сих пор. Google анонсировала ряд ограничений для --load-extension в Chrome [требует проверки - конкретный источник не подтверждён], но для Edge, Яндекс.Браузера и Opera техника остаётся актуальной. Отдельный post-compromise инструмент SharpSilentChrome (описывается в исследованиях Angara Security) устанавливает расширения через модификацию файлов Secure Preferences и Preferences - для его detection нужен мониторинг файловых изменений в директории профиля браузера.

В Atomic Red Team (redcanaryco/atomic-red-team) доступны три теста для Software Extensions (T1176): установка расширений в Chrome/Chromium (Developer Mode), Firefox и Edge Chromium. Прогоните их в тестовой среде - сразу увидите, срабатывают ли ваши правила или нет.

Что мониторить сверх sideloading:

1. Новый extension ID в инвентаризации, отсутствующий в approved list - корреляция baseline (osquery/MDE) с allowlist. Алерт P2.
2. Изменение permissions у существующего расширения - индикатор supply chain-компрометации. Это P1, и вот почему: если расширение вчера просило доступ к bookmarks, а сегодня хочет chrome.cookies - что-то пошло не так.
3. DNS/proxy-обращения от процесса браузера к свежезарегистрированным доменам или доменам с typosquatting-паттерном - сетевой детект C2.
4. Аномальное количество расширений на одном endpoint - порог зависит от baseline, но 15+ расширений на рабочей машине заслуживают ручной проверки.

Для фреймворка D3FEND (MITRE) техникам T1176/T1176.001 соответствуют контрмеры: Software Inventory (D3-SWI) - инвентаризация через osquery/MDE; Asset Vulnerability Enumeration (D3-AVE) - оценка permissions; Software Update (D3-SU) - управляемое обновление через pinning; Restore Software (D3-RS) - восстановление чистой версии при компрометации.

Чеклист hardening: управление расширениями браузера в организации​

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

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

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

На практике GPO-настройка нередко заканчивается на пункте 5 этого списка. GPO настроена, режим разработчика отключён - формально периметр закрыт. А дальше - тишина. Detection pipeline отсутствует: инвентаризация расширений не ведётся, Sigma-правила на --load-extension не импортированы, корреляции между allowlist и реальным парком нет. Когда в декабре 2024-го расширение Cyberhaven получило вредоносное обновление, команды без мониторинга узнали об этом из новостей - через дни, не через минуты.

Кейс Cyberhaven обнажил неудобную правду: policy enforcement и detection - два разных процесса, один не заменяет другой. Можно заблокировать 99% расширений через GPO, но если скомпрометировано расширение из allowlist (а пароль-менеджер или DLP-агент всегда в allowlist), GPO бесполезна. Расширение обновится через Chrome Web Store, пройдёт автоматическую проверку и начнёт эксфильтрацию. Единственная защита на этом этапе - version pinning плюс алерт на изменение permissions или обращение к нехарактерному домену.

Через год-два индустрия, скорее всего, придёт к модели, где каждое обновление одобренного расширения проходит корпоративный pipeline статического анализа - по аналогии с software composition analysis для npm и PyPI. Пока этого нет, остаётся триада: allowlist, pinning, continuous monitoring. Проверьте свой парк osquery-запросом из раздела выше. Если нашли расширения вне approved list - у вас та же проблема, что была у Cyberhaven, только вы о ней пока не знаете. На codeby.net в профильном треде коллеги разбирают конкретные кейсы supply chain-компрометации расширений и делятся рабочими detection-конфигурациями.