15 de septiembre de 2026
Pentesting de PLC y sistemas de control industrial sin detener la planta

Respuesta rápida: sí se puede evaluar la seguridad de una red industrial sin interrumpir producción, pero no ejecutando un pentesting de TI dentro de ella. El método correcto separa el trabajo en tres capas: reconocimiento 100% pasivo sobre el tráfico real, explotación activa en réplica de laboratorio o ambiente de pruebas, y validación acotada en producción solo durante ventana acordada y con plan de reversión firmado. Un escaneo estándar lanzado contra un PLC de generación antigua puede dejarlo en fallo, y ese riesgo no se asume nunca por conveniencia de agenda.
Por qué un pentest de TI no sirve aquí
Las herramientas de pentesting tradicionales asumen que el objetivo tolera tráfico malformado, conexiones simultáneas y reintentos. Un PLC de hace quince años tiene una pila TCP/IP mínima: puede quedar en estado de fallo por recibir paquetes que no espera, y volver a estado operativo puede requerir intervención física en terreno.
Los protocolos industriales agravan el cuadro porque en su diseño original no contemplan autenticación:
| Protocolo | Riesgo principal |
|---|---|
| Modbus TCP | Sin autenticación ni cifrado; cualquiera en el segmento puede leer y escribir registros |
| DNP3 (sin Secure Authentication) | Comandos de control aceptados sin verificación de origen |
| S7comm / S7commPlus | Operaciones de carga de programa y cambio de modo de CPU accesibles según versión y configuración |
| EtherNet/IP – CIP | Servicios de configuración expuestos sin control de acceso |
| OPC UA mal configurado | Modo sin seguridad habilitado por compatibilidad, anulando el diseño seguro del estándar |
No hay que explotar una vulnerabilidad para escribir en un registro Modbus. Basta con alcanzar el segmento. Por eso el hallazgo relevante casi nunca es un CVE: es una ruta de red que no debería existir.
Las tres capas del método
Capa 1 — Reconocimiento pasivo (sin riesgo)
Se captura tráfico desde un puerto SPAN o un TAP en los switches de nivel 2 y 3 del modelo Purdue. No se envía un solo paquete a la red.
Qué se obtiene:
- Inventario real de activos: fabricante, modelo, versión de firmware cuando el protocolo la expone
- Matriz de comunicaciones: quién habla con quién, por qué puerto y con qué frecuencia
- Protocolos en uso y sus configuraciones de seguridad
- Flujos anómalos: conexiones a internet, tráfico entre zonas que deberían estar separadas, acceso remoto activo
- Credenciales transmitidas en claro
En la mayoría de las plantas esta capa por sí sola ya justifica el proyecto, porque nadie tenía el inventario.
Capa 2 — Explotación en ambiente controlado
Aquí se hace el trabajo ofensivo real, contra equipamiento equivalente al productivo: réplica de laboratorio, banco de pruebas del integrador o ambiente de contingencia.
Qué se prueba:
- Manipulación de registros y lógica: leer y escribir puntos de proceso, modificar setpoints, evaluar si es posible cambiar el modo de CPU
- Análisis de firmware: extracción, búsqueda de credenciales embebidas, servicios de depuración abiertos, mecanismos de verificación de firma
- Archivos de proyecto de ingeniería: los proyectos de TIA Portal o Studio 5000 frecuentemente contienen credenciales y revelan la lógica completa del proceso
- Ataques a HMI: acceso no autenticado, escalamiento a sistema operativo, manipulación de la vista del operador
- Falsificación de datos hacia el historian y hacia el operador: el escenario más peligroso no es detener la planta, es hacer que el operador vea valores normales mientras el proceso se desvía
Capa 3 — Validación acotada en producción
Solo lo que no pudo probarse en laboratorio, con condiciones no negociables:
- Ventana acordada por escrito, con operaciones informado y personal de planta presente
- Plan de reversión y punto de detención definidos antes de empezar
- Canal de comunicación abierto en todo momento con la sala de control
- Un operador con autoridad para detener la prueba en cualquier segundo
- Registro completo de cada acción ejecutada, con hora
En esta capa se prueban típicamente: caminos de pivote desde TI hacia TO, efectividad real de las reglas de firewall, aislamiento de la DMZ industrial y control de acceso remoto de proveedores.
Lo que casi siempre encontramos
La ruta TI → TO existe. Se llega al segmento industrial desde la red corporativa, normalmente pasando por la estación de ingeniería o por un servidor de historian con doble interfaz.
El acceso remoto del proveedor es permanente. Debería habilitarse por ventana y está siempre activo, con credencial compartida y sin registro de sesión.
Las credenciales por defecto siguen vigentes en HMI, switches industriales y gateways.
La estación de ingeniería es el activo más crítico y el menos protegido. Tiene el proyecto completo, acceso a todos los PLC, salida a internet y sin control de medios extraíbles.
El historian es bidireccional cuando debería ser unidireccional. Se diseñó para exportar datos a TI y terminó aceptando conexiones entrantes.
El entregable
Un informe de pentesting industrial útil tiene:
- Resumen ejecutivo en lenguaje de negocio, expresado en impacto operacional: horas de parada, riesgo de daño a equipos, exposición a personas.
- Inventario de activos descubierto, que en muchos casos pasa a ser el inventario oficial de la planta.
- Matriz de comunicaciones real versus la arquitectura documentada. La brecha entre ambas suele ser el hallazgo de mayor valor.
- Hallazgos priorizados por riesgo de proceso, no por CVSS. Un CVSS 9.8 en un equipo aislado importa menos que un CVSS 5.0 en el lazo de control de un sistema instrumentado de seguridad.
- Recomendaciones con control compensatorio explícito para todo lo que no se pueda parchar, que será la mayoría.
- Retest incluido tras la remediación.
Si el informe entrega una lista de CVE ordenada por puntaje, quien lo hizo no entiende OT.
Relación con el marco normativo
Para organizaciones calificadas como Operador de Importancia Vital, este ejercicio aporta evidencia directa para las obligaciones de gestión de riesgos y de monitoreo continuo de la Ley 21.663, y sustenta el análisis de riesgo exigido por ISA/IEC 62443 en su parte de evaluación.
Conoce nuestro enfoque completo en servicios principales y el contexto del sector en ciberseguridad industrial OT y SCADA en Chile.
Preguntas frecuentes
¿Puede un pentesting detener mi planta?
Mal ejecutado, sí. Por eso la fase activa nunca se lanza contra producción sin ventana acordada, plan de reversión y personal de planta presente. La fase de descubrimiento es enteramente pasiva y no envía tráfico.
¿Necesito un laboratorio propio para hacerlo?
Ayuda mucho, pero no siempre es indispensable. Se puede trabajar con el banco de pruebas del integrador, con equipamiento de repuesto o con ambiente de contingencia.
¿Cuánto dura un proyecto típico?
Entre 3 y 6 semanas para un sitio único, dependiendo de la cantidad de activos y de si hay fase de laboratorio.
¿Qué diferencia hay con una auditoría ISA/IEC 62443?
La auditoría evalúa si el diseño y los procesos cumplen el estándar. El pentesting verifica empíricamente si los controles resisten. Son complementarios: el estándar dice qué debería existir, la prueba dice si funciona.
¿Sirve si mis equipos tienen 20 años y no se pueden parchar?
Sirve especialmente en ese caso. El objetivo deja de ser parchar y pasa a ser diseñar controles compensatorios: segmentación, control de acceso, monitoreo y restricción de rutas.
¿Entregan evidencia utilizable para ANCI?
Sí. El informe se estructura para servir como respaldo del proceso de gestión de riesgos y de las medidas técnicas implementadas.