Punto de partida
En ciberseguridad existe una realidad que rara vez se acepta en entornos institucionales: los sistemas no caen por una sola vulnerabilidad, caen cuando múltiples fallas empiezan a alinearse; cuando la superficie de ataque crece sin control, cuando la operación pierde disciplina y cuando la seguridad deja de ser una práctica activa para convertirse en una suposición.
Eso es lo que ocurrió en este caso; no como un evento aislado, sino como una acumulación progresiva de decisiones que fueron debilitando cada capa del sistema hasta dejarlo completamente expuesto.
Este análisis no se construye desde acceso privilegiado ni desde intervención directa sobre el sistema; se construye desde lo que quedó expuesto después del incidente.
Toda la reconstrucción técnica se basa en información pública distribuida tras el ataque, incluyendo contenido difundido en blogs, foros, repositorios abiertos y canales donde circularon evidencias del compromiso. Esa información, aunque fragmentada, permitió identificar patrones, correlacionar comportamientos y reconstruir la secuencia del incidente desde una perspectiva técnica.
Aquí hay un punto clave que suele pasarse por alto; cuando un sistema es vulnerado, el ataque no termina en la intrusión, continúa en la exposición. Y esa exposición, cuando es analizada con método, permite entender no solo qué ocurrió, sino por qué fue posible.
Este enfoque responde a principios de OSINT y análisis forense sobre fuentes abiertas, donde la evidencia no se obtiene accediendo al sistema, sino interpretando correctamente lo que el propio incidente dejó visible; no es una suposición, es reconstrucción técnica basada en trazas públicas.
Pero hay algo más importante aún; este tipo de análisis no surge de la intuición ni de la experiencia aislada, responde a un marco metodológico que integra capacidades técnicas específicas. La correlación de fuentes abiertas, la identificación de patrones en filtraciones, el entendimiento del comportamiento del malware en entornos reales y la interpretación de datos provenientes de ecosistemas no indexados forman parte de un proceso estructurado.
Ese proceso es precisamente el que se desarrolla en los programas de formación de DENDRO; la reconstrucción presentada en este artículo se apoya directamente en enfoques trabajados en el C|OSDRD, enfocado en investigación sobre fuentes abiertas y correlación de datos distribuidos; en el C|2DWDRD, orientado al análisis de información proveniente de deep web y dark web, donde este tipo de filtraciones suele originarse y propagarse; y en el C|TMAD, que aborda el análisis táctico de malware, permitiendo entender cómo un archivo aparentemente inofensivo, como un PDF, puede convertirse en un vector real de compromiso.
Lo relevante aquí no es el curso en sí; es la capacidad que desarrolla. Porque en escenarios como este, la diferencia no está en tener acceso al sistema; está en saber leer lo que el incidente dejó expuesto, conectar los puntos correctos y construir una narrativa técnica que no dependa de suposiciones, sino de evidencia.
Eso es inteligencia aplicada; y es exactamente lo que separa a quien observa el incidente, de quien realmente lo entiende.
No fue un hackeo sofisticado ni una intrusión imposible de prever; fue la consecuencia de un entorno que ya estaba debilitado desde su propia operación, donde coincidieron autenticación débil, desarrollo inseguro, infraestructura vulnerable y una normalización peligrosa del uso de fuentes externas no controladas.
El uso de bots en Telegram conectados a bases de datos ilícitas de ciudadanos peruanos, incluyendo información de RENIEC, SIDPOL y telefonía, introdujo una exposición que rara vez se considera en diseño de sistemas: la pérdida de control sobre el origen de los datos. Estos bots no operan bajo trazabilidad, no validan integridad y no garantizan seguridad; funcionan dentro de ecosistemas donde la manipulación de información es parte del modelo.
En ese momento, el sistema deja de ser cerrado y comienza a interactuar con infraestructura externa no confiable; y es dentro de ese mismo flujo donde aparecen los archivos PDF, no como elementos aislados, sino como parte de la dinámica de consulta. Estos documentos, entregados por los propios bots, eran percibidos como información útil, cuando en realidad representaban un vector de entrada.
Cuando un operador descarga y abre un archivo desde una fuente ilícita, el problema ya no es el contenido; es la confianza implícita en su origen. En ese punto, un PDF deja de ser un documento y pasa a ser un posible contenedor de malware, capaz de comprometer el dispositivo, capturar credenciales o exponer tokens de sesión.
El compromiso del dispositivo móvil cambia completamente el escenario; ya no se trata de acceder al sistema, sino de extraer acceso desde el usuario. Credenciales, sesiones activas y datos de autenticación comienzan a salir del entorno sin que el sistema central tenga visibilidad.
Estas credenciales no se usan de inmediato; son verificadas, organizadas y gestionadas mediante canales de mensajería que funcionan como un esquema de Command & Control distribuido. No se requiere infraestructura dedicada cuando los propios canales permiten validar accesos, coordinar acciones y sostener la operación. El sistema, en este punto, aún no ha sido atacado directamente; pero ya ha perdido el control.
Cadena de compromiso: acceso, autenticación y desplazamiento
Con credenciales válidas, el acceso deja de ser un desafío técnico. Superbúho, como módulo de autenticación dentro del PI3, operaba bajo un modelo básico de usuario y contraseña, sin autenticación multifactor, sin validación contextual y sin control de sesión robusto; bajo estas condiciones, una credencial comprometida es indistinguible de un acceso legítimo.
El sistema no detecta anomalías, no correlaciona comportamiento y no valida contexto; simplemente acepta la clave. Aquí ocurre uno de los errores más graves en seguridad: confundir autenticación con identidad.
Una vez dentro, el atacante no necesita forzar nuevas entradas; simplemente reutiliza lo que ya existe. El acceso inicial permite identificar credenciales embebidas, conexiones activas y servicios internos; a partir de ahí, el movimiento lateral se produce de forma progresiva.
El desplazamiento interno no debe entenderse como una acción aislada, sino como una expansión natural del acceso. El atacante avanza de un componente a otro reutilizando credenciales, consultando nuevas bases y aprovechando relaciones de confianza entre sistemas que nunca debieron estar expuestas de ese modo.
No hay ruptura de barreras porque las barreras no existen; la red interna confía en sí misma, y esa confianza es precisamente lo que facilita el desplazamiento. El movimiento lateral, en este caso, no es un mérito ofensivo extraordinario; es la consecuencia directa de una arquitectura sin segmentación, sin validación cruzada y sin controles de contexto entre servicios.
- El acceso inicial permite identificar nuevas credenciales y rutas internas.
- Los servicios se consumen entre sí sin controles fuertes de autenticación.
- La ausencia de segmentación convierte cada componente en un pivot potencial.
- La reutilización de accesos reduce fricción y acelera el compromiso.
Cuando una red interna fue diseñada para confiar más de lo que verifica, el atacante ya no necesita abrir puertas; solo necesita seguir los caminos que el sistema dejó listos.
Arquitectura expuesta: PHP, SOAP y lógica sin seguridad
El análisis, sustentado en información expuesta en canales de Telegram, evidencia que el sistema operaba sobre una arquitectura basada en PHP; esto no representa un problema en sí mismo, pero sí se convierte en uno cuando la implementación carece de controles de seguridad.
Se identifican patrones claros; uso de variables como $lchUrlWS, consumo directo de servicios
SOAP desde el backend, credenciales incrustadas en código fuente, conexiones directas a bases MySQL sin
capas intermedias de protección y ausencia de consultas parametrizadas, lo que expone el sistema a SQL
Injection. A esto se suma una lógica de negocio sin validación estricta de entradas, lo que amplía aún más
la superficie de ataque.
Esto no es una vulnerabilidad puntual; es una arquitectura que fue desarrollada sin considerar amenazas reales. El problema no fue PHP; fue cómo se utilizó.
http://10.1.1.42:448/p2/find/nominal/1.2/ad/nominals.asmxDentro de esta misma arquitectura, uno de los elementos más críticos fue la exposición de servicios internos como el endpoint anterior, asociado a consultas nominales. Operaba sin cifrado, sin autenticación robusta y sin validación estricta de parámetros; lo que permitía manipulación de solicitudes y abuso del servicio desde la red interna.
Al estar integrado directamente en el backend PHP, este servicio no solo era accesible, sino funcional dentro del flujo del sistema; esto lo convierte en un punto de pivot, es decir, un componente que puede ser utilizado para ampliar el alcance del acceso inicial. Cuando un servicio interno carece de controles básicos, deja de ser un recurso operativo y se convierte en una superficie activa de explotación.
CVE y escalada de privilegios: cuando la deuda técnica acelera el compromiso
En paralelo, el entorno operativo basado en CentOS 7 fuera de soporte, con kernel 3.10.x, introduce un factor determinante: la exposición a vulnerabilidades conocidas.
CVE como CVE-2022-0185, CVE-2021-4034 (PwnKit) y CVE-2017-6074 no son teóricas; son mecanismos documentados que permiten escalada de privilegios y ejecución de código. En un entorno donde el atacante ya tiene acceso inicial, estas vulnerabilidades actúan como aceleradores del compromiso.
El atacante deja de depender de credenciales; puede elevar privilegios, ejecutar código y consolidar control. Ahí el incidente cruza una línea crítica: el acceso deja de ser un problema de autenticación y pasa a convertirse en un problema de dominio operativo del sistema.
La falta de hardening, la ausencia de una política real de parchado y el mantenimiento de plataformas obsoletas no son detalles administrativos; son condiciones que convierten vulnerabilidades conocidas en rutas activas hacia el control total.
PI3, exfiltración y persistencia
El acceso al PI3 no es un salto técnico; es una consecuencia directa del recorrido anterior. La evidencia filtrada muestra múltiples bases de datos accesibles, tablas asociadas a armamento, auditorías, registros operativos y estructuras completas de sistemas relacionados; además, expone información del entorno como sistema operativo, kernel y virtualización.
Esto no corresponde a una filtración parcial; corresponde a un acceso amplio, estructurado y sostenido. Cuando se compromete un sistema de este tipo, no solo se exponen datos; se compromete la capacidad de análisis, la trazabilidad y la lógica operativa del entorno.
La extracción de información se realiza de forma progresiva, utilizando accesos legítimos y sesiones válidas; esto reduce el ruido y dificulta la detección. El atacante puede descargar bases completas, acceder a registros sensibles y obtener código fuente sin necesidad de ejecutar acciones agresivas; al mismo tiempo, la persistencia se mantiene mediante el mismo esquema de Command & Control basado en mensajería, lo que permite continuar la operación sin necesidad de presencia constante en el sistema.
La ruptura real: cuando la operación legitima lo ilícito
Aquí se encuentra el núcleo del problema. El uso de bots conectados a bases de datos ilícitas no es un detalle técnico; es una ruptura estructural del modelo de seguridad. Plataformas como Lederdata o Xdata operan con información obtenida sin control, sin trazabilidad y sin validación.
Cuando un entorno institucional comienza a interactuar con estas fuentes, pierde control sobre su superficie de ataque; deja de ser un sistema protegido y se convierte en un sistema expuesto por diseño.
Telegram no es el problema. La herramienta no es el riesgo; el riesgo es cómo se utiliza. Cuando los canales externos se integran al flujo operativo sin control, sin auditoría y sin comprensión del riesgo, el sistema deja de ser un entorno cerrado y pierde visibilidad sobre su propia operación.
No falló un exploit, ni una herramienta. Falló el sistema completo; la autenticación, el desarrollo en PHP, la arquitectura, la gestión de vulnerabilidades y la operación. Pero, sobre todo, falló el criterio.
Un sistema no se compromete cuando es atacado; se compromete cuando deja de ser controlado.
En DENDRO no analizamos incidentes para describirlos. Los analizamos para entender por qué fueron posibles.
¿Qué decisiones convirtieron el sistema en el propio vector de ataque?