Detectando ataques basados en credenciales en Databricks

En Databricks, sabemos que tus datos son tu activo más valioso. Databricks ha trabajado con miles de clientes para desplegar de forma segura la Databricks Data + AI Platform con las características adecuadas para cumplir con sus requisitos de seguridad, privacidad y normativos.

El ciberataque moderno no siempre comienza con un perímetro roto; comienza con un inicio de sesión válido. Una vez que un atacante adquiere una cookie de sesión filtrada, un token de acceso personal (PAT) o una credencial de entidad de servicio, la brecha inicial ya está completa. A partir de ese momento, todo su objetivo es mezclarse y operar bajo la apariencia de tu usuario o servicio comprometido.

Pero tener una llave no significa que conozcas el edificio. Imagina a un intruso pasando una tarjeta para entrar a una oficina segura. Es posible que haya pasado por las puertas giratorias, pero aún tiene que lidiar con el guardia de seguridad, adivinar a qué pisos tiene acceso y averiguar dónde está la bóveda. Como un atacante carece del contexto profundo y localizado de tus empleados reales, su comportamiento eventualmente lo delatará. Detectar esas irregularidades es la forma de atraparlo.

En esta publicación, analizamos cómo se desarrolla un ataque basado en credenciales en la plataforma Databricks, cómo detectar el cambio en el comportamiento de una identidad utilizando los registros de auditoría detallados de Databricks y Genie, cómo responder una vez que confirmas una vulneración y qué controles limitan lo que una credencial robada puede hacer en primer lugar.

Un modelo para seguir ataques basados en credenciales

Al establecer el acceso a través de credenciales legítimas, los atacantes, al igual que los profesionales de la seguridad, también entienden que su acceso puede ser revocado en cualquier momento si se desvían demasiado del comportamiento esperado de la identidad. Los atacantes confían en la secuenciación de ataques no lineales, como validar un conjunto de credenciales para mapear tu entorno, y luego recuperar otro conjunto de credenciales para regresar a través de una nueva identidad o espacio de trabajo que no tenga actividad de reconocimiento asociada. Además, los atacantes pueden recopilar información sin establecer persistencia o asegurar su camino de regreso a tu plataforma Databricks antes de concluir sus objetivos.

Cómo se ve esto en la práctica

Considera a un ingeniero de datos cuyo token de acceso personal es copiado de un registro de integración y entrega continua (CI/CD) mal configurado. En cuestión de minutos, el token se utiliza desde una nueva IP para listar ámbitos de secretos, catálogos y repositorios en todo el espacio de trabajo, algo que este ingeniero nunca ha hecho. Se lee un secreto que contiene una credencial de entidad de servicio. Una hora después, esa entidad de servicio, no el ingeniero, crea una función, se añade a un grupo de administración y exporta un puñado de scripts de inicio. Cada uno de estos eventos podría pasar como uso rutinario de la plataforma, pero en conjunto muestran a una intrusión moviéndose a través de la cadena de ataques.

En Databricks, esperamos una secuenciación de eventos no lineal en relación con los ataques basados en credenciales y utilizamos este modelo para conectar eventos individuales en una sola investigación en lugar de tratarlos como eventos no relacionados.

Las seis etapas de un ataque basado en credenciales

Cuando los atacantes aprovechan credenciales comprometidas en un entorno de plataforma como servicio (PaaS), como Databricks, su actividad se puede agrupar en seis etapas, aunque rara vez se desplazan a través de ellas en línea recta. Cada etapa a continuación describe lo que el atacante intenta hacer y qué buscar en las tablas de registro de auditoría de Databricks. Trata esta guía como un punto de partida y ajústala a la automatización normal de tu entorno.

Nota: Los eventos se escriben como service_name.action_name, por ejemplo secrets.getSecret.

1. El atacante obtiene acceso con credenciales válidas

El inicio de sesión en sí rara vez parece inusual. Debido a que la credencial es real, la autenticación se realiza con éxito como lo haría para el propietario legítimo. Sin embargo, lo que hace la identidad en los minutos posteriores al inicio de sesión a menudo se ve muy diferente de su actividad normal, y ese cambio es lo que los equipos de respuesta pueden detectar. En el ejemplo del ingeniero de datos, el token robado se autentica con éxito y la única diferencia al iniciar sesión es una IP de origen que el ingeniero nunca ha utilizado. La actividad que sigue es lo que destaca.

Objetivo del atacante: Acceder al espacio de trabajo con credenciales válidas, ya sea una sesión de navegador robada, un PAT reproducido o una credencial de entidad de servicio, y mezclarse con la actividad que los controles están diseñados para permitir.

Qué buscar:

• Utiliza el evento de autenticación como punto de partida para tu cronología. Un inicio de sesión por sí solo rara vez es suficiente para generar una alerta, pero sus user_identity, source_ip_address, user_agent, sessionId, request_id y workspace_id te permiten seguir lo que hace la credencial a continuación.
• Marca los eventos de accounts.tokenLogin que llegan en una ráfaga corta desde un cliente desconocido y son seguidos por el uso del mismo token desde una IP de origen diferente. Este patrón puede indicar que alguien está probando un token robado, y requestParams.tokenId te permite vincular esos eventos al mismo token.
• Marca los tokens OAuth de entidades de servicio que se generan desde la red esperada con un agente de usuario inesperado, especialmente cuando la actividad desde una nueva IP de origen sigue dentro de un minuto.

2. El atacante mapea el entorno

A continuación, el atacante necesita saber a qué puede acceder la credencial antes de que se revoque el acceso. Como resultado, una identidad comprometida puede pasar de su actividad ordinaria a listar datos, secretos, código y controles de red en cuestión de segundos. Este reconocimiento generalmente abarca varios servicios a la vez y se mueve más rápido que una persona navegando por la interfaz de usuario. En nuestro escenario, esta etapa es la ráfaga de llamadas que listan ámbitos de secretos, catálogos y repositorios a los pocos minutos de usar el token, lo cual es una actividad que el ingeniero nunca ha realizado antes.

Objetivo del atacante: Construir un mapa de los datos accesibles, credenciales, repositorios y barreras de protección para planificar un camino más profundo en el entorno antes de que se revoque el acceso.

Qué buscar:

• Busca una sola identidad que realice llamadas rápidas de listado en los planos de espacio de trabajo y cuenta, como secrets.listScopes / listSecrets, unityCatalog.listMetastores / listCatalogs / listSchemas / listExternalLocations / listStorageCredentials, repos.listRepos y los niveles de cuenta accountsManager.listWorkspaceConfigurations / listNetworkConfigurations / listStorageConfigurations. Por ejemplo, es poco probable que cinco o más API de descubrimiento distintas llamadas en un minuto sean una persona navegando por la plataforma.
• Compara la actividad con la línea base de la identidad. La primera enumeración de secretos realizada por una identidad establecida, o una sesión de SQL que cambia de consultas de negocio a SHOW TABLES contra esquemas de control de acceso y configuración, es más significativa que un alto volumen de llamadas. Cuando el registro de auditoría detallado está habilitado, commandSubmit conserva la consulta en commandText.
• Incluye las solicitudes fallidas en tu búsqueda. Investiga la primera IpAccessDenied de una identidad, especialmente cuando sigue a accounts.oidcTokenAuthorization o se repite en todos los espacios de trabajo. En ese caso, la autorización tuvo éxito pero la solicitud provino de una red bloqueada, lo que suele ser el registro más temprano de una credencial que se está reproduciendo desde una ubicación no confiable.

3. El atacante recopila más credenciales

La recopilación de credenciales suele requerir varios pasos. El atacante lista los ámbitos de secretos, lista los secretos que contienen y luego lee los que parecen útiles. El valor que recuperan les permite regresar como una identidad diferente, a menudo con más privilegios. Por esta razón, vale la pena dar seguimiento a cada secreto leído por una identidad sospechosa. En el ejemplo del ingeniero de datos, el atacante lee un secreto que contiene una credencial de entidad de servicio. A partir de ese momento, la investigación tiene que seguir dos identidades: el ingeniero y la entidad de servicio.

Objetivo del atacante: Recuperar un token, una clave de API o un secreto de entidad de servicio que actualice el punto de apoyo inicial a un acceso en todo el entorno bajo una nueva identidad.

Qué buscar:

• Genera alertas sobre la progresión de las llamadas. secrets.listScopes por sí solo es común y genera ruido. Sin embargo, listScopes seguido de listSecrets y luego de getSecret, repetido en múltiples ámbitos en rápida sucesión, indica extracción de datos. listSecrets registra el ámbito, y getSecret registra tanto el ámbito como la clave.
• Correlaciona las lecturas denegadas con las posteriores exitosas. Una getSecret denegada en un ámbito estrictamente controlado, seguida de una lectura exitosa de la misma clave o una relacionada en un ámbito menos restringido, sugiere que la identidad está buscando una copia a la que pueda acceder.
• Monitorea el acceso del lado de la computación además de la API de secretos. Cuando el registro de auditoría detallado está habilitado, los eventos de los notebooks submitCommand y de Databricks SQL commandSubmit pueden mostrar código que llama a utilidades de secretos o ejecuta read_files() en rutas que contienen credenciales. Ten en cuenta que el texto enviado muestra lo que se ejecutó, pero no confirma que se haya devuelto un valor.
• Conecta cada lectura de secretos con lo que sucede a continuación, como una nueva accounts.tokenLogin, la primera actividad vista de una entidad de servicio, una IP o agente de usuario modificado, o llamadas a generateTemporaryTableCredential / generateTemporaryVolumeCredential. Durante la respuesta, rota cada credencial a la que la identidad podría haber accedido y verifica dónde se usó cada una, además de dónde se almacenó.

4. El adversario encuentra una ruta de ejecución viable

Una vez que se establece el acceso, los adversarios buscan una forma de ejecutar su propio código. En Databricks, esto suele ocurrir a través de funciones definidas por el usuario (UDF) y trabajos. Una función puede envolver una carga útil en un código de apariencia ordinaria que se puede llamar repetidamente, y un trabajo puede ejecutar ese código según una programación en diferentes recursos de cómputo. Por lo tanto, la pregunta clave para la detección es si una identidad ha comenzado a realizar acciones que no había realizado antes. Volviendo al ingeniero de datos, una hora después de que se lee el secreto, la entidad de servicio crea una función. Debido a que la entidad de servicio, en lugar del ingeniero, realiza esta acción, una búsqueda limitada únicamente a la actividad del ingeniero se la perdería.

Objetivo del adversario: Establecer una forma confiable y reutilizable de ejecutar cargas útiles, con una alternativa cuando se bloquea una ruta de cómputo.

Qué buscar:

• Prioriza los eventos createFunction de una identidad, IP o catálogo sin historial de creación de funciones, especialmente cuando aparecen varios en un período corto. Cuando las definiciones de funciones estén disponibles, marca el código que ejecuta procesos, evalúa código de forma dinámica, accede a metadatos de instancias, abre conexiones de red salientes o escribe en el almacenamiento en la nube. Realiza también un seguimiento de las referencias entre funciones, ya que un contenedor de apariencia inofensiva puede llamar a una UDF de mayor riesgo. Ten en cuenta que function_info en system.access.audit está enmascarado excepto para los administradores de cuentas y databricks_pii_access, así que combina los datos de auditoría con los inventarios de funciones.
• Rastrea la ruta de los trabajos por identidad, IP y ID de trabajo o ejecución. Una secuencia típica es importNotebook, luego changeJobAcl, Jobs create, runNow y getRunOutput. Estos eventos rara vez conservan el cuerpo del notebook, así que conserva las versiones del notebook y las configuraciones de los trabajos junto con ellos. La actividad repetida de importar y ejecutar desde una misma fuente es una señal más fuerte que cualquiera de las dos acciones por separado.
• Busca una identidad que cambie de recursos de cómputo después de un fallo. Por ejemplo, una creación de clúster fallida o submitRun seguidas poco después por startWarehouse, o por un nuevo trabajo en recursos de cómputo diferentes, puede indicar que un adversario está eludiendo una ruta bloqueada. Los códigos de respuesta y el corto intervalo entre eventos son lo que separa esta secuencia de los errores rutinarios. Los recursos de cómputo serverless son una alternativa común.

5. El adversario establece persistencia

Con una forma de ejecutar código, los adversarios intentan a continuación asegurarse de poder regresar después de que se revoque la credencial original. Los métodos comunes de persistencia incluyen concesiones de acceso, tokens recién creados, cambios en la pertenencia a grupos y workspaces, y ediciones en el plano de control. La señal más útil es un cambio sensible realizado por una identidad o contexto de ejecución desconocido. Por ejemplo, un cambio de permisos realizado desde el interior de un trabajo merece un escrutinio mayor que el mismo cambio realizado por un administrador en la consola. A continuación, en el escenario, la entidad de servicio se añade a un grupo de administradores. Incluso si se revoca el token del ingeniero, esa pertenencia al grupo mantiene el acceso del adversario.

Objetivo del adversario: Crear rutas de acceso duraderas e independientes que sobrevivan a la revocación de la credencial comprometida.

Qué buscar:

• Genera alertas sobre concesiones de permisos e identidad desde contextos inesperados, como putAcl en un ámbito de secretos, updatePermissionAssignment, addPrincipalToGroup o setAdmin. Presta especial atención cuando una entidad de servicio otorga acceso a otra identidad, o cuando se producen múltiples asignaciones en un período corto.
• Trata los intentos de modificar los controles de seguridad como de alta gravedad, incluso cuando fallen. Esto incluye setSetting / deleteSetting, ediciones de listas de acceso de IP y createPrivateAccessSettings. Revisa el cambio solicitado, la respuesta y la fuente antes de concluir si realmente se eludió un control. Revisa también los cambios en grupos SCIM provenientes de cualquier fuente que no sea el IdP esperado.
• Marca las llamadas a generateDbToken provenientes de una fuente desconocida o durante la ejecución de un trabajo. Cada token resultante es una credencial independiente que deberá ser revocada.
• Vigila las cargas de trabajo que continúan por sí solas. Correlaciona los eventos del plano de control con run_by, run_as y la ventana de ejecución esperada. Si un trabajo sigue modificando grupos, permisos o configuraciones después de que se detiene la actividad interactiva del adversario, es posible que esté manteniendo el acceso por sí mismo. Conserva la definición del trabajo y los artefactos antes de terminarlo.

6. El adversario recopila datos y limpia el acceso

La recopilación de datos puede ser tan pequeña como unas pocas exportaciones dirigidas, y la limpieza puede implicar algo más que eliminar archivos. Vigila las exportaciones dirigidas, las solicitudes de credenciales temporales, la eliminación de herramientas de corta duración y los comandos ofuscados que dificultan la reconstrucción de la actividad. Cualquiera de estos eventos puede parecer rutinario, por lo que la secuencia que los rodea importa más que la exportación o eliminación individual. Por último, la entidad de servicio de nuestro escenario exporta un puñado de scripts de inicio. Por sí sola, es una exportación pequeña. Sin embargo, dado que sigue a una lectura de secretos y a una nueva función de la misma entidad de servicio, debe investigarse como parte de la misma intrusión.

Objetivo del adversario: Tomar los datos que importan y borrar las herramientas más obvias, dejando un acceso más silencioso en su lugar.

Qué buscar:

• Analiza el contexto de cada exportación en lugar de la cantidad de exportaciones. workspaceExport registra la ruta, el formato y si fue una descarga directa. Prioriza las exportaciones realizadas por identidades desconocidas, hacia rutas inusuales o en formatos inusuales, desde redes no vistas anteriormente, o que siguen a un acceso a secretos o a una nueva ejecución. Una exportación pequeña y dirigida de scripts de inicio puede filtrar más información que un volcado masivo de SOURCE.
• Conserva registros de objetos de corta duración. Un createFunction seguido de deleteFunction para la misma función en una sola sesión, o un ciclo repetido de creación, eliminación y recreación, puede indicar un intento de eliminar evidencia. Conserva las definiciones y los tiempos antes de revertir cualquier cosa. A los objetos que sobreviven a menudo se les asignan nombres más plausibles que los de los eliminados.
• Conecta los ráfagas de credenciales temporales y lectura de datos (generateTemporaryTableCredential, generateTemporaryVolumeCredential, Delta Sharing, lecturas de almacenamiento en la nube) con el reconocimiento anterior. Los comandos codificados o mediante scripts son demasiado comunes como para activar alertas por sí solos, así que correlaciónalos con un user agent desconocido, tiempos similares a la automatización, acceso a secretos o nuevas funciones.

Investigación de ataques basados en credenciales con Genie

Utilizando la cadena de ataques basados en credenciales como guía, puedes indicar a Genie que recorra las fases del ataque sin necesidad de escribir cada consulta desde cero. Todas las detecciones de esta publicación se ejecutan en la teleometría que ya tienes. Databricks escribe la actividad del plano de control en la tabla del sistema system.access.audit.

Para empezar, instala la aplicación de detección, que añade un agente de Genie para el registro de auditoría de Databricks. Puedes usarlo desde Genie One de dos formas:

• Pregunta con tus propias palabras, como "¿Qué notebooks exportó user@example.com ayer?" Genie escribe y ejecuta el SQL por ti.
• Usa las detecciones integradas. El agente de Genie de la aplicación de detección incluye más de 30 detecciones, desde el uso indebido de tokens hasta concesiones de administrador. Pregunta "¿Quién creó tokens de acceso personal la semana pasada?" y Genie ejecuta la detección correspondiente en lugar de escribir nuevo SQL. Asígnale un objetivo, como "¿Fuimos comprometidos en los últimos 90 días?", y recorrerá las detecciones una por una.

Ten en cuenta dos límites. Primero, un resultado vacío no significa que no haya pasado nada. El evento puede estar fuera de tu ventana de tiempo, o el registro de auditoría detallado puede estar desactivado. Segundo, los registros de auditoría indican que algo cambió y quién lo hizo, pero a menudo no muestran los valores antiguos o nuevos.

De la detección a la respuesta

Una vez que una búsqueda identifica una identidad que no encaja en su patrón normal, el enfoque cambia hacia el acceso que el adversario todavía posee. Como los ataques basados en credenciales no son lineales, el primer acceso que encuentras rara vez es el único. En el ejemplo del ingeniero de datos, revocar el token del ingeniero dejaría la credencial de la entidad de servicio, su membresía en el grupo de administradores y la función que creó. Una respuesta completa elimina tanto la credencial original como cada ruta que el adversario creó después, incluyendo concesiones, tokens, funciones y trabajos que siguen ejecutándose después de deshabilitar al usuario.

Ante la sospecha de un espacio de trabajo comprometido, los equipos de respuesta deben:

1. Deshabilitar la identidad. Desactiva el usuario a nivel de cuenta, lo que bloquea todos los espacios de trabajo. No existe una API para finalizar las sesiones de navegador de un usuario, pero la desactivación los bloquea. Para una entidad de servicio, elimina sus secretos de OAuth y desactívala con la API SCIM de la cuenta. Los tokens de OAuth que la entidad de servicio ya posee siguen siendo válidos por hasta una hora.
2. Revocar sus tokens de acceso personal. Desactivar un usuario no elimina sus tokens, y estos vuelven a funcionar si el usuario es reactivado. Usa la API de gestión de tokens o el informe de tokens en la consola de la cuenta.
3. Guarda lo que necesites y detén el proceso de cómputo. Exporta primero las definiciones de los trabajos y las versiones de los notebooks. Luego cancela las ejecuciones de trabajos, termina los clústeres y detén los almacenes SQL. En serverless, cancela la ejecución o la sentencia. Desactivar un usuario no detiene los procesos de cómputo que ya se están ejecutando.
4. Rota cada secreto que el actor haya leído. Cámbialo en la fuente y luego actualiza el valor almacenado. Rota también la credencial que el adversario usó para ingresar.
5. Deshacer la persistencia creada por el actor. Elimina las ACL de ámbitos de secretos, las asignaciones de espacios de trabajo y las membresías de grupos. Elimina las funciones y revoca las concesiones. Restaura tus políticas de ingreso basado en contexto (y las listas de acceso IP, si aún las usas) a partir de tus propios registros.
6. Revisa el código que la identidad pudo cambiar fuera de Databricks, como los scripts de inicio y el código ETL en el almacenamiento en la nube.
7. Confirma que se detuvo. Ejecuta una búsqueda de la actividad realizada por el actor. Si el registro de auditoría detallado estaba desactivado, actívalo. El texto de los comandos solo se registra mientras está activo.

Prevención de ataques basados en credenciales

Para volver al ejemplo del edificio de oficinas: el ingreso basado en contexto decide quién pasa por las puertas giratorias, y el principio de privilegios mínimos decide qué pisos puede abrir su credencial. Una detección temprana aporta tiempo de respuesta, pero los controles preventivos limitan lo que una credencial robada puede hacer. Los controles a continuación se agrupan según lo que le quitan al adversario, aproximadamente en el orden en que rompen su cadena de ataque.

Evita la entrada de credenciales robadas

El control preventivo más fuerte contra la reutilización de credenciales es el control de ingreso basado en contexto. Evalúa quién realiza una solicitud, de dónde proviene y para qué es, en lugar de depender de un único perímetro de red. Esto es especialmente útil a medida que más organizaciones se alejan de las VPN. Incluso sin una red corporativa como base, puedes limitar un token robado a los contextos que su propietario realmente utiliza. Por ejemplo, puedes restringir una entidad de servicio con privilegios a solicitudes de API desde redes confiables mientras aplicas una política diferente a los usuarios humanos.

• Aplica políticas tanto a las solicitudes del espacio de trabajo como de la cuenta. Las políticas del espacio de trabajo no cubren la consola de la cuenta ni las API a nivel de cuenta.
• Comienza en modo de prueba (dry-run). Revisa las denegaciones y las violaciones en system.access.inbound_network, protege primero las entidades de servicio con privilegios y aplica el cumplimiento después de haber considerado la automatización legítima y las integraciones de socios.
• Prueba los flujos de trabajo serverless y de conectividad privada antes de una aplicación generalizada, ya que siguen reglas de política separadas. Documenta cualquier excepción y monitorea su uso.
• Trata las listas de acceso IP como una capa adicional. Cuando ambas aplican, una solicitud debe pasar por ambas. Configura las listas del espacio de trabajo y de la consola de la cuenta si aún las usas.

Reduce el valor de las credenciales obtenidas

• Establece requisitos de caducidad y rotación para las credenciales de entidades de servicio, credenciales de integración y tokens de acceso personal, y retira las credenciales que ya no se utilicen. Las credenciales inactivas son especialmente atractivas para los adversarios porque un compromiso puede pasar desapercibido durante meses.
• Haz cumplir el principio de privilegios mínimos en los ámbitos de secretos. Evita almacenar copias de credenciales potentes en ámbitos con diferentes ACL, y revisa quién puede listar el contenido del ámbito así como quién puede recuperar valores.

Limita lo que una credencial puede ejecutar o cambiar

• Restringe las operaciones de alto impacto. Limita la creación de UDF, los cambios en las ACL de ámbitos de secretos, los cambios de permisos en el espacio de trabajo, la administración de trabajos y los cambios en las políticas de ingreso a identidades aprobadas y automatización controlada.
• Separa las rutas administrativas de las rutas de cómputo. Los tiempos de ejecución de trabajos ordinarios no deberían poder modificar los controles de cuentas y redes, y cualquier intento de hacerlo debe generar una alerta.
• Protege los entornos de ejecución en la nube. Usa configuraciones de servicio de metadatos seguras cuando sea posible y restringe la salida del cómputo para que las cargas de trabajo no puedan acceder libremente a los puntos de enlace de credenciales o destinos no aprobados.
• Restringe qué identidades pueden gestionar identidades de cuentas, asignar acceso a espacios de trabajo y crear trabajos.

Conserva las evidencias

• Conserva telemetría lista para investigaciones ante posibles vulneraciones de seguridad.
• Conserva registros de auditoría, historial de versiones de notebooks y trabajos, definiciones y dependencias de UDF, historial de cambios de permisos, eventos de escritura en almacenamiento en nube y registros de denegación de entrada basados en contexto el tiempo suficiente para reconstruir un ataque.

Recuerda que el radio de impacto de una credencial robada es tan dañino como los privilegios que se le hayan asignado. Reduce esa exposición y prepárate para buscar actividad anómala siguiendo estos pasos:

• Revisa las mejores prácticas de seguridad de Databricks para asegurar tus espacios de trabajo y tu cuenta.
• Activa el registro de auditoría detallado y configura el control de entrada basado en contexto para cubrir ambos planos.
• Implementa la Detection App para comenzar tus búsquedas y hazle tu primera pregunta a Genie: "¿Fuimos vulnerados en los últimos 90 días?"

(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original