Tu firewall de $10,000 dólares te protege. Hasta que un hacker entra por la cafetera inteligente.
No es metáfora. No es exageración para titular de blog. Es un hallazgo real de una prueba de penetración que el equipo de Duriva ejecutó en un corporativo de la Ciudad de México. La cafetera inteligente del piso ejecutivo — conectada al WiFi corporativo para que el CEO pudiera programar su espresso desde el celular — tenía credenciales de fábrica, firmware sin actualizar desde 2019 y estaba en la misma VLAN que los servidores de recursos humanos. Un dispositivo de $200 dólares fue la puerta de entrada a los expedientes laborales de 4,000 empleados.
Y la empresa tenía firewall. Tenía antivirus enterprise. Tenía política de contraseñas. Tenía ISO 27001 en proceso. Tenía todo lo que el checklist dice que debes tener. Todo excepto a alguien cuyo trabajo fuera pensar como atacante.
Eso es un hacker ético. Y eso es lo que el corporativo latinoamericano no entiende — o no quiere entender — que necesita.
Compliance no es seguridad. Punto.
Voy a decir algo que los consultores de cumplimiento normativo no quieren escuchar: pasar una auditoría de compliance no significa que tu empresa sea segura. Significa que tu empresa cumplió con un checklist. Y un checklist es una fotografía de requisitos mínimos en un momento específico del tiempo. Un atacante no consulta tu checklist antes de atacarte.
He visto esto docenas de veces en 17 años de carrera. Empresas con certificaciones vigentes que son vulneradas porque la certificación evalúa procesos documentados, no capacidad real de resistir un ataque. La certificación pregunta: «¿Tiene usted una política de gestión de parches?» La empresa responde: «Sí, aquí está el documento.» La certificación se otorga. Nadie verifica si los parches se aplicaron. Nadie verifica si el documento refleja la realidad operativa. Nadie intenta vulnerar el sistema para comprobar si la política funciona.
El compliance mira papeles. El hacker ético mira sistemas. Y los sistemas no mienten.
Un hacker ético — un pentester, un red teamer, un profesional de seguridad ofensiva, como quieras llamarlo — no revisa si tienes documentada una política de segmentación de red. Conecta su laptop a un puerto de red de la sala de juntas y comprueba si puede llegar al servidor de base de datos desde ahí. Si puede, tu política de segmentación es papel. Si no puede, tu política es real. Esa es la diferencia entre compliance y seguridad.
En Latinoamérica, esa diferencia es un abismo. Y las empresas están cayendo en él.
El estado del hacking ético en Latinoamérica: de nicho underground a necesidad corporativa
Hace 15 años, cuando empecé a participar en comunidades de seguridad ofensiva en la región, el hacking ético era un concepto que generaba desconfianza. «Contratar a un hacker» sonaba contradictorio. Los directivos no entendían por qué pagarían a alguien para atacar sus propios sistemas. Los departamentos legales no sabían cómo manejar un contrato de pruebas de penetración. Los equipos de TI se sentían amenazados — como si contratar a un pentester fuera una crítica a su trabajo.
Esa mentalidad ha cambiado. Pero no lo suficiente. No a la velocidad que exige el panorama de amenazas actual.
En Estados Unidos y Europa, las pruebas de penetración son parte del ciclo de vida de cualquier sistema crítico. No son opcionales. No son «algo que haremos cuando haya presupuesto.» Son requisito para operar. PCI-DSS las exige para cualquier entidad que procese tarjetas de crédito. SOC 2 las requiere como parte del programa de seguridad. El regulador financiero las audita. La aseguradora cibernética las pide antes de emitir la póliza.
En Latinoamérica, la situación es diferente. Las pruebas de penetración siguen siendo, para la mayoría de los corporativos, un gasto discrecional. Algo que se contrata cuando sobra presupuesto al final del año fiscal. O algo que se contrata después de un incidente — cuando el daño ya está hecho.
He trabajado con empresas en México, Colombia, Perú, Chile, Argentina, Ecuador, República Dominicana, Costa Rica, Panamá y Guatemala. En todos esos países he visto el mismo patrón: las empresas multinacionales con matrices en Estados Unidos o Europa hacen pentesting porque la matriz se los exige. Las empresas locales — incluso las grandes, incluso las que facturan cientos de millones de dólares — no lo hacen. O lo hacen una vez, reciben el reporte, lo archivan y no vuelven a pensar en ello hasta que algo explota.
Y las cosas están explotando con frecuencia creciente.
MassScan y la realidad de la superficie de ataque latinoamericana
Voy a explicar algo que a los CISO latinoamericanos debería quitarles el sueño. Y lo voy a explicar con una herramienta que cualquier hacker — ético o no — puede ejecutar en 45 minutos.
MassScan es un escáner de puertos. Pero no un escáner de puertos cualquiera. Es un escáner que puede barrer todo el espacio de direcciones IPv4 — las 4,300 millones de direcciones IP del mundo — en menos de seis minutos si tienes el ancho de banda suficiente. Robert David Graham lo creó como proyecto open source. Es legal. Es público. Cualquiera puede descargarlo.
Lo que MassScan hace es simple: le dices qué puerto quieres escanear y te dice cuántas direcciones IP en el mundo tienen ese puerto abierto. Puerto 3389, escritorio remoto de Windows. Puerto 445, compartición de archivos SMB. Puerto 1433, Microsoft SQL Server. Puerto 3306, MySQL. Puerto 8080, interfaces de administración web. Lo que quieras.
Cuando ejecutas MassScan contra los rangos de IP asignados a países latinoamericanos, lo que encuentras es perturbador.
Miles de servidores con escritorio remoto expuesto directamente a internet. Sin VPN. Sin MFA. Accesibles desde cualquier lugar del mundo con un usuario y contraseña — que en muchos casos son «admin/admin» o «administrador/123456» porque nadie los cambió.
Miles de bases de datos con puertos abiertos al mundo. MySQL, SQL Server, PostgreSQL, MongoDB. Bases de datos que deberían estar detrás de un firewall, accesibles únicamente desde la red interna, y que están expuestas como si fueran páginas web públicas.
Interfaces de administración de routers, switches, cámaras de seguridad, sistemas de control industrial — todo expuesto. Todo accesible. Todo esperando a que alguien con las credenciales de fábrica entre y tome control.
Y eso es lo que encuentra un escaneo pasivo. Sin explotar nada. Sin vulnerar nada. Solo mirando qué puertas están abiertas. El equivalente digital de caminar por un centro comercial y ver qué tiendas dejaron la puerta abierta después de cerrar.
Ahora imagina lo que encuentra un hacker ético cuando le das autorización para cruzar esas puertas.
Por qué tu corporativo necesita un hacker ético, no otro appliance de seguridad
CISO que me lee y que está pidiendo presupuesto para el próximo año fiscal: necesito que entiendas algo que va a cambiar tu forma de pensar la seguridad de tu empresa.
Tu problema no es que te falten herramientas. Tu problema es que no sabes si las herramientas que tienes funcionan.
Tienes un firewall de última generación. ¿Funciona? No lo sabes. Sabes que está encendido. Sabes que tiene las reglas que el proveedor configuró cuando lo instaló. Pero no sabes si esas reglas resisten un ataque real. No lo sabes porque nadie lo ha probado.
Tienes un WAF protegiendo tu aplicación web. ¿Bloquea ataques? No lo sabes. Sabes que el dashboard muestra gráficas de «amenazas bloqueadas.» Pero no sabes si un atacante con conocimiento puede evadir esas reglas, inyectar SQL a través de un parámetro que el WAF no inspecciona, o explotar una vulnerabilidad en la lógica de negocio que ningún WAF del mundo detecta porque los WAF no entienden lógica de negocio.
Tienes EDR en cada endpoint. ¿Detecta malware avanzado? No lo sabes. Sabes que detectó un par de adware que un empleado descargó por accidente. Pero no sabes si detecta un payload personalizado que un red teamer — o un atacante real — genere específicamente para evadir tu EDR. Porque los EDR detectan patrones conocidos. Un atacante sofisticado genera patrones desconocidos.
Tienes SIEM recolectando logs. ¿Tu equipo de monitoreo ve alertas? Probablemente. ¿Entiende las alertas? ¿Las prioriza correctamente? ¿Responde a tiempo? ¿Distingue un falso positivo de un ataque real? No lo sabes. Porque nunca has generado un ataque controlado que ponga a prueba la capacidad de detección y respuesta de tu equipo.
Un hacker ético hace todo eso. Prueba el firewall. Evade el WAF. Genera payloads que desafían al EDR. Genera alertas que ponen a prueba al equipo de monitoreo. Y al final te entrega un reporte que no dice «usted cumple con el requisito 6.2 del estándar X» — dice «entré a su red por aquí, llegué a su base de datos por acá, extraje estos datos por allá, y nadie en su equipo lo detectó.»
Eso es seguridad real. Todo lo demás es teatro.
Los cinco hallazgos más comunes en pentesting corporativo en LATAM
Después de 17 años haciendo esto en la región y habiendo formado a más de 1,300 peritos en 10 países, puedo decir que los hallazgos se repiten con una consistencia deprimente. Las empresas son diferentes — tamaños diferentes, industrias diferentes, países diferentes. Pero los errores son los mismos. Una y otra vez.
1. Segmentación de red inexistente o decorativa
La segmentación de red es el concepto de dividir la red de una empresa en zonas aisladas, de manera que si un atacante compromete una zona, no pueda moverse lateralmente a las demás. Es seguridad básica. Es el equivalente a que un hospital tenga puertas entre áreas — si hay un incendio en urgencias, el fuego no llega a quirófano.
En la mayoría de los corporativos latinoamericanos que hemos auditado, la segmentación es inexistente o decorativa. Existen VLANs en el papel. El diagrama de red las muestra. Pero las reglas de firewall entre VLANs son tan permisivas que un atacante puede saltar de la red de invitados a la red de servidores de producción sin encontrar resistencia.
Hemos visto corporativos donde la red WiFi de invitados — la que le das al visitante con la contraseña escrita en un post-it en recepción — está en la misma subred que los servidores de contabilidad. En la misma. Sin firewall entre ellas. Sin ACL. Sin nada. Un visitante con una laptop y Wireshark puede ver el tráfico de la red de contabilidad desde la sala de espera.
2. Credenciales por defecto en infraestructura crítica
Switches con la contraseña de fábrica. Firewalls con la contraseña que el integrador puso el día de la instalación y que compartió por correo electrónico. Consolas de administración de servidores con «admin/admin.» Interfaces de gestión de hipervisores con contraseñas que son el nombre de la empresa seguido de «123.»
He visto controladores de dominio de Active Directory — la pieza central de la infraestructura de identidad de cualquier corporativo que usa Windows — con cuentas de administrador local que tienen la contraseña «P@ssw0rd.» La contraseña que literalmente todos los tutoriales de seguridad usan como ejemplo de lo que no debes poner.
Y no estoy hablando de PYMES de 20 empleados. Estoy hablando de corporativos con miles de usuarios, cotizados en bolsa, con presupuestos de TI de millones de dólares. La contraseña de fábrica no es un problema de presupuesto. Es un problema de cultura.
3. Aplicaciones web con vulnerabilidades de hace una década
Inyección SQL. Cross-site scripting. Insecure direct object references. Falta de validación de entrada. Sesiones que no expiran. Tokens predecibles. Endpoints de API sin autenticación.
Estas vulnerabilidades están documentadas desde hace 15 años en el OWASP Top 10. Son las vulnerabilidades más conocidas, más documentadas, más enseñadas del mundo de la seguridad web. Y siguen apareciendo en las aplicaciones corporativas latinoamericanas como si el OWASP Top 10 no existiera.
La razón es estructural: las aplicaciones se desarrollan con presión de tiempo y presupuesto. Se priorizan las funcionalidades sobre la seguridad. Se contrata al desarrollador más barato. No se hacen revisiones de código. No se hacen pruebas de seguridad antes de poner la aplicación en producción. La aplicación sale, funciona, el usuario la usa y todos están contentos — hasta que un atacante encuentra la inyección SQL que le da acceso a toda la base de datos.
4. Movimiento lateral sin detección
Este es quizá el hallazgo más grave. No por la vulnerabilidad en sí, sino por lo que implica: que un atacante puede moverse dentro de la red de la empresa durante días, semanas o meses sin ser detectado.
En las pruebas de penetración que Duriva ha ejecutado en corporativos de la región, el tiempo promedio que nuestros red teamers pasan dentro de la red antes de ser detectados — si es que son detectados — es medido en días. No en minutos. No en horas. En días.
Eso significa que un atacante real — que no tiene la restricción ética de avisar si llega demasiado lejos — tiene todo el tiempo del mundo para mapear la red, identificar los activos críticos, exfiltrar datos y establecer persistencia. Para cuando el equipo de seguridad detecta algo — si es que detecta algo –, el atacante ya tiene lo que quería.
Los equipos de seguridad de los corporativos latinoamericanos están configurados para detectar amenazas obvias. Un escaneo de puertos ruidoso. Un intento de fuerza bruta contra el login de la VPN. Un malware conocido que el antivirus atrapa. Esas son las amenazas que detectan porque esas son las amenazas para las que están entrenados.
Un atacante sofisticado no hace ruido. Usa credenciales legítimas robadas. Se mueve con protocolos normales de la red. Usa herramientas nativas del sistema operativo — PowerShell, WMI, PsExec. No instala malware detectable. Se camufla con el tráfico normal. Y pasa desapercibido.
5. IoT como vector de ataque ignorado
La cafetera del inicio de este artículo no es un caso aislado. Es un patrón.
Cámaras de seguridad IP con credenciales de fábrica, conectadas a la red corporativa, con puertos de administración abiertos. Impresoras con servidores web integrados que almacenan en caché los últimos documentos impresos — incluyendo contratos confidenciales, estados financieros, nóminas. Termostatos inteligentes. Pantallas de sala de juntas con conexión WiFi. Sensores de ocupación. Sistemas de control de acceso físico. Todos conectados a la red. Todos con firmware desactualizado. Todos ignorados por el equipo de seguridad porque «no son computadoras.»
Son computadoras. Son computadoras con Linux embebido, con puertos abiertos, con servicios corriendo, con interfaces de administración accesibles y con contraseñas de fábrica. Son computadoras que nadie parchea, nadie monitorea, nadie incluye en el inventario de activos y nadie considera en la evaluación de riesgos.
Un hacker ético los encuentra en los primeros 30 minutos de reconocimiento. Un atacante real también.
La evolución que LATAM necesita: de pentesting anual a red team continuo
El modelo tradicional de contratación de seguridad ofensiva en Latinoamérica es el siguiente: la empresa contrata un pentesting una vez al año. El pentester viene, prueba durante una o dos semanas, entrega un reporte PDF de 300 páginas que nadie lee completo, el equipo de TI remedia las vulnerabilidades críticas (algunas, no todas), y todos se olvidan del tema hasta el próximo año.
Ese modelo es insuficiente. Es como ir al médico una vez al año, hacerte un chequeo y asumir que estarás sano los otros 364 días. La salud no funciona así. La seguridad tampoco.
El panorama de amenazas cambia todos los días. Nuevas vulnerabilidades se publican todos los días. Nuevos sistemas se despliegan todos los meses. Empleados entran y salen. Configuraciones cambian. Aplicaciones se actualizan — o dejan de actualizarse. La superficie de ataque de una empresa es un organismo vivo que muta constantemente. Un pentesting anual es una radiografía de un momento. No es un monitoreo de salud.
Lo que los corporativos latinoamericanos necesitan es evolución hacia tres niveles de madurez:
Nivel 1: Pentesting periódico. Pruebas de penetración al menos dos veces al año, o cada vez que se despliega un sistema nuevo significativo. Alcance definido. Reporte con vulnerabilidades priorizadas por riesgo real, no por severidad CVSS genérica. Plan de remediación con fechas y responsables. Validación de remediación — el pentester vuelve y verifica que las vulnerabilidades se cerraron.
Nivel 2: Red team dedicado. Un equipo — interno o externo — cuyo trabajo permanente es intentar vulnerar la empresa. No con alcance definido. No con fecha de inicio y fecha de fin. Sin restricciones artificiales. El red team ataca cuando quiere, como quiere, por donde quiere. Ingeniería social. Acceso físico. Ataques a la cadena de suministro. Phishing dirigido. Todo vale. Y el blue team — el equipo de defensa — tiene que detectarlos, contenerlos y responder.
Nivel 3: Purple team. El red team y el blue team trabajan juntos. El red team ejecuta un ataque. El blue team intenta detectarlo. Si no lo detecta, se sientan juntos, analizan por qué falló la detección y ajustan las defensas. El siguiente ataque prueba si el ajuste funcionó. Ciclo continuo de ataque, detección, mejora, ataque, detección, mejora. Iterativo. Permanente. Sin fin.
La mayoría de los corporativos latinoamericanos están en el Nivel 0 — no hacen nada — o en un Nivel 1 tibio: pentesting anual con reporte archivado. Los que están en Nivel 2 se cuentan con los dedos de una mano en la mayoría de los países de la región. Los que están en Nivel 3 son, en mi experiencia, excepcionales.
Y mientras tanto, los atacantes — los reales, los que no tienen restricciones éticas ni alcance definido ni contrato de confidencialidad — operan en modo continuo, 24/7, 365 días al año.
La asimetría es evidente. Y las empresas la están perdiendo.
La cafetera no era el problema. La mentalidad sí.
Voy a volver a la cafetera del inicio. Porque la cafetera no era el problema. La cafetera era el síntoma.
El problema era que la empresa había construido toda su estrategia de seguridad alrededor de la protección perimetral. Firewall en el borde. Antivirus en los endpoints. Política de contraseñas para los usuarios. Todo mirando hacia afuera. Todo asumiendo que el atacante viene de internet, cruza el firewall, y ataca los servidores.
Pero el modelo de «castillo y foso» murió hace una década. El atacante no necesita cruzar el firewall si puede entrar por un dispositivo IoT que está adentro del castillo. No necesita adivinar la contraseña del usuario si puede robarla a través de un phishing que el usuario no detectó. No necesita explotar una vulnerabilidad zero-day si hay un servidor con un parche pendiente de hace dos años.
La mentalidad de seguridad perimetral asume que adentro es seguro y afuera es peligroso. Un hacker ético demuestra en 48 horas que adentro es tan peligroso como afuera. A veces más.
La mentalidad que los corporativos latinoamericanos necesitan adoptar es zero trust — no confiar en nada ni en nadie, verificar todo, asumir que la red ya está comprometida y actuar en consecuencia. Y la única forma de saber si tu implementación de zero trust funciona es ponerla a prueba con alguien que piense como atacante.
El costo de no tener un hacker ético
Director financiero que me lee y que está evaluando si el costo de un programa de seguridad ofensiva se justifica: déjame darte los números que deberían importarte.
El costo promedio de un incidente de ciberseguridad para una empresa mediana en Latinoamérica — incluyendo respuesta al incidente, recuperación de sistemas, pérdida de productividad, daño reputacional y potenciales sanciones regulatorias — se mide en cientos de miles de dólares. Para empresas grandes, en millones.
El costo de un programa de pentesting periódico — dos pruebas al año con alcance razonable — es una fracción de eso. Una fracción pequeña.
Pero el argumento no es solo económico. Es de supervivencia. Porque cuando el incidente ocurre — cuando el ransomware cifra todos los servidores, cuando la base de datos de clientes aparece a la venta en un foro de la dark web, cuando la transferencia fraudulenta vacía la cuenta corporativa — no es solo dinero lo que se pierde. Es confianza. Es reputación. Es la relación con clientes que tardó años en construirse y que se destruye en un comunicado de prensa.
Un hacker ético encuentra la vulnerabilidad antes que el atacante. Eso es todo lo que necesitas saber para justificar la inversión.
Lo que Duriva ha aprendido haciendo seguridad ofensiva en la región
17 años. 10 países. Más de 1,300 peritos formados. Incontables pruebas de penetración. Incontables hallazgos. Y una conclusión que se ha reforzado con cada proyecto:
La tecnología no es el problema. La mentalidad es el problema.
Las empresas latinoamericanas compran tecnología de seguridad de primer nivel. Firewalls de Palo Alto, CrowdStrike en los endpoints, Splunk en el SIEM, Zscaler en la nube. La tecnología es la misma que usan las empresas en Silicon Valley. El hardware es idéntico. El software es idéntico. Las licencias son las mismas.
Pero la forma de usarla es diferente. La forma de configurarla es diferente. La forma de monitorearla es diferente. La forma de responder cuando genera una alerta es diferente. Y la forma de probarla — si es que se prueba — es diferente.
No es un problema de presupuesto. Es un problema de prioridades. De cultura. De entender que la seguridad no es un producto que compras sino un proceso que ejecutas. Y que ese proceso incluye, de forma no negociable, a alguien cuyo trabajo es intentar romper lo que construiste.
Lo que necesita saber cada persona que lee esto
CEO del corporativo latinoamericano: tu empresa probablemente tiene vulnerabilidades que tu equipo de TI no conoce. No porque sean incompetentes, sino porque están demasiado cerca del sistema para verlo como lo ve un atacante. Necesitas ojos externos. Ojos hostiles controlados. Un hacker ético te muestra lo que un atacante real va a encontrar, antes de que el atacante real lo encuentre.
CISO que está armando presupuesto: deja de pedir dinero para más appliances. Pide dinero para probar los que ya tienes. Un pentesting que demuestre que tu firewall de $10,000 dólares tiene reglas permisivas que anulan su valor es más útil que otro firewall de $10,000 dólares que nadie va a configurar correctamente.
Director de TI que siente que un pentesting es una crítica a su trabajo: no lo es. Es una herramienta de mejora. Los mejores equipos de TI que he conocido en la región son los que piden el pentesting, no los que lo resisten. Porque entienden que encontrar una vulnerabilidad antes que un atacante no es una falla del equipo de TI — es un éxito del programa de seguridad.
Regulador latinoamericano que me lee: las regulaciones de ciberseguridad en la región están atrasadas respecto al panorama de amenazas. La mayoría exige controles mínimos y auditorías de cumplimiento, pero no exige pruebas de penetración periódicas. No exige red team. No exige validación práctica de la seguridad. Mientras eso no cambie, las empresas seguirán invirtiendo en cumplimiento de papel y no en seguridad real.
Llevo 17 años haciendo esto. He entrado por cafeteras, por impresoras, por cámaras de seguridad, por termostatos, por el WiFi de invitados, por la VPN que no tenía MFA, por el servidor de desarrollo que «nadie usa» pero que estaba conectado a la red de producción, por el Active Directory con la contraseña de administrador que era el nombre de la empresa.
Cada una de esas entradas fue bajo contrato, bajo autorización, bajo marco legal. Cada una fue documentada, reportada y remediada. Cada una hizo a la empresa más segura.
Pero cada una de esas vulnerabilidades existía antes de que la encontráramos. Y si nosotros no la hubiéramos encontrado, alguien más lo habría hecho. Alguien sin contrato. Sin autorización. Sin marco legal. Sin la obligación de reportar.
Esa es la diferencia entre un hacker ético y un atacante. Ambos encuentran la misma vulnerabilidad. Solo uno te la reporta.
Tu corporativo necesita al que reporta. Y lo necesita ahora. No después del incidente. No después de la filtración. No después de la llamada del regulador. Ahora.