Resumen ejecutivo
El 30 de abril de 2026 se observó una publicación atribuida al actor MrGobliniciano, donde afirmaba haber obtenido un paquete de supuestas firmas electrónicas asociadas al Tribunal Supremo Electoral de Guatemala.
El actor afirmó que el paquete contenía 2,136 firmas electrónicas en formato JPG. También publicó una referencia parcial a un endpoint de la API de firmaelectronica.tse.org.gt.
Con la evidencia revisada, esto no parece una intrusión sofisticada ni una operación compleja. Lo que se observa es más básico, pero igualmente serio: abuso de una API o endpoint de descarga mediante enumeración secuencial de identificadores.
El paquete contiene archivos numerados de forma consecutiva desde 9400.jpg hasta 11535.jpg.
No se observaron gaps en la numeración.
Del total revisado:
| Métrica | Valor |
|---|---|
| Archivos totales | 2,136 |
| Archivos de 0 bytes | 665 |
| Archivos con contenido | 1,471 |
| ID inicial | 9400 |
| ID final | 11535 |
| Gaps detectados | 0 |
| Formato observado | JPG |
La lectura técnica es clara. No parece una selección manual de archivos. Parece un barrido automatizado de IDs.
El riesgo no está en una técnica espectacular. El riesgo está en que un endpoint aparentemente permitió consultar y descargar recursos mediante identificadores predecibles. Eso apunta a controles insuficientes de autorización, validación, rate limiting o detección de abuso.
Qué publicó el actor
La publicación afirmaba que el paquete contenía imágenes de firmas asociadas a empleados del TSE.
También incluía una referencia parcial a una API y enlaces externos para descarga del paquete. En este análisis no se reproduce el endpoint completo.
Por seguridad, este análisis no reproduce:
- la URL completa del endpoint
- parámetros de API
- enlaces de descarga
- firmas reales
- nombres de personas
- identificadores sensibles
- rutas que puedan facilitar abuso adicional
El objetivo no es redistribuir el material. El objetivo es documentar el patrón técnico observado y el riesgo institucional asociado.
Qué se observó en el paquete
La revisión local del paquete muestra tres elementos importantes.
Archivos JPG numerados
El paquete contiene archivos .jpg nombrados con números consecutivos.
El rango observado va de 9400.jpg a 11535.jpg.
Ese rango da exactamente 2,136 identificadores posibles.
11535 - 9400 + 1 = 2136
Cero gaps
No se detectaron saltos en la numeración.
Esto importa porque sugiere que el proceso no fue manual. El actor no parece haber elegido firmas una por una. El patrón se parece más a un script recorriendo un rango completo.
Archivos vacíos y archivos válidos
Dentro del paquete hay archivos de 0 bytes y archivos JPEG con contenido real.
| Tipo de archivo | Cantidad |
|---|---|
| Archivos de 0 bytes | 665 |
| Archivos con contenido | 1,471 |
La mezcla de archivos vacíos y válidos es una señal fuerte de enumeración.
Un proceso manual probablemente no habría guardado cientos de archivos vacíos. Un script, en cambio, sí puede guardar la respuesta de cada ID, aunque el servidor no devuelva una imagen útil.
Lectura técnica
El patrón observado es compatible con enumeración secuencial de recursos.
Se observa:
- numeración ascendente
- rango continuo
- cero gaps
- archivos vacíos
- imágenes JPEG válidas
- descarga masiva parcial
El flujo probable es simple.
- probar un ID
- guardar la respuesta
- pasar al siguiente ID
- repetir hasta completar el rango
Cuando el ID tenía una imagen asociada, el archivo contenía datos. Cuando no había contenido útil, quedó un archivo de 0 bytes.
Esto no requiere una explotación compleja. Puede ocurrir cuando una API permite consultar recursos por identificadores predecibles y no valida adecuadamente si quien solicita el recurso tiene derecho a verlo.
Por qué parece abuso de API
Este caso encaja con un problema común en APIs y endpoints de descarga.
No necesariamente se necesita “hackear” el servidor. A veces basta con que el sistema permita pedir recursos por ID y no tenga controles suficientes.
Posibles debilidades a revisar
- IDs numéricos predecibles
- falta de autorización por recurso
- endpoint que devuelve archivos sin validar permisos
- ausencia de rate limiting efectivo
- falta de detección de enumeración
- respuestas que permiten saber si un recurso existe
- descarga directa de recursos sensibles
- controles débiles contra scraping
El problema no es que exista una API. El problema es que una API expuesta sin controles puede convertirse en una vía de extracción masiva.
La importancia de los archivos de 0 bytes
Los 665 archivos vacíos son relevantes.
No necesariamente significan que el paquete esté dañado. En este contexto, pueden indicar que el script intentó descargar un recurso para un ID específico, pero el servidor no devolvió contenido útil.
Eso refuerza la hipótesis de barrido automatizado.
Si el actor solo hubiera descargado firmas existentes, no tendría sentido conservar tantos archivos vacíos. Pero si el proceso fue automático, sí tiene sentido: se recorrió el rango completo y se guardó cada respuesta.
Imagen de firma no es lo mismo que firma electrónica válida
El actor afirma que las imágenes pueden utilizarse para validar documentos oficiales. Esa afirmación debe tratarse con cautela.
Una imagen JPG de una firma no equivale necesariamente a una firma electrónica criptográfica válida.
Una firma electrónica formal debería depender de:
- certificados digitales
- claves criptográficas
- integridad del documento
- trazabilidad del firmante
- validación contra autoridad certificadora
- verificación técnica del documento firmado
Una imagen de firma no debería ser suficiente para validar un documento oficial.
Aun así, la exposición de imágenes de firma sí representa riesgo.
Puede facilitar
- suplantación visual
- fraude documental
- documentos aparentemente legítimos
- ingeniería social
- abuso de procesos débiles
- engaño a usuarios o instituciones que validen por apariencia
El riesgo depende de cómo se usen esas imágenes dentro de los procesos del TSE o de terceros.
El punto crítico es la autorización por recurso
El control más importante no es ocultar la URL.
El control importante es validar cada recurso del lado del servidor.
Aunque alguien conozca o adivine un ID, el sistema debería validar lo siguiente
- quién solicita el recurso
- si tiene sesión válida
- si tiene permisos suficientes
- si puede consultar esa firma específica
- si el recurso debe ser público o privado
- si la solicitud corresponde a un flujo legítimo
Si conocer un número basta para obtener un archivo sensible, el diseño es débil.
Rate limiting y detección de abuso
El patrón observado también plantea dudas sobre controles de abuso.
Un sistema sensible debería detectar lo siguiente
- cientos o miles de solicitudes consecutivas
- acceso a IDs incrementales
- descargas en volumen
- muchas respuestas vacías
- solicitudes sin navegación previa
- patrones repetitivos de User-Agent
- actividad anómala por IP, sesión o usuario
- consumo inusual de ancho de banda
No basta con bloquear por IP. Un actor puede rotar infraestructura.
La detección debería combinar señales como las siguientes
- usuario
- sesión
- IP
- ASN
- país
- tasa de solicitudes
- cantidad de recursos consultados
- cantidad de respuestas vacías
- comportamiento histórico
Controles recomendados
Autorización fuerte
Cada firma o archivo debe validarse individualmente del lado del servidor.
No basta con que el endpoint esté oculto. No basta con que el ID no se muestre en la interfaz.
Identificadores no predecibles
Se deben evitar IDs secuenciales expuestos directamente en endpoints descargables.
Cuando aplique, usar identificadores no enumerables, firmados y con expiración.
Tokens de descarga limitados
Los enlaces de descarga deberían usar tokens con estas características
- firmados del lado servidor
- asociados a un recurso específico
- asociados a sesión o usuario
- con expiración corta
- revocables
- de un solo uso cuando aplique
Rate limiting adaptativo
Aplicar límites por los siguientes elementos
- IP
- usuario
- sesión
- recurso
- rango de IDs
- cantidad de descargas
- volumen transferido
- cantidad de errores o respuestas vacías
Detección de enumeración
Crear alertas para los siguientes patrones
- IDs consecutivos solicitados
- alto volumen de recursos consultados
- alto porcentaje de respuestas vacías
- descargas secuenciales
- comportamiento automatizado
- descargas masivas en poco tiempo
Respuestas uniformes
El sistema no debería revelar demasiado con respuestas distintas para cada caso.
Si un ID existe, no existe o no está autorizado, la respuesta no debería facilitar el mapeo de recursos disponibles.
Protección de recursos sensibles
Las imágenes de firma no deberían estar en rutas públicas o directamente consultables.
Deben servirse mediante un controlador que aplique autenticación, autorización, registro y controles de abuso.
Qué debería revisar el TSE
El TSE debería revisar, como mínimo, los siguientes puntos
- logs del endpoint o API asociado a firma electrónica
- volumen de solicitudes por IP, usuario, sesión y User-Agent
- rangos de IDs consultados
- horarios de descarga masiva
- respuestas exitosas, bloqueadas, inexistentes y vacías
- existencia de tokens reutilizables
- posibilidad de descarga sin autenticación
- controles de autorización por firma
- permisos de usuarios internos y externos
- exportaciones o consultas masivas
- actividad previa al mantenimiento del sitio
- copias del paquete en servicios externos
También debería determinar si esas imágenes tienen valor operativo real.
Si son solo elementos visuales, el riesgo principal es fraude visual y suplantación. Si participan en algún proceso de validación débil, el riesgo aumenta.
Lo que no se puede afirmar todavía
Con la evidencia disponible, no se debe afirmar de forma definitiva lo siguiente
- que el TSE sufrió una intrusión profunda
- que hubo acceso a una base de datos completa
- que las imágenes permiten validar criptográficamente documentos oficiales
- que las 2,136 entradas correspondan a firmas útiles o vigentes, ni que todas pertenezcan a personal activo del TSE
- que todos los archivos representan empleados activos
- que el endpoint sigue siendo explotable actualmente
Sí puede afirmarse con mayor base lo siguiente
- se publicó un paquete asociado a supuestas firmas
- el paquete contiene 2,136 archivos JPG
- el rango de archivos es secuencial y continuo
- 665 archivos están vacíos
- 1,471 archivos tienen contenido
- el patrón es compatible con enumeración secuencial
- el caso amerita revisión urgente de API, autorización y rate limiting
Conclusión
Este caso no debe analizarse como una hazaña técnica sofisticada.
La evidencia apunta a abuso de un endpoint o API que aparentemente permitió recorrer identificadores consecutivos y descargar recursos cuando existían.
La numeración ascendente, el rango continuo, la ausencia de gaps y la mezcla de archivos vacíos con imágenes válidas son consistentes con un barrido automatizado.
El riesgo real está en el diseño y control del acceso a los recursos.
Puntos críticos
- IDs predecibles
- validación insuficiente
- controles débiles de descarga
- ausencia de detección de enumeración
- rate limiting insuficiente
- posible exposición de imágenes sensibles
Una API no necesita estar “hackeada” para ser abusada.
Si permite enumerar y descargar recursos sensibles, el problema ya existe.
Anexo: métricas observadas
| Métrica | Valor |
|---|---|
| Archivos totales | 2,136 |
| Archivos de 0 bytes | 665 |
| Archivos con contenido | 1,471 |
| ID inicial | 9400 |
| ID final | 11535 |
| Rango teórico | 2,136 |
| Gaps detectados | 0 |
| Formato observado | JPG |