Resolución de nombres de red en Microsoft Defender for Identity

La resolución de nombres de red (NNR) es un componente principal de la funcionalidad de Microsoft Defender for Identity. Defender for Identity captura actividades basadas en el tráfico de red, eventos de Windows y ETW: estas actividades normalmente contienen datos IP.

Con NNR, Defender for Identity puede correlacionar entre actividades sin procesar (que contienen direcciones IP) y los equipos pertinentes implicados en cada actividad. En función de las actividades sin procesar, las entidades de perfiles de Defender for Identity, incluidos los equipos, generan alertas de seguridad para actividades sospechosas.

Para resolver direcciones IP a nombres de equipo, los sensores de Defender for Identity buscan las direcciones IP mediante los métodos siguientes:

Métodos principales:

  • NTLM a través de RPC (puerto TCP 135)
  • NetBIOS (puerto UDP 137)
  • RDP (puerto TCP 3389): solo el primer paquete de Bienvenida al cliente

Método secundario:

  • Consulta el servidor DNS mediante la búsqueda inversa de DNS de la dirección IP (UDP 53)

Para obtener mejores resultados, se recomienda usar al menos uno de los métodos principales. La búsqueda inversa de DNS de la dirección IP solo se realiza cuando:

  • No hay respuesta de ninguno de los métodos principales.
  • Hay un conflicto en la respuesta recibida de dos o más métodos principales.

Nota:

No se realizan autenticaciones en ninguno de los puertos.

Defender for Identity evalúa y determina el sistema operativo del dispositivo en función del tráfico de red. Después de recuperar el nombre del equipo, el sensor de Defender for Identity comprueba Active Directory y usa huellas digitales TCP para ver si hay un objeto de equipo correlacionado con el mismo nombre de equipo. El uso de huellas digitales TCP ayuda a identificar dispositivos no registrados que no sean de Windows, lo que facilita su proceso de investigación. Cuando el sensor de Defender for Identity encuentra la correlación, el sensor asocia la dirección IP al objeto del equipo.

En los casos en los que no se recupera ningún nombre, se crea un perfil de equipo sin resolver por IP con la dirección IP y la actividad detectada pertinente.

Los datos de NNR son cruciales para detectar las siguientes amenazas:

  • Sospecha de robo de identidad (pass-the-ticket)
  • Sospecha de ataque DCSync (replicación de servicios de directorio)
  • Reconocimiento de asignación de red (DNS)

Para mejorar la capacidad de determinar si una alerta es un verdadero positivo (TP) o un falso positivo (FP), Defender for Identity incluye el grado de certeza de la resolución de nombres de equipo en la evidencia de cada alerta de seguridad.

Por ejemplo, cuando los nombres de equipo se resuelven con alta certeza, aumenta la confianza en la alerta de seguridad resultante como verdadero positivo o TP.

La evidencia incluye el tiempo, la dirección IP y el nombre del equipo en el que se resolvió la dirección IP. Cuando la seguridad de la resolución es baja, use esta información para investigar y comprobar qué dispositivo era el origen verdadero de la dirección IP en este momento. Después de confirmar el dispositivo, puede determinar si la alerta es un falso positivo o FP, similar a los ejemplos siguientes:

  • Sospecha de robo de identidad (pass-the-ticket): la alerta se desencadenó para el mismo equipo.

  • Sospecha de ataque DCSync (replicación de servicios de directorio): la alerta se desencadenó desde un controlador de dominio.

  • Reconocimiento de asignación de red (DNS): la alerta se desencadenó desde un servidor DNS.

    Evidencia de certeza.

Recomendaciones para la configuración

  • NTLM sobre RPC:

    • Compruebe que el puerto TCP 135 está abierto para la comunicación entrante desde los sensores de Defender for Identity, en todos los equipos del entorno.
    • Compruebe toda la configuración de red (servidores de seguridad), ya que esto puede impedir la comunicación con los puertos pertinentes.
  • NetBIOS:

    • Compruebe que el puerto UDP 137 está abierto para la comunicación entrante desde los sensores de Defender for Identity, en todos los equipos del entorno.
    • Compruebe toda la configuración de red (servidores de seguridad), ya que esto puede impedir la comunicación con los puertos pertinentes.
  • RDP:

    • Compruebe que el puerto TCP 3389 está abierto para la comunicación entrante desde los sensores de Defender for Identity, en todos los equipos del entorno.
    • Compruebe toda la configuración de red (servidores de seguridad), ya que esto puede impedir la comunicación con los puertos pertinentes.

    Nota:

    • Solo se requiere uno de estos protocolos, pero se recomienda usar todos ellos.
    • No se admiten puertos RDP personalizados.
  • DNS inversos:

    • Compruebe que el sensor puede acceder al servidor DNS y que las zonas de búsqueda inversa están habilitadas.

Problemas de mantenimiento

Para asegurarse de que Defender for Identity funcione bien y el entorno esté configurado correctamente, Defender for Identity comprueba el estado de resolución de cada sensor y emite una alerta de mantenimiento por método, proporcionando una lista de los sensores de Defender for Identity con una tasa de éxito baja de resolución de nombres activa mediante cada método.

Nota:

Para deshabilitar un método NNR opcional en Defender for Identity que no se adapta a las necesidades de su entorno, abra un caso de soporte técnico.

Cada alerta de mantenimiento proporciona detalles específicos del método, los sensores, la directiva problemática y las recomendaciones de configuración. Para obtener más información sobre problemas de mantenimiento, consulte Problemas de mantenimiento del sensor de Microsoft Defender for Identity.

Consulte también