Google и Microsoft удалили из своих магазинов расширение ModHeader — популярный инструмент для редактирования HTTP-заголовков. Причина банальна и неприятна одновременно: исследователи безопасности нашли внутри официальной версии расширения скрытый механизм сбора данных о посещённых сайтах. Механизм не работал — но был готов заработать в любой момент.
Расширение стояло у примерно 900 тысяч пользователей Chrome и порядка 700 тысяч пользователей Edge (по данным сторонних трекеров), суммарно около 1,6 миллиона установок. Microsoft убрала листинг в Edge 3 июля, Google последовала неделю позже — 10 июля. Анализировалась версия 7.0.18, идентификатор расширения — idgpnmonknjnojddfkpgkljpfnnfcklj.
Расследование провела британская компания Stripe OLT. Специалисты сверили код с подписью Google Web Store и подтвердили: это не подделка и не взломанная копия, а именно та версия, что официально раздавалась через магазин. Независимо это подтвердили HackIndex, разобравшие версию 7.0.18, и исследователь Юнус Айдин, изучивший версию 7.0.17. Обе команды описали одинаковую цепочку передачи данных.
Механизм устроен так. При первом запуске расширение строит цифровой отпечаток устройства и загружает зашитый в код ключ шифрования. Далее при обычном сёрфинге оно фиксирует домен каждой открытой страницы, шифрует его и складывает локально — до тысячи уникальных доменов. Раз в сутки собранный список вместе с отпечатком устройства отправляется на api.stanfordstudies[.]com, после чего локальная копия стирается. Время отправки для каждой установки смещено индивидуально — чтобы тысячи расширений не начали «сигналить» одновременно и не привлекли внимание сетевых мониторингов.
Почему же ничего не произошло? Потому что запуск всей цепочки контролируется внутренним списком разрешений, который в текущей версии поставляется пустым. Проверка всегда проваливается, и передача данных никогда не запускается. Никаких доказательств реальной утечки хотя бы одного домена исследователи не нашли. Проблема в другом: чтобы включить сбор, достаточно просто заполнить этот список — без новых разрешений, без клика пользователя, обычным тихим обновлением. Вся инфраструктура — ключ, конечная точка, планировщик отправки, логика хранения — уже лежит на компьютерах пользователей и ждёт команды.
При этом кое-что действительно работало, и работало активно. При установке, обновлении или удалении расширение связывалось с extensions-hub[.]com, передавая название продукта, версию и данные о браузере. А скрипт, запускавшийся на каждой открытой странице, вёл локальное журналирование — записывал метаданные реальных сетевых запросов открытым текстом в локальное хранилище.
Автоматические сканеры безопасности проглядели это без труда — ModHeader получал низкий уровень риска, а некоторые проверки давали оценку до 95 из 100 баллов. Причины просты: данные шифровались, поэтому сканеры видели только бессмысленный набор символов; сама отправка была заблокирована пустым списком, так что песочницы не фиксировали исходящего трафика; вредоносный код был минифицирован и вплетён в легитимную кодовую базу; домены-адресаты не имели репутации вредоносных; а подписанное популярное расширение по умолчанию считается доверенным. Как формулируют это в Stripe OLT — подпись магазина доказывает, откуда взялся файл, но ничего не говорит о том, что этот файл делает.
Анализ доменной инфраструктуры добавил вопросов. Домен stanfordstudies[.]com не имеет никакой связи со Стэнфордским университетом — это перепрофилированный старый домен, за которым скрывается база данных на движке OpenSearch. Домен extensions-hub[.]com изначально настраивался для рекламных целей. На момент анализа оба домена указывали на один и тот же сервер Amazon, что намекает на единого оператора, хотя прямым доказательством не является.
Есть и косвенные признаки происхождения — упрощённая китайская локализация в настройках, маркер-«соль» в коде, записанный иероглифом 盐, почтовый провайдер китайского происхождения. Исследователи из Stripe OLT не назвали конкретную группу или человека, стоящего за этим — и не будем делать этого и мы, поскольку прямых доказательств нет.
У ModHeader и до этого была не безупречная репутация. В 2023 году на расширение поступали жалобы за внедрение рекламы в результаты поиска, и примерно тогда же оно, судя по всему, перешло на модель с рекламной монетизацией. Кто именно взял управление расширением после этого — неизвестно, исследователи не делают никаких заявлений об оригинальном разработчике. Любопытная деталь: официальный сайт ModHeader до сих пор публикует рекламный тариф, где заявляется полное отсутствие сбора пользовательских данных — что прямо противоречит найденному, хоть и неактивному, встроенному сборщику истории браузера. Разработчик на момент публикации результатов исследования никак не отреагировал.
Схема напоминает то, о чём ещё в 2021 году писал журналист Брайан Кребс — популярные расширения тихо скупаются и превращаются в инструменты сбора данных. Разница лишь в том, что в этом случае добавились шифрование и механизм ухода от детектирования через пустой список разрешений. 2025 год добавил похожих примеров: несколько расширений Chrome попадались на сборе данных под видом «анонимной аналитики», а другие маскировались под Workday и NetSuite, чтобы украсть сессионные куки. Проблема в том, что редакторы заголовков и менеджеры куки по самой своей природе требуют широкого доступа к браузеру — и когда доверие к таким инструментам подрывается, потенциальный ущерб получается огромным.
Обычным пользователям стоит удалить ModHeader из Chrome и Edge — вероятно, браузер уже автоматически его отключил. После удаления данные очищаются, но нужно проверить, не восстановит ли расширение синхронизация профиля или корпоративная политика управления расширениями. Если через ModHeader когда-либо вводились чувствительные данные — API-ключи, bearer-токены, сессионные куки — их нужно сменить, поскольку исследователи обнаружили, что функция хранения истории заголовков записывала полные HTTP-заголовки на диск.
Специалистам по информационной безопасности стоит блокировать и логировать на уровне DNS или прокси-сервера обращения к stanfordstudies[.]com и extensions-hub[.]com, а также проверить журналы на наличие идентификатора расширения и POST-запросов к api.stanfordstudies[.]com/app/log. Stripe OLT опубликовала готовые к использованию KQL-запросы для поиска подобной активности в Microsoft Defender и Sentinel.
Удаление конкретного расширения решает только эту конкретную проблему. Главная тревога в другом: внутри доверенного, широко используемого инструмента, прошедшего верификацию магазина, существовал полностью готовый сборщик данных, спроектированный, судя по всему, для активации через обычное обновление, которое просто заполнит пустой список разрешений. Автоматические сканеры признали его безопасным — и точно так же они, вероятно, признают безопасными следующие подобные инструменты, устроенные по той же схеме. Для тех, кто проверяет расширения перед публикацией или установкой в организации, из этой истории вытекают три конкретные вещи, на которые нужно обращать внимание: спящие участки кода, которые обычное тестирование никогда не активирует; новые адреса для связи с внешними серверами, вшитые в код; и функции, которые обычное обновление способно включить без предупреждения — особенно если у расширения сменился разработчик или владелец.
Расширение стояло у примерно 900 тысяч пользователей Chrome и порядка 700 тысяч пользователей Edge (по данным сторонних трекеров), суммарно около 1,6 миллиона установок. Microsoft убрала листинг в Edge 3 июля, Google последовала неделю позже — 10 июля. Анализировалась версия 7.0.18, идентификатор расширения — idgpnmonknjnojddfkpgkljpfnnfcklj.
Расследование провела британская компания Stripe OLT. Специалисты сверили код с подписью Google Web Store и подтвердили: это не подделка и не взломанная копия, а именно та версия, что официально раздавалась через магазин. Независимо это подтвердили HackIndex, разобравшие версию 7.0.18, и исследователь Юнус Айдин, изучивший версию 7.0.17. Обе команды описали одинаковую цепочку передачи данных.
Механизм устроен так. При первом запуске расширение строит цифровой отпечаток устройства и загружает зашитый в код ключ шифрования. Далее при обычном сёрфинге оно фиксирует домен каждой открытой страницы, шифрует его и складывает локально — до тысячи уникальных доменов. Раз в сутки собранный список вместе с отпечатком устройства отправляется на api.stanfordstudies[.]com, после чего локальная копия стирается. Время отправки для каждой установки смещено индивидуально — чтобы тысячи расширений не начали «сигналить» одновременно и не привлекли внимание сетевых мониторингов.
Почему же ничего не произошло? Потому что запуск всей цепочки контролируется внутренним списком разрешений, который в текущей версии поставляется пустым. Проверка всегда проваливается, и передача данных никогда не запускается. Никаких доказательств реальной утечки хотя бы одного домена исследователи не нашли. Проблема в другом: чтобы включить сбор, достаточно просто заполнить этот список — без новых разрешений, без клика пользователя, обычным тихим обновлением. Вся инфраструктура — ключ, конечная точка, планировщик отправки, логика хранения — уже лежит на компьютерах пользователей и ждёт команды.
При этом кое-что действительно работало, и работало активно. При установке, обновлении или удалении расширение связывалось с extensions-hub[.]com, передавая название продукта, версию и данные о браузере. А скрипт, запускавшийся на каждой открытой странице, вёл локальное журналирование — записывал метаданные реальных сетевых запросов открытым текстом в локальное хранилище.
Автоматические сканеры безопасности проглядели это без труда — ModHeader получал низкий уровень риска, а некоторые проверки давали оценку до 95 из 100 баллов. Причины просты: данные шифровались, поэтому сканеры видели только бессмысленный набор символов; сама отправка была заблокирована пустым списком, так что песочницы не фиксировали исходящего трафика; вредоносный код был минифицирован и вплетён в легитимную кодовую базу; домены-адресаты не имели репутации вредоносных; а подписанное популярное расширение по умолчанию считается доверенным. Как формулируют это в Stripe OLT — подпись магазина доказывает, откуда взялся файл, но ничего не говорит о том, что этот файл делает.
Анализ доменной инфраструктуры добавил вопросов. Домен stanfordstudies[.]com не имеет никакой связи со Стэнфордским университетом — это перепрофилированный старый домен, за которым скрывается база данных на движке OpenSearch. Домен extensions-hub[.]com изначально настраивался для рекламных целей. На момент анализа оба домена указывали на один и тот же сервер Amazon, что намекает на единого оператора, хотя прямым доказательством не является.
Есть и косвенные признаки происхождения — упрощённая китайская локализация в настройках, маркер-«соль» в коде, записанный иероглифом 盐, почтовый провайдер китайского происхождения. Исследователи из Stripe OLT не назвали конкретную группу или человека, стоящего за этим — и не будем делать этого и мы, поскольку прямых доказательств нет.
У ModHeader и до этого была не безупречная репутация. В 2023 году на расширение поступали жалобы за внедрение рекламы в результаты поиска, и примерно тогда же оно, судя по всему, перешло на модель с рекламной монетизацией. Кто именно взял управление расширением после этого — неизвестно, исследователи не делают никаких заявлений об оригинальном разработчике. Любопытная деталь: официальный сайт ModHeader до сих пор публикует рекламный тариф, где заявляется полное отсутствие сбора пользовательских данных — что прямо противоречит найденному, хоть и неактивному, встроенному сборщику истории браузера. Разработчик на момент публикации результатов исследования никак не отреагировал.
Схема напоминает то, о чём ещё в 2021 году писал журналист Брайан Кребс — популярные расширения тихо скупаются и превращаются в инструменты сбора данных. Разница лишь в том, что в этом случае добавились шифрование и механизм ухода от детектирования через пустой список разрешений. 2025 год добавил похожих примеров: несколько расширений Chrome попадались на сборе данных под видом «анонимной аналитики», а другие маскировались под Workday и NetSuite, чтобы украсть сессионные куки. Проблема в том, что редакторы заголовков и менеджеры куки по самой своей природе требуют широкого доступа к браузеру — и когда доверие к таким инструментам подрывается, потенциальный ущерб получается огромным.
Обычным пользователям стоит удалить ModHeader из Chrome и Edge — вероятно, браузер уже автоматически его отключил. После удаления данные очищаются, но нужно проверить, не восстановит ли расширение синхронизация профиля или корпоративная политика управления расширениями. Если через ModHeader когда-либо вводились чувствительные данные — API-ключи, bearer-токены, сессионные куки — их нужно сменить, поскольку исследователи обнаружили, что функция хранения истории заголовков записывала полные HTTP-заголовки на диск.
Специалистам по информационной безопасности стоит блокировать и логировать на уровне DNS или прокси-сервера обращения к stanfordstudies[.]com и extensions-hub[.]com, а также проверить журналы на наличие идентификатора расширения и POST-запросов к api.stanfordstudies[.]com/app/log. Stripe OLT опубликовала готовые к использованию KQL-запросы для поиска подобной активности в Microsoft Defender и Sentinel.
Удаление конкретного расширения решает только эту конкретную проблему. Главная тревога в другом: внутри доверенного, широко используемого инструмента, прошедшего верификацию магазина, существовал полностью готовый сборщик данных, спроектированный, судя по всему, для активации через обычное обновление, которое просто заполнит пустой список разрешений. Автоматические сканеры признали его безопасным — и точно так же они, вероятно, признают безопасными следующие подобные инструменты, устроенные по той же схеме. Для тех, кто проверяет расширения перед публикацией или установкой в организации, из этой истории вытекают три конкретные вещи, на которые нужно обращать внимание: спящие участки кода, которые обычное тестирование никогда не активирует; новые адреса для связи с внешними серверами, вшитые в код; и функции, которые обычное обновление способно включить без предупреждения — особенно если у расширения сменился разработчик или владелец.