Un informe de Luke Richards, Dmitriy Beryoza y Kat Traxler.
El reciente incidente de seguridad en Okta representa otra visión de un compromiso de la cadena de suministro. Aunque parece que este ataque no se ha llevado a cabo en su totalidad, con el resultado de un número aparentemente limitado de empresas afectadas, plantea una serie de cuestiones interesantes sobre las que reflexionar en términos de cómo sería un ataque a la cadena de suministro contra un IDP cuando se llevara a cabo en su totalidad. El resultado de un ataque contra un IDP, o contra cualquier tecnología similar de uso generalizado, podría ser un grupo de ataque con acceso a millones de usuarios y miles de empresas.
La táctica de comprometer la cadena de suministro en sí misma no es nueva, ya que nos vienen a la mente infracciones recientes de gran repercusión, como las de Kaseya y SolarWinds. Pero la idea de un ataque a la cadena de suministro centrado en la gestión de cuentas asusta cuando se estudia en detalle lo que tendría que hacer un equipo de seguridad.
El acceso a cuentas ha desempeñado un papel en el 85% de los ataques recientes. Las cuentas proporcionan a los atacantes acceso a casi todo en una organización, desde recursos cloud en aplicaciones SaaS de cloud pública hasta activos de red, sin necesidad de cargas útiles ni contacto con puntos finales supervisados.
Dadas las preguntas planteadas sobre lo que podría haber ocurrido, a continuación esbozamos las recomendaciones que los equipos de seguridad deben adoptar en caso de que un IDP u otro software centrado en la identidad se vea implicado en un compromiso de la cadena de suministro. Estas recomendaciones también se aplican al compromiso de cuentas resultante de tácticas distintas de los ataques a la cadena de suministro. Desde el punto de vista de un atacante, la cadena de suministro es sólo uno de los muchos métodos para comprometer una cuenta. La forma en que los atacantes aprovechan las cuentas comprometidas para completar sus objetivos dentro de un entorno objetivo, y la forma en que los defensores pueden detectar y responder a esas acciones, son esencialmente las mismas, independientemente del método inicial de compromiso.
Evaluar la situación actual
Obtenga toda la información posible sobre la infracción
Cuandoun compromiso implica a un tercero, la información controlada publicada por la organización afectada y las declaraciones realizadas por los atacantes, la imagen completa de lo que está ocurriendo puede ser difícil de reunir. Incluya en su análisis múltiples fuentes de información, incluidos los comentarios de investigadores de seguridad independientes, para estimar el alcance del incidente.
Determinar el calendario aproximado de la infracción
A veces, la noticia del suceso de seguridad aparece semanas o incluso meses después del ataque. Para encontrar el mayor número posible de IoC, lance una red amplia y defina un marco temporal realista en el que podría haberse producido la actividad maliciosa.
Haga inventario de todo lo que toca su proveedor de identidad
Las empresas modernas utilizan cientos de servicios y aplicaciones diferentes, y a veces incluso los SOC tienen problemas para hacer un seguimiento preciso del inventario. No se puede proteger adecuadamente lo que no se conoce, por lo que es crucial adquirir un conocimiento completo de todas las entidades a las que presta servicios el proveedor para cubrir todas las consecuencias de la violación.
Revisar la actividad reciente en los registros y las alertas que se hayan activado.
Los proveedores establecidos deben tener buenos registros de toda la actividad crítica dentro del entorno. Armado con la estimación de la línea de tiempo, revise todos los cambios relevantes en la configuración del sistema para detectar cualquier cosa que pudiera dar a los atacantes un punto de apoyo en su empresa: nuevos usuarios administradores, permisos elevados, credenciales de acceso redundantes, aplicaciones recién instaladas, dispositivos inscritos, etcétera. También debe evaluarse cualquier alerta de seguridad registrada.
Investigar cualquier otro cambio que pueda proporcionar un acceso redundante.
A veces el registro disponible puede no estar habilitado o ser inadecuado. Merecerá la pena que revises la configuración de seguridad actual para ver si se ha cambiado algo fuera de lo normal.
Mitigar los cambios malintencionados
Anular cambios de configuración malintencionados
Este paso se explica por sí mismo: cualquier cambio malicioso detectado debe ser revertido. Se deben registrar todos los detalles para obtener una imagen completa del ataque y ayudar en las actividades forenses posteriores.
Restablecer contraseñas de usuario
Cuando sospechas que cuentas de usuario individuales pueden estar comprometidas, forzar la renovación de credenciales de usuario puede ser un paso necesario. Aunque este paso será impopular entre tu base de usuarios, es fácil de llevar a cabo y es un paso práctico para hacer frente a un posible compromiso de cuentas.
Rotación de claves y certificados
Restablecer las credenciales de aplicaciones y servicios suele ser una actividad mucho más compleja y laboriosa. Aunque puede ser inevitable si se filtran los secretos pertinentes, asegúrate de que es necesario antes de embarcarte en ello.
Revocar todos los permisos excesivos de terceros
Algunos proveedores de identidad (incluido Okta) pueden solicitar permiso al cliente para acceder y modificar la configuración del inquilino o realizar la depuración del sistema. Ante un compromiso del proveedor, sería prudente revocar cualquier acceso de este tipo que ya se haya concedido.
Apuntalar las defensas
Revisar la configuración de seguridad actual
Este es otro paso obvio. Un incidente de seguridad es una gran oportunidad para revisar la configuración de seguridad actual y reforzarla. Los productos de gestión de la postura de seguridad como Siriux, que pueden escanear e identificar lagunas en las configuraciones de los controles de Azure AD y M365, pueden ser de gran ayuda.
Instalar una solución de supervisión
Incluso la solución de seguridad mejor configurada no es inmune a las brechas. El factor humano o los ataques a la cadena de suministro (como una violación del IdP) pueden eludir las defensas externas. Para hacer frente cuando se producen incidentes, se necesita una solución eficaz de detección y respuesta como la plataforma Vectra para supervisar la actividad maliciosa y detener la progresión de los atacantes.
Revisar los manuales de respuesta a incidentes
Lo ideal es que ya tenga un plan para un incidente en su proveedor de identidades, y que lo esté ejecutando ahora mismo. Aquellos que se encuentren con lagunas en la preparación deben aprovechar esta oportunidad para poner en marcha un plan para hacer frente a las consecuencias de una brecha en un proveedor de infraestructura crítica del que dependa su empresa.
Considerar una auditoría de terceros
Cuando el polvo se asiente, es bueno programar una auditoría de terceros por un proveedor de seguridad respetable para verificar que su postura de seguridad está bien diseñada y no contiene agujeros aparentes.
¿Cuáles son los signos de una cuenta comprometida?
Cuando una o más cuentas se ven comprometidas, el impacto no siempre es inmediatamente evidente. Debido a la variedad de acciones que puede realizar una cuenta y a la forma en que se gestionan los activos, la señal de una cuenta comprometida se caracteriza más generalmente por una actividad anómala relacionada con el acceso a servicios, funcionalidades, hosts o datos valiosos. Definir lo que es anómalo e incluso lo que es valioso no es, obviamente, una tarea sencilla.
Mientras que los equipos pueden buscar en los registros de Active Directory de la red y revisar las acciones registradas por un servicio cloud , la escala y la naturaleza ambigua del problema se manejan mejor utilizando soluciones de IA para dar sentido a lo que es anómalo y alineado con el objetivo de un atacante. Esto es especialmente importante cuando nos enfrentamos a situaciones en las que la alternativa a no saber con precisión quién está comprometido es volver a utilizar credenciales, tokens de acceso y, potencialmente, claves privadas.
Vectra aplica la IA basada en la seguridad para supervisar y responder a las acciones de los atacantes con cuentas comprometidas que abarcan su empresa en la nube cloud, SaaS y AWS. Las alertas se centran no solo en lo que es anómalo, sino en el comportamiento de los atacantes. Las técnicas como Privilege Analytics de Vectra, que comprenden automáticamente el valor de las cuentas y los activos tanto en entornos de nube cloud como de SaaS puro, pueden dar sentido a lo anormal al comprender el valor de los activos en función de su actividad histórica.
Investigación manual de cuentas comprometidas y de alto riesgo
Para aquellos que no se benefician de una plataforma como Vectra, los cazadores de amenazas tendrán que evaluar los detalles del incidente y cómo el IDP interactúa con su entorno para determinar las posibles cuentas sospechosas de estar comprometidas. En el caso de Okta, esto puede hacerse, por ejemplo, observando los cambios en las cuentas durante el periodo de control del atacante revelado dentro de la infraestructura del IDP.
Durante las operaciones normales de Operaciones de Seguridad, los analistas pueden dedicar un esfuerzo extra a la supervisión de cuentas de alto perfil, como administradores de dominio y cuentas de servicio. Estas suelen ser cuentas robustas y estables, con pocos cambios en su funcionamiento diario. Cuando nos vemos obligados a considerar un ataque de tipo cadena de suministro, la atención se desplaza más allá del alcance de esas cuentas de altos privilegios, a casi todas las cuentas de la red. Renovar las credenciales, los tokens de acceso y, potencialmente, las claves privadas, es una tarea no sólo complicada y lenta, sino a veces insostenible.
Si se sospecha que una cuenta está comprometida o está etiquetada como de alto riesgo, el mejor lugar para buscar fuera de las detecciones son los registros de seguridad de Active Directory y, en particular, los siguientes ID de eventos
- 4624 (Una cuenta ha iniciado sesión con éxito) esta cuenta produce dos tipos de nota de inicio de sesión.
- Tipo de conexión 10
§ Inicio de sesión interactivo remoto - Está relacionado con RDP, asistencia remota o conexión en la sombra. Este tipo de inicio de sesión también iniciaría sesión en la dirección IP remota.
- Tipo de inicio de sesión 3
§ Network Logon - Esto indicaría un usuario autenticado conectándose a un servicio en el host remoto.
- 4768 Se ha generado un vale de autenticación Kerberos (TGT ) este evento indica que se está autenticando una cuenta de usuario en la red. El TGT se da a una cuenta válida con una contraseña válida. De nuevo, esto generaría una dirección IP para rastrear posibles comportamientos anómalos.
El seguimiento de estos registros podría revelar actividad en cuentas potencialmente comprometidas. Las cuentas de aplicaciones y servicios tienden a ser muy estables, por lo que Vectra aprende el comportamiento normal de estas cuentas y puede proporcionar una Detección de Anomalías de Privilegios cuando empiezan a actuar fuera de sus patrones establecidos. Lo mismo ocurre con las cuentas más efímeras, o las que tienen un alcance más amplio, como las cuentas de operador, o las cuentas de usuario normales. Es menos probable que estas cuentas interactúen con los servicios que son estables y críticos para el negocio, lo que permite que el enfoque de Vectrapara supervisar las identidades en busca de comportamientos anómalos genere detecciones y guíe el enfoque de su equipo en consecuencia.
Si desea más información sobre Vectra,póngase en contacto con nosotrosopruebe nuestra demo.