Phishing con correos autenticados de Google: respuestas automáticas, Google Sites e indicios de relay de autenticación

Versión 2 — revisión mayor (2026-10-04). Este artículo se ha reescrito tras una contrarrevisión externa y una comprobación propia de varias de sus afirmaciones. Se retiran dos «fingerprints» que resultaron ser componentes de la plataforma Google Sites, se corrige la cadena de red atribuida a un scan de URLScan, se reformula el vector del correo y se rebaja la certeza de varias capacidades del kit. Lo que cambia y por qué está en la fe de erratas. Las afirmaciones retiradas ya no aparecen en el cuerpo ni en las tablas.

Índice

1. Qué demuestra este caso y qué no
2. El correo: un autorespondedor de Google
3. Google Sites como contenedor del señuelo
4. Qué páginas están relacionadas (y con qué fuerza)
5. Infraestructura observada
6. El kit «gats»: qué contiene el código y qué no prueba
7. Timeline
8. Preguntas abiertas
9. Indicadores, por uso
10. MITRE ATT&CK
11. Por qué SPF, DKIM y DMARC no bastan (y qué sí ayuda)
12. Regla YARA
13. Inventario de evidencias
14. Fe de erratas 2026-10-04
15. Historial de actualizaciones
16. Apéndice — indicadores en texto plano

El 30 de mayo de 2026 recibí un correo de security-noreply@google.com con SPF, DKIM y DMARC válidos y un enlace de phishing en el asunto. Este artículo documenta lo que se puede demostrar a partir de él.

Qué demuestra este caso y qué no

Separo tres niveles: observado (hay un artefacto que lo muestra), inferido (compatible con lo observado, sin prueba directa) y no demostrado (afirmado en la versión anterior sin base suficiente).

El correo: un autorespondedor de Google

De:        security-noreply@google.com
Responder: noreply@google.com
Asunto:    Re: Account recovery initiated. Wasn't you? Secure your account: sites.google.com/view/G-733828
Recibido:  Fri, 29 May 2026 23:43:40 -0700  (= 2026-05-30 06:43 UTC, Received del buzón)
IP:        209.85.220.69  (mail-sor-f69.google.com)
SPF:       pass  (MAIL FROM en *.apphosting.bounces.google.com)
DKIM:      pass  (d=google.com, s=20251104)
DMARC:     pass  (p=REJECT, alineado por DKIM)
App-ID:    s~google.com:roach-hotel
Gmail:     etiqueta Spam visible en la captura

Lo que muestra la captura es un autorespondedor, no una notificación de recuperación de cuenta. El cuerpo dice que el buzón no lo lee nadie, remite a bughunters.google.com y aclara que ese canal no resuelve problemas de seguridad de la cuenta. El asunto empieza por Re: y reproduce un texto que no escribe Google: el señuelo con la URL. El campo h= de ARC-Message-Signature enumera auto-submitted, in-reply-to y references, típicas de una respuesta automática; esa enumeración no demuestra por sí sola que existan en el mensaje, y su presencia y valores habría que verificarlos en el original.

La lectura más sencilla: alguien envió un mensaje a un buzón de Google con autorespuesta, con el señuelo como asunto, y la respuesta acabó en el buzón de la víctima. Cómo se dirigió esa respuesta a la víctima (remitente falsificado en el mensaje que la desencadenó, backscatter u otro mecanismo) no está confirmado: para eso haría falta el mensaje desencadenante. El texto «Account recovery initiated» forma parte del señuelo y no prueba que se usara un flujo real de recuperación.

Dos matices que la versión anterior no recogía:

• Fecha. La cabecera Received del buzón está en -0700. El correo se recibió el 30 de mayo a las 06:43 UTC, no el 29.
• Entrega. El mensaje aparece con la etiqueta Spam en la captura. No se ha establecido si se entregó allí o se movió después, ni si intervino una clasificación automática, una regla o una acción manual. Esta imagen no sirve para evaluar la eficacia de los filtros.

Los correos vía Google Workspace (Marketo)

Otros dos correos (29 de mayo a las 01:27 UTC y 30 de mayo a las 12:13 UTC) salieron de workspace@google.com a través de Marketo. Son la respuesta automática a un formulario de contacto de Google Workspace, con el señuelo metido en un campo libre:

From:   Google Workspace <workspace@google.com>
Via:    Marketo (oak.mktdns.com, 199.15.214.195)
SPF/DKIM/DMARC: pass
Texto reflejado: "We noticed a new sign-in from Miami, Florida [...]
                  secure your account: sites.google.com/view/g-733828"

808-GJW-314 (el identificador de la cuenta de Marketo de Google) y la cabecera X-MSYS-API con el tracking desactivado son de la plataforma emisora, no del atacante: las fija la plantilla de Google/Marketo. Los dos llegan a alias distintos de la dirección de la víctima (+api6506976 y +api4020596), que alguien tuvo que escribir al rellenar el formulario. Es compatible con un identificador por envío o por víctima, pero no demuestra su función exacta ni que esté automatizado.

Secuencia de los tres correos. Para comparar los tres se usa la misma referencia: la cabecera Received que añade el servidor de Gmail del buzón de destino (mismo servidor en los tres), normalizada a UTC. Son horas de recepción, no de envío, así que no se interpretan como cadencia del atacante.

La versión anterior daba «25 horas» entre los dos primeros a partir de fechas sin normalizar.

Google Sites como contenedor del señuelo

Google Sites no hace de proxy: la página es un contenedor visual dentro de un dominio de confianza, y el navegador carga el contenido del atacante como un documento incrustado, con sus propias reglas de origen. Las seis páginas preservadas usan dos formas de incrustar.

Iframe por código (G-733828 y g-798225, idénticas):

<style>
  body, html { margin: 0; padding: 0; height: 100%; overflow: hidden; }
  iframe     { width: 100%; height: 100vh; border: none; overflow: hidden; }
</style>
<iframe
    src="hxxps://123753243[.]com/v3/identity/login"
    allow="clipboard-read; clipboard-write;"
    scrolling="no">
</iframe>

g-624594 apunta al mismo destino con otro snippet: allow="camera;microphone" y sandbox="allow-scripts allow-same-origin allow-popups allow-forms allow-top-navigation".

Embed de página completa por URL («Whole page embed»: case-159331, ticket-179902, ticket-925681). Aquí el autor del sitio solo indica una URL, que Google carga a través de su propio frame de embeds.

Sobre el portapapeles: allow="clipboard-read; clipboard-write" declara que el contenido incrustado puede usar esas funciones, sujetas a la política de permisos efectiva del navegador, el foco y la interacción del usuario; no significa que el acceso se conceda. En los artefactos preservados examinados (shim.js y el HTML del login) no se identificaron llamadas a la API del portapapeles, ni se observó captura alguna.

Qué páginas están relacionadas (y con qué fuerza)

La búsqueda en URLScan de páginas de Google Sites con títulos de login devolvió seis con el patrón sites.google.com/view/(g|G|ticket|case)-NNNNNN, indexadas entre diciembre de 2025 y mayo de 2026. Guardé el HTML de cada una.

La versión anterior presentaba dos valores comunes a las seis páginas como el fingerprint del actor: productName: 6b8ce7c0… y un «embed hash» 16cb204c…. Ninguno de los dos distingue nada:

• productName aparece en el mismo bloque de configuración de plataforma (window['ppConfig']) en páginas legítimas de Google Sites. Lo he comprobado en tres sitios sin relación con el caso, dos de ellos con URLs /view/ como las del actor.
• El «embed hash» es un segmento de la ruta del frame de embeds genérico de Google (<N>-atari-embeds.googleusercontent.com/embeds/16cb204c…/inner-frame-minified.html). Aparece en incidencias públicas ajenas a este caso, como la #7131 de Ruffle (junio de 2022), y en informes públicos de sandbox.

Quitados esos dos valores, la relación entre páginas se apoya solo en lo que controla el autor de cada sitio:

El scan de julio lo envió un tercero a URLScan (019f32f6-c0bd-74ab-aae1-0cf9a04c697d, 2026-07-05 15:47 UTC). Registra:

sites.google.com/view/ticket-7371564   (título "Signin")
  └─ embed → xvcbxcvxncvbn[.]xyz/v3/signin/identifier?_g=…   (tras Cloudflare)
       └─ GET xvcbxcvxncvbn[.]xyz/shim.js   HTTP 200, 16.613 bytes
            SHA256 9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e   (= muestra de mayo)

Lo que se puede sostener: las tres páginas de mayo comparten destino, y el mismo componente cliente (shim.js) se reutilizó en dos dominios distintos, en mayo y en julio. Ni lo uno ni lo otro demuestra un mismo operador, un backend idéntico ni continuidad operativa entre ambas fechas. Que case-159331 y las páginas ticket- de diciembre de 2025 a mayo de 2026 tengan relación con todo esto es una hipótesis razonable, pero no está demostrada. Por eso se retira la afirmación de «al menos seis meses de actividad confirmada».

Hay que distinguir misma técnica (Google Sites como contenedor), mismo componente de código (mismo shim.js), misma infraestructura y mismo operador. Hay prueba fuerte de misma infraestructura para las tres páginas de mayo y de mismo componente entre mayo y julio. Mismo operador no está demostrado.

Infraestructura observada

123753243[.]com

Registrado el 2026-05-23 en NICENIC (IANA 3765). Resolvía a IPs anycast de Cloudflare, así que no es accionable a nivel de IP. Sirvió el login falso y shim.js el 30 y 31 de mayo. El 2026-06-04 se observó en clientHold y sin resolver. Se había enviado un abuse report el 2026-05-30. La relación causal no está confirmada: solo consta que la suspensión se observó cuatro días después del reporte. RDAP last changed (2026-06-04T17:20:05Z) registra un cambio en el objeto, sin decir qué campo cambió.

El primer certificado del dominio aparece en CT 12 minutos después del registro. Es compatible con un aprovisionamiento automático del proveedor DNS/CDN, pero no indica que toda la infraestructura estuviera operativa a esa hora.

view-requests[.]com y 45[.]92[.]1[.]158

Registrado el 2026-03-14 en NICENIC. La observación más sólida es el scan de URLScan del 2026-05-06 sobre case-159331 (019dfe9e…), anterior a esta investigación:

sites.google.com/view/case-159331
  └─ embed → view-requests[.]com  →  45[.]92[.]1[.]158   (HTTP 200, cert Let's Encrypt E8 servido en esa conexión)
       ├─ POST view-requests[.]com/api/status  (×6)  →  45[.]92[.]1[.]158
       └─ GET  ipapi.co/json/  (×4)            →  172.67.69.226 (Cloudflare, el servicio ipapi.co)

La versión anterior lo resumía como «Google Sites → view-requests → Cloudflare → 45.92.1.158». Era incorrecto: la IP de Cloudflare del scan es la de ipapi.co (un servicio de geolocalización por IP que la página consulta), no un salto intermedio hacia el dominio malicioso. El 6 de mayo el dominio ya se servía directamente desde 45[.]92[.]1[.]158.

Dos detalles de ese scan:

• La API de cliente de view-requests[.]com (POST /api/status + consulta a ipapi.co) no es la de shim.js (/api/sessions/...). Puede ser otra fase del flujo (por ejemplo, un filtro previo al login), otra versión u otro kit. No hay vínculo de código con «gats».
• Ese día, en esa conexión, se sirvió un certificado Let’s Encrypt de view-requests[.]com desde la IP. Es una observación de handshake para ese dominio y esa fecha, y no se puede generalizar a otros dominios ni a otras fechas.

Observaciones posteriores (junio-agosto de 2026, desde un nodo aislado): en las peticiones y valores de SNI ensayados (accesos únicos, sin rutas ni tokens del kit) se observó HTTP 406, un certificado *.yandex.tr y cabeceras con marcadores de Yandex (x-yandex-req-id con identificadores de distintos datacenters, cookies _yasc). Lo trato como una observación distinta, sin demostrar que sea el mismo servicio que funcionaba en mayo:

• Un 406 aislado tiene varias explicaciones posibles (selección de virtual host, política de la aplicación, otro componente de red). No identifica el mecanismo de filtrado. CF-Connecting-IP es una cabecera que Cloudflare añade a la petición hacia el origen, así que su ausencia en una respuesta no significa nada.
• Los marcadores de Yandex son compatibles con una capa compartida de Yandex Cloud, con un tenant o con un proxy que reenvía respuestas de otro servicio. No permiten atribuir la administración de la máquina.
• El puerto 22 que reporta Censys no está confirmado como del actor.

Las renovaciones de certificados observadas para view-requests[.]com son compatibles con automatización y no prueban intervención humana; el mecanismo concreto no se ha determinado. Que 123753243[.]com dejara de tener emisiones nuevas tras su suspensión coincide en el tiempo, pero no es un control experimental: clientHold retira el dominio del DNS y no demuestra que el actor perdiera acceso al backend. Que un certificado sea wildcard prueba lo que cubre y la validación correspondiente, no que haya subdominios desplegados. La CA emisora, por sí sola, no indica si un certificado está en el origen o en el edge.

Coincidencias de proveedor

Los dos dominios comparten registrador (NICENIC) y usan pares distintos de nameservers de Cloudflare. Que coincida el registrador discrimina poco: es un registrador muy usado en abuso, y la coincidencia solo sirve combinada con evidencia técnica más específica. Los pares de NS distintos indican configuraciones DNS distintas. Una misma cuenta de Cloudflare puede recibir pares diferentes, así que no se puede deducir ni la identidad de las cuentas ni que hubiera una separación deliberada. La IP 45[.]92[.]1[.]158 aparece en un feed de ISC de 2023, pero eso no extiende la operación a ese año.

El kit «gats»: qué contiene el código y qué no prueba

Entre el 30 y el 31 de mayo, 123753243[.]com servía una réplica del login de Google y el script /shim.js (16.613 bytes, SHA256 9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e). El código usa «gats» como nombre interno (gats-session, window.gats, gats-bouncing) y su cabecera lo describe como «shared client glue loaded by every sign-in template». «gats» es una etiqueta tomada del código, no la identidad de un actor ni de un producto comercial.

Qué hay en el código

• Una API de sesión: POST /api/sessions, polling de GET /api/sessions/:id/status cada ~800 ms, POST /api/sessions/:id/action (acciones retry_email, change_account, retry) y DELETE /api/sessions/:id.
• Rutas para el flujo de login completo de Google: contraseña, selección de método, TOTP, SMS, push con number matching, códigos de respaldo, pruebas de identidad por email y teléfono, /challenge/wa (WebAuthn), cambio forzado de contraseña, una pantalla de espera (/verify) y otra de rechazo (/rejected).
• Dos comentarios que mencionan «Kameleo profile» (por ejemplo: «retry_email action so the same Kameleo profile navigates back with the corrected email»).
• Gestión explícita de las restricciones de cookies de Safari y de la partición de iframes, compatible con un diseño pensado para funcionar dentro de un embed.
• La palabra «Google» construida carácter a carácter (["G","o","o","g","l","e"].join("")). Es compatible con un intento de evitar firmas de texto, aunque la intención no consta.
• Una cookie _theme que elige el esquema de color claro u oscuro en el cliente. Es una preferencia de interfaz: no demuestra que exista un panel de administración.

Escala de evidencia por capacidad

Clasificación: kit de phishing con indicios sólidos de diseño para relay de autenticación (AiTM). No está verificado públicamente que funcione con cada método MFA. Un kit de phishing puede implementar AiTM, así que la oposición «plataforma AiTM, no un kit» de la versión anterior se retira. Que lo opere un navegador Kameleo, que haya un perfil por víctima y dónde se ejecuta ese navegador son inferencias a partir de dos comentarios. Sobre WebAuthn: la ruta /challenge/wa solo indica que el flujo contempla ese estado. Las passkeys están vinculadas criptográficamente al origen, que es cualitativamente distinto de teclear un OTP en una página falsa.

El código no coincide con los kits públicos que revisé (Evilginx, EvilProxy, Tycoon 2FA, Rockstar 2FA, Sneaky 2FA, Mamba 2FA, Greatness, ONNX/Caffeine). Esa comparación no se documenta aquí en detalle, así que debe leerse como orientativa, y en ningún caso es una prueba de desarrollo propio: podría ser un PhaaS privado o un fork. La calidad de los comentarios es una decisión de diseño documentada y no dice nada sobre la autoría o la experiencia de quien lo escribió.

Timeline

Horas en UTC. La columna «Evidencia» indica de dónde sale cada dato.

2025-12-02   ticket-925681 indexada (embed → túnel trycloudflare)     URLScan; vínculo con gats NO demostrado
2026-03-14   Registro view-requests[.]com (NICENIC)                    RDAP
2026-03-15   view-requests[.]com → 45[.]92[.]1[.]158                   OTX passive DNS
2026-05-06   case-159331 → view-requests[.]com @ 45[.]92[.]1[.]158     URLScan 019dfe9e (transacciones + cert)
2026-05-23   Registro 123753243[.]com (NICENIC)                        RDAP / CT
2026-05-29   01:27  Correo vía Workspace/Marketo, señuelo G-733828      Received del buzón
2026-05-30   06:43  Correo autorespondedor security-noreply@google.com Received del buzón; etiqueta Spam
2026-05-30   12:13  Segundo correo vía Workspace/Marketo, mismo señuelo Received del buzón
2026-05-30   Abuse report a NICENIC
2026-05-30/31 123753243[.]com sirve login falso + shim.js (gats)       Muestra preservada (E-04)
2026-06-04   123753243[.]com observado en clientHold                   RDAP (last changed 17:20:05Z); causalidad no confirmada
2026-06/08   45[.]92[.]1[.]158 responde 406 con marcadores Yandex      Accesos únicos desde nodo aislado
2026-07-05   ticket-7371564 → xvcbxcvxncvbn[.]xyz carga el mismo shim.js  URLScan 019f32f6, scan de un tercero (E-06)
2026-08-21   Menos candidatas nuevas en URLScan                        Visibilidad de una fuente, no ritmo real
2026-10-04   Control negativo: productName / embed hash son de Google  HTML de páginas legítimas de Google Sites

Preguntas abiertas

• Cómo se desencadenó el autorespondedor y cómo llegó la respuesta a la víctima. Hace falta el mensaje desencadenante, que no tengo. El abuso está reportado al programa de vulnerabilidades de Google (bughunters.google.com), que es quien puede ver ese lado.
• Qué es view-requests[.]com respecto a «gats». El 6 de mayo usaba otra API de cliente. ¿Es una fase previa al login, otra versión u otro kit?
• Si las páginas ticket- de diciembre de 2025 a mayo de 2026 son del mismo operador. No se conserva el contenido de los túneles.
• «Miami, Florida» en los asuntos. La explicación más sencilla es que forma parte del texto inventado del señuelo. Las alternativas (que salga de la infraestructura del atacante o del perfil de la víctima) no tienen respaldo.
• Efectividad del relay por método MFA. Requeriría una prueba de laboratorio controlada que no se ha hecho.

Indicadores, por uso

Bloqueo específico

123753243[.]com                       # clientHold observado el 2026-06-04; útil en retrospectiva
hxxps://123753243[.]com/v3/identity/login
xvcbxcvxncvbn[.]xyz                   # sirvió shim.js el 2026-07-05 (scan 019f32f6); estado actual no verificado
shim.js  SHA256 9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e
sites.google.com/view/G-733828
sites.google.com/view/g-798225
sites.google.com/view/g-624594
sites.google.com/view/ticket-7371564

Hunting con contexto (requiere revisión humana)

view-requests[.]com                   # vínculo con gats no demostrado; sí asociado a case-159331 (2026-05-06)
sites.google.com/view/case-159331
Patrón de slug: sites.google.com/view/(g|G|ticket|case|portal|verify)-[0-9]{6,7}
                # combinado con título de login de Google y un embed hacia un dominio externo
Correo de google.com cuyo asunto o cuerpo refleja una URL de sites.google.com/view/...
Regla YARA GATS_AiTM_shimjs (v7)      # firma de esta build, ver sección YARA

Infraestructura compartida o de plataforma: no bloquear de forma indiscriminada basándose solo en este informe

45[.]92[.]1[.]158                     # asociada a view-requests[.]com el 2026-05-06; después, marcadores Yandex y posible capa compartida
security-noreply@google.com, workspace@google.com, noreply@google.com
X-Google-Appengine-App-Id: s~google.com:roach-hotel
Marketo 808-GJW-314, oak.mktdns.com [199.15.214.195]
X-MSYS-API con tracking desactivado
NICENIC (IANA 3765)                   # registrador muy usado; baja discriminación

Histórico (sin contenido preservado)

aimed-activities-erik-magnetic.trycloudflare.com          # ticket-925681
nursing-nominations-spirituality-origin.trycloudflare.com # ticket-179902

Retirados en esta versión

productName 6b8ce7c01e3dacd3d2c7a8cd322ff979   # configuración de plataforma de Google Sites
embed hash  16cb204cf3a9d4d223a0a3fd8b0eec5d   # ruta del frame de embeds genérico de Google
hxxps://view-requests[.]com/v3/...             # rutas nunca observadas en ese dominio

MITRE ATT&CK

ATT&CK Enterprise consultado el 2026-10-04. Estados: observado / inferido.

Retiradas respecto a la versión anterior:

• T1102 y T1665 están en la táctica Command and Control, no en Defense Evasion, y aquí no hay evidencia del uso de C2 que describen.
• T1056.003 describe código instalado en portales expuestos reales, no un clon de login.
• T1566.003 no se añade: se mantiene T1566.002 como mapeo principal del enlace de phishing. T1566.003 sí puede incluir el correo web personal, así que el uso del email no la excluye; falta justificar cómo el abuso de estos servicios encaja en su alcance.
• T1036.005 se sustituye por T1656, que encaja mejor.

Por qué SPF, DKIM y DMARC no bastan (y qué sí ayuda)

Los tres protocolos comprueban cosas distintas. SPF comprueba si la IP está autorizada para la identidad SMTP (MAIL FROM). DKIM vincula una firma criptográfica al dominio d=. DMARC exige que uno de los dos esté alineado con el dominio del From: visible. Ninguno evalúa si el contenido es legítimo, y el propio estándar DMARC advierte de que un resultado positivo no garantiza que el mensaje sea seguro o deseable. Si un servicio autorizado refleja texto que controla un tercero (un asunto en una autorespuesta, un campo de formulario), el resultado es un correo de phishing con autenticación perfecta.

El mensaje aparece con la etiqueta Spam, pero no se ha establecido cómo llegó ahí, así que este caso no permite valorar la eficacia de los filtros. Leer las cabeceras sí sirvió: de ellas salen la plataforma emisora, la cronología y el propio vector (el asunto es una cabecera). Lo que no basta es quedarse con tres pass.

Lo que ayuda:

• Reglas que combinen el contenido del mensaje, la URL completa, el destino incrustado en la página y el comportamiento, en lugar de bloquear remitentes legítimos o todo Google Sites.
• Análisis del destino final de los enlaces, incluido el contenido incrustado en páginas de plataformas de confianza.
• MFA resistente al phishing (FIDO2/WebAuthn, passkeys) donde el entorno lo permita, revisando los métodos alternativos y de recuperación: si la política los permite, un atacante podría inducir al usuario a emplear un mecanismo menos resistente. Ese comportamiento no se ha demostrado en este caso. La razón técnica es la vinculación al origen; no es una inmunidad absoluta frente a cualquier compromiso de cuenta.
• Formar a los usuarios para que juzguen el destino y no el remitente.

BIMI no habría cambiado nada aquí: el remitente era legítimo.

Regla YARA

Descarga: gats_aitm.yar (v7). Es una firma de hunting para esta build concreta de shim.js, basada en strings literales. No es una firma estructural del framework, y cada coincidencia necesita revisión humana.

Lo verificado (yara 4.5.5 sobre la muestra preservada):

• Coinciden los 15 identificadores de string declarados, con 36 apariciones en total (antes se publicaba como «36/36 strings», que mezclaba identificadores con apariciones).
• Evasión: si se renombra el codename gats y se cambia el comentario de cabecera ($h1), la regla deja de disparar aunque se conserve «Kameleo profile» ($k1), porque la rama 4 necesita dos strings $s*. La v6 decía que también había que cambiar $k1, y era incorrecto. Si solo se renombra gats, la regla sigue disparando por la rama 2.
• Análisis estático, no ensayado: $a1, $g1, $h1 y $k1 aparecen solo en comentarios, así que un proceso que los elimine dejaría de encontrarlos. No se ha probado un minificador concreto ni su efecto final sobre la condición.
• Dispara también sobre texto que describe el kit (informes, este mismo artículo). Un match no indica que la muestra esté presente.

Limitaciones de la validación publicada:

• El negativo (0 coincidencias en 58.208 ficheros JS locales) mide ficheros, no ejemplos independientes. El corpus no está publicado ni deduplicado.
• No se han probado transformaciones benignas como la minificación o el reformateo.
• Las revisiones con dos modelos de IA ayudan a encontrar fallos, pero no cuentan como dos fuentes independientes.

Cambios de la v6 a la v7, comprobados con diff: 4 líneas de metadatos (modified, version, fp_validation y scope). Los bloques strings y condition son idénticos.

gats_aitm.yar v6  SHA256 e0f7b287ae16459084f8368758f890af8874b6237457efcfdb8412828e114a6c
gats_aitm.yar v7  SHA256 51feefbc66ddb415d5e781d49f4a526b922f17c5ccd776095b982725db97926c

Inventario de evidencias

# E-03 · HTML de las páginas (SHA256)
G-733828       85eb7ceda2a87124f60bda4d56aad945425aad17f43aa6decefc1e3410afdb14
g-798225       200764fcb0e9de77af48559c9349efa2a9ce1e8d10897916e2e7c6e1fba3d241
g-624594       7ae9f36baf5e75e04e077ba93d0ae7bd61b95bb02742cd91eb8f8de7a613d304
case-159331    0486fed8da5cb14d5bc19a541a8b6dcb2bf6fcde9e60352cde6fef36dfc68acf
ticket-179902  fd925794461f270856e8223e07ca12ffa282033a14d4021f2223a349d17a2871
ticket-925681  19df54fca42a228752ebad868fa04eea2b15fb7ecf49a86a3f5c7a31cc1a34f9

# E-07 · controles negativos (HTML descargado el 2026-10-04, SHA256)
https://sites.google.com/uchicago.edu/yudeng   7650948ed4ff3c4a956acc0320b749a590e72be345c3e6a0ca38b326d5368460
https://sites.google.com/view/yuding/home      499dbfb75c1b928e475d8ba5923b461a565c80bd0f2f28389a673b468df11088
https://sites.google.com/view/sites-help       698daf1b0bc3cd82214cd4f2aa84ef4a466aeb2f8a0854141d8b11ca252872f3
# En los tres: window['ppConfig'] = {productName: '6b8ce7c01e3dacd3d2c7a8cd322ff979', ...}

Las páginas del actor y los correos no se publican íntegros porque contienen URLs activas o datos personales. Se pueden facilitar a investigadores bajo petición.

Fe de erratas 2026-10-04

Esta revisión corrige errores concretos de agrupación, de interpretación de red, del vector del correo, del alcance de las capacidades atribuidas y de varias interpretaciones de infraestructura. Se agrupan en cinco bloques; el detalle está en la tabla desplegable.

1. Agrupación de páginas. Los dos «fingerprints del cluster» (productName y el embed hash) son componentes de la plataforma Google Sites. Sin ellos, no se sostienen las seis páginas como una única operación ni los «seis meses de actividad». Lo demostrado es el mismo destino para tres páginas de mayo y el mismo componente cliente en mayo y en julio.
2. Red. La cadena «Google Sites → view-requests → Cloudflare → 45.92.1.158» confundía una consulta a ipapi.co con un salto de red. Las rutas /v3/... atribuidas a view-requests[.]com nunca se observaron en ese dominio.
3. El correo. El artefacto observado es una autorespuesta; no se ha demostrado que la desencadenara Account Recovery. Se recibió el 30 de mayo (UTC), no el 29; aparece con la etiqueta Spam; y el intervalo de «25 horas» era incorrecto.
4. Capacidades del kit. Relay de MFA, Kameleo, panel de administración, captura del portapapeles y «desarrollador senior» pasan de confirmados a inferidos o retirados. La oposición «plataforma AiTM, no un kit» se retira.
5. Interpretaciones de infraestructura. CA ≠ posición en la red, wildcard ≠ subdominios, renovación ≠ mantenimiento, 406 ≠ filtrado por cabeceras, registrador común ≠ nexo de atribución, NS distintos ≠ cuentas distintas, proximidad temporal ≠ causalidad del abuse report. MITRE corregido.

Qué ha fallado en el proceso

Las re-verificaciones anteriores (9 de junio, 4 de julio, 21 de agosto) repitieron consultas y confirmaron que los datos seguían ahí, pero no pusieron a prueba las interpretaciones. La del 9 de junio llegó a decir que «todo el cuerpo técnico se confirmó», y no era así: los errores de este bloque ya estaban en el texto y en la evidencia preservada. Comprobaban si la infraestructura existía, no si las conclusiones se seguían de ella.

Qué cambio en mi método

• Control negativo antes de llamar fingerprint a algo: comprobar el valor contra páginas legítimas de la misma plataforma.
• Cada arista del grafo con su origen: URL, frame que la inicia, destino, fecha y tipo de evidencia. Una lista plana de IPs contactadas no es una cadena.
• Todas las fechas en UTC antes de calcular intervalos.
• Escala de evidencia para capacidades: una ruta o un comentario en el código no confirman que algo funcione.
• Las re-verificaciones intentan refutar, no solo repetir consultas.

Historial de actualizaciones

• 2026-05-30. Publicación inicial. Ese mismo día llega el segundo correo vía Workspace/Marketo, con el mismo señuelo.
• 2026-05-31. Captura del login falso y de shim.js en 123753243[.]com.
• 2026-06-04. 123753243[.]com en clientHold.
• 2026-06-09. Re-verificación desde un nodo aislado. Marcadores de Yandex en 45[.]92[.]1[.]158; puerto 22 sin confirmar.
• 2026-07-04. Correcciones: T1584.001 → T1583.001; los identificadores de Google y de Marketo no son del atacante; X-MSYS-API no es atribuible al atacante; se publica el hash de shim.js.
• 2026-08-21. Las renovaciones de certificado no demuestran mantenimiento. Nuevas páginas candidatas con slugs portal-/verify-, sin vínculo demostrado; ticket-7371564 carga el mismo shim.js.
• 2026-08-22. Regla YARA v6.
• 2026-10-04. Versión 2: revisión mayor tras una contrarrevisión externa y un control negativo propio. Ver la fe de erratas. Regla YARA v7 (solo metadatos). Se documenta el scan de julio y se añade un inventario de evidencias. El abuso del autorespondedor, reportado al programa de vulnerabilidades de Google.

Metodología: la investigación (cabeceras, pivots, capturas, re-verificaciones) es trabajo propio. Esta versión incorpora una contrarrevisión externa y se redactó con asistencia de IA (Claude, Anthropic). Los artefactos están preservados y se citan en el inventario de evidencias: los dos scans de URLScan y los controles negativos se pueden verificar públicamente; el resto se puede facilitar a investigadores con acceso controlado. Las observaciones que aún no ha corroborado un tercero se marcan como tales.

Operación reportada a Google Safe Browsing, Google Cloud Abuse, Google Workspace y NICENIC. El abuso del autorespondedor de security-noreply@google.com está reportado además al programa de vulnerabilidades de Google (bughunters.google.com).

Apéndice — indicadores en texto plano

# ============================================================
# BLOQUEO ESPECÍFICO
# ============================================================
123753243[.]com                              # clientHold observado el 2026-06-04; RDAP last changed 2026-06-04T17:20:05Z; instante de aplicación no confirmado
xvcbxcvxncvbn[.]xyz                          # sirvió shim.js el 2026-07-05 (URLScan 019f32f6); estado actual no verificado
hxxps://123753243[.]com/v3/identity/login
hxxps://123753243[.]com/v3/signin/identifier
sites.google.com/view/G-733828
sites.google.com/view/g-798225
sites.google.com/view/g-624594
sites.google.com/view/ticket-7371564

# shim.js (kit "gats", 16613 bytes)
#   SHA256 9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e
#   SHA1   8b74b60567160b1753059452406638d27dce2c0a
#   MD5    7bbd1d7d485b6f6ebbeb28b469970670

# API del kit (shim.js, 2026-05-31)
POST   /api/sessions
GET    /api/sessions/:id/status
POST   /api/sessions/:id/action
DELETE /api/sessions/:id

# Rutas del flujo (shim.js / HTML del login, 2026-05-31)
/v3/signin/challenge/pwd   /v3/signin/challenge/pwd/retry   /v3/signin/challenge/pwd/last
/v3/signin/challenge/selection   /v3/signin/challenge/totp   /v3/signin/challenge/sc
/v3/signin/challenge/dp   /v3/signin/challenge/dp/number   /v3/signin/challenge/bc
/v3/signin/challenge/ipe   /v3/signin/challenge/ipe/collect   /v3/signin/challenge/ipp
/v3/signin/challenge/kpp   /v3/signin/challenge/wa   /v3/signin/verify
/v3/signin/review   /v3/signin/review/done   /v3/signin/rejected

# ============================================================
# HUNTING CON CONTEXTO
# ============================================================
view-requests[.]com                          # asociado a case-159331 (2026-05-06); vínculo con gats no demostrado
sites.google.com/view/case-159331
# slug: sites.google.com/view/(g|G|ticket|case|portal|verify)-[0-9]{6,7} + título de login + embed externo

# ============================================================
# NO BLOQUEAR DE FORMA INDISCRIMINADA (plataforma / compartido)
# ============================================================
45[.]92[.]1[.]158                            # AS210558; asociada a view-requests[.]com el 2026-05-06; después, marcadores Yandex
security-noreply@google.com / workspace@google.com / noreply@google.com
X-Google-Appengine-App-Id: s~google.com:roach-hotel
Marketo 808-GJW-314 / oak.mktdns.com [199.15.214.195]

# ============================================================
# HISTÓRICO
# ============================================================
aimed-activities-erik-magnetic.trycloudflare.com
nursing-nominations-spirituality-origin.trycloudflare.com

# ============================================================
# RETIRADOS 2026-10-04 (no usar)
# ============================================================
# productName 6b8ce7c01e3dacd3d2c7a8cd322ff979   -> plataforma Google Sites
# embed hash  16cb204cf3a9d4d223a0a3fd8b0eec5d   -> frame de embeds genérico de Google