Webshell en la Municipalidad de Tacna expone el API del RENIEC y datos biométricos de miles de peruanos
Un subdominio de la Municipalidad Provincial de Tacna fue comprometido mediante una webshell PHP en el servidor de Mesa de Partes. Lo que encontraron los atacantes dentro: tokens de autenticación activos hacia el API ConsultaPIDE del RENIEC, más de 10,000 fotos biométricas descargadas y 2,872 credenciales del sistema SISTRAM en texto plano.
El PIDE: la columna vertebral del Estado peruano — sin ninguna protección en el extremo más débil
El PIDE (Plataforma de Interoperabilidad del Estado) conecta a municipalidades y entidades públicas con información oficial en tiempo real: RENIEC, SUNARP, SUNAT, antecedentes penales, MTC, SUNEDU, SERVIR, SBS, Migraciones y MINEDU. Es la infraestructura que habilita los trámites administrativos del Estado peruano.
Y está conectada a servidores municipales con PHP 5.3.
El compromiso: vector clásico, consecuencias no triviales
El subdominio de Mesa de Partes de la Municipalidad Provincial de Tacna fue comprometido mediante una webshell PHP, subida al servidor después de reemplazar un PDF legítimo. Es el vector más documentado en compromisos de servidores web y, en 2025, uno que no debería funcionar en infraestructura gubernamental con acceso a sistemas nacionales.
Una vez con la webshell activa, los atacantes no encontraron solo documentos municipales.
Lo que encontraron dentro
Tokens de acceso al RENIEC vía PIDE
El servidor almacenaba tokens de autenticación activos hacia el API ConsultaPIDE del RENIEC. Con esas credenciales, los atacantes realizaron scraping automatizado: descargaron fotos biométricas y datos personales directamente desde los sistemas centrales del Estado.
Las imágenes publicadas como prueba en Telegram muestran la baja resolución y la marca de agua característica del API del RENIEC. Los atacantes mencionaron acceso a "40 millones de registros" — cifra probablemente inflada para el mercado, pero que revela la escala del acceso que tenían sobre el API.
El actor InkaRoot publicó evidencia de acceso a múltiples endpoints del ConsultaPIDE, sugiriendo que el token comprometido tenía permisos amplios — o que el punto de entrada no era solo esta municipalidad sino algún nodo con acceso más amplio a la intranet estatal.
El archivo liberado
Se publicó un archivo .rar con más de 10,000 fotos biométricas del RENIEC, cada una asociada a su número de DNI. No como muestras — como entrega completa.
Base de usuarios SISTRAM
También se filtró la base de usuarios del sistema SISTRAM municipal: 2,872 registros con usuario, contraseña (texto plano o hash débil), nombre completo, apellidos, DNI, email y celular de funcionarios municipales.
Escala del acceso
- —Tokens activos hacia el API RENIEC/PIDE
- —Más de 10 TB de documentos administrativos municipales
- —400 GB de expedientes municipales desde 2016
La infraestructura que lo hizo posible
El servidor comprometido corría PHP 5.3.8 sobre Linux Kernel 2.6.32 (RHEL/CentOS 6) — software sin soporte oficial desde 2020 y 2017 respectivamente. No es un servidor antiguo que nunca fue priorizado: es un servidor con acceso a sistemas nacionales críticos corriendo sobre una pila de software que lleva años sin parches de seguridad.
Los atacantes operaron con privilegios administrativos completos y tenían capacidad de pivoting dentro de la red municipal.
La respuesta de la municipalidad
Los atacantes notificaron a los responsables del servidor sobre la vulnerabilidad antes de publicar. La respuesta fue insultos y contenido en ASCII dentro de la propia webshell.
El acceso no fue cerrado inmediatamente tras la notificación.
El problema estructural: el PIDE como superficie de ataque distribuida
El compromiso de Tacna no es una falla aislada de esa municipalidad. Es la consecuencia predecible de cómo está diseñado el extremo de acceso al PIDE.
Actualmente, la mayoría de municipalidades peruanas conectadas al PIDE:
- —No tienen restricciones de IP en el API (cualquier servidor con token puede consultar)
- —No tienen rate limiting por entidad
- —No tienen auditorías activas de los patrones de acceso a su token
- —Corren infraestructura con versiones de software sin soporte
El PIDE fue diseñado para interoperabilidad. No fue diseñado para sobrevivir a un servidor municipal comprometido con acceso total al API del RENIEC. La arquitectura asume que todos los extremos son seguros — una suposición que este incidente demuestra como incorrecta.
Esta vulnerabilidad se va a repetir. Las condiciones que la hacen posible existen en decenas de municipalidades conectadas al PIDE hoy.
Qué requiere implementación urgente
En el extremo del RENIEC/PCM (PIDE):
- —Restricción de acceso al API por IP registrada — cada entidad debería tener tokens vinculados a rangos de IP autorizados
- —Rate limiting por token de entidad — con alertas ante descargas en volumen anómalo
- —Auditoría de patrones de uso por token: horario, volumen, tipos de consulta
- —Rotación inmediata de tokens de todas las entidades conectadas cuando una es comprometida
En los extremos municipales:
- —Validación de tipo real en la carga de archivos — no solo extensión, sino magic bytes y contenido
- —Actualización de la pila de software a versiones con soporte activo
- —Separación de red entre servidores web públicos y sistemas con acceso a APIs de Estado
Esta investigación fue publicada originalmente en LinkedIn. El objetivo es generar visibilidad sobre vulnerabilidades estructurales en la infraestructura de interoperabilidad del Estado peruano antes de que sean explotadas de forma masiva y silenciosa.
Si tu institución está conectada al PIDE o gestiona infraestructura con acceso a APIs nacionales y quieres evaluar su exposición, contáctanos.