Tu empresa recibe una alerta de credenciales expuestas: cómo investigarla

Qué comprobar de un anuncio de venta, qué registros revisar, qué pedir al proveedor de inteligencia de amenazas y cuándo cerrar el caso.

Portátil con una alerta de correo expuesto en una filtración, junto a un shiba y una taza de café.

El proveedor que os vigila las filtraciones manda una alerta: persona@empresa.example, con una contraseña y la URL del portal corporativo, marcada como «reciente». Alguien tiene que decidir si es un incidente, una filtración antigua que vuelve a circular o algo intermedio, y casi nunca tiene todos los datos para hacerlo. Por «proveedor» me refiero al servicio que te manda estas alertas: a veces viene incluido en el antivirus, otras en el paquete de tu proveedor informático, y otras se contrata aparte.

Qué significa cada tipo de alerta y cómo leer sus fechas lo contamos en Tu correo aparece en la dark web. Aquí va lo que yo haría después, ya dentro de la empresa.

Qué podemos comprobar de un anuncio de venta

A veces la alerta trae la captura de un anuncio y una muestra de los datos. El vendedor puede presumir de tener la base de datos completa o acceso de administrador, pero la muestra solo permite comprobar una parte: ni el volumen ni que el acceso siga funcionando. Y a veces mezcla datos reales con filtraciones antiguas, o se los atribuye a la empresa equivocada.

Al documentarlo, conviene ser concretos:

La muestra contiene correos de la organización. El vendedor afirma disponer de acceso activo, pero todavía no hemos podido confirmarlo.

Qué revisar dentro de la empresa

Empezaría por comprobar si la cuenta existe, si está activa y a qué tiene acceso. También si pertenece a una persona o se utiliza para administrar sistemas o ejecutar servicios.

Después revisaría la actividad relacionada con el caso: inicios de sesión, dispositivos, cambios en los métodos de autenticación, reglas de reenvío del correo y accesos a documentos.

Estos registros necesitan contexto. Una IP desconocida podría pertenecer a una VPN y una ubicación extraña podría ser un error de geolocalización. Y un inicio de sesión aceptado solo dice que alguien usó credenciales válidas, no quién.

Otra limitación: cuánto puedes revisar. Si solo se guardan siete días de registros, no se puede descartar un acceso de hace meses, y eso hay que decirlo en las conclusiones.

Para validar la alerta, sigue los procedimientos autorizados de tu organización. No pruebes a iniciar sesión con la contraseña filtrada ni pidas al usuario que envíe su contraseña actual por correo o por un ticket.

Volvamos a la alerta del principio

Al pedirle más información al proveedor, resulta que acaba de incorporar el registro a su plataforma, pero no sabe cuándo se obtuvieron los datos.

La cuenta sigue activa. Su propietario nos cuenta que a veces accede desde su ordenador personal. Ese equipo es una posibilidad que investigar, aunque todavía no podemos atribuirle el origen de la exposición.

Mientras se revisa el caso, el equipo protege los accesos afectados y comprueba la actividad disponible. En el registro de la investigación deja anotado:

  • Lo confirmado: hay un registro que relaciona la cuenta con el servicio.
  • Lo pendiente: cuándo se obtuvieron los datos, de qué equipo proceden y si alguien los ha utilizado.
  • Las medidas tomadas: qué accesos se han protegido, qué falta por revisar y quién se ocupa de ello.

No hace falta saberlo todo para empezar a proteger cuentas. Lo que no vale es escribir «el equipo del usuario estaba infectado» cuando solo es una hipótesis.

Qué información pedir al proveedor

Pídele al proveedor de dónde sale la alerta, qué fechas tiene, qué tipo de datos incluye y por qué la relaciona con tu empresa. Y si es la primera vez que lo ve o es una exposición que ya os había notificado.

Si asigna un nivel de confianza, debería explicar en qué se basa. Que haya comprobado una muestra vale mucho más que «el vendedor tiene buena reputación en el foro».

Al compartir la evidencia dentro de la empresa, limita el acceso a quien lo necesite. Si contiene contraseñas o datos personales, evita copiarlos completos en correos o tickets de acceso amplio.

Cuándo dar por cerrada la investigación

Antes de cerrar el caso, debería quedar documentado qué se ha expuesto, qué cuentas o equipos estaban afectados, qué medidas se han tomado y qué actividad se ha podido revisar.

Hay casos que se cierran rápido, porque los datos eran antiguos y esas contraseñas ya no se usan. Otros acaban en un equipo comprometido. Y algunos se cierran sin saber de dónde salió la información ni si alguien la usó. También es un resultado válido, siempre que quede anotado qué no se pudo revisar y por qué.

¿Hablamos de este artículo?

Comparte una duda o algo que te haya servido. Revisamos los comentarios antes de publicarlos.

Cargando comentarios…

No uses nombres del equipo. Los alias de los lectores no están verificados.Entre 10 y 2.000 caracteres. Sin datos personales, contraseñas ni información confidencial.

Si prefieres preguntar en privado, escríbenos aquí.