¿Cómo Encuentran Vulnerabilidades los Hackers?

Los hackers encuentran vulnerabilidades en aplicaciones reales combinando técnicas automatizadas de escaneo, análisis de código fuente y dinámico, fuzzing, y pruebas manuales de penetración. Usan herramientas como Burp Suite, OWASP ZAP y Metasploit para mapear aplicaciones, identificar puertos abiertos, detectar versiones obsoletas de software con fallos conocidos, y ejecutar ataques contra los puntos débiles más comunes documentados en el OWASP Top 10.

Por qué es importante entender cómo se encuentran vulnerabilidades

Si sos administrador de sistemas, desarrollador o responsable de seguridad, necesitás pensar como un atacante. Las vulnerabilidades no desaparecen porque vos no las veas. Mientras vos dormís, hay actores maliciosos (criminales, grupos de hacktivismo, rivales comerciales) buscando activamente los agujeros en tu código.

Lo que pasó con curl en 2026 lo ilustra bien. El proyecto cerró su programa de bug bounty (no sin antes recibir 95% de reportes inválidos), pero eso no significa que curl sea más seguro. Al contrario: significa que hay menos ojos profesionales buscando. Y mientras tanto, versiones antiguas de curl siguen en uso en servidores que nunca se actualizaron porque “si no está roto, no lo toco” (y ahora está roto, pero nadie lo sabe).

Los atacantes saben esto. Saben que muchas organizaciones usan software con 5, 10 o más años de antigüedad. Saben que ese desastre de control de acceso que parece que nadie revisó en años es probable que sea explotable. Y lo van a buscar sistemáticamente.

Métodos principales de descubrimiento de vulnerabilidades

El descubrimiento de vulnerabilidades comienza con el reconocimiento. Los hackers empiezan donde siempre: mapeando tu infraestructura. Hacen escaneo de redes para identificar qué máquinas están activas, abren nmap para ver qué puertos están escuchando, ejecutan banners grabbing para determinar qué versiones específicas de software estás corriendo.

Eso que ves en películas donde el hacker “abre una terminal y ataca el mainframe”? En la realidad es: nmap -sV miempresa.com para obtener las versiones, luego googlear “CVE + nombre + versión”, y si hay un exploit público, intentar ejecutarlo. Simple, menos dramático, más efectivo.

Una vez que sabe qué software estás usando, el atacante consulta bases de datos públicas como el National Vulnerability Database (NVD) o Shodan. Ahí busca CVEs (Common Vulnerabilities and Exposures) asociados a esas versiones específicas. Si encontró que estás corriendo Apache 2.4.41 (lanzado en 2020) con un RCE crítico no parcheado, ya ganó.

Footprinting: recolección de información

El footprinting es menos glamoroso de lo que suena. Es cavar en DNS records, whois, certificados SSL públicos (sí, el certificado que vos pusiste para que HTTPS funcione expone qué dominios alojás), emails filtrados en breaches previos, credenciales hardcodeadas en repositorios GitHub públicos que alguien hizo push por accidente.

Un atacante ve un certificado SSL con múltiples dominios y ya sabe cuáles son tus servicios internos. Ve un repositorio GitHub viejo de un ex-empleado que olvidó hacer privado, y encuentra contraseñas de base de datos. Ve un email en un foro de 2015 preguntando cómo configurar tu aplicación interna, y extrae detalles técnicos que vos mismo desconocías que habías expuesto. Lo explicamos a fondo en mediante agentes de análisis automatizado.

Análisis estático versus análisis dinámico: dos enfoques que se complementan

El análisis estático inspecciona el código fuente sin ejecutarlo. Herramientas como SonarQube, GHIDRA (la herramienta de la NSA que Palantir usa en ciertos contextos) y PeStudio automatizan la búsqueda de patrones inseguros: variables sin validar, funciones deprecadas, buffers sin límite, criptografía débil.

El análisis dinámico, en cambio, ejecuta la aplicación y observa qué hace en tiempo real. Herramientas como Frida (inyecta código en procesos en vivo) y APKTool (desensambla apps Android) permite ver qué sucede cuando enviás inputs específicos, cómo maneja el error, dónde se quiebra.

Lo fuerte de un atacante es que no elige: usa ambas. Analiza el código si lo puede conseguir (repositories públicos, binarios descompilados), pero si no puede, ejecuta la aplicación sistemáticamente, probando cada input, cada endpoint, cada función, hasta encontrar algo que se quiebre.

Un ejemplo: si la aplicación tiene un formulario de login, el ataque dinámico intenta SQL injection (' OR '1'='1), XSS (<script>alert(1)</script>), inyecciones LDAP, inyecciones XPATH. El análisis estático ve en el código que nunca hiciste sanitization del input. Ambos llegan a la conclusión: la aplicación es vulnerable.

Fuzzing: ataque automatizado por generación de datos caóticos

El fuzzing es una de las técnicas más efectivas porque es simple y brutal. Tomá un punto de entrada de tu aplicación (un formulario, una API, un parser de archivos) y enviále datos aleatorios o malformados a alta velocidad.

Herramientas como Wfuzz (fuzzing web) y AFL (American Fuzzy Lop, para binarios) generan miles de payloads por minuto. Cada payload es una pequeña variación: si probó “AAAAAA”, después prueba “AAAAAAB”, luego “AAAAABAAAAA”. Lo que buscan es encontrar alguna combinación que haga que el programa:

• Lance una excepción no manejada (crash = vulnerability)
• Sobrescriba memoria (buffer overflow, heap overflow)
• Ejecute código no autorizado (RCE)
• Acceda a datos que no debería

El fuzzing típicamente tarda 40 a 90 segundos por iteración según la complejidad de la aplicación. Pero el volumen compensa: un fuzzer puede probar millones de inputs en horas. Es metralla digital. Los defensores la odian porque no se puede predecir, y los atacantes la aman por la misma razón. En en repositorios públicos profundizamos sobre esto.

Las 10 vulnerabilidades más buscadas: OWASP Top 10 2025

Ojo acá: no todos los hackers son creativos. Muchos usan el OWASP Top 10 como checklist. Si una vulnerabilidad está en esa lista, ya saben que probablemente tu equipo también se la conoce. Y si todavía está ahí en tu aplicación, es porque la negligencia ganó.

Herramientas profesionales: Burp Suite, OWASP ZAP, Metasploit

Burp Suite es el estándar de facto para pentesting web. Cuesta USD 399 anuales por la licencia profesional (hay versión community gratuita), pero vale cada centavo. Intercepta todo el tráfico HTTP/HTTPS entre tu navegador y la aplicación, te permite modificar requests sobre la marcha, y tiene un escáner automatizado que busca las vulnerabilidades comunes. Los hackers lo usan porque funciona (spoiler: no funciona mejor que las cosas gratuitas, pero lo ven usar en Netflix y lo adoptan).

OWASP ZAP es la alternativa gratuita. Hace 80% de lo que Burp hace, es código abierto, y se integra fácil en pipelines CI/CD. Corre escaneos automatizados, identifica inyecciones, misconfiguración, credenciales débiles. Menos pulida que Burp, pero si estás iniciando o sos una startup, es más que suficiente.

Metasploit es el framework de explotación. No busca vulnerabilidades; asume que ya las encontraste. Lo que hace es automatizar el proceso de escribir el exploit, ejecutarlo, y mantener acceso. Es el arma que dispara la bala que el hacker ya sabe dónde está. Versión community es libre; versión pro (USD 35k/año) tiene más payloads y características.

OpenVAS escanea redes completas en busca de vulnerabilidades conocidas. Mucho más ruidoso que Burp (porque escanea todo, no solo una aplicación), pero es gratuito y cubre miles de CVEs públicas.

Reverse engineering: desarmando binarios sin ver el código

No siempre el hacker tiene acceso al código fuente. Pero eso no es un problema real. Si lograron tu ejecutable (porque lo descargaron de tu sitio público, o lo sacaron del APK de tu app, o simplemente lo pidieron a Amazon), pueden descompilarlo.

GHIDRA (desarrollada por la NSA y liberada en 2019) es la herramienta estándar. Toma un binario compilado y lo desensambla a pseudocódigo legible (no perfecto, pero funciona). JADX desensambla Android apps directamente a Java fuente. radare2 es más low-level pero extremadamente poderosa.

Subís el binario, GHIDRA te muestra las funciones, los strings (ahí encontrás URLs hardcodeadas, mensajes de error, a veces credenciales), las llamadas a sistema, el flujo lógico. No es perfectamente claro, pero es suficiente para encontrar dónde valida autenticación, dónde genera tokens, dónde encripta datos. Y una vez que ves la lógica, el ataque es cuestión de matemática.

Bug bounty: cómo los hackers legales encuentran vulnerabilidades y ganan dinero

No todos los hackers buscan vulnerabilidades para robar dinero o datos. Algunos las buscan legalmente en programas de bug bounty, y las grandes empresas les pagan por encontrarlas responsablemente. Cubrimos ese tema en detalle en con herramientas basadas en IA.

PayPal ha pagado USD 3 millones desde 2014 por más de 80 vulnerabilidades críticas reportadas. Google, Facebook, Microsoft tienen programas activos. Plataformas como HackerOne y Bugcrowd conectan hackers con empresas que quieren que busques voluntariamente en su código.

El modelo funciona porque es un win-win: el hacker gana dinero (de USD 100 a USD 50.000+ por hallazgo crítico, dependiendo de la empresa), y la empresa parchea el agujero antes de que un malo lo encuentre. Una vulnerabilidad RCE en Facebook hace algunos años valía USD 40.000.

El drama reciente es que curl cerró su programa en 2026 después de recibir 95% de reportes completamente inválidos (gente reportando “cosas” que no son vulnerabilidades, solo ignorancia). Pero eso es excepcional. La mayoría de programas activos sigue viva.

Errores comunes que dejan la puerta abierta

Error 1: No actualizar dependencias. Tu aplicación usa Apache 2.4.41 porque así la dejaron hace 6 años. No es tu culpa (técnicamente), pero es tu vulnerabilidad. Los hackers lo saben. Tienen exploits públicos listos. La solución es mantener un proceso automático de updates: Dependabot en GitHub, renovatebot, lo que sea. Si tu tech team dice “no actualizamos porque no sabemos qué va a romper”, eso es un problema organizacional que vas a pagar caro.

Error 2: Confiar en la obscuridad como seguridad. “Nadie va a encontrar mi panel de admin si está en /admin_panel_secreto_del_2015”. Equivocado. Un fuzzer de directorios (dirbuster, gobuster) prueba miles de paths por segundo. Un crawl del sitio encuentra todas tus URLs. El WAYBACK MACHINE guarda versiones viejas de tu sitio. Los atacantes tienen listas de 10 millones de rutas comunes. La obscuridad no es seguridad. Es lo primero que pierdes.

Error 3: Errores que devuelven información del sistema. Tu aplicación quiebra y muestra un stack trace con rutas de archivo, versión de PHP, librerías importadas. Es como dejar un manual de instrucciones en el sitio de ataque. Configurá que los errores en producción se logueen en el servidor, no se muestren al usuario. En desarrollo está bien; en producción, nunca.

Error 4: Credenciales en el código. Alguien hace push accidental de credenciales a GitHub. El repositorio es público (o era). GitHub tiene bots que buscan automáticamente credenciales expuestas. Los hackers también. Ya pasó a Twilio, a Travis CI, a montones. Si pusiste una API key en el código, asumí que está comprometida. Usá secrets managers (AWS Secrets Manager, HashiCorp Vault, .env files en .gitignore). Tema relacionado: en plataformas como GitHub.

Preguntas Frecuentes

¿Cuál es la diferencia entre penetration testing y hacking?

Penetration testing (pentesting) es autorizado. Una empresa te contrata para buscar vulnerabilidades en su sistema. Hacking no autorizado es ilegal. El técnico es idéntico; la diferencia legal es monumental. Un pentester usa las mismas herramientas que un hacker, pero con permiso escrito de la empresa, dentro de un alcance definido, sin acceder a datos reales de usuarios. El hacker hace lo mismo pero sin permiso.

¿Es posible encontrar vulnerabilidades sin hacer fuzzing o usar herramientas?

Sí. Revisión de código manual, pruebas de caja negra (usar la aplicación como usuario normal pero malicioso), exploración de parámetros, pruebas de autenticación. Un pentester experimentado encuentra vulnerabilidades leyendo el código y probando manualmente. Las herramientas automatizan y escalan, pero la inteligencia sigue siendo humana.

¿Qué hace que una vulnerabilidad sea “crítica” versus “baja”?

Criticidad combina impacto (¿qué tan malo es si se explota?) y probabilidad (¿qué tan fácil es explotarla?). Una inyección SQL que le permite al atacante robar todas las contraseñas es crítica: alto impacto, relativamente fácil. Un error tipográfico en un mensaje de error es bajo: impacto mínimo, difícil de explotar. CVSS (Common Vulnerability Scoring System) lo cuantifica en escala 0-10.

¿Cuánto tiempo tarda en encontrar una vulnerabilidad?

Depende. Una inyección SQL en un formulario mal hecho: 5 minutos. Una lógica de negocio rota que solo se ve bajo condiciones específicas: semanas. Un atacante con acceso a la red: horas. Un pentester con scope limitado: días. No hay número mágico.

¿Las aplicaciones modernas (React, Vue, backend serverless) son más seguras que las antiguas?

No necesariamente. Los frameworks modernos tienen defensas mejores contra ciertos ataques (CSRF protection built-in, sanitization automática en algunos casos). Pero también pueden ser más complejos, más difíciles de auditar, y generan nueva superficie de ataque (APIs REST sin rate limiting, cookies sin protección SameSite). Es un trade-off. Código antiguo bien escrito es más seguro que código moderno escrito de forma negligente.

Conclusión

Los hackers encuentran vulnerabilidades porque les importa, porque es sistemático, y porque la mayoría de las empresas no hace lo suficiente para defenderse. La combinación de escaneo automatizado, análisis manual, fuzzing y reverse engineering es prácticamente imparable contra una aplicación mediocre.

Lo que podés hacer: mantener dependencias actualizadas (automatizá), no expongas información en errores (configurá), validá todos los inputs como si un atacante los escribiera (porque así es), usá criptografía moderna (HTTPS/TLS 1.3 como mínimo), implementá autenticación fuerte (MFA, TOTP, passkeys), loguea todo lo importante. No es sexy. No es novel. Pero funciona.

Si querés estar realmente seguro, contratá un pentester. Vale USD 5.000 a USD 50.000 dependiendo del scope y la empresa, pero es infinitamente más barato que un breach posterior. Un pentester en una semana encuentra lo que un hacker descubre lentamente entre un mes y un año. Y eso da tiempo para parchearlo.

Fuentes

• The Power Education – Identificación y explotación de vulnerabilidades en aplicaciones
• Tarlogic – Cómo se detectan vulnerabilidades en aplicaciones
• OWASP – Top 10 Web Application Security Risks 2025
• Campus Ciberseguridad – Burp Suite como herramienta de penetration testing
• WeLiveSecurity – Bug Bounty: cómo funciona el hacking ético