
Resumen ejecutivo
El 1 de mayo de 2026 circuló una publicación atribuida al actor NemorisHacking, en la que afirmaba haber comprometido información asociada al Instituto Nacional de Estadística de Guatemala, mencionando el dominio datos.ine.gob.gt.
La publicación fue amplificada por algunas cuentas de monitoreo como si se tratara de un compromiso crítico de infraestructura vinculada al INE y a un sistema de salud. Sin embargo, la evidencia observada no sostiene, por sí sola, esa narrativa.
La captura publicada por el actor no corresponde claramente al portal de datos del INE. Lo que se observa es una interfaz de Go.Data, plataforma utilizada para gestión epidemiológica. La instancia identificada públicamente en Guatemala corresponde al dominio godataguatemala.mspas.gob.gt, asociado al Ministerio de Salud Pública y Asistencia Social, no al INE.
Con la evidencia disponible, la lectura más prudente no es “hackeo al INE”. La hipótesis más razonable es otra: acceso a una instancia Go.Data asociada al MSPAS mediante credenciales previamente expuestas en logs de infostealers.
Esto no elimina el riesgo. Si las credenciales estaban vigentes, el acceso indebido sigue siendo un incidente serio. Pero técnicamente no es lo mismo que explotar una plataforma, comprometer infraestructura del INE o demostrar una intrusión nueva y sofisticada.
La diferencia importa: una captura con acceso no equivale automáticamente a un hackeo confirmado del sistema que el actor menciona.
Qué afirmó el actor
El actor publicó un mensaje en X donde afirmaba haber accedido a información relacionada con Guatemala y mencionaba como referencia el dominio datos.ine.gob.gt.
Junto al texto, publicó una captura donde se observa una interfaz de Go.Data con elementos típicos de una plataforma de seguimiento epidemiológico, incluyendo módulos relacionados con:
- casos
- contactos
- resultados de laboratorio
- eventos
- reportes e indicadores
- gestión de brotes
Ese contenido fue suficiente para que algunas cuentas externas presentaran el caso como un compromiso crítico del INE. El problema es que mencionar un dominio no prueba que la evidencia visual corresponda a ese dominio.
En este caso, la atribución se distorsionó muy rápido.
El problema de la narrativa alarmista
La amplificación pública del caso cayó en una confusión frecuente:
- tomar la afirmación del actor como si fuera una atribución técnica válida
- asumir que una captura de una plataforma equivale a explotación del sistema
- mezclar una interfaz sanitaria con el dominio mencionado por el actor
- presentar el caso como si fuera un hackeo confirmado al INE
Eso es precisamente lo que debe evitarse en análisis serios.
Una publicación de un actor en redes no es evidencia suficiente de compromiso del activo que dice haber afectado. Como regla general, hay que separar:
- lo que dice el actor
- lo que realmente muestra la evidencia
- qué sistema parece ser
- qué entidad probablemente lo opera
- qué hipótesis técnica explica mejor el acceso observado
En este caso, esos cinco puntos no convergen hacia “hackeo al INE”.
Qué muestra realmente la evidencia
La evidencia visual publicada apunta a Go.Data, no a un portal estadístico del INE.
Go.Data es una plataforma utilizada para gestión de brotes, casos, contactos y seguimientos epidemiológicos. La interfaz observada es consistente con ese tipo de entorno y no con un portal tradicional de datos abiertos o estadísticas.
Además, la revisión de superficie observada para ine.gob.gt no muestra un subdominio identificado como Go.Data. En cambio, la superficie observada para mspas.gob.gt sí incluye godataguatemala.mspas.gob.gt.
Esto ya cambia de forma importante la lectura del caso.

INE y Go.Data no son lo mismo
El punto central es este: el actor menciona datos.ine.gob.gt, pero la captura mostrada corresponde a una plataforma Go.Data.
Eso implica que se mezclaron indebidamente tres cosas distintas:
- el dominio mencionado por el actor
- la plataforma mostrada en la evidencia visual
- la institución que probablemente opera esa plataforma
Con la evidencia revisada, esos tres elementos no son equivalentes.
La conclusión prudente no es que el INE haya sido hackeado. La conclusión prudente es que:
- la captura apunta a una plataforma Go.Data
- la instancia conocida de Go.Data Guatemala está bajo
mspas.gob.gt - por tanto, la atribución directa al INE no está técnicamente sostenida
Que el actor escriba “INE” no convierte al INE en el sistema realmente mostrado en la evidencia.
Go.Data Guatemala está documentado bajo MSPAS
Este punto es importante porque deja de ser solo una inferencia visual.
Existe documentación pública de Go.Data Guatemala donde se indica que el Ministerio de Salud Pública y Asistencia Social adoptó la plataforma en mayo de 2020 para registrar casos de COVID-19, contactos y seguimientos. Esa misma documentación indica que el software fue instalado en servidores locales del MSPAS y publicado bajo el dominio godataguatemala.mspas.gob.gt.
Eso fortalece la atribución correcta del activo observado.
No se está diciendo que cualquier acceso a Go.Data equivalga automáticamente a compromiso masivo del MSPAS. Lo que se está diciendo es algo más preciso:
- la evidencia mostrada no corresponde claramente al INE
- la evidencia sí es consistente con una instancia Go.Data asociada al MSPAS
Gráfico sugerido

La hipótesis técnica más sólida
Con la evidencia disponible, la hipótesis más consistente es que el actor no explotó una vulnerabilidad nueva ni “hackeó” el INE.
La explicación más razonable es otra:
uso de credenciales antiguas filtradas por infostealers
Un infostealer es un tipo de malware diseñado para robar información almacenada en equipos comprometidos, incluyendo:
- usuarios y contraseñas
- cookies de sesión
- tokens
- accesos guardados en el navegador
- datos autofill
- información de clientes de correo y aplicaciones
Si un usuario institucional fue comprometido por este tipo de malware y sus credenciales quedaron expuestas, un tercero puede intentar reutilizarlas más adelante para acceder a sistemas reales.
En otras palabras, el acceso observado pudo derivar de credenciales válidas previamente robadas, no de una intrusión nueva al portal.
Eso cambia completamente la lectura del caso.
No todo acceso es hackeo.
Por qué esta hipótesis encaja mejor
La hipótesis de credenciales filtradas encaja mejor por varias razones:
1. La evidencia visual apunta a MSPAS, no a INE
La captura corresponde a una plataforma Go.Data. La instancia conocida de Go.Data Guatemala está bajo mspas.gob.gt.
2. Existen exposiciones agregadas por infostealers en dominios del MSPAS
Se revisaron reportes agregados de exposición asociados a distintos dominios institucionales del Estado. Para mspas.gob.gt, el reporte revisado muestra:
- 11 empleados comprometidos
- 298 terceros comprometidos
- 3,113 usuarios o clientes comprometidos
- 3,422 identidades comprometidas en total
3. El volumen observado en INE es mucho menor
Para ine.gob.gt, el reporte revisado muestra:
- 11 empleados comprometidos
- 27 terceros comprometidos
- 191 usuarios o clientes comprometidos
- 229 identidades comprometidas en total
El dato importante no es solo que MSPAS tenga más exposición agregada que INE. Lo importante es que la evidencia visual del caso coincide con una plataforma del MSPAS.
4. El patrón es coherente con reutilización de credenciales
Un actor que obtiene una credencial filtrada no necesita explotar el sistema para ingresar. Si la cuenta sigue activa y la contraseña no ha sido rotada, el acceso puede lograrse con mecanismos totalmente legítimos desde el punto de vista del sistema.
Eso sigue siendo un incidente serio. Pero no es lo mismo que vulnerar técnicamente la plataforma.
Exposición observada en instituciones del Estado
La revisión agregada de reportes por dominio muestra que el problema no se limita al MSPAS ni al INE. La superficie de riesgo por credenciales expuestas asociadas a infostealers alcanza a múltiples instituciones del Estado.
La siguiente tabla resume algunos de los dominios revisados y sus conteos agregados.
| Dominio | Empleados | Terceros | Usuarios o clientes | Total observado |
|---|---|---|---|---|
sat.gob.gt |
10 | 345 | 118,260 | 118,615 |
pnc.gob.gt |
40 | 20 | 30,955 | 31,015 |
oj.gob.gt |
9 | 29 | 29,773 | 29,811 |
renap.gob.gt |
1 | 1 | 19,994 | 19,996 |
mineduc.gob.gt |
71 | 732 | 17,655 | 18,458 |
contraloria.gob.gt |
17 | 76 | 16,860 | 16,953 |
muniguate.com |
37 | 61 | 9,056 | 9,154 |
minfin.gob.gt |
0 | 47 | 8,057 | 8,104 |
igssgt.org |
16 | 73 | 5,166 | 5,255 |
sib.gob.gt |
0 | 36 | 4,490 | 4,526 |
mp.gob.gt |
38 | 38 | 4,235 | 4,311 |
mspas.gob.gt |
11 | 298 | 3,113 | 3,422 |
guatecompras.gt |
0 | 0 | 2,109 | 2,109 |
ine.gob.gt |
11 | 27 | 191 | 229 |
sit.gob.gt |
1 | 2 | 116 | 119 |
mem.gob.gt |
1 | 13 | 48 | 62 |
banguat.gob.gt |
0 | 19 | 2 | 21 |
Cómo debe leerse esta tabla
Estos datos no deben interpretarse como confirmación de acceso activo a todos esos sistemas. Tampoco deben usarse para publicar usuarios, contraseñas ni detalles sensibles.
La lectura correcta es otra:
- hay exposición agregada asociada a credenciales institucionales
- parte de esa exposición puede provenir de equipos infectados por infostealers
- si las credenciales siguen vigentes, pueden convertirse en accesos reales
- el riesgo operativo es serio aunque no exista explotación directa del sistema
Gráfico sugerido

MSPAS vs INE: comparación útil para este caso
Si el objetivo es analizar específicamente la narrativa pública de este incidente, el contraste más útil es entre mspas.gob.gt e ine.gob.gt.
MSPAS
- 3,422 identidades comprometidas en total
- 298 terceros comprometidos
- evidencia visual consistente con una plataforma Go.Data asociada a MSPAS
INE
- 229 identidades comprometidas en total
- no se observó una instancia Go.Data claramente atribuible al INE en la superficie revisada
- el actor solo menciona el dominio
datos.ine.gob.gt, pero la evidencia visual no lo sostiene
Esto no implica que el INE esté libre de riesgo. Implica algo más acotado y más importante para este caso:
La evidencia publicada por el actor se alinea mejor con un acceso a una plataforma del MSPAS que con un hackeo al INE.
Gráfico sugerido

No todo acceso es hackeo
Este caso ilustra un punto que vale repetir.
Un acceso indebido puede ocurrir sin explotación técnica nueva del portal.
Si un actor utiliza una credencial válida previamente robada, el sistema puede aceptarla como si se tratara de un usuario legítimo. Desde fuera, eso puede verse como “entró al sistema”. Pero desde el punto de vista técnico, la explicación puede ser muy distinta a un compromiso del servidor.
Por eso conviene separar:
Acceso con credenciales válidas
- puede originarse en infostealers
- puede involucrar credenciales antiguas
- puede involucrar cuentas no rotadas
- no prueba por sí solo vulnerabilidad del sistema
Explotación técnica del sistema
- implicaría una debilidad explotada del lado del servidor o de la aplicación
- requiere evidencia diferente
- no se demuestra solo con una captura de pantalla
En este caso, lo segundo no está demostrado.
Lo que sí está razonablemente planteado es lo primero.
Una credencial robada no necesita una vulnerabilidad para causar daño. Si sigue vigente, es acceso.
El riesgo real no es menor, solo es distinto
Decir que esto no parece un hackeo al INE no significa minimizar el incidente.
El riesgo sigue siendo serio si hubo acceso real a una instancia Go.Data asociada al MSPAS, porque se trata de una plataforma que puede contener información sensible vinculada a brotes, casos, contactos y procesos epidemiológicos.
La diferencia está en el diagnóstico técnico.
No parece un caso de intrusión espectacular ni de explotación nueva del sistema. Parece algo más mundano, más común y, en ciertos aspectos, más preocupante:
- credenciales antiguas robadas
- rotación insuficiente
- cuentas que siguen vigentes
- falta de invalidación o monitoreo oportuno
- exposición institucional acumulada por infostealers
Eso obliga a mirar el problema donde probablemente está.
Qué debería hacerse
Las instituciones públicas deberían tratar los logs de infostealers como una fuente crítica de riesgo operativo, no como simple ruido externo.
Medidas urgentes
- rotar credenciales expuestas o potencialmente expuestas
- invalidar sesiones activas cuando exista sospecha de robo de credenciales
- implementar MFA en sistemas administrativos, VPN, correo y plataformas con datos sensibles
- correlacionar credenciales filtradas con usuarios activos
- deshabilitar cuentas antiguas, cuentas de terceros y accesos sin justificación operativa
- revisar accesos recientes desde IPs, países, horarios, dispositivos o navegadores inusuales
- revisar si hay exportaciones, búsquedas o accesos masivos no habituales
- evitar que personal institucional almacene contraseñas en navegadores de equipos no administrados
- fortalecer EDR, filtrado web, hardening de navegadores y control de extensiones
- establecer un proceso periódico de hunting y remediación enfocado en credenciales filtradas por infostealers
Recomendaciones específicas para Go.Data
Para la instancia Go.Data asociada al MSPAS, las acciones mínimas deberían incluir:
- rotación inmediata de credenciales con acceso a Go.Data
- revisión de cuentas activas e inactivas
- revisión de cuentas de terceros
- cierre de sesiones vigentes
- revisión de logs de autenticación
- revisión de accesos por IP, país, horario, dispositivo y navegador
- validación de permisos por rol
- búsqueda de exportaciones o consultas inusuales
- confirmación de que cuentas antiguas o fuera de operación estén deshabilitadas
- verificación de MFA, si la plataforma o el esquema de acceso lo permiten
Limitaciones del análisis
Este análisis tiene limitaciones y debe leerse como una evaluación preliminar basada en evidencia observada, no como una conclusión forense definitiva.
Puntos importantes:
- no se está afirmando que todos los datos agregados de exposición correspondan a accesos activos vigentes
- no se está afirmando que toda exposición en infostealer logs implique compromiso actual del sistema
- no se está afirmando exfiltración confirmada desde Go.Data
- no se está afirmando ausencia total de otras hipótesis
Lo que sí se sostiene con la evidencia disponible es que:
- la atribución pública al INE es débil
- la evidencia visual apunta a Go.Data
- la instancia Go.Data conocida en Guatemala corresponde al MSPAS
- existe exposición agregada de credenciales asociadas a
mspas.gob.gt - la hipótesis de reutilización de credenciales filtradas encaja mejor que la narrativa de hackeo al INE
Conclusión
La evidencia revisada no sostiene la narrativa de un hackeo al INE.
Lo observado apunta a algo distinto: una captura de Go.Data, plataforma asociada al MSPAS, posiblemente accedida mediante credenciales previamente expuestas en logs de infostealers.
Eso no es un detalle menor. Pero tampoco es lo mismo que comprometer técnicamente al INE ni demostrar una explotación sofisticada del sistema.
La publicación alarmista mezcla dominio, plataforma y atribución de forma imprecisa. El problema real parece ser otro: credenciales institucionales viejas que todavía pueden abrir puertas.
Ese es el punto que urge atender.
Anexo: datos agregados revisados
Exposición agregada por dominio
| Dominio | Total observado |
|---|---|
sat.gob.gt |
118,615 |
pnc.gob.gt |
31,015 |
oj.gob.gt |
29,811 |
renap.gob.gt |
19,996 |
mineduc.gob.gt |
18,458 |
contraloria.gob.gt |
16,953 |
muniguate.com |
9,154 |
minfin.gob.gt |
8,104 |
igssgt.org |
5,255 |
sib.gob.gt |
4,526 |
mp.gob.gt |
4,311 |
mspas.gob.gt |
3,422 |
guatecompras.gt |
2,109 |
ine.gob.gt |
229 |
sit.gob.gt |
119 |
mem.gob.gt |
62 |
banguat.gob.gt |
21 |
Comparativo puntual MSPAS e INE
| Dominio | Empleados | Terceros | Usuarios o clientes | Total |
|---|---|---|---|---|
mspas.gob.gt |
11 | 298 | 3,113 | 3,422 |
ine.gob.gt |
11 | 27 | 191 | 229 |