• Servicios
    • Servicio de Reporte SOC
    • Managed services
    • Asesoría de TI
      • Asesoría en Vulnerabilidad TI
      • Pruebas de Penetración
      • Gestión de Acceso Privilegiado
      • Ingeniería Social
      • SHIELD: Para Pequeñas y Medianas Empresas
    • Servicios Financieros Auditoría
      • Servicio PCI DSS
    • Cumplimiento TI Con Gobierno
  • Industrias
    • Servicios Financieros
    • Concesionarias
    • Empresas
  • Acerca de Nosotros
    • Conozca al equipo
    • Trabaja con Nosotros
    • Aviso de Privacidad
  • Blog
  • Contacto
  • Learning

Llámanos hoy: +52 56 4001 5585

Encuéntranos
ecalvillo@ocd-tech.com.mx
OCD Tech MéxicoOCD Tech México
  • Servicios
    • Servicio de Reporte SOC
    • Managed services
    • Asesoría de TI
      • Asesoría en Vulnerabilidad TI
      • Pruebas de Penetración
      • Gestión de Acceso Privilegiado
      • Ingeniería Social
      • SHIELD: Para Pequeñas y Medianas Empresas
    • Servicios Financieros Auditoría
      • Servicio PCI DSS
    • Cumplimiento TI Con Gobierno
  • Industrias
    • Servicios Financieros
    • Concesionarias
    • Empresas
  • Acerca de Nosotros
    • Conozca al equipo
    • Trabaja con Nosotros
    • Aviso de Privacidad
  • Blog
  • Contacto
  • Learning

Nadie tuvo que forzar la entrada: cómo entramos en la mayoría de los pentests

Inicio » Blog OCD Tech » Nadie tuvo que forzar la entrada: cómo entramos en la mayoría de los pentests

Nadie tuvo que forzar la entrada: cómo entramos en la mayoría de los pentests

Cada vez que iniciamos un pentest, hay una expectativa implícita del lado del cliente: que vamos a encontrar una falla técnica exótica, un servidor sin parchar, alguna vulnerabilidad con nombre propio y número de CVE. Que el informe va a hablar de código y de exploits.

La realidad suele ser más incómoda. En la mayoría de los ejercicios que hacemos, el primer acceso no viene de explotar nada. Viene de credenciales que alguien reutilizó, de una cuenta que nadie dio de baja, de un entorno de prueba que quedó publicado con información real. No forzamos la puerta. Nos dejaron pasar.

Queremos hablar de eso, porque es el tipo de hallazgo que rara vez aparece en los titulares de ciberseguridad y que, sin embargo, explica una buena parte de los incidentes que vemos en empresas medianas y pequeñas en México.

Credenciales que abren más de una puerta

El patrón es este: la misma contraseña que usa una persona para su correo corporativo también abre el panel administrativo de un sistema interno. A veces también su cuenta en una herramienta de terceros. A veces también algo personal.

No hace falta adivinarla. Las contraseñas de millones de cuentas circulan en filtraciones públicas desde hace años, y probarlas contra otros servicios es un procedimiento rutinario para cualquier atacante. Cuando existe un segundo factor de autenticación, ese intento se detiene ahí. Cuando no existe, la contraseña filtrada de hace tres años sigue siendo una llave vigente.

Lo que encontramos en campo no es gente descuidada. Es gente que administra ocho o diez accesos distintos sin un gestor de contraseñas y que resuelve el problema de la única forma humanamente sostenible: repitiendo. El descuido no está en la persona, está en no haberle dado una alternativa y en no haber puesto un segundo factor donde más importa.

Cuentas que siguen vivas después de la salida

Una persona renuncia. Se le retira el equipo, se le hace la entrevista de salida, se firma el finiquito. Y su usuario sigue activo tres meses después, con los mismos permisos que tenía el último día.

Esto pasa porque la baja de accesos casi nunca tiene un dueño claro. Recursos Humanos sabe que la persona salió. Sistemas sabe cómo desactivar la cuenta. Pero si nadie definió quién avisa a quién y en qué plazo, el paso simplemente no ocurre. Y se multiplica: un correo, un CRM, un repositorio, una VPN, un acceso a la nube, cada uno administrado por alguien distinto.

Estas cuentas son especialmente valiosas para un atacante porque nadie las está mirando. Su dueño ya no las usa, así que ninguna actividad sospechosa le va a parecer rara a nadie. Un inicio de sesión a las tres de la mañana desde otro país no genera una sola pregunta, porque no hay quien la haga.

Preproducción con datos reales

Los entornos de prueba existen por una buena razón: nadie quiere experimentar sobre el sistema del que dependen las operaciones. El problema empieza cuando ese entorno se llena con una copia de la base de datos productiva, porque es la manera más rápida de probar con información que se parece a la verdadera.

Y entonces ese ambiente, que casi nunca tiene el mismo nivel de protección, contiene exactamente los mismos datos de clientes que el sistema que sí protegemos. Con frecuencia está publicado en internet para que el proveedor externo pueda trabajar, con credenciales genéricas, sin monitoreo, sin respaldo de bitácoras.

Desde la perspectiva regulatoria esto importa mucho más de lo que parece. Una copia de datos personales en un ambiente de prueba sigue siendo un tratamiento de datos personales, con las obligaciones que eso implica bajo la normativa mexicana. Un incidente ahí es un incidente, sin descuento por tratarse de un ambiente que internamente llamamos secundario.

Cada vez que iniciamos un pentest, hay una expectativa implícita del lado del cliente: que vamos a encontrar una falla técnica exótica, un servidor sin parchar, alguna vulnerabilidad con nombre propio y número de CVE. Que el informe va a hablar de código y de exploits.

La realidad suele ser más incómoda. En la mayoría de los ejercicios que hacemos, el primer acceso no viene de explotar nada. Viene de credenciales que alguien reutilizó, de una cuenta que nadie dio de baja, de un entorno de prueba que quedó publicado con información real. No forzamos la puerta. Nos dejaron pasar.

Queremos hablar de eso, porque es el tipo de hallazgo que rara vez aparece en los titulares de ciberseguridad y que, sin embargo, explica una buena parte de los incidentes que vemos en empresas medianas y pequeñas en México.

Credenciales que abren más de una puerta

El patrón es este: la misma contraseña que usa una persona para su correo corporativo también abre el panel administrativo de un sistema interno. A veces también su cuenta en una herramienta de terceros. A veces también algo personal.

No hace falta adivinarla. Las contraseñas de millones de cuentas circulan en filtraciones públicas desde hace años, y probarlas contra otros servicios es un procedimiento rutinario para cualquier atacante. Cuando existe un segundo factor de autenticación, ese intento se detiene ahí. Cuando no existe, la contraseña filtrada de hace tres años sigue siendo una llave vigente.

Lo que encontramos en campo no es gente descuidada. Es gente que administra ocho o diez accesos distintos sin un gestor de contraseñas y que resuelve el problema de la única forma humanamente sostenible: repitiendo. El descuido no está en la persona, está en no haberle dado una alternativa y en no haber puesto un segundo factor donde más importa.

Cuentas que siguen vivas después de la salida

Una persona renuncia. Se le retira el equipo, se le hace la entrevista de salida, se firma el finiquito. Y su usuario sigue activo tres meses después, con los mismos permisos que tenía el último día.

Esto pasa porque la baja de accesos casi nunca tiene un dueño claro. Recursos Humanos sabe que la persona salió. Sistemas sabe cómo desactivar la cuenta. Pero si nadie definió quién avisa a quién y en qué plazo, el paso simplemente no ocurre. Y se multiplica: un correo, un CRM, un repositorio, una VPN, un acceso a la nube, cada uno administrado por alguien distinto.

Estas cuentas son especialmente valiosas para un atacante porque nadie las está mirando. Su dueño ya no las usa, así que ninguna actividad sospechosa le va a parecer rara a nadie. Un inicio de sesión a las tres de la mañana desde otro país no genera una sola pregunta, porque no hay quien la haga.

Preproducción con datos reales

Los entornos de prueba existen por una buena razón: nadie quiere experimentar sobre el sistema del que dependen las operaciones. El problema empieza cuando ese entorno se llena con una copia de la base de datos productiva, porque es la manera más rápida de probar con información que se parece a la verdadera.

Y entonces ese ambiente, que casi nunca tiene el mismo nivel de protección, contiene exactamente los mismos datos de clientes que el sistema que sí protegemos. Con frecuencia está publicado en internet para que el proveedor externo pueda trabajar, con credenciales genéricas, sin monitoreo, sin respaldo de bitácoras.

Desde la perspectiva regulatoria esto importa mucho más de lo que parece. Una copia de datos personales en un ambiente de prueba sigue siendo un tratamiento de datos personales, con las obligaciones que eso implica bajo la normativa mexicana. Un incidente ahí es un incidente, sin descuento por tratarse de un ambiente que internamente llamamos secundario.

Por qué esto no es un problema de presupuesto

Es tentador leer todo lo anterior y concluir que hace falta invertir en tecnología. En algunos casos sí, un gestor de contraseñas y una solución de autenticación multifactor tienen costo. Pero la mayor parte de lo que describimos no se arregla comprando nada.

Se arregla decidiendo quién es responsable de qué. Quién autoriza un acceso nuevo. Quién lo revoca cuando alguien sale. Cada cuánto alguien se sienta a revisar la lista completa de usuarios activos y pregunta, uno por uno, si esa persona todavía necesita ese permiso.

Ese ejercicio, hecho una vez al trimestre, cierra más puertas que buena parte del software de seguridad que se vende en el mercado.

Por dónde empezar esta semana

Si dirige una empresa y quiere saber dónde está parado, hay tres cosas que puede pedir hoy y que deberían poder responderse en pocos días.

La lista completa de usuarios activos en cada sistema, contrastada contra la nómina vigente. Toda cuenta que no corresponda a una persona actualmente contratada es un hallazgo.

El inventario de accesos administrativos, con nombre y apellido de quién los tiene y por qué. Si la respuesta a por qué es “siempre los ha tenido”, eso también es un hallazgo.

La confirmación de qué ambientes no productivos existen, si están accesibles desde internet y con qué datos están cargados.

Ninguna de estas tres preguntas requiere conocimiento técnico para formularse. Las tres suelen incomodar, y esa incomodidad es justamente la señal de que valía la pena preguntarlas.

Lo que un atacante necesita realmente

Nos gusta imaginar al atacante como alguien sofisticado, con capacidades fuera de nuestro alcance. A veces lo es. Pero en la enorme mayoría de los casos que vemos, no necesitó serlo.

Necesitó que nadie estuviera revisando quién tiene acceso a qué. Eso es todo.

En OCD Tech México acompañamos a empresas mexicanas a responder esas preguntas antes de que las responda alguien más. Si quiere saber qué encontraríamos en su organización, conversemos.

Leave a Reply

Your email is safe with us.
Cancel Reply

Contáctenos

Si tiene alguna duda sobre nuestros servicios, escribanos y nos comunicaremos a la brevedad.

Enviar mensaje

Auditoría de TI – Consultoría en Ciberseguridad – Aseguranza

OCD Tech, con sede en Boston, ha sido un referente en la región noreste de EE.UU. Con más de 12 años de operación, hemos consolidado nuestra experiencia en ciberseguridad.

En 2022, tras un crecimiento excepcional en Auditoría y Seguridad de TI, nos convertimos en una entidad independiente y expandimos nuestro alcance con la creación de OCD Tech México, fortaleciendo nuestra presencia internacional en ciberseguridad.

Información de Contacto

  • OCD Tech México
  • Av. San Jerónimo 1256, San Jerónimo Lídice, La Magdalena Contreras, 10200 Ciudad de México, CDMX
  • +52 56 4001 5585
  • lmendoza@ocd-tech.com.mx
  • ecalvillo@ocd-tech.com.mx

ocd-tech.com.mx

Síguenos

Certificaciones de nuestro Equipo

  • Certified Information Systems Security Professional (CISSP)
  • Certified Information Systems Auditor (CISA)
  • Offensive Security Wireless Professional (OSCP)
  • System Security Certified Practitioner (SSCP)
  • CSX Cybersecurity Practitioner
  • CyberArk Trustee / CyberArk Defender
  • Symantec Certified Security Awareness Advocate
  • Qualys Certified Vulnerability Management Specialist
  • Project Management Professional (PMP)
  • GIAC Penetration Tester (GPEN)
  • CompTIA Security+
  • CompTIA Network+
  • Certified in Risk and Information Systems Control (CRISC)
  • Jamf Certified Associate
  • Microsoft Technology Associate – Security
  • AWS Certified Cloud Practitioner
  • Apple Certified Associate
  • Sumo Logic Certified
  • Splunk Core Certified User
  • JumpCloud Core Certification

© 2026 — Highend WordPress Theme. Theme by HB-Themes.

  • Aviso de Privacidad