Robo de credenciales: cómo pueden extraer datos de tu empresa sin hackear tus servidores

Cuando una empresa piensa en una filtración de datos, normalmente imagina primero una vulnerabilidad técnica: un servidor mal configurado, una aplicación desactualizada o un atacante tratando de romper las defensas desde Internet. Ese tipo de incidentes sigue existiendo, pero hay otra situación mucho más difícil de detectar porque, desde el punto de vista del sistema, puede comenzar como una sesión perfectamente normal.

Un atacante consigue el usuario y la contraseña de una persona autorizada. Ingresa por el mismo formulario que utiliza todos los días el trabajador, accede a las mismas plataformas y comienza a consultar información utilizando permisos que el sistema considera legítimos. No necesitó vulnerar el servidor. No necesitó descubrir una falla nueva. Simplemente consiguió una identidad digital que ya tenía acceso.

Este escenario dejó de ser hipotético en Chile. En mayo de 2026, la Agencia Nacional de Ciberseguridad informó que, al investigar publicaciones de información personal, no había encontrado evidencia de ataques contra la infraestructura tecnológica en ciertos casos, pero sí accesos no autorizados realizados mediante credenciales válidas de usuarios, probablemente comprometidas anteriormente en filtraciones o mediante malware del tipo infostealer.

El caso permite entender un cambio importante en la seguridad empresarial: proteger el perímetro ya no es suficiente si una cuenta legítima puede abrir demasiado fácilmente el acceso a información sensible.

Este problema es una de las amenazas que comenzamos a desarrollar en nuestro artículo sobre cómo proteger los datos de una empresa ante ataques potenciados por inteligencia artificial. En esta ocasión nos concentraremos exclusivamente en la identidad: qué ocurre cuando las credenciales correctas terminan en las manos equivocadas.

Una contraseña puede haber sido robada mucho antes del ataque

Una de las dificultades del robo de credenciales es que el momento en que se obtiene una contraseña y el momento en que finalmente se utiliza pueden estar separados por bastante tiempo.

Las credenciales pueden provenir de una filtración anterior de otro servicio, una campaña de phishing, reutilización de contraseñas o malware instalado en el computador del usuario. Los llamados infostealers, por ejemplo, están diseñados para extraer información almacenada en un dispositivo, incluyendo credenciales, cookies de sesión y otros antecedentes que posteriormente pueden reutilizarse o comercializarse.

La propia ANCI explica en su servicio CiberLupa que este tipo de malware puede capturar credenciales desde computadores personales o compartidos, acumulando posteriormente grandes cantidades de información que puede terminar circulando en mercados ilícitos.

Esto introduce un problema difícil de observar para la empresa. Una contraseña puede haber quedado comprometida sin que exista ninguna señal visible dentro de sus propios sistemas. El incidente recién se manifiesta cuando otra persona intenta utilizarla.

Incluso una organización con una infraestructura correctamente configurada puede verse afectada si uno de sus usuarios utiliza la misma contraseña en varios servicios o trabaja desde un dispositivo comprometido.

Por eso el control de identidad debería considerar que una contraseña válida demuestra cada vez menos por sí sola.

El sistema puede creer que todo está funcionando correctamente

Imaginemos que una persona del área comercial tiene acceso al CRM de la empresa. Su cuenta puede consultar nombres, correos, teléfonos, historial de contactos y oportunidades comerciales. Si otra persona obtiene sus credenciales y accede desde Internet, el CRM podría interpretar inicialmente que simplemente se trata del usuario habitual.

La aplicación funciona.

La base de datos funciona.

El servidor funciona.

La autenticación incluso puede indicar que el usuario y la contraseña son correctos.

Y, sin embargo, la información está siendo consultada por alguien que nunca debió verla.

Ese es uno de los motivos por los que el concepto de “hackeo” puede quedarse corto para explicar algunos incidentes actuales. No siempre existe una barrera tecnológica que fue violentada. En ocasiones, el atacante consigue utilizar correctamente los mecanismos disponibles para una persona legítima.

La pregunta para la empresa deja entonces de ser únicamente “¿podrían entrar?” y pasa a ser también “¿qué podrían hacer si entraran con la cuenta de alguno de nuestros usuarios?”.

Una cuenta comprometida revela cuánto confía realmente el sistema

El impacto de una credencial robada depende en gran medida de los permisos asociados a esa cuenta.

Una persona que puede visualizar únicamente los registros necesarios para realizar su trabajo presenta un riesgo diferente a otra que puede descargar la totalidad de una base. Lo mismo ocurre con cuentas capaces de modificar permisos, crear usuarios, acceder a información histórica o exportar archivos sin restricciones.

Con el tiempo, es frecuente que los permisos se acumulen. Un trabajador cambia de área, pero conserva el acceso anterior. Una persona recibe privilegios administrativos para resolver una contingencia y nadie los retira. Un proveedor termina un proyecto, pero su usuario continúa activo. En otros casos varias personas utilizan la misma cuenta porque resulta más sencillo que administrar usuarios individuales.

Mientras no ocurra un incidente, estas situaciones parecen problemas menores de administración. Cuando una credencial termina comprometida, se convierten en parte del alcance de la filtración.

Por eso uno de los principios más útiles es el de mínimo privilegio: usuarios, proveedores, servicios y aplicaciones deberían acceder solamente a aquello que necesitan para desarrollar su función.

Esta revisión está directamente relacionada con el trabajo de inventario de datos personales. Saber qué datos tiene una empresa es el primer paso; el siguiente es entender qué sistemas los contienen y quién puede realmente consultarlos.

El segundo factor ayuda, pero tampoco todos los métodos son iguales

Una de las medidas más conocidas frente al robo de contraseñas es la autenticación multifactor o MFA. El principio es sencillo: conocer la contraseña no debería ser suficiente para acceder. La persona debe demostrar además que posee otro factor.

Implementarla sigue siendo una medida importante, especialmente en cuentas administrativas, correo electrónico, infraestructura cloud, CRM y sistemas que contienen información sensible. NIST recomienda utilizar MFA y advierte expresamente que las contraseñas por sí solas no son resistentes al phishing.

Sin embargo, existe una diferencia importante entre tener cualquier segundo factor y utilizar un mecanismo diseñado para resistir phishing.

Un código enviado por SMS o generado por una aplicación mejora considerablemente una cuenta protegida solamente con contraseña, pero todavía puede ser entregado accidentalmente a un atacante. Lo mismo puede ocurrir con algunas notificaciones de aprobación si la víctima es engañada para autorizarlas.

NIST señala que mecanismos donde el usuario introduce manualmente códigos de un solo uso no se consideran resistentes al phishing. Tecnologías criptográficas como FIDO/WebAuthn y las passkeys pueden ofrecer una protección superior porque vinculan la autenticación al servicio real con el que la persona está interactuando.

Esto no significa que una empresa deba reemplazar mañana todos sus métodos de acceso. Sí significa que debería diferenciar cuentas comunes de cuentas críticas y aplicar controles proporcionales al riesgo.

La cuenta que administra una plataforma completa merece un estándar diferente a una cuenta utilizada exclusivamente para consultar información pública.

Proteger una cuenta no resuelve el problema si los datos están demasiado expuestos

Hay otro punto que suele perderse cuando toda la conversación se concentra en contraseñas y autenticación.

Supongamos que la empresa mejora sus controles, activa MFA y establece contraseñas más robustas. El riesgo disminuye, pero continúa existiendo una pregunta más profunda: ¿qué información queda disponible una vez que el acceso ha sido autorizado?

Si el CRM contiene diez años de contactos, si cualquier ejecutivo puede exportarlos o si una plataforma secundaria conserva una copia completa de la base original, una sola cuenta comprometida todavía puede generar un impacto considerable.

La seguridad de la identidad y la arquitectura de los datos deberían analizarse juntas.

Esto es especialmente importante porque los datos personales rara vez permanecen en un único sistema. Como revisamos en dónde viven realmente los datos personales en una empresa, la información suele desplazarse desde un formulario hacia CRM, planillas, herramientas de marketing, automatizaciones y servicios de terceros.

Una credencial robada de cualquiera de esas plataformas puede abrir una nueva ruta hacia los mismos datos.

Por eso proteger una empresa no significa solamente proteger “la base principal”. Significa comprender todo el recorrido.

Detectar comportamientos extraños puede ser tan importante como autenticar

Si un atacante utiliza credenciales válidas, parte de la defensa debe producirse después del inicio de sesión.

Una persona que normalmente trabaja desde Chile y de pronto accede desde otra ubicación, una cuenta que nunca descarga archivos y comienza a realizar exportaciones masivas o un usuario que consulta cientos de registros durante la madrugada pueden generar señales interesantes.

No toda anomalía representa un ataque. Los trabajadores viajan, cambian horarios y algunas actividades excepcionales son legítimas. El objetivo del monitoreo no debería ser bloquear automáticamente cualquier comportamiento diferente, sino disponer de suficiente información para identificar cuándo una actividad necesita revisión.

Esto requiere registros.

Si una plataforma no conserva información sobre accesos, acciones relevantes, modificaciones o exportaciones, investigar posteriormente un incidente se vuelve mucho más difícil. La empresa puede saber que una cuenta fue comprometida y, aun así, no poder determinar qué información estuvo disponible.

Este punto conecta directamente con el Registro de Actividades de Tratamiento o RAT. El RAT no reemplaza los logs técnicos, pero obliga a entender qué tratamientos existen, qué sistemas intervienen, qué proveedores participan y qué medidas deberían acompañarlos.

La documentación y la evidencia técnica deben conversar.

Dar de baja accesos debería formar parte del proceso de salida

Uno de los riesgos más fáciles de reducir es también uno de los más olvidados.

Cuando un trabajador cambia de área o deja la empresa, cuando termina un contrato con un proveedor o cuando una plataforma deja de utilizarse, los accesos deberían revisarse como parte del cierre del proceso.

No basta con eliminar una cuenta del correo corporativo si la misma persona conserva acceso independiente al CRM, almacenamiento cloud, panel de hosting, herramientas de automatización o servicios contratados directamente.

Las empresas que han crecido incorporando distintas aplicaciones en diferentes momentos suelen descubrir que no existe un único lugar desde donde administrar todos estos permisos.

La solución no pasa necesariamente por comprar otra plataforma. Primero conviene identificar qué sistemas existen, quién administra cada uno y qué usuarios continúan activos.

Esta es también una de las señales que abordamos en ¿Tu empresa está en riesgo frente a la Ley 21.719?. Una organización que no puede explicar con claridad quién accede a los datos difícilmente puede demostrar que mantiene un control adecuado sobre ellos.

El robo de credenciales también cambia cómo debemos pensar la Ley 21.719

El problema deja de ser exclusivamente de ciberseguridad cuando la cuenta comprometida permite acceder a datos personales.

La Ley 21.719 establece que los responsables deben adoptar medidas adecuadas para asegurar confidencialidad, integridad, disponibilidad y resiliencia de los sistemas de tratamiento, además de evitar accesos no autorizados. También exige considerar el riesgo y poder acreditar la existencia y funcionamiento de las medidas adoptadas.

Esto tiene una consecuencia práctica importante.

Ante un incidente, no bastará con explicar que alguien consiguió una contraseña.

La organización tendrá que entender qué cuenta fue comprometida, qué permisos tenía, qué información podía consultar, qué registros existen, qué medidas estaban activas y qué acciones se realizaron después de detectar el problema.

Por eso preparar a una empresa para la nueva regulación no consiste solamente en actualizar políticas de privacidad. Como desarrollamos en cómo demostrar cumplimiento de la Ley 21.719 sin quedarse solo en documentos, el cumplimiento necesita evidencias que provienen de sistemas y procesos reales.

El checklist de la Ley 21.719 para empresas también incorpora seguridad, bitácoras y respuesta a incidentes dentro de las prioridades tecnológicas que conviene revisar.

Qué debería revisar una empresa antes de que aparezca una credencial comprometida

El objetivo no debería ser construir una organización donde resulte imposible robar una contraseña. Esa promesa sería poco realista.

La estrategia más robusta consiste en aceptar que eventualmente alguna credencial puede verse comprometida y diseñar controles que reduzcan tanto la probabilidad como el impacto.

Esto implica revisar cómo se autentican los usuarios, pero también quién conserva acceso, qué cuentas tienen privilegios elevados, qué plataformas contienen datos relevantes, cuánto puede exportarse desde cada una y qué registros permiten reconstruir posteriormente una actividad.

También conviene diferenciar los sistemas según su criticidad. No todos necesitan exactamente el mismo nivel de control. Una herramienta interna con información poco sensible puede justificar medidas diferentes a un CRM con miles de clientes o a una plataforma donde se administran datos personales especialmente protegidos.

La privacidad desde el diseño en sitios, aplicaciones y CRM apunta justamente a incorporar estas decisiones antes de que una plataforma llegue a producción o acumule años de información.

También pueden existir decisiones arquitectónicas que reduzcan la cantidad de datos directamente expuestos. La tokenización de datos personales, por ejemplo, permite analizar escenarios donde determinadas aplicaciones trabajan con referencias en lugar de acceder constantemente al dato identificable original.

No todas las empresas necesitarán estas medidas. Lo importante es evaluar el riesgo de forma proporcional a la información y a la operación.

Una cuenta válida no debería transformarse en acceso ilimitado

El robo de credenciales demuestra una debilidad conceptual importante: durante mucho tiempo asumimos que autenticar correctamente a una persona era suficiente para confiar en sus acciones posteriores.

Ese supuesto es cada vez menos sostenible.

Una contraseña puede filtrarse. Un dispositivo puede infectarse. Una sesión puede ser robada. Una persona puede ser engañada para aprobar un segundo factor. Y una cuenta olvidada puede continuar funcionando meses después de que dejó de ser necesaria.

Por eso una estrategia moderna de protección debería combinar identidad, permisos, monitoreo y arquitectura de datos.

La autenticación responde quién intenta entrar. Los permisos determinan qué puede hacer. Los registros permiten entender qué hizo. Y la forma en que almacenamos los datos define cuánto puede quedar expuesto si todas las capas anteriores fallan.

Para una empresa, esa última pregunta es probablemente la más importante.

Si mañana se compromete la cuenta de uno de nuestros trabajadores, ¿sabemos exactamente qué información quedaría a su alcance?

Si la respuesta requiere revisar varios sistemas, preguntar a diferentes proveedores o depender de la memoria de las personas, el problema no comienza cuando alguien roba la contraseña. Comienza bastante antes.

En Datactil trabajamos estos desafíos desde la revisión de sistemas, integraciones, permisos, infraestructura y circulación de información. Una evaluación de proyecto puede servir para identificar qué plataformas concentran los principales riesgos y qué controles tiene sentido priorizar sin sobredimensionar la solución.

Preguntas frecuentes

¿Qué es el robo de credenciales?

Es la obtención no autorizada de datos que permiten acceder a una cuenta, como usuario y contraseña. Pueden obtenerse mediante phishing, filtraciones anteriores, reutilización de contraseñas o malware especializado, entre otros mecanismos.

¿Qué es un infostealer?

Es un tipo de malware orientado a extraer información desde un dispositivo comprometido. Dependiendo del caso, puede capturar credenciales, cookies de sesión y otra información almacenada que posteriormente puede ser utilizada para acceder a servicios.

¿Cambiar la contraseña es suficiente después de una filtración?

Es una medida necesaria cuando existe evidencia de compromiso, pero puede no ser suficiente. También conviene revisar sesiones activas, dispositivos, segundo factor de autenticación, accesos recientes y otros servicios donde la misma contraseña pudiera haberse utilizado.

¿MFA evita completamente el robo de cuentas?

No. Reduce considerablemente el riesgo, pero algunos mecanismos pueden ser vulnerables a phishing. Para cuentas especialmente críticas conviene evaluar métodos de autenticación resistentes al phishing, como tecnologías basadas en FIDO/WebAuthn o passkeys.

¿Qué relación existe entre credenciales comprometidas y la Ley 21.719?

Si una cuenta comprometida permite acceder sin autorización a datos personales, el incidente se relaciona directamente con las obligaciones de seguridad y protección de esos datos. Por eso es importante poder determinar qué información estaba disponible y qué medidas existían para reducir el riesgo.