Este producto no es compatible con el sitio Datadog seleccionado. ().
App and API Protection se encuentra en versión preliminar en el sitio de Datadog Government US1-FED.
Los usuarios son entidades de confianza en sus sistemas con acceso a información confidencial y la capacidad de realizar acciones confidenciales. Los actores maliciosos han identificado a los usuarios como una oportunidad para atacar sitios web y robar datos y recursos valiosos.
Datadog App and API Protection (AAP) proporciona capacidades de detección y protección integradas para ayudarle a gestionar esta amenaza.
Esta guía describe cómo utilizar AAP para prepararse y responder a campañas de apropiación de cuentas (ATO). Esta guía se divide en tres fases:
Aprenda a reaccionar ante las campañas de ATO, incluyendo las estrategias de los atacantes, la clasificación, la respuesta, la investigación, el monitoreo y la limpieza.
Fase 1: Recopilación de información de inicio de sesión
Para detectar patrones maliciosos, AAP requiere visibilidad de la actividad de inicio de sesión de sus usuarios. Esta fase describe cómo habilitar y validar esta visibilidad.
Paso 1.1: Asegúrese de que AAP esté habilitado en su servicio de identidad
Este paso describe cómo configurar su servicio para usar AAP.
Paso 1.2: Habilitación de AAP en su servicio de inicio de sesión
Para habilitar AAP en su servicio de inicio de sesión, asegúrese de cumplir con los siguientes requisitos:
De manera similar a Datadog APM, AAP requiere una integración de biblioteca en sus servicios y un Datadog Agent en ejecución.
AAP generalmente se beneficia del uso de la biblioteca más nueva posible; sin embargo, las versiones mínimas admitidas están documentadas en Requisitos de compatibilidad.
Como mínimo, Threat Detection debe estar habilitado. Idealmente, Automatic user activity event tracking también debería estar habilitado.
Para habilitar AAP mediante una nueva implementación, utilice la variable de entorno/configuración de biblioteca APPSEC_ENABLED o Remote Configuration. Puede utilizar cualquiera de los dos métodos, pero la Remote Configuration se puede configurar mediante la interfaz de usuario de Datadog.
Para habilitar AAP mediante Remote Configuration, y sin tener que reiniciar sus servicios, haga lo siguiente:
Busque trazas etiquetadas con actividad de inicio de sesión desde su servicio de inicio de sesión. Por ejemplo, en Search for, es posible que tenga @appsec.security_activity:business_logic.users.login.*.
Verifique si todos sus servicios de inicio de sesión están reportando actividad de inicio de sesión. Puede ver esto en la faceta Service.
Busque trazas etiquetadas con actividad de inicio de sesión exitosa y fallida desde su servicio de inicio de sesión. Puede actualizar la consulta de búsqueda en Search for para filtrar business_logic.users.login.success o business_logic.users.login.failure.
Abra una traza.
En la pestaña Security, revise el Business Logic Event.
Verifique si el evento es para un usuario falso.
Revise algunas trazas, tanto de inicios de sesión exitosos como fallidos. Para fallos de inicio de sesión, busque trazas con usr.exists como true (intento de inicio de sesión fallido por un usuario existente) y false.
Las verificaciones deben realizarse independientemente de si el usuario existe o no.
En caso de un usuario falso (usr.exists:false), busque los siguientes problemas:
Un solo evento: si la traza contiene múltiples eventos de inicio de sesión, como éxitos y fallos, esto podría deberse a una instrumentación automática incorrecta. Para cambiar la instrumentación automática, vaya a Paso 1.5: Instrumentación manual de sus servicios.
¿Contiene el evento los metadatos obligatorios? Podría aparecer como una sección de atribución de usuario en caso de un inicio de sesión exitoso. Los metadatos obligatorios son usr.login y usr.exists en caso de fallo de inicio de sesión, y usr.login y usr.id en caso de inicio de sesión exitoso. Si faltan algunos metadatos, vaya a Paso 1.5: Instrumentación manual de sus servicios.
AAP recopila información de inicio de sesión y metadatos mediante un SDK integrado en las bibliotecas de Datadog. La instrumentación se realiza llamando al SDK cuando el inicio de sesión de un usuario es exitoso o falla, y proporcionando al SDK los metadatos del inicio de sesión. El SDK adjunta el inicio de sesión y los metadatos a la traza y los envía a Datadog, donde se conservan.
usr.login: Obligatorio para el éxito y el error de inicio de sesión. Este campo contiene el nombre utilizado para iniciar sesión en la cuenta. El nombre puede ser una dirección de correo electrónico, un número de teléfono, un nombre de usuario o cualquier otra cosa. El propósito de este campo es identificar las cuentas objetivo incluso si no existen en sus sistemas, ya que un usuario podría ser capaz de cambiar esas cuentas. Además, este campo proporciona información sobre la ubicación de la base de datos utilizada por el atacante. Este valor no debe confundirse con usr.id.
usr.exists: Obligatorio para inicios de sesión fallidos. Este campo es necesario para algunas detecciones predeterminadas. El campo ayuda a reducir la prioridad de los intentos dirigidos a cuentas que no existen en sus sistemas.
AAP puede usar reglas personalizadas de WAF en la aplicación para marcar intentos de inicio de sesión y extraer de la solicitud los metadatos necesarios para las reglas de detección.
Este enfoque requiere que Remote Configuration esté habilitado y funcionando. Verifique que Remote Configuration se esté ejecutando para este servicio en Remote Configuration.
Para usar reglas WAF personalizadas en la aplicación, haga lo siguiente:
Nombre su regla y seleccione la categoría Business Logic.
Establezca el tipo de regla como users.login.failure para errores de inicio de sesión y users.login.success para inicios de sesión exitosos.
Seleccione su servicio y escriba la regla para que coincida con los intentos de inicio de sesión. Por lo general, usted hace coincidir el método (POST), el URI con una expresión regular (^/login) y el código de estado (403 para errores, 302 o 200 para éxito).
Recopile las etiquetas requeridas por las reglas de detección. La etiqueta más importante es usr.login. Suponiendo que el inicio de sesión se proporcionó en la solicitud, puede agregar una condición y establecer store value as tag como operador.
Seleccione un parámetro de usuario específico como entrada, ya sea en el cuerpo o en la consulta.
Establezca el campo Tag en el nombre de la etiqueta donde desea guardar el valor capturado usando usr.login.
Haga clic en Save. La regla se envía automáticamente a cada instancia del servicio y luego comienza a capturar los errores de inicio de sesión.
Después de configurar la instrumentación para sus servicios, AAP monitorea las campañas de ataque. Puede revisar el tráfico en la sección Attacks overviewBusiness logic.
La gravedad de la señal se establece según la urgencia de la amenaza: desde Low en caso de ataques fallidos hasta Critical en caso de compromisos de cuenta exitosos.
Las acciones cubiertas en las siguientes secciones le ayudan a identificar y aprovechar las detecciones más rápidamente.
Paso 2.1: Configuración de las notificaciones
Notifications proporciona una advertencia en su canal preferido cuando se activa una señal. Para crear una regla de notificación, haga lo siguiente:
Seleccione Signal y elimine todas las entradas excepto App & API Protection.
Restrinja la regla a category:account_takeover y expanda las gravedades para incluir Medium.
Agregue destinatarios de notificaciones (Slack, Teams, PagerDuty).
Para obtener más información, consulte Notification channels.
Pruebe y luego guarde la regla.
La notificación se envía la próxima vez que se genera una señal.
Paso 2.2: Validar la propagación adecuada de datos
En entornos de microservicios, generalmente se accede a los servicios mediante hosts internos que ejecutan otros servicios. Este entorno interno hace que sea difícil identificar los rasgos únicos de la solicitud del atacante original, como la IP, el agente de usuario, la huella digital, etc.
AAP Traces puede ayudarle a validar que el evento de inicio de sesión esté correctamente etiquetado con las IP de origen, el agente de usuario, etc. Para validar, revise las trazas de inicio de sesión en Traces y verifique lo siguiente:
Las IP de origen (@http.client_ip) son variadas y son IP públicas.
Problema: Si los intentos de inicio de sesión provienen solo de unas pocas IP, podría tratarse de un proxy que no puede bloquear sin arriesgar la disponibilidad.
Solución: Reenvíe la IP del cliente de la solicitud inicial a través de un encabezado HTTP, como X-Forwarded-For. Puede usar un encabezado personalizado para mejorar la seguridad y configurar el SDK para que lo lea utilizando la variable de entorno DD_TRACE_CLIENT_IP_HEADER.
El agente de usuario (@http.user_agent) es consistente con el tráfico esperado (navegador web, aplicación móvil, etc.)
Problema: El agente de usuario podría ser reemplazado por el agente de usuario en la biblioteca de red del microservicio que realiza la llamada.
Solución: Utilice el agente de usuario del cliente al llamar a servicios posteriores.
Se completan múltiples encabezados. Puede ver esto en la See more details de una traza en el bloque Request.
Problema: Los encabezados de solicitud normales (por ejemplo, accept-encoding) no se reenvían al servicio instrumentado. Esto perjudica la generación de huellas digitales (@appsec.fingerprint.*) y degrada la capacidad de la señal para aislar la actividad de un atacante.
Solución: Reenvíe esos encabezados al llamar a un microservicio posterior.
El bloqueo automático de AAP se puede utilizar para bloquear ataques en cualquier momento del día. El bloqueo automático puede ayudar a bloquear ataques antes de que los miembros de su equipo estén en línea, brindando seguridad durante las horas fuera de servicio. Dentro de un ATO, el bloqueo automático puede ayudar a mitigar los problemas de carga causados por el aumento en los intentos fallidos de inicio de sesión o evitar que el atacante utilice cuentas comprometidas.
Puede configurar el bloqueo automático para bloquear las IP identificadas como parte de un ataque. Esta es solo una corrección parcial porque los atacantes pueden cambiar las IP; sin embargo, puede darle más tiempo para implementar una corrección integral.
Para configurar el bloqueo automático, haga lo siguiente:
En Search, ingrese tag:"category:account_takeover".
Abra las reglas donde desea activar el bloqueo. Datadog recomienda activar el bloqueo de IP para una gravedad de High o Critical.
En la regla, en Define Conditions, en Security Responses, habilite IP automated blocking. También puede habilitar User automated blocking. Puede controlar el comportamiento de bloqueo por condición. Cada regla puede tener múltiples condiciones basadas en su confianza y el éxito del ataque.
Datadog no recomienda el bloqueo permanente de direcciones IP. Es poco probable que los atacantes reutilicen las IP y el bloqueo permanente podría resultar en el bloqueo de usuarios. Además, AAP tiene un límite de cuántas IP puede bloquear (~10000), y esto podría llenar esta lista con IP innecesarias.
Fase 3: Reacción ante campañas de ATO
Esta sección describe el comportamiento común de los hackers en la apropiación de cuentas y cómo clasificar, investigar y hacer un seguimiento de las detecciones.
Cómo ejecutan los atacantes sus campañas
Eventualmente, sus sistemas son atacados. La oleada de intentos de inicio de sesión maliciosos a menudo puede eclipsar el volumen de actividad de inicio de sesión normal que el servicio espera. La carga podría aumentar causando problemas de disponibilidad y el atacante podría iniciar sesión exitosamente en una cuenta en cualquier momento.
Las acciones que toman los atacantes dependen de su estrategia y de las configuraciones de sus sistemas. Algunos atacantes podrían decidir abusar inmediatamente de su acceso para extraer valor antes de que usted haya tenido tiempo de congelar sus cuentas comprometidas. Otros podrían mantener las cuentas inactivas hasta un momento posterior.
Hay muchas estrategias disponibles, pero es importante entender que la cadena de valor de los ataques a menudo se divide cuidadosamente:
El actor que inicia el ataque a menudo compra una base de datos de credenciales a un proveedor (probablemente adquirida por el compromiso de otro servicio).
El actor obtiene un script diseñado para automatizar los intentos de inicio de sesión mientras evade la detección (aleatorizando encabezados, tratando de parecerse lo más posible al tráfico normal).
El actor compra acceso a una red de bots, lo que le permite aprovechar muchas IPs diferentes para ejecutar su ataque. Existen casos extremos donde grandes campañas con más de 500 mil intentos estaban tan distribuidas que Datadog vio un promedio de 1.01 solicitudes por IP y un solo intento por cuenta.
Cuando se descubren credenciales válidas, podrían venderse a otro actor para que las aproveche con algún fin, como robo financiero, spam, abuso, etc.
Cuando un ataque comienza contra sus sistemas, el sistema genera señales etiquetadas como Credential Stuffing, Distributed Credential Stuffing o Bruteforce, dependiendo de la estrategia del atacante.
Paso 3.1: Clasificación
El primer paso es confirmar que la detección sea correcta. Ciertos comportamientos, como un escaneo de seguridad en un punto de conexión de inicio de sesión o una gran cantidad de rotación de tokens, podrían parecer un ataque para la detección. El análisis depende de la señal, y los siguientes ejemplos proporcionan una guía general que debe personalizarse para su situación.
La señal busca un intento de robar una cuenta de usuario probando muchas contraseñas diferentes para esta cuenta. Generalmente, un pequeño número de cuentas son el objetivo de estas campañas.
Revise las cuentas marcadas como comprometidas. Haga clic en un usuario para abrir un resumen de la actividad reciente.
Preguntas para la clasificación:
¿Ha habido un aumento repentino de la actividad?
¿Es la primera vez que esas direcciones IP intentan iniciar sesión?
¿Están marcadas por inteligencia de amenazas?
Si la respuesta a esas preguntas es sí, es probable que la señal sea legítima.
Puede adaptar su respuesta según la sensibilidad de la cuenta. Por ejemplo, una cuenta gratuita con acceso limitado frente a una cuenta de administrador.
Esta señal busca una gran cantidad de cuentas con inicios de sesión fallidos provenientes de una pequeña cantidad de direcciones IP. Esto suele ser causado por atacantes poco sofisticados.
Revise las cuentas marcadas como objetivo para encontrar similitudes y establecer la sensibilidad de esos usuarios.
Si comparten atributos, como provenir todos de una misma institución, verifique si la dirección IP podría ser un proxy para esta institución revisando su actividad pasada al pasar el cursor sobre ella y abrir el panel lateral.
Preguntas para la clasificación:
¿Ha habido un aumento repentino de la actividad?
¿Las cuentas no están correlacionadas?
¿Las direcciones IP están marcadas por inteligencia de amenazas?
¿Hay muchos más inicios de sesión fallidos que exitosos?
Si la respuesta a esas preguntas es sí, es probable que la señal sea legítima. Puede adaptar su respuesta según la escala del ataque y si se están comprometiendo cuentas.
Esta señal busca un gran aumento en el número total de errores de inicio de sesión en un servicio. Esto es causado por atacantes sofisticados que aprovechan una red de bots.
Datadog intenta identificar atributos comunes entre los errores de inicio de sesión en su servicio. Esto puede revelar defectos en el script del atacante que pueden usarse para aislar la actividad maliciosa. Cuando se encuentra, se muestra una sección llamada Attacker Attributes. Si está presente, revise si se trata de una actividad legítima seleccionando el clúster y haciendo clic en Explore clusters.
Si es precisa, la actividad del clúster debería coincidir estrechamente con el aumento de errores de inicio de sesión y, al mismo tiempo, ser baja o inexistente antes. Si no hay ningún clúster disponible, haga clic en Investigate in full screen y revise los usuarios/IP objetivo en busca de valores atípicos.
Si la lista está truncada, haga clic en View in AAP Traces Explorer y ejecute la investigación con el explorador de trazas. Para obtener herramientas adicionales, consulte Paso 3.3: Investigación.
Si la conclusión del triaje es que la señal es un falso positivo, puede marcarla como falso positivo y cerrarla.
Si el falso positivo fue causado por una configuración única en su servicio, puede agregar filtros de supresión para silenciar los falsos positivos.
Paso 3.2: Interrupción del atacante como respuesta preliminar
Si el ataque está en curso, es posible que desee interrumpir al atacante mientras investiga más a fondo. Interrumpir al atacante ralentiza el ataque y reduce el número de cuentas comprometidas.
Este es un paso común, aunque es posible que desee omitir este paso en las siguientes circunstancias:
Las cuentas tienen poco valor inmediato. Puede bloquear estos casos posteriores al compromiso sin causar daños.
Desea mantener la máxima visibilidad del ataque evitando cualquier acción que alerte al atacante sobre la investigación y haga que cambie sus tácticas.
La aplicación de esta respuesta preliminar requiere que Remote Configuration esté habilitada para sus servicios.
Si desea iniciar una respuesta parcial, haga lo siguiente:
Es probable que los atacantes utilicen un pequeño número de IP. Para bloquearlos, abra la señal y utilice los Siguientes pasos. Puede establecer la duración del bloqueo.
Datadog recomienda 12h, lo cual es suficiente para que el ataque se detenga y evitar bloquear a usuarios legítimos cuando, después del ataque, esas IPs se reciclan para usuarios legítimos. Datadog no recomienda el bloqueo permanente. También puede bloquear a los usuarios comprometidos, aunque un mejor enfoque sería extraerlos y restablecer sus credenciales utilizando sus propios sistemas.
Por último, puede habilitar el bloqueo automático de IP desde la sección de Siguientes pasos para que las nuevas IP se bloqueen automáticamente mientras realiza su investigación.
Estos ataques suelen utilizar un gran número de IP desechables. Debido a la latencia de Datadog, es poco práctico bloquear los intentos de inicio de sesión bloqueando la IP antes de que el atacante la elimine de su grupo.
En su lugar, bloquee los rasgos de la solicitud que sean exclusivos del intento malicioso (un agente de usuario, un encabezado específico, una huella digital, etc.).
En una señal Distributed Credential Stuffing campaign, Datadog identifica automáticamente rasgos claros y los presenta como Attacker Attributes.
Antes de bloquear, Datadog recomienda que revise la actividad del clúster para confirmar que la actividad es realmente maliciosa.
Las preguntas que intenta responder son:
¿Es el tráfico malicioso? ¿Existía este tráfico antes del inicio del ataque?
¿Se puede capturar un volumen significativo de tráfico legítimo?
¿Puede ser efectivo el bloqueo basado en este clúster?
Para hacerlo, seleccione su clúster y haga clic en Explore clusters.
Aparece el explorador de Investigate y proporciona indicadores de tráfico del clúster: una gran parte del tráfico del ataque y una alta proporción de IPs marcadas por Threat Intelligence.
Esos son dos indicadores importantes:
% de Threat Intel
Distribución de tráfico
Haga clic en un indicador para ver más información sobre el tráfico del clúster.
En Cluster Activity, hay una visualización del volumen del tráfico general de APM que coincide con este clúster. Al compararlo con los datos de AAP, tenga cuidado con la escala, ya que los datos de APM pueden estar muestreados mientras que los de AAP no.
En el siguiente ejemplo, gran parte del tráfico proviene de antes del ataque. Esto significa que una actividad legítima coincide con este clúster en el tráfico normal y se bloquearía si usted tomara medidas. No necesita escalar ni hacer clic en Block All Attacking IPs en la señal.
En otro ejemplo, la actividad del clúster comenzó con el ataque. Esto significa que no debería haber daños colaterales y puede proceder a bloquear.
Después de confirmar que los rasgos coinciden con los atacantes, puede enviar una regla de WAF en la aplicación para bloquear las solicitudes que coincidan con esos rasgos. Esto es compatible solo para rasgos basados en el agente de usuario.
Haga clic en Create New Rule y complete la configuración.
Siga los pasos en Define your custom rule.
En Select the services you want this rule to apply to, seleccione su servicio de inicio de sesión o los servicios donde desea bloquear las solicitudes. También puede dirigir el bloqueo a la ruta de inicio de sesión.
En If incoming requests match these conditions, configure las condiciones de la regla.
Si desea bloquear un agente de usuario específico, péguelo en Values. En Operator, puede usar matches value in list, o, si desea más flexibilidad, también puede usar Matches RegEx.
Utilice la sección Preview matching traces como revisión final del impacto de la regla. Si no se muestran trazas inesperadas, seleccione un modo de bloqueo y guarde la regla.
Hay múltiples acciones de bloqueo disponibles. Dependiendo de la sofisticación de los atacantes, es posible que desee una respuesta más sigilosa para que no se den cuenta de inmediato de que fueron bloqueados.
Cuentas comprometidas por los atacantes para que pueda restablecer sus credenciales.
Pistas sobre la fuente de las cuentas atacadas, que puede usar para restablecimientos de contraseña proactivos o un mayor escrutinio.
Datos sobre la infraestructura del atacante, que puede usar para detectar intentos futuros u otra actividad maliciosa (relleno de tarjetas de crédito, abuso, etc.).
El primer paso es aislar la actividad del atacante del tráfico general de la aplicación.
Aislar la actividad del atacante
Mientras aísla la actividad del atacante, asegúrese de que sus filtros actuales sean exhaustivos mediante dos pruebas:
Vaya a Traces y luego excluya las trazas según los filtros que identifique. El objetivo es que el volumen de tráfico restante sea similar al volumen de tráfico normal. Si todavía observa un pico de inicios de sesión durante el ataque, significa que son necesarios más filtros para aislar el ataque de manera integral.
Observe el tráfico que coincide con sus filtros durante un período de tiempo extendido (por ejemplo, si el ataque duró una hora, use un día). Cualquier tráfico que coincida antes o después del ataque probablemente sea un falso positivo.
A continuación, comience aislando la actividad del ataque.
Extraiga la lista de usuarios atacados yendo a Signals.
Puede consultar las trazas de los usuarios atacados haciendo clic en el enlace login attempts en Security Traces.
Si desea acceso directo a los usuarios atacados, puede extraer la lista desde el panel lateral de señal.
A partir de esta lista de usuarios, puede crear una consulta de traza para revisar toda la actividad de los usuarios atacados. Siga esta plantilla:
Los inicios de sesión exitosos deben considerarse sospechosos.
Esta señal marcó mucha actividad proveniente de unas pocas IP y está estrechamente relacionada con su variante distribuida. Es posible que deba utilizar el método de relleno de credenciales distribuido si la señal omitió partes del ataque.
Puede consultar las trazas que coinciden con las IP atacantes haciendo clic en el enlace login attempts en Security Traces.
Si desea acceso directo a las IP atacantes, puede extraer la lista del panel lateral de señal.
A partir de la lista de IPs, puede crear una consulta de traza para revisar toda la actividad de las IP sospechosas. Siga esta plantilla:
Los inicios de sesión exitosos deben considerarse sospechosos.
Esta señal marcó un gran aumento en los errores de inicio de sesión en un servicio. Si el ataque es lo suficientemente grande, esta señal también podría activar las señales de Bruteforce o Credential Stuffing. La señal también es capaz de detectar ataques difusos de manera más integral.
En el caso de ataques difusos, los atributos del atacante están disponibles en la señal.
Después de abrir la señal en el panel lateral, haga clic en Investigate in full screen.
En Attacker Attributes, seleccione el clúster y haga clic en Filter this signal by selection. A continuación, en Traces, haga clic en View in AAP Traces Explorer.
Esto lo lleva al explorador de trazas con los filtros configurados en los atributos marcados. Puede comenzar la investigación con la consulta actual, pero debería ampliarla para que también coincida con los inicios de sesión exitosos además de los fallidos. Puede hacerlo reemplazando @appsec.security_activity:business_logic.users.login.failure con @appsec.security_activity:business_logic.users.login.*. Revise la exhaustividad y precisión del filtro usando la técnica descrita anteriormente.
En caso de que esos atributos sean inexactos o incompletos, puede intentar identificar otros rasgos para aislar la actividad del atacante. Volviendo a la señal de página completa y desplazándose hacia abajo hasta la Traces sección, encontrará un botón Analysis. Esto abre la opción de visualizar, donde el tráfico del ataque se segmenta por una gran variedad de atributos.
Los atributos más comunes se presentan en la parte superior de una tabla, pero puede visualizar su impacto desplazándose hacia abajo. Cada fila muestra la proporción de tráfico que coincide con este atributo y qué tan de cerca coincide este tráfico con la “forma” del aumento en el tráfico. Su objetivo es identificar los atributos que juntos aíslan este aumento en la actividad mientras excluyen el tráfico en estado estable. Tenga en cuenta la escala de los gráficos, ya que no todas las trazas pueden estar etiquetadas con cada atributo (por ejemplo, Inteligencia de amenazas). Además, tenga en cuenta que algunos campos no se pueden usar para bloquear (Inteligencia de amenazas, ASNs y geolocalización de IP).
Tras identificar los atributos, selecciónelos de la lista y verifique su exhaustividad activando y desactivando el botón Filtering enabled. Una vez que esté satisfecho, haga clic en View Traces para profundizar en los usuarios afectados.
Revisar inicios de sesión exitosos y fallidos
Revisar los inicios de sesión exitosos y fallidos ayuda a identificar lo siguiente:
Qué buscan los atacantes para que pueda bloquearlos.
Qué están haciendo los atacantes para que pueda capturarlos, incluso si cambian sus scripts.
Qué tan exitosos son los atacantes para que pueda recuperar las cuentas de las que tomaron control y ver cuánto tiempo tiene para reaccionar.
Cuando la actividad del atacante esté aislada, revise los inicios de sesión exitosos y considere las siguientes preguntas:
¿Se ha comprometido alguna cuenta?
¿Están los atacantes haciendo algo con sus cuentas comprometidas o las están dejando inactivas?
¿Son las cuentas accedidas posteriormente por una infraestructura diferente?
¿Existe alguna actividad pasada de esta infraestructura?
Para los errores de inicio de sesión, considere las siguientes preguntas:
¿Están los atacantes apuntando a un subconjunto específico de usuarios?
¿Qué tan exitosos son? La precisión de los ataques debería estar en el rango de 1/100-1/1000.
¿Están superando los captchas o la autenticación multifactor?
A medida que avanza su investigación, puede ir y venir entre este paso y el siguiente a medida que esté listo para aplicar una respuesta basada en sus hallazgos.
Paso 3.4: Respuesta
Las capacidades de investigación de Datadog se enriquecen con datos de su backend, los cuales no están disponibles para la biblioteca que ejecuta la respuesta. Debido a eso, no todos los campos son compatibles con la aplicación de una respuesta.
Los atacantes motivados intentan eludir su respuesta tan pronto como se dan cuenta de ella. En previsión de este enfoque, haga lo siguiente:
Asegúrese de no perder visibilidad sobre el ataque.
Haga que el bloqueo sea lo más difícil posible de identificar por parte del atacante. Por ejemplo, haga que la respuesta de bloqueo sea la misma que la de su error de inicio de sesión. Esto puede confundir a los atacantes y hacerles creer que su ataque sigue siendo exitoso.
Haga que el bloqueo sea lo más difícil posible de eludir por parte del atacante. Utilice rasgos sutiles, como valores de encabezado específicos, en lugar de direcciones IP.
Puede utilizar las capacidades de bloqueo integradas de Datadog para denegar cualquier solicitud que cumpla con ciertos criterios, o exportar los datos automáticamente a uno de sus sistemas para realizar una respuesta (restablecimiento de credenciales, simulación de errores de inicio de sesión al bloquear, etc.).
Bloqueo de Datadog
Los usuarios que forman parte del tráfico bloqueado por Datadog ven una página You’re blocked, o reciben un código de estado personalizado, como una redirección. El bloqueo se puede aplicar a través de dos mecanismos, cada uno con diferentes características de rendimiento: la Lista de denegación y las reglas personalizadas de WAF.
Lista de denegación
La Lista de denegación es una forma eficiente de bloquear una gran cantidad de entradas, pero está limitada a direcciones IP y usuarios. Si su investigación descubrió un pequeño conjunto de direcciones IP responsables del ataque (<1000), bloquear estas direcciones IP es el mejor curso de acción.
La Lista de denegación se puede administrar y automatizar utilizando la plataforma de Datadog haciendo clic en Automate Attacker Blocking en la señal.
Utilice las opciones de señal Automate Attacker Blocking o Block All Attacking IPs para bloquear todas las direcciones IP atacantes durante unas horas, una semana o de forma permanente. De manera similar, puede bloquear a los usuarios comprometidos. Como recordatorio, Datadog no recomienda bloquear direcciones IP de forma permanente debido a los riesgos de bloquear tráfico legítimo después de que las direcciones IP se reciclen en grupos públicos.
Si la señal no fue precisa, puede extraer la lista, los usuarios o las direcciones IP y agregarlos a la lista de denegación manualmente.
Reglas de WAF en la aplicación
Si la lista de denegación no es suficiente, puede crear una regla de WAF. Una regla de WAF se evalúa más lentamente que la lista de denegación, pero es más flexible.
Haga clic en Create New Rule y complete la configuración.
Siga los pasos en Define your custom rule.
En Select the services you want this rule to apply to, seleccione su servicio de inicio de sesión o los servicios en los que desee bloquear las solicitudes. También puede dirigir el bloqueo a la ruta de inicio de sesión.
En If incoming requests match these conditions, configure las condiciones de la regla.
Si desea bloquear un agente de usuario específico, puede pegarlo en Values. En Operator, puede usar matches value in list, o si desea más flexibilidad, también puede usar una Matches RegEx.
Utilice la sección Preview matching traces como revisión final del impacto de la regla. Si no se muestran trazas inesperadas, seleccione un modo de bloqueo y guarde la regla.
La respuesta se envía automáticamente a los rastreadores y los rastreos bloqueados aparecen en el Traces explorer.
Hay múltiples acciones de bloqueo disponibles. Dependiendo de la sofisticación de los atacantes, es posible que desee una respuesta más sigilosa para que los atacantes no se den cuenta de inmediato de que fueron bloqueados.
Puede configurar una señal para enviar cualquier ID de usuario mediante un webhook. Este método se puede utilizar para enviar usuarios comprometidos a sus sistemas y restablecer sus credenciales o restringirlos. El objetivo es hacer que esas cuentas sean inútiles para el atacante.
No todas las reglas son compatibles con esta función. De las reglas predeterminadas, las reglas compatibles son:
Campaña distribuida de relleno de credenciales (huella digital del atacante)
Ataque de fuerza bruta
Ataque de Credential Stuffing
Para configurar una señal para enviar un ID de usuario mediante un webhook, haga lo siguiente:
Vaya a la configuración de notificaciones en una condición de regla de detección.
Agregue un destinatario y active Notify para cada @usr.id nuevo detectado. Esto le permite exportar la lista cuando ocurren actualizaciones.
Los destinos de notificación establecidos en la condición de la regla de detección reciben un mensaje cuando se detectan nuevos ID de usuario. Los perfiles de notificación que monitorean estas señales no reciben alertas por nuevos ID de usuario.
Para recibir ID de usuario específicos y comprometidos con un webhook, configure un webhook utilizando la integración de webhook de Datadog. Incluya la variable $SECURITY_SIGNAL_ATTRIBUTES en la carga útil del webhook. Los ID de usuario se almacenan bajo la ruta @usr.id en la carga útil JSON.
Al hacer el parseo de la carga útil, puede actuar sobre los ID en sus propios sistemas.
Importante: La lista solo contiene los ID detectados desde la última notificación. Los ID no se desduplican si vuelven a iniciar sesión.
Paso 3.5: Hacer un seguimiento de
Después de que el atacante introduce la respuesta, podría suspender o adaptar su ataque. Siga haciendo un seguimiento de la tasa de intentos de inicio de sesión después de introducir la respuesta, especialmente los fallidos. Los ataques podrían disminuir solo para reanudarse después de unos minutos, horas o días.
Si se reanuda un ataque a gran escala, la señal de Distributed Credential Stuffing debería volver a ejecutarse. En este caso, revise las siguientes consideraciones:
Los atacantes persistentes a menudo requieren múltiples iteraciones de medidas defensivas antes de rendirse.
La defensa ideal es una estrategia de bloqueo robusta que el atacante no pueda eludir.
Los atacantes intentan evadir la detección con frecuencia alterando las IP y los agentes de usuario. Es menos probable que modifiquen profundamente el script que obtuvieron para enviar sus intentos de inicio de sesión, por lo que los encabezados son un objetivo más resistente.
Las estrategias efectivas incluyen métodos basados en huellas digitales o de correlación que identifican combinaciones de encabezados poco comunes.
Haga un seguimiento del tráfico bloqueado resultante de respuestas defensivas anteriores.
Bloquear el tráfico del atacante puede bloquear inadvertidamente el tráfico legítimo. Implemente mecanismos para desbloquear el tráfico legítimo, ya sea adaptando la respuesta de Datadog o asegurándose de que se desbloquee después del ataque.
Paso 3.6: Limpieza
Después de unos días sin actividad significativa del atacante, puede considerar que el ataque terminó y pasar a una fase de limpieza.
Los objetivos de la fase de limpieza son los siguientes:
Deshabilite cualquier mitigación que se haya agregado.
Asegúrese de que no se bloquee tráfico legítimo.
Identifique oportunidades para fortalecer los servicios contra futuros ataques.
Identifique la fuente de los datos que el atacante utilizó contra los usuarios.
Deshabilitar mitigaciones
El bloqueo de usuario debe basarse en el temporizador que configuró cuando seleccionó Block All Attacking IPs en la señal. Esta configuración de bloqueo de usuario no requiere ninguna acción adicional.
Si configuró el bloqueo permanente, desbloquee a los usuarios y las IPs de la lista de denegados haciendo lo siguiente:
En la lista de entidades, localice la IP o el usuario y, a continuación, haga clic en Unblock.
Deshabilite o elimine cualquier regla personalizada de WAF en la aplicación
Para deshabilitar o eliminar reglas de WAF en la aplicación, vaya a la página de reglas de WAF en la aplicación personalizadas y deshabilite las reglas haciendo clic en Monitoring o Blocking y seleccionando Disable Rule.
Si la regla ya no es relevante, puede eliminarla haciendo clic en más opciones (…) y seleccionando Delete.
Valide que no se bloquee tráfico legítimo
Para validar que no se bloquee tráfico legítimo, el volumen de tráfico debe coincidir estrechamente con el del ataque, sin prácticamente trazas bloqueadas fuera de las oleadas principales.
Para validar que no se bloquee tráfico legítimo, haga lo siguiente:
Vaya a Traces y busque las trazas bloqueadas con la búsqueda @appsec.blocked:true.
Si observa un tráfico significativo bloqueado de forma continua, es probable que se trate de usuarios legítimos.
Deshabilite la regla de bloqueo incorrecta para evitar bloquear a más usuarios.
Priorice el desbloqueo de ese tráfico desde el Denylist.
Fortalecimiento de sus servicios
Las campañas grandes de ATO rara vez son un evento aislado. Es posible que desee aprovechar el tiempo entre ataques para fortalecer sus servicios y establecer configuraciones que pueda utilizar durante ataques posteriores.
Aquí hay algunos ejemplos comunes de fortalecimiento:
Limite la tasa de intentos de inicio de sesión por IP/usuario/rango de red/agente de usuario: Esta función de bloqueo suave le permite reducir agresivamente la escala del ataque en algunas circunstancias con un impacto mínimo en los usuarios normales, incluso si comparten rasgos con el atacante.
Añadir fricción al inicio de sesión: Para romper la automatización de los atacantes sin afectar significativamente a los usuarios, utilice captchas o modifique el flujo de inicio de sesión durante un ataque (por ejemplo, requiera que se obtenga un token desde un nuevo punto de conexión).
Aplique la autenticación de múltiples factores (MFA): Datadog descubrió que la MFA es extremadamente eficaz para detener el compromiso de cuentas. Podría requerir que sus usuarios con mayores privilegios utilicen MFA, especialmente durante los ataques.
Limitar acciones sensibles para los usuarios: Si sus servicios permiten a los usuarios realizar acciones sensibles (gastar dinero, acceder a información sensible, cambiar información de contacto, etc.), es posible que desee prohibir a los usuarios de alto riesgo con inicios de sesión sospechosos hasta que sean revisados manualmente o mediante autenticación de múltiples factores. Los inicios de sesión sospechosos pueden ser enviados programáticamente a sus sistemas por Datadog a través de un webhook.
Capacidad para consumir hallazgos de señales programáticamente: Cree un punto de conexión para consumir webhooks de Datadog y tomar medidas automáticamente contra usuarios/IPs/rasgos sospechosos.
Identificación de la fuente de datos del atacante
Los atacantes adquieren listas de cuentas comprometidas de forma masiva. Al identificar la fuente de su base de datos, puede identificar proactivamente a los usuarios en riesgo.
Para identificar la fuente de su base de datos, exporte a los usuarios afectados por el ataque utilizando una de estas opciones:
En los detalles de la señal, en Targeted users, haga clic en Export to CSV. Esta opción exporta hasta 10k usuarios.
Si necesita exportar más de 10k usuarios, pagine su consulta manualmente realizando API calls. El explorador de Traces realiza llamadas similares, por lo que puede basar sus solicitudes en la llamada que está realizando al agrupar por @appsec.events_data.usr.login. Establezca el límite en 10000 y utilice rangos de tiempo más pequeños para evitar el límite del backend.
Cuando tenga una lista, revísela en busca de atributos comunes:
Si todos los usuarios provienen de una región o un cliente.
Una gran mayoría de usuarios comparte algún compromiso conocido (utilice la API de Have I Been Pwned).
Cuando se identifique la fuente de la base de datos, fuerce proactivamente un restablecimiento de contraseña de esos clientes o márquelos como de mayor riesgo. Esto aumenta la confianza de que los futuros inicios de sesión sospechosos fueron realmente comprometidos.
Revise la actividad adicional del atacante
Aprovechando la firma del atacante, amplíe los filtros para observar qué actividad que no sea de inicio de sesión realizaron.
Este filtro puede ser menos preciso. Por ejemplo, un filtro que coincide con la firma de una aplicación móvil con tráfico legítimo, pero que fue clonada por el atacante para su ataque. El filtro podría mostrar la investigación realizada por el atacante con antelación y compartir pistas sobre lo que el atacante podría intentar hacer a continuación.
También puede pivotar sobre la infraestructura utilizada por el atacante. ¿Esas IP maliciosas hicieron algo más que inicios de sesión? ¿Están accediendo a otras APIs sensibles?
Conclusión
El robo de cuentas es una amenaza común, pero también mucho más compleja que los vulnerabilidades por inyección tradicionales. Detectarlos requiere una integración estrecha con sus sistemas e implica suficiente incertidumbre como para que las respuestas automatizadas no sean posibles para los ataques más avanzados.
En esta guía, hizo lo siguiente:
Aprendió cómo pueden presentarse las campañas de apropiación de cuentas, cómo clasificarlas y cómo contrarrestarlas.
Instrumentó sus servicios de inicio de sesión para proporcionar a Datadog AAP todo el contexto que necesita.
Configuró sus servicios de inicio de sesión para proporcionar todas las capacidades en el momento del ataque.
Esta es una orientación general. Dependiendo de sus aplicaciones y entornos, podría haber una necesidad de estrategias de respuesta adicionales.
1
2
rulesets:- %!s(<nil>) # Rules to enforce .
Solicite una demostración personalizada
Comience con Datadog
Ask AI
AI-generated responses may be inaccurate. Verify important info.
