Hoy, Huntress Managed SIEM's Brute Force Sentry está disponible para todos los clientes de Managed SIEM. Convierte los ataques de fuerza bruta que nuestro SOC ve en el campo en detecciones que se activan antes, con la evidencia y las guías de hardening que necesitas para cerrar la brecha. Brute Force Sentry vigila tus superficies de inicio de sesión expuestas a internet, incluyendo RDP, RD Gateway y el portal RDWeb en Windows, y SSH en Linux. Cuando una serie de inicios de sesión fallidos termina en uno exitoso, el SOC de Huntress investiga.
Todo inicio de sesión expuesto recibe intentos, y la mayoría de esos intentos son bots que prueban "administrator" en un gateway que alguien configuró hace años. El problema es que uno de esos miles de intentos termina en un inicio de sesión exitoso, y una regla de umbral genérica lo trata igual que al resto.
Brute Force Sentry está diseñado para encontrar justamente ese caso.
RDP sigue siendo una puerta de entrada que usan los atacantes
La investigación de Huntress vincula RDP con el 10–20 % de cómo los atacantes avanzados logran entrar en las redes. Muchas organizaciones no se dan cuenta de que su portal RDWeb o su RD Gateway son accesibles desde internet hasta que alguien empieza a probar nombres de usuario en ellos.
RDWeb y RD Gateway se comportan de forma muy similar a un portal de SSL VPN. La autenticación ocurre en el portal web, antes de que el usuario llegue siquiera a un endpoint, así que ese portal es donde se alinean los atacantes.
La mayoría de los SIEM manejan la fuerza bruta con una sola regla de umbral, algo como "X inicios de sesión fallidos en Y minutos". Si la configuras baja, tu equipo se ahoga en alertas de bots que nunca logran entrar. Si la configuras alta, un ataque lento distribuido entre docenas de cuentas pasa justo por debajo de ella. En ambos casos, la regla no puede responder la pregunta que realmente importa: ¿funcionó alguno de esos intentos?
Cómo funciona Brute Force Sentry
Brute Force Sentry lee la telemetría de autenticación que tu Managed SIEM ya recopila en las tres plataformas: eventos de seguridad de Windows (4624, 4625, 4740, 4776) y el registro de conexión propio de RD Gateway, sshd de Linux y macOS, y separa la "fuerza bruta" en las técnicas distintas que realmente son:
Fuerza bruta tradicional: una sola fuente que adivina contra unas pocas cuentas hasta que algo funciona
Fuerza bruta distribuida: muchas fuentes que atacan la misma cuenta, cada una lo bastante silenciosa por sí sola para parecer normal
Spraying: una lista corta de credenciales comunes probadas en muchas cuentas
Credential stuffing: pares de nombre de usuario y contraseña de filtraciones anteriores, probados para ver cuáles todavía funcionan
Enumeración de nombres de usuario: intentos repetidos contra cuentas que no existen, para detectar nombres válidos antes de que empiece la adivinación
Lee cada plataforma en su propio idioma. Windows distribuye una sola autenticación entre varios ID de evento, con el motivo del fallo escondido en un código de estado, y a veces la verificación de credenciales ocurre en un controlador de dominio en lugar de en el equipo atacado. Linux escribe una sola línea de sshd que ya distingue una contraseña incorrecta de un intento contra una cuenta que nunca existió. En lugar de reducir ambos casos a un mínimo común denominador, los normalizamos en un solo registro de autenticación que conserva lo que cada plataforma sabe, de modo que la lógica de detección es idéntica en todas partes y nada se pierde en la traducción.
Está ajustado por superficie, no de una sola vez. Cada una tiene su propia detección de correlación específica en lugar de una regla única y ruidosa. Nuestros investigadores ajustaron cada detección por superficie de inicio de sesión usando datos históricos de los socios, y luego la validaron contra ataques simulados del mundo real en el laboratorio antes de que llegara al SOC.
Correlaciona entre proveedores. Los inicios de sesión fallidos y el éxito que viene después a menudo quedan registrados por dos sistemas distintos en el mismo equipo. Brute Force Sentry normaliza ambos en una sola superficie de autenticación, de modo que una única detección puede seguir el ataque desde el primer fallo hasta el inicio de sesión exitoso.
Se activa solo y te avisa cuando no puede hacerlo. Brute Force Sentry se activa por organización en cuanto fluye la telemetría que necesita. Si falta esa telemetría, se muestra como no disponible junto con el motivo, así que un panel silencioso significa que Huntress revisó y no encontró nada.
Las cuentas que persiguen no son las que estás vigilando
En los casos de compromiso que Huntress ha trabajado, las cuentas afectadas no siempre eran de administradores de dominio. Eran las que nadie reclama: inicios de sesión compartidos creados para un dispositivo, una recepción o una integración puntual, con una contraseña que nadie ha cambiado desde entonces y una excepción de MFA que nadie recuerda haber otorgado. No aparecen en una revisión de cuentas privilegiadas y no le pertenecen a nadie que notaría su uso. Por eso los atacantes van a por ellas primero, y el patrón se repite sin importar la puerta por la que entren: un escritorio o gateway de Windows, un servidor Linux o una Mac que comparte su pantalla.
Brute Force Sentry muestra los nombres de usuario que se están probando, no solo cuántas veces. Eso incluye los que no existen. Una serie de fallos contra cuentas que nunca fueron reales es enumeración de nombres de usuario: alguien trabajando con una lista, aprendiendo tu convención de nombres antes de empezar a adivinar contraseñas en serio. Detectar eso te dice que un ataque se está preparando, no que ya está en marcha. Y ver a qué cuentas reales vuelve un atacante una y otra vez te dice qué credenciales cambiar esta noche, no el próximo trimestre.
Alrededor de 1.700 intentos en 72 segundos
En junio de 2026, el SOC de Huntress manejó un caso de compromiso en una organización que usaba Remote Desktop Gateway. El atacante atacó ocho cuentas con entre 212 y 215 inicios de sesión fallidos cada una, alrededor de 1.700 intentos en 72 segundos, y luego logró entrar.
Cada uno de esos fallos estaba registrado en los registros de eventos del equipo que ejecutaba el gateway. El inicio de sesión exitoso que vino justo después fue registrado por RD Gateway, un proveedor distinto en el mismo equipo. Conectar ambos requería una detección que todavía no existía, y Brute Force Sentry se construyó justamente para hacer esa conexión.
Para ver con qué frecuencia aparece este patrón, revisamos 30 casos confirmados de compromiso de RDWeb/RDG durante las primeras cuatro semanas de pruebas. En 20 de ellos, la señal de Brute Force Sentry habría llegado al SOC hasta una hora antes. Esa es una hora entre el primer intento del atacante y su primer movimiento dentro de la red, y es una hora que nuestros analistas pueden usar para contener la cuenta.
Un atacante que entra por tu gateway sigue avanzando, así que mientras antes veas el inicio de sesión, menos parte de la red habrá tocado.
Lo que verás en el portal
La mayoría de la actividad de fuerza bruta nunca tiene éxito, y hasta ahora los partners no veían nada de eso. Brute Force Sentry lo muestra en tiempo real, para que puedas actuar en tus propios términos antes de que algo logre entrar:
Superficies expuestas: qué superficies de inicio de sesión expuestas a internet están bajo ataque, incluidas algunas que quizás no sabías que eran accesibles
Cuentas objetivo: las cuentas a las que los atacantes vuelven una y otra vez
Orígenes: de dónde vienen los intentos, y qué orígenes siguen regresando
Compromisos: inicios de sesión exitosos que siguieron a una serie de fallos, cada uno vinculado a su reporte de incidente
Recibes una notificación cuando hay un compromiso, y puedes optar por recibir notificaciones de cada intento, exitoso o no.
Figura 1: Panel de Brute Force Sentry
Menos ruido para ti, más pruebas para tus clientes
Si eres un MSP, probablemente ya le dijiste a un cliente que su RD Gateway necesita MFA o debería estar detrás de una VPN. Brute Force Sentry te da sus propios datos para respaldar ese argumento, empezando por si el portal debería estar expuesto o no: qué cuentas fueron atacadas la semana pasada, cuántos intentos hubo y de dónde vinieron. Combina eso con la guía de refuerzo en cada hallazgo, y la conversación pasa de "deberíamos" a "esto fue lo que pasó".
Los equipos de TI internos obtienen el mismo beneficio. No necesitas convertirte en especialista en registros de eventos de Windows para saber si una ráfaga de 4625 era ruido de fondo o el inicio de una intrusión, porque el SOC de Huntress ya está revisando los que importan.
Construido a partir de los ataques que trabaja nuestro SOC
Brute Force Sentry comenzó con un incidente real y un vacío que nuestros analistas pudieron identificar. Así es como queremos que Managed SIEM siga creciendo: tomar los ataques que nuestro SOC ve en los entornos de los socios y convertirlos en detecciones que se activan antes, con la evidencia incluida.
A cada inicio de sesión expuesto le tocan la puerta. Ahora sabrás a cuál le respondieron.
¿Ya tienes Huntress Managed SIEM? Está incluido para todos los clientes de Managed SIEM y se activa automáticamente en cuanto fluye tu telemetría de autenticación de Windows. ¿Eres nuevo en Managed SIEM? Reserva una demo para ver Brute Force Sentry y al SOC de Huntress en acción.
