Qué encuentra un pentest: 6 puntos débiles, casos reales y riesgos para el negocio en 2026

Un pentest muestra algo más que vulnerabilidades técnicas. A veces el mayor riesgo está escondido en una operación de negocio corriente o en cómo reaccionan los empleados ante un correo falso.

Nuestros especialistas encontraron y llevaron a cabo dos casos reveladores: una vulnerabilidad crítica de lógica de negocio en un exchange de criptomonedas, donde un atacante podría haber retirado todos los fondos disponibles en el exchange a un tipo de cambio de su elección, y una simulación de phishing en uno de los tres mayores bancos de Ucrania (miles de empleados), donde el 64% de todos los empleados hizo clic en el enlace y el 36% introdujo su usuario y contraseña.

Estos casos no son una muestra estadística. Muestran por qué es importante revisar no solo las vulnerabilidades técnicas conocidas, sino también la lógica de negocio, los permisos de acceso y el comportamiento de los usuarios.

A continuación repasamos seis categorías de riesgo: cómo funcionan, a qué consecuencias pueden llevar y por dónde empezar a revisarlas. Para el contexto internacional citamos aparte datos de Verizon DBIR 2026, OWASP, NCSC, CERT-UA y otras fuentes primarias. Esos datos no son estadísticas de clientes de Veiltrack.

En resumen: qué muestran las revisiones de seguridad

• Lógica de negocio: nuestros especialistas encontraron una vulnerabilidad crítica en un exchange de criptomonedas: el usuario podía cambiar el tipo de cambio en su propia operación. Un atacante podría haber retirado todos los fondos disponibles en el exchange a un tipo de cambio de su elección, así que la pérdida solo habría estado limitada por la cantidad de fondos que tenía el exchange.
• Phishing: en una simulación de entrenamiento en uno de los tres mayores bancos de Ucrania (miles de empleados), el 64% de todos los empleados hizo clic en el enlace y el 36% introdujo su usuario y contraseña. Algunos lo hicieron varias veces, con distintas combinaciones de credenciales.
• Seis categorías para revisar: permisos de acceso en las API, lógica de negocio, protección de las cuentas frente al phishing, configuración del dominio de correo, servicios externos y permisos de acceso en la nube.
• Contexto internacional: Verizon DBIR 2026 informa de que la explotación de vulnerabilidades pasó a ser el principal vector inicial de las brechas en la muestra estudiada: el 31%. El factor humano estuvo presente en el 62% de las brechas. ^{[1] [2]}
• Resultado práctico: para cada categoría se da un primer paso de revisión.

La conclusión principal del autor: tener un control técnico no significa todavía que una operación de negocio o una cuenta estén protegidas frente al abuso. En una revisión importa establecer no solo si hay una vulnerabilidad, sino también qué acción concreta puede hacer un usuario o un atacante y a qué consecuencias lleva.

Dos casos que encontraron y llevaron a cabo nuestros especialistas ilustran esta diferencia: en el exchange, un usuario podía cambiar el tipo de cambio de su propia operación y retirar fondos; en la simulación de phishing de entrenamiento, el 36% de todos los empleados del banco introdujo sus credenciales, y una parte lo hizo varias veces.

Esto no es una estadística del mercado ucraniano, sino dos casos aislados. Las cifras internacionales de Verizon DBIR 2026 se dan como contexto y no deben atribuirse a Veiltrack.

Sobre el autor y el método

Este material lo preparó Vlad Kraevsky, fundador de Veiltrack. Trabaja en ciberseguridad desde 2019, tiene más de seis años de experiencia en pentesting y ha dirigido un equipo de pentesters.

Este material combina tres fuentes de conocimiento distintas:

1. Casos anonimizados de la práctica de nuestros especialistas. Las dos historias de abajo describen lo que encontraron y llevaron a cabo nuestros especialistas. No nombramos las organizaciones, el número exacto de empleados ni los importes de las operaciones.
2. Observaciones profesionales cualitativas. Las seis categorías son un repaso experto de riesgos, no un ranking por frecuencia, número de hallazgos o criticidad.
3. Fuentes externas. Estándares de OWASP, recomendaciones de NCSC y Microsoft, datos de Verizon DBIR 2026, avisos de CERT-UA y especificaciones técnicas. Sus estadísticas no se trasladan a las empresas ucranianas sin datos propios.

No damos el número de revisiones de Veiltrack, la proporción de clientes con determinadas vulnerabilidades ni estimaciones de pérdidas económicas, porque para esta publicación no hay cifras confirmadas de ese tipo.

Historia 1. El exchange de criptomonedas: el usuario podía cambiar el tipo de cambio de su operación

Nuestros especialistas encontraron una vulnerabilidad crítica de lógica de negocio en un exchange de criptomonedas: el usuario podía cambiar el tipo de cambio en su propia operación, cambiar fondos en condiciones ventajosas para él y retirarlos.

El problema no era adivinar una contraseña ni usar una versión de software anticuada. El sistema permitía ejecutar una operación financiera con un parámetro que debían controlar las reglas de negocio.

A qué podría haber llevado. Un atacante podría haber retirado todos los fondos disponibles en el exchange a un tipo de cambio de su elección, así que la pérdida solo habría estado limitada por la cantidad de fondos que tenía el exchange.

Por qué importa al negocio. Si el sistema comprueba mal el precio, el tipo de cambio, la comisión o el límite, el riesgo aparece sin necesidad de obtener permisos de administrador. El usuario puede quedarse dentro de su propia cuenta y, aun así, hacer una operación que el negocio no había previsto.

OWASP WSTG trata las pruebas de lógica de negocio como un área aparte y explica los límites de la búsqueda automatizada de estos problemas. ^[4]

Qué revisar primero. En las operaciones con dinero, comprueba qué parámetros llegan del cliente, qué valores decide el servidor y si se puede alterar el orden previsto de los pasos. Presta especial atención al tipo de cambio, el importe, la comisión, los límites y la repetición de operaciones.

Conclusión para el dueño del negocio: el sistema puede aceptar y ejecutar correctamente una petición y, aun así, el resultado de la operación puede contradecir las reglas de negocio. Por eso no basta con revisar una función financiera solo en busca de vulnerabilidades técnicas estándar: también hay que averiguar quién controla los parámetros críticos de la operación y si el sistema es capaz de rechazar un cambio inadmisible.

Pregunta clave para la revisión: ¿puede un usuario corriente obtener una ventaja económica cambiando los parámetros o el orden de las operaciones que el sistema le permite hacer?

Más en el artículo sobre pruebas de seguridad de fintech y pagos.

Historia 2. Simulación de phishing: el 64% hizo clic en el enlace, el 36% introdujo credenciales

Nuestros especialistas llevaron a cabo una simulación de phishing de entrenamiento en uno de los tres mayores bancos de Ucrania (no revelamos el nombre). El banco tiene miles de empleados. Resultados:

• El 64% de todos los empleados hizo clic en el enlace del correo de prueba.
• El 36% de todos los empleados introdujo su usuario y contraseña en la página de entrenamiento.

Una parte de los empleados introdujo sus credenciales varias veces, a veces con distintas combinaciones de usuarios y contraseñas. Ocurría porque la página se recargaba tras enviar el formulario.

Qué significan estas cifras. Ambos porcentajes se calculan sobre todos los empleados del banco, no solo sobre los que abrieron el mensaje o hicieron clic en el enlace.

Son los resultados de una sola simulación de entrenamiento en un gran banco. No significan que el 64% de los empleados de los bancos ucranianos haga clic en enlaces de phishing ni que el 36% de los empleados de las empresas ucranianas revele sus contraseñas. Igualmente, que el 36% de los empleados introdujera datos no equivale a un 36% de cuentas comprometidas.

Por qué importa. Hacer clic en un enlace e introducir credenciales son hechos distintos. Para evaluar el riesgo no basta con contar los clics: hay que evaluar aparte la disposición de los usuarios a introducir datos en una página que toman por auténtica.

Que se repita la introducción tras recargar el formulario también muestra que un flujo de inicio de sesión fallido o poco claro no hace necesariamente que la persona se detenga.

Qué hacer. La formación de los empleados debe combinarse con la protección técnica de las cuentas. El NCSC británico recomienda preferir FIDO2 a los métodos de MFA que usan códigos. ^[5]

Aparte, prevé una forma sencilla de avisar de correos sospechosos y comprueba no solo los clics en enlaces, sino también las acciones posteriores en el escenario de entrenamiento.

Conclusión: el resultado de una simulación de phishing no puede evaluarse solo por los clics. En este caso el 64% de todos los empleados hizo clic en el enlace, el 36% de todos los empleados introdujo su usuario y contraseña, y una parte repitió la introducción tras recargarse el formulario.

Estas observaciones describen tres aspectos distintos del comportamiento: el clic en el enlace, la introducción de credenciales y los intentos repetidos de introducirlas.

Para el cliente esto significa que el informe de una simulación debe explicar no solo el número de clics, sino también las acciones posteriores de los participantes. Si no, una parte importante del resultado de la revisión pasa desapercibida.

Cómo funciona una revisión así se describe en el artículo sobre simulación de phishing para empleados.

6 puntos débiles que conviene revisar en un negocio

A continuación, seis categorías de riesgo a las que conviene prestar atención al revisar aplicaciones web, API, infraestructura externa, correo y cuentas en la nube.

Esto no es un ranking de las vulnerabilidades más frecuentes en Ucrania. No las ordenamos por número de proyectos, frecuencia ni puntuación CVSS.

Para cada categoría explicamos en qué consiste el problema, el posible impacto en el negocio y un primer paso práctico. Las fuentes primarias públicas se citan como fundamento técnico o contexto internacional, no como prueba de la frecuencia de hallazgos en clientes de Veiltrack.

1. Acceso a datos ajenos a través de la API (IDOR / BOLA)

Qué es. El servidor puede identificar bien al usuario, pero comprobar poco si tiene derecho a un objeto concreto: una cuenta, un documento, un perfil o una operación.

Por qué importa. Un error de autorización a nivel de objeto puede permitir ver o modificar datos ajenos. El alcance de las consecuencias depende de qué objetos quedan abiertos y qué acciones permite la API.

En el OWASP API Security Top 10 2023, Broken Object Level Authorization (BOLA) figura como API1:2023. ^[3]

Primer paso. Crea dos cuentas de prueba con distintos derechos sobre los datos. Comprueba si el primer usuario puede leer o modificar a través de la API los objetos del segundo. El control de acceso debe aplicarlo el servidor en cada operación, no solo la interfaz de la aplicación. Más en el artículo sobre pruebas de seguridad de webs y API.

2. Errores en la lógica de negocio

Qué es. Una aplicación puede procesar bien cada petición por separado y, aun así, permitir acciones que contradicen las reglas de negocio: cambiar parámetros financieros, repetir una operación o saltarse un paso obligatorio.

Por qué importa. Estos errores pueden afectar directamente al dinero y a los procesos operativos. El ejemplo del exchange de criptomonedas de arriba muestra cómo un usuario corriente podía hacer una operación en condiciones ventajosas para él por un control incorrecto del tipo de cambio.

OWASP WSTG explica que revisar la lógica de negocio exige entender los procesos de la aplicación y a menudo no puede sustituirse por completo con un escaneo automático. ^[4]

Primer paso. Identifica las operaciones que afectan al dinero, los saldos, las bonificaciones, las comisiones o los derechos de los usuarios. Para cada una, comprueba el origen de los parámetros críticos, el orden permitido de las acciones y la posibilidad de ejecutarla de nuevo.

Conclusión: el riesgo depende no solo de una vulnerabilidad técnica, sino también de qué acción de negocio permite hacer el sistema.

3. Phishing y MFA que se puede eludir

Qué es. Un empleado introduce su contraseña en una página falsa. Si no hay segundo factor, o es un código por SMS o de una aplicación, el atacante también puede interceptarlo.

Por qué importa. El factor humano está presente en el 62% de las brechas según DBIR 2026. ^[2] El NCSC británico escribe que los códigos de aplicaciones y de generadores de hardware son vulnerables al phishing con interceptación del código, y que las confirmaciones push ofrecen solo una resistencia parcial por el ataque de «fatiga de solicitudes». La resistencia al phishing la da FIDO2: llaves de seguridad y passkeys. ^[5]

El phishing también se usa contra organizaciones ucranianas. El aviso de CERT-UA del 21 de mayo de 2026 describe envíos de correos desde cuentas comprometidas de organizaciones estatales. ^[6] Es la descripción de una campaña concreta, no una estadística de phishing entre empresas ucranianas.

Qué conviene revisar aparte. Tener MFA en el servicio corporativo principal no garantiza que todas las demás formas de acceso estén protegidas igual. Revisa la VPN, los protocolos de correo, las interfaces administrativas y otros puntos externos de autenticación.

En las cuentas con privilegios críticos, evalúa aparte si se usa MFA resistente al phishing, en concreto llaves FIDO2 o passkeys. ^[5]

Primer paso. Activa la MFA en todos los accesos desde fuera y empieza por llaves FIDO2 o passkeys para los administradores y el departamento de finanzas. En paralelo, haz una simulación de phishing y cuenta por separado los clics en el enlace y la introducción de credenciales. Sobre la configuración del correo y la respuesta al phishing, lee el artículo sobre protección del correo frente al phishing.

4. Configuración de la protección del dominio de correo (SPF, DKIM, DMARC)

Qué es. SPF define las fuentes permitidas de envío de correo, DKIM permite verificar la firma criptográfica del mensaje y DMARC vincula los resultados de esas comprobaciones con el dominio del campo From y fija la política para los mensajes que no superan la autenticación.

Por qué importa. Una configuración incorrecta puede facilitar la suplantación del dominio del remitente. NCSC recomienda aplicar estos mecanismos contra la suplantación de correo. ^[7]

RFC 9989 describe DMARC y sustituye a RFC 7489. ^[8] Google exige SPF y DKIM, y además DMARC a los remitentes que envían más de 5000 mensajes al día a direcciones personales de Gmail. Para el resto de remitentes, el requisito básico es SPF o DKIM. ^[9]

Qué conviene revisar aparte. No te limites al dominio de correo principal. Revisa todos los dominios corporativos, incluidos los que ya no se usan para la correspondencia habitual.

Fíjate en los dominios sin DMARC, en la autenticación correcta de los remitentes legítimos y en la política p=none. Está pensada para monitorizar y por sí sola no exige al destinatario rechazar los mensajes que no pasan DMARC. ^[8]

Antes de pasar a quarantine o reject, comprueba las fuentes legítimas de correo para no romper la entrega de mensajes de trabajo.

Primer paso. Comprueba SPF, DKIM y DMARC en todos tus dominios. Configura los informes de DMARC, asegúrate de que las fuentes legítimas de correo superan la autenticación y, tras comprobarlo, pasa de la monitorización a las políticas quarantine o reject.

Limitación importante. SPF, DKIM y DMARC no protegen frente a todos los tipos de phishing, en particular frente a correos enviados desde un buzón realmente comprometido.

5. Servicios externos olvidados y versiones antiguas de software

Qué es. Un servidor de pruebas, un panel de administración antiguo, una pasarela VPN o un servicio del que nadie se acordó tras la salida de un administrador. Es accesible desde internet y hace tiempo que no se actualiza.

Por qué importa. Un servicio olvidado puede seguir accesible desde internet sin actualizaciones regulares y sin el control de un responsable.

Según Verizon DBIR 2026, la explotación de vulnerabilidades pasó a ser el vector inicial de brechas más frecuente en la muestra estudiada: el 31%. En el conjunto de datos sobre vulnerabilidades incluidas en CISA KEV, solo el 26% de los hallazgos se corrigieron por completo en todas las instancias detectadas, y el tiempo mediano hasta la corrección completa fue de 43 días. Son cifras de la muestra del estudio, no estadísticas de empresas ucranianas. ^{[1] [2]}

OWASP API9:2023 describe aparte los riesgos de una gestión inadecuada del inventario de API. ^[3]

Qué conviene revisar aparte. Compara el registro interno de activos de TI con los dominios, las direcciones IP y los servicios realmente accesibles desde internet. Presta especial atención a los entornos de prueba, los paneles administrativos antiguos y los servicios para los que cuesta identificar a un responsable.

Criterio de resultado: para cada activo accesible desde internet debe estar claro para qué se necesita, quién responde de él, cómo se controla su disponibilidad y si necesita una actualización.

Primer paso. Haz una lista de todo lo que se ve desde internet: dominios, subdominios, direcciones IP, servicios. Apaga lo que sobre y, para el resto, compara las versiones con el catálogo CISA KEV ^[11] y actualiza primero las que aparezcan en él. El escaneo de vulnerabilidades regular ayuda a no volver a esto una vez al año.

6. Permisos de sobra en la nube y en Microsoft 365

Qué es. Demasiadas personas tienen derechos de administrador global, las cuentas de servicio tienen acceso total «por si acaso» y no se revocan los derechos de antiguos empleados y contratistas.

Por qué importa. Los derechos administrativos excesivos aumentan las posibles consecuencias de que una cuenta quede comprometida.

Verizon DBIR 2026 señala que, en la muestra estudiada de entornos en la nube de terceros, el tiempo para corregir la mitad de los hallazgos relacionados con contraseñas débiles y derechos de acceso incorrectos llegaba a casi ocho meses. Estos datos no son una evaluación del estado de Microsoft 365 en Ucrania. ^[2]

Microsoft recomienda el principio de mínimo privilegio, la concesión temporal de derechos mediante Privileged Identity Management, la revisión periódica de accesos y menos de cinco administradores globales. ^[10]

Qué conviene revisar aparte. Averigua qué cuentas tienen derechos administrativos en Microsoft 365 y en otros entornos en la nube. Revisa la actividad de las cuentas de antiguos empleados y contratistas, el alcance de los derechos de las cuentas de servicio, y los plazos de validez y el procedimiento de revocación de las claves de acceso.

Criterio de resultado: cada derecho privilegiado debe tener una finalidad justificada. Si un derecho ya no hace falta para una tarea, hay que revocarlo o limitarlo. ^[10]

Primer paso. Exporta la lista de todas las cuentas con roles de administrador, deja el mínimo y da al resto roles más acotados. La revisión paso a paso se describe en los artículos sobre revisión de seguridad de Microsoft 365 y pentest de la nube en AWS, Azure y GCP.

Qué significan estos ejemplos para quien contrata un pentest

La tarea principal de una revisión es mostrar no solo el nombre de una vulnerabilidad, sino también la acción que permite hacer y a qué puede llevar para el negocio.

Tres conclusiones de la práctica de nuestros especialistas

1. El riesgo financiero puede surgir dentro de una cuenta corriente. En un caso, el usuario de un exchange de criptomonedas podía cambiar el tipo de cambio de su propia operación, hacer el cambio en condiciones ventajosas y retirar los fondos; un atacante podría haber retirado todos los fondos disponibles en el exchange. Este ejemplo muestra por qué las pruebas de lógica de negocio deben abarcar no solo errores técnicos, sino también las reglas de ejecución de las operaciones financieras.
2. Un clic y la introducción de la contraseña son indicadores distintos. En una simulación de phishing de entrenamiento en uno de los tres mayores bancos de Ucrania, el 64% de todos los empleados hizo clic en el enlace y el 36% de todos los empleados introdujo su usuario y contraseña. Son dos indicadores con la misma base de cálculo pero con distinto significado.
3. Repetir la introducción de datos también cuenta. En esa misma simulación, una parte de los empleados introdujo distintas combinaciones de credenciales tras recargarse el formulario. Por tanto, el análisis del comportamiento no debe terminar con contar la primera interacción con la página.

Fuente de los ejemplos: la práctica de nuestros especialistas, descrita por Vlad Kraevsky, fundador de Veiltrack. No es un estudio estadístico ni una muestra representativa de empresas ucranianas.

Por eso los resultados de una revisión conviene evaluarlos teniendo en cuenta la gravedad técnica, la accesibilidad de la función vulnerable, el posible escenario de abuso y las consecuencias para el negocio. La puntuación CVSS es útil, pero no sustituye el análisis de un escenario concreto.

Si quieres que un especialista revise a mano estos seis puntos en tu empresa, empieza por la página de pentest.

Checklist: seis primeros pasos

• Con dos cuentas de prueba hemos comprobado que una no ve ni modifica los datos de la otra en la API.
• El precio, el tipo de cambio, la comisión y los límites los determina y comprueba el servidor, no el cliente.
• La MFA está activada en todos los accesos externos y los administradores tienen llaves FIDO2 o passkeys.
• Todos los dominios tienen SPF, DKIM y DMARC, y la política de DMARC avanza hacia quarantine o reject.
• Hay una lista de todo lo que se ve desde internet y las versiones están comparadas con el catálogo CISA KEV.
• Hay menos de cinco administradores globales y se han eliminado los permisos de sobra y las cuentas antiguas.

Descargar la lista de preparación (PDF)PDF · A4

Cómo hacemos estas revisiones se describe en la página cómo hace Veiltrack un pentest; allí también puedes descargar un informe de demostración sobre una aplicación ficticia.

Autor: Vlad Kraevsky, fundador de Veiltrack. En ciberseguridad desde 2019, más de seis años de experiencia en pentesting, experiencia dirigiendo un equipo de pentesters.

FAQ

¿De dónde salen las historias y por qué no tienen nombres?

Son casos anonimizados de la práctica de nuestros especialistas, sin nombres, fechas ni detalles que permitan reconocer a una empresa.

¿Se pueden considerar el 64% y el 36% estadísticas de phishing en Ucrania?

No. Son los resultados de una sola simulación de entrenamiento en un gran banco, y ambos porcentajes se calculan sobre todos sus empleados. Es una simulación, no una estadística de Ucrania. Una estadística representativa requiere muchas organizaciones y una metodología única, por eso para el contexto internacional citamos aparte estudios públicos: Verizon DBIR 2026, OWASP, NCSC, CERT-UA.

¿Qué punto débil cerrar primero?

El que lleva al dinero o a grandes volúmenes de datos: la lógica de negocio de los pagos, el acceso a objetos ajenos en la API y las cuentas de administrador sin MFA resistente al phishing. Después, el correo y los servicios olvidados.

¿Basta con enseñar a los empleados a no hacer clic en enlaces?

No. En la simulación de phishing de este artículo, el 64% de todos los empleados hizo clic en el enlace y el 36% introdujo su usuario y contraseña. La formación hace falta, pero conviene combinarla con protección técnica: NCSC recomienda preferir FIDO2 a la MFA con códigos. ^[5]

¿Puedo usar este material en publicaciones?

Sí, con un enlace a esta página y la atribución «Fuente: práctica de nuestros especialistas, descrita por Vlad Kraevsky, fundador de Veiltrack». No conviene presentar estos casos como «investigación de Veiltrack» ni como «estadística de los bancos ucranianos». Las cifras de estudios de terceros es mejor citarlas por las fuentes primarias de la lista de abajo.

Referencias

1. Verizon: 2026 Data Breach Investigations Report news release (19 May 2026) verizon.com
2. Verizon: 2026 Data Breach Investigations Report (full report) verizon.com
3. OWASP Top 10 API Security Risks 2023 api-security.owasp.org
4. OWASP Web Security Testing Guide: Introduction to Business Logic github.com
5. NCSC: Multi-factor authentication for your corporate online services. Recommended types of MFA ncsc.gov.uk
6. CERT-UA: Updated UAC-0057 toolset: OYSTERFRESH, OYSTERSHUCK and OYSTERBLUES (21.05.2026) cert.gov.ua
7. NCSC: Email security and anti-spoofing ncsc.gov.uk
8. RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) rfc-editor.org
9. Google Workspace Admin Help: Email sender guidelines support.google.com
10. Microsoft Learn: Best practices for Microsoft Entra roles learn.microsoft.com
11. CISA: Known Exploited Vulnerabilities catalog data github.com