Um coletor de histórico de navegação embutido na versão assinada permanecia inativo por causa de uma allow-list vazia, mas a chave de criptografia, o endpoint de call-home e o agendador já estavam na máquina e poderiam ser ativados por uma atualização de rotina.
| Componente | ModHeader, extensão de edição de cabeçalhos HTTP com cerca de 1,6 milhão de instalações somadas em Chrome e Edge, versão 7.0.18, identificador de extensão idgpnmonknjnojddfkpgkljpfnnfcklj. A versão analisada corresponde ao build genuíno assinado, confirmado contra a assinatura da Web Store, e não a uma cópia falsificada. |
| Vetor | O código de segundo plano minificado contém um coletor de histórico condicionado a uma allow-list interna distribuída vazia. Com a lista vazia, a verificação falha sempre e o pipeline não coleta nenhum domínio. A ativação exigiria apenas popular essa lista por uma atualização de rotina, sem novas permissões e sem qualquer interação do usuário. |
| Impacto | Risco condicionado de coleta dos domínios visitados, até 1000 distintos, criptografados localmente e enviados a um endpoint externo. No estado analisado o coletor estava dormente e não surgiu prova de que tenha reunido ou transmitido qualquer domínio. Já estavam ativos, porém, o beacon de telemetria de instalação, atualização e desinstalação e o registro local de metadados de requisição em texto claro. |
| Prioridade | Remover a extensão de Chrome e Edge, confirmar que sync de perfil ou política de extensão gerenciada não a reinstale, e bloquear, registrar e caçar os domínios de call-home no DNS e no proxy. |
| IoCs | Domínios defangados stanfordstudies[.]com e extensions-hub[.]com, e o endpoint api.stanfordstudies[.]com/app/log. Segundo a análise, os dois endpoints de API resolviam para o mesmo servidor Amazon no momento do estudo. |
Google e Microsoft retiraram de suas lojas a extensão ModHeader, uma ferramenta popular de edição de cabeçalhos HTTP com cerca de 1,6 milhão de instalações somadas entre Chrome e Edge, depois que pesquisadores identificaram um coletor de histórico de navegação embutido na própria versão publicada na loja oficial. A análise técnica foi conduzida pela empresa de segurança britânica Stripe OLT, que comparou o código com a assinatura da Web Store do Google e confirmou que o coletor foi distribuído dentro da extensão genuína, e não em uma cópia falsificada. A revisão cobriu o build do Chrome, com cerca de 900 mil usuários, enquanto rastreadores de terceiros estimavam outros 700 mil no Edge. A Microsoft removeu a listagem do Edge em 3 de julho e o Google retirou a versão do Chrome uma semana depois, em 10 de julho.
O ponto central não é a funcionalidade anunciada, que continua editando cabeçalhos HTTP na versão 7.0.18, e sim um segundo sistema presente no código de segundo plano minificado. Esse componente permanecia dormente porque sua ativação depende de uma allow-list interna distribuída vazia, de modo que a verificação falha a cada execução e o pipeline de coleta é interrompido antes de reunir qualquer domínio. A preocupação técnica está no fato de que a chave de criptografia embutida, a URL do endpoint, o agendador e a lógica de armazenamento já estão instalados na máquina do usuário: preencher a lista seria uma alteração pequena, entregue como atualização de rotina, sem novas permissões e sem clique do usuário. Teardowns independentes, descritos por HackIndex sobre a versão 7.0.18 e pelo pesquisador Yunus Aydin sobre a 7.0.17, relataram o mesmo fluxo.
Na primeira execução, o componente oculto constrói uma impressão digital do dispositivo e carrega uma chave de criptografia embutida no código. À medida que o usuário navega, ele captura o domínio de cada página aberta, criptografa esse valor e o armazena localmente, acumulando até 1000 domínios distintos. Uma vez por dia, um agendador agrupa a lista criptografada com a impressão digital do dispositivo, envia o pacote para o endpoint defangado api.stanfordstudies[.]com e apaga a cópia local. O horário de envio é deslocado por instalação, o que evita que todos os navegadores com o coletor ativo emitissem o beacon ao mesmo tempo, um sinal de projeto orientado a passar despercebido em telemetria de rede.
A ativação de toda essa cadeia está condicionada a uma allow-list interna: o coletor só roda se o navegador corresponder a uma entrada da lista, e essa lista é distribuída vazia, o que mantém o fluxo desligado. Nem todo o comportamento, porém, estava adormecido. Em instalação, atualização e desinstalação, a extensão emitia um beacon para o domínio defangado extensions-hub[.]com, informando produto, versão e navegador. Além disso, um script executado em todas as páginas já vinha registrando metadados reais de requisição em armazenamento local em texto claro, o que indica que essa parte estava efetivamente em funcionamento. A Stripe OLT associou os domínios a infraestrutura real e mantida: stanfordstudies[.]com não tem relação com Stanford e é um domínio antigo reaproveitado, servindo de fachada para um back end OpenSearch, enquanto extensions-hub[.]com está configurado para publicidade. Os dois endpoints de API resolviam para o mesmo servidor Amazon no momento da análise, o que é compatível com um único operador, sem, no entanto, provar essa hipótese.
A superfície de risco abrange usuários das versões afetadas do ModHeader em Chrome e Edge, com destaque para ambientes onde a extensão foi instalada de forma ampla ou distribuída por política gerenciada. Como o coletor está no build assinado e verificado, controles que confiam apenas na origem e na assinatura do arquivo não sinalizam o comportamento, já que a assinatura de loja comprova de onde o arquivo veio, não o que ele faz. O texto do próprio plano de anúncios do ModHeader afirma não coletar dados de usuário, o que é difícil de conciliar com a presença de um coletor de histórico embutido, ainda que desligado.
- Instalações do ModHeader em Chrome e Edge, incluindo a versão 7.0.18 e a versão 7.0.17 citada nos teardowns.
- Extensão identificada pelo ID idgpnmonknjnojddfkpgkljpfnnfcklj, distribuída pelos canais oficiais das lojas.
- Perfis com sync habilitado ou políticas de extensão gerenciadas, que podem reintroduzir a extensão após a remoção manual.
- Ambientes que dependem de checadores automatizados, que chegaram a classificar a extensão como de baixo risco, com notas de até 95 de 100.
A caça deve focar nos artefatos de call-home e no identificador da extensão, já que o pipeline de coleta pode estar presente mesmo sem evidência de exfiltração ativa. Como a análise aponta que o coletor estava dormente, o objetivo do hunting é confirmar presença, contatos de rede observados e persistência via sync ou política, e não presumir vazamento de histórico que não foi comprovado. A Stripe OLT publicou consultas de caça em KQL prontas para Microsoft Defender e Sentinel, úteis como ponto de partida para correlacionar instalações e contatos de rede.
- Contatos de DNS e proxy para os domínios defangados stanfordstudies[.]com e extensions-hub[.]com.
- Requisições POST para o endpoint defangado api.stanfordstudies[.]com/app/log.
- Presença do ID de extensão idgpnmonknjnojddfkpgkljpfnnfcklj no inventário de navegadores gerenciados.
- Beacons de instalação, atualização e desinstalação carregando produto, versão e navegador para extensions-hub[.]com.
- Registros locais de metadados de requisição gravados em texto claro pelo script executado em páginas.
A resposta imediata é remover a extensão de Chrome e Edge; em muitos casos o navegador pode tê-la desativado automaticamente após as remoções das lojas. A desinstalação limpa os dados armazenados pela extensão, então o cuidado adicional é garantir que o sync de perfil ou uma política de extensão gerenciada não a reinstale silenciosamente. No plano de rede, bloquear e registrar os domínios de call-home reduz o risco caso o pipeline seja ativado por uma atualização futura, e o monitoramento contínuo desses indicadores ajuda a detectar tentativas de reintrodução. O episódio também reforça uma lição de processo: a revisão de extensões precisa considerar caminhos de código dormentes que os testes nunca acionam, novos endpoints de call-home e capacidades que uma atualização de rotina pode habilitar após uma troca de mãos, especialmente quando ferramentas assinadas e populares são lidas como confiáveis por padrão.
- Remover o ModHeader de Chrome e Edge e validar que a extensão não permanece instalada.
- Confirmar que sync de perfil e políticas de extensão gerenciada não reinstalam a extensão.
- Bloquear e registrar stanfordstudies[.]com e extensions-hub[.]com no DNS e no proxy.
- Caçar nos logs o ID da extensão e requisições POST para api.stanfordstudies[.]com/app/log.
- Revisar critérios de aprovação de extensões para tratar código dormente e novos endpoints como sinais de risco, não apenas assinatura e reputação.
0 Comentários