24 декабря 2024 года одно фишинговое письмо убило DLP-решение с 400 000 пользователей. Письмо было замаскировано под уведомление Chrome Web Store о нарушении политик и попало разработчику расширения Cyberhaven. Малварная версия 24.10.4 появилась в официальном магазине и 31 час сливала cookies Facebook Business и токены ChatGPT на C2-домен
cyberhavenext[.]pro. Потом за дело взялись исследователи - Hunters Team Axon, GitLab Threat Intelligence, Secure Annex - и выяснилось: Cyberhaven была лишь одним элементом supply chain кампании на 100+ расширений и миллионы пользователей. Русскоязычные источники описывают угрозы браузерных расширений в общих чертах, но ни один не разбирает технику именно этой кампании: CSP-stripping через declarativeNetRequest, многоэтапную C2-архитектуру и конкретные IOC для threat hunting.Бизнес-логика атаки: зачем злоумышленникам browser extension malware
Расширения браузера - один из самых недооценённых векторов. Chrome держит порядка 65% рынка, а на движке Chromium работают Edge, Opera, Яндекс.Браузер, Brave - это около 80%. Расширение, написанное для одного, совместимо почти со всеми. По данным Verizon DBIR 2025, 26% всех подтверждённых нарушений связаны с веб-атаками, и browser extension malware - растущий сегмент.С точки зрения атакующего, расширение - идеальный payload:
- Работает внутри легитимного процесса
chrome.exe- вредоносный трафик малозаметен для классических EDR - Переживает перезагрузку: persistence без дополнительных механизмов закрепления
- Получает доступ к cookies, DOM, буферу обмена, истории через документированный Chrome API
- Автоматически обновляется через Chrome Web Store - один скомпрометированный аккаунт разработчика превращается в канал доставки на сотни тысяч устройств
Главный экономический фактор: один угнанный аккаунт разработчика популярного расширения = автоматическое обновление на все устройства. При этом удаление расширения из Chrome Web Store не триггерит деинсталляцию. Пользователи остаются скомпрометированными до ручного удаления.
Анатомия supply chain кампании: от фишинга разработчика до миллионов жертв
OAuth-фишинг как обход MFA
Атака началась с таргетированных писем разработчикам Chrome-расширений. Письма имитировали уведомления от Google: расширение якобы нарушает политики и будет удалено. Вектор - не классический credential phishing, а OAuth-фишинг: жертва авторизовала вредоносное OAuth-приложение "Privacy Policy Extension".Запрашиваемые permission были прицельными:
Полный контроль над публикацией обновлений. MFA обходится полностью - OAuth-токен даёт прямой доступ к аккаунту разработчика без повторной аутентификации. В случае Cyberhaven между получением доступа и публикацией малварной версии прошло менее суток: около 01:32 25 декабря 2024 года версия 24.10.4 появилась в Chrome Web Store. Рождественское утро - идеальный тайминг, когда SOC работает на минимуме. Команда безопасности Cyberhaven обнаружила компрометацию в тот же день, чистая версия 24.10.5 вышла в течение 24 часов. Для расследования привлекли Mandiant.
[Применимо: внешний вектор, таргетированная атака на разработчиков расширений, не требует предварительного доступа к инфраструктуре жертвы]
Масштаб: одна кампания - более 100 расширений
По данным Hunters Team Axon, кампания была активна минимум семь месяцев до обнаружения. Начальный анализ выявил 35+ скомпрометированных расширений с суммарной аудиторией свыше 2,5 миллиона пользователей. Независимо от этого, GitLab Threat Intelligence в феврале 2025 года идентифицировала кластер из 16 малварных расширений (минимум 3,2 миллиона пользователей), где атакующий, по оценке исследователей, часть расширений купил у оригинальных разработчиков легально, а не через компрометацию. Дальнейший анализ сообщества расширил число известных тамперированных расширений до 100+.Затронутые расширения покрывали разные ниши: блокировщики рекламы (Crystal Ad block - 6,8 млн пользователей), VPN-сервисы (Brisk VPN - 5,6 млн), утилиты буфера обмена (Clipboard Helper - 3,5 млн), скриншотеры (Nimble Capture), emoji-клавиатуры, прокси-сервисы. Все реально выполняли заявленную функцию - именно поэтому ручное обнаружение было практически невозможно.
Технический разбор: CSP-stripping через declarativeNetRequest
Анализ вредоносных расширений из кластера GitLab Threat Intelligence выявил единый паттерн в service worker. Код делал три вещи.Heartbeat к конфигурационному серверу. При установке расширение отправляло POST-запрос на уникальный домен, передавая версию и жёстко зашитый integer ID. В ответ приходила JSON-конфигурация, которая сохранялась в
chrome.storage.local. Конфигурационные данные формально выглядели привязанными к функционалу ("screenInScreen":1, "QuickShare":1), но ни одно из этих значений не использовалось в основном коде. Классическая заготовка под второй этап.CSP-stripping. Ключевой технический приём кампании - злоупотребление
declarativeNetRequest для обнуления заголовка Content Security Policy:
JavaScript:
chrome.declarativeNetRequest.updateSessionRules({
addRules: [{
id: ruleId,
action: {
type: "modifyHeaders",
responseHeaders: [{
header: "content-security-policy",
operation: "set", value: ""
}]
},
condition: {
urlFilter: hostname,
resourceTypes: ["main_frame", "sub_frame"]
}
}],
removeRuleIds: [ruleId]
})declarativeNetRequest - это замена старого webRequest, которую Google продвигала как более безопасную в Manifest V3.HEALTHCHECK-таймер. Каждую минуту расширение проверяло открытые вкладки и перезагружало те, что были активны дольше 500 секунд. Предположительно - для обновления инъецированных payload.
Инфраструктура C2 и OPSEC-ошибка атакующего
Каждое расширение использовало уникальный конфигурационный домен (например, для KProxy -kproxy[.]site, отдельный от рабочего kproxy[.]com). Всё выглядело аккуратно - пока исследователи GitLab не заглянули в HTTP-заголовки ответов. Все домены резолвились через Bunny CDN и содержали единое значение x-do-app-origin: 978bc8ed-09a8-444b-9142-df5a19366612 - идентификатор приложения на DigitalOcean Apps Platform. Один Express-сервер обслуживал все C2-домены.Одна ошибка OPSEC - и весь кластер расширений связан в единую кампанию с атрибуцией к одному актору.
Ещё деталь: жёстко зашитые integer ID в heartbeat-запросах образовывали примерно возрастающий ряд. Часть ID в последовательности не соответствовала известным расширениям - что может указывать на значительно больший масштаб операций, чем удалось задокументировать.
Цепочка атаки: от recon до exfiltration
Полный kill chain кампании:
- Recon: идентификация расширений с большой пользовательской базой через Chrome Web Store, поиск контактов разработчиков
- Initial Access: OAuth-фишинг разработчика (T1566.002) или покупка расширения у автора
- Persistence: публикация малварного обновления в Chrome Web Store, автоматическое обновление у пользователей (T1176.001 - Browser Extensions)
- Defense Evasion: CSP-stripping обнуляет политики безопасности для инъекции payload, трафик идёт из легитимного процесса браузера
- Collection: перехват cookies, session tokens, DOM-содержимого через Content Scripts, browser hijacking
- C2: heartbeat к конфигурационному серверу, динамическая загрузка payload после снятия CSP
- Exfiltration: отправка собранных данных (cookies Facebook Business, credentials ChatGPT) на C2-инфраструктуру
DeviceTvmBrowserExtensions для инвентаризации расширений на endpoint-уровне, но не анализируют runtime-поведение service worker. SentinelOne на момент анализа не имеет нативного browser extension visibility. Elastic Security 8.x+ способен детектировать подозрительные аргументы командной строки Chrome (--load-extension), но supply chain атаки через Chrome Web Store используют штатный механизм обновления - без аргументов командной строки, без артефактов на диске за пределами стандартной директории расширений. Ни один из трёх вендоров не видит, что расширение обнуляет CSP в runtime.Обнаружение вредоносных расширений Chrome: практические методы
Анализ manifest.json и кода service worker
При анализе вредоносных аддонов Chrome первый шаг -manifest.json. Вот на что смотреть:- Комбинация
cookies+declarativeNetRequest+webRequest+<all_urls>для расширения, которому по функционалу достаточно одного домена. Зачем VPN-клиенту доступ к cookies всех сайтов? - Permission
declarativeNetRequestс правилом на модификацию security-заголовков: CSP, X-Frame-Options, X-Content-Type-Options. Легитимных причин обнулять CSP у пользовательского расширения практически нет - Service worker с
fetch/POST к внешним доменам, не связанным с основной функцией расширения - Значения в
chrome.storage.local, которые не читаются основным кодом - паттерн подготовки ко второму этапу
%LOCALAPPDATA%\Google\Chrome\User Data\Default\Extensions\, на GNU/Linux: ~/.config/google-chrome/Default/Extensions/. Каждая поддиректория содержит manifest.json для ручного или автоматизированного аудита permissions.Sigma-правила и детектирование через EDR
В репозитории SigmaHQ (SigmaHQ/sigma) есть три правила для T1176 и T1176.001:proc_creation_win_browsers_chromium_load_extension.yml- детектирует запуск Chromium-браузера с--load-extension(sideloading расширения с диска)proc_creation_win_browsers_chromium_susp_load_extension.yml- расширенный вариант с детекцией подозрительных путей загрузкиproc_creation_win_malware_chrome_loader_execution.yml- правило для семейства ChromeLoader
YAML:
detection:
selection:
CommandLine|contains: '--load-extension'
Image|endswith:
- '\chrome.exe'
- '\msedge.exe'
- '\brave.exe'
condition: selection--load-extension ловят sideloading с диска. Supply chain атаки через Chrome Web Store этого артефакта не оставляют - расширение обновляется штатным механизмом. Для кампании декабря 2024 Sigma-правила сработают только в post-compromise сценарии, где атакующий уже на endpoint и грузит расширение вручную (как описано у Angara Security - через --load-extension или подмену LNK-ярлыка).Для supply chain сценариев нужен мониторинг на уровне extension inventory.
Microsoft Defender XDR: таблица
DeviceTvmBrowserExtensions в Advanced Hunting позволяет инвентаризировать и фильтровать расширения по permissions:
Код:
DeviceTvmBrowserExtensions
| where ExtensionName has_any ("vpn","proxy","ad block")
| where BrowserName == "chrome"
| project DeviceName, ExtensionName, ExtensionId,
ExtensionVersion, IsActivatedIOC кампании для threat hunting
Конкретные индикаторы из исследований Hunters Team Axon и GitLab Threat Intelligence для добавления в SIEM/DNS-фильтр:C2-домены (по данным Hunters Team Axon):
chatgptforsearch[.]comgraphqlnetwork[.]prointernetdownloadmanager[.]prosavegptforchrome[.]comseasonalweatherstatspro[.]site
140[.]82[.]50[.]201149[.]28[.]71[.]39140[.]82[.]45[.]42149[.]248[.]56[.]63
declarativeNetRequest.updateSessionRules, модификации заголовка content-security-policy и heartbeat-логики с chrome.alarms. Правило доступно в приложении к tech note на gitlab-com.gitlab.io.Полные списки IOC (включая Extension ID всех известных скомпрометированных расширений) ведутся в нескольких местах: Hunters Team Axon GitHub repository, Extension Total (Cyberhaven Incident Live), Secure Annex (John Tuckner).
Чеклист для SOC: обнаружение и реагирование
Нумерованный план действий - можно передавать в SOC или сисадмину как есть:D3FEND (MITRE) рекомендует для T1176.001 четыре контрмеры: Software Inventory (D3-SWI), Asset Vulnerability Enumeration (D3-AVE), Software Update (D3-SU), Restore Software (D3-RS). На практике: знать что установлено, сканировать на известные малварные ID, обновлять из проверенных источников, при компрометации - откатывать к чистому состоянию.
Для тестирования детектирующих возможностей в лабораторной среде: Atomic Red Team (redcanaryco/atomic-red-team) содержит три теста для T1176 - установка расширения в Chrome/Chromium через Developer Mode, в Firefox и в Edge Chromium. Все тесты выполняются вручную (executor: manual), платформы: GNU/Linux, Windows, macOS.
Google потратила годы на Manifest V3 как ответ на угрозы расширений - ограничение API, замена
webRequest на declarativeNetRequest, ужесточение проверок. Кампания декабря 2024 показала, что declarativeNetRequest не просто не устранила проблему - она дала атакующим новый, легитимный инструмент для снятия CSP. Ephemeral session rules работают тихо, не вызывают алертов и формально используют документированный API. Google прошла путь от "любое расширение может делать что угодно" до "расширение использует наш безопасный API для того, чтобы делать что угодно". По документам - безопаснее. На практике - тот же результат.Проблема глубже конкретной кампании. Модель доверия Chrome Web Store построена на предположении, что разработчик - добросовестный участник. OAuth-фишинг разрушает это за один клик. Автоматическая проверка Google при публикации обновлений обнаружит обфусцированный
eval(), но не обнуление CSP-заголовков через легитимный API. Исследование 2025 года из arxiv подтверждает: исследователи успешно обошли механизмы безопасности и Firefox, и Chrome, опубликовав вредоносные расширения в обоих магазинах. В контролируемой среде, по этическим стандартам - но атакующим этика не мешает.Единственная работающая стратегия - жёсткий allowlist через Chrome Enterprise Policy в корпоративной среде и browser extension inventory через EDR. CrowdStrike Exposure Management и таблица
DeviceTvmBrowserExtensions в Microsoft Defender XDR дают visibility, без которого невозможно даже оценить масштаб экспозиции. Всё остальное - реактивная борьба с последствиями. Парадокс: большинство SOC до сих пор не мониторят расширения браузеров, хотя через них проходит больше чувствительных данных, чем через любой endpoint-процесс. Проверьте свой allowlist расширений и сверьте Extension ID с IOC из Hunters Team Axon - если хотя бы одно совпадение найдётся, у вас та же проблема, что была у Cyberhaven в рождественскую ночь.
Последнее редактирование модератором:
