Bastaron cinco minutos para convertir a un usuario estándar en administrador global

Pasamos tres meses evaluando cómo se comprometen realmente los entornos de Microsoft 365. Lo que encontramos debería cambiar tu forma de pensar sobre el endurecimiento de la seguridad de identidad.

Frente a una audiencia en vivo durante nuestro evento de lanzamiento, el gerente principal de producto de Huntress, Scott Riley, creó un usuario ficticio de Microsoft 365 al que llamó "Standard Steve": una cuenta regular sin acceso de administrador, que representa el tipo de credencial que un atacante obtiene en una campaña de phishing. Luego se sentó con esa cuenta, un asistente de IA y un cronómetro. Cinco minutos y medio después, Standard Steve era administrador global.

Scott no usó exploits novedosos ni herramientas sofisticadas. Encontró una cuenta de servicio que era dueña de una aplicación empresarial con permisos excesivos, creó una credencial para ella, le pidió a un modelo de IA en lenguaje sencillo que escribiera un script para escalar sus privilegios, y lo ejecutó. Eso fue todo.

Probablemente había siete controles distintos que podrían haber ayudado en diferentes etapas a detener o frenar el ataque. Ninguno estaba implementado.

Lo aterrador no es que un atacante hábil pueda hacer esto. Es que Scott no es un atacante hábil. Es solo un tipo que sabe que los atacantes se adelantan aprovechando brechas básicas que quedan abiertas. 

Lo que encontramos en 12.000 inquilinos de Microsoft

Esa demostración no ocurrió en el vacío. Fue una ilustración que construimos para que un dato se sintiera real.

El año pasado, los ataques basados en identidad representaron el 79% de todos los incidentes críticos y de alta gravedad a los que respondió Huntress. La mayoría se originó en las mismas brechas evitables que Standard Steve tenía completamente abiertas.

Durante los últimos tres meses, Huntress ejecutó un programa de Early Access para Managed Identity Security Posture Management (ISPM), implementándolo en más de 12.000 inquilinos de Microsoft 365. Los datos que recopilamos fueron consistentes y preocupantes.

Más del 60% de esos inquilinos carecía de al menos la mitad de los controles de seguridad recomendados por Huntress. Y no se trata solo de organizaciones nuevas en herramientas de seguridad. Esto incluye entornos donde ya había herramientas de la postura de seguridad de identidad implementadas y en funcionamiento.

Las brechas específicas que encontramos con más frecuencia:

• El 66% no tenía configuraciones de MFA recomendadas implementadas

• El 55% permitía que usuarios estándar realizaran funciones de nivel administrativo

• El 59% tenía cuentas de administrador con restricciones insuficientes

Son brechas de seguridad como estas las que le permitieron a Scott escalar a Standard Steve a administrador global en cinco minutos. 

Por qué esto sigue pasando

Esta es la parte que los datos no explican de inmediato: los profesionales que administran estos entornos saben qué hacer. Entienden la necesidad de la MFA. Saben que las cuentas con privilegios excesivos son un problema. No están ignorando el riesgo.

Durante nuestro evento de lanzamiento, reunimos a operadores de MSP y líderes internos de TI para hablar con franqueza sobre por qué persiste la brecha entre saber y hacer. Tres personas distintas describieron los mismos patrones.

El miedo al impacto en los usuarios impide que los controles entren en vigor. Implementar una política de acceso condicional implica que alguien podría quedar bloqueado, los flujos de trabajo podrían romperse, o la mesa de ayuda podría saturarse. La opción más segura parece ser esperar hasta tener más tiempo para evaluar el impacto. Así que la política queda en borrador.

Las excepciones se acumulan y nunca se depuran. Un técnico desactiva MFA para un usuario para cerrar un ticket. El ticket se cierra. El siguiente ticket ya está abierto. La excepción permanece. 

La desviación de configuración ocurre constantemente y pasa desapercibida durante días. Microsoft cambia valores predeterminados. Los niveles de licenciamiento cambian. Un administrador hace un cambio. Un proveedor impone una excepción. Cualquiera de estas situaciones puede reabrir silenciosamente una brecha, y sin una aplicación continua, nadie se da cuenta hasta días o semanas después.

Las empresas heredan un nuevo inquilino a través de fusiones y adquisiciones, lo que lleva a que los MSP hereden una postura desconocida en cada cliente nuevo. Cuando te haces cargo de un entorno que dejó otro proveedor, o incorporas una empresa que nunca tuvo TI administrada, partes de cualquier estado en que hayan quedado las cosas. Si eso significa un puntaje de seguridad en los 40, ahora asumes ese riesgo desde el primer día.

Todo esto se va acumulando. Microsoft 365 abarca múltiples portales, docenas de categorías de configuración y cientos de controles individuales. Mantenerse al día con lo que significa "bueno" a medida que evolucionan la plataforma, los marcos de cumplimiento y el panorama de amenazas es un trabajo en sí mismo. La mayoría de los equipos que hacen esto también gestionan endpoints, atienden tickets, dan soporte a usuarios y lidian con impresoras.

Al final, el problema no es la apatía. Es que el endurecimiento de la seguridad es genuinamente difícil de hacer de forma continua y a gran escala con tiempo y experiencia limitados.

Por qué la desviación de configuración es un problema de exposición, no solo de mantenimiento

La mayoría de los equipos piensa en la desviación de configuración como algo que degrada la postura con el tiempo. Eso es cierto, pero subestima el riesgo real.

Según Microsoft, el tiempo promedio desde la intrusión inicial hasta el movimiento lateral es de 48 minutos. Cuando una configuración se desvía, la ventana para que un atacante la explote no se mide en días. Se mide en el tiempo entre cuando tú te das cuenta y cuando ellos actúan.

Las herramientas que vuelven a escanear en ciclos de 24 horas (y luego te hacen hacer el trabajo de corregir la desviación) no protegen contra esa ventana. La documentan después de los hechos.

Cuando detectamos una desviación en Managed ISPM, la identificamos y corregimos en minutos. Esa diferencia—15 minutos frente a 24 horas—es la distancia entre que un atacante encuentre una puerta cerrada y que encuentre una abierta.

Qué hace diferente Managed ISPM

La promesa central de Managed ISPM es simple: encontramos las brechas de identidad en tu entorno de Microsoft 365, las corregimos y las mantenemos corregidas. 

Lo que distingue esto de otras herramientas en este espacio es dónde realmente recae el trabajo. La mayoría de las herramientas de postura te muestran qué está mal y devuelven la corrección a tu equipo. Es un producto razonable. Pero no resuelve el problema de capacidad y experiencia. Alguien todavía tiene que definir qué significa "bueno", priorizar qué corregir primero, gestionar el impacto en los usuarios y mantenerse al tanto de la desviación. 

Managed ISPM es diferente porque nosotros asumimos el marco de endurecimiento de la seguridad, y el trabajo que viene después. Huntress define la línea base de mejores prácticas para la seguridad de identidades de Microsoft 365, la mantiene actualizada a medida que Microsoft cambia y las tácticas de los atacantes evolucionan, y la implementa y aplica por ti. No necesitas ser un experto en identidades de Microsoft para administrar un entorno endurecido.

Una captura de pantalla de la consola de Huntress Managed ISPM

También hemos creado funciones clave que resuelven algunos de los mayores desafíos de endurecimiento de la seguridad que vemos enfrentar a los equipos:

Learning Mode. Elimina el riesgo de las implementaciones de acceso condicional con un período temporal de solo informe. Huntress revisa diariamente los datos de impacto de cada política en Learning Mode y muestra con claridad qué posibles impactos en los usuarios deben resolverse antes de activar la aplicación. El resultado es una aplicación más segura, decisiones más rápidas y la confianza para implementar los controles que la mayoría de los equipos suelen posponer. 

Implementaciones administradas. Los equipos obtienen un punto de partida práctico y una ruta automatizada hacia la implementación. Huntress agrupa las políticas en oleadas de implementaciones guiadas y las ordena según su importancia e impacto en los usuarios, para que nunca pierdas tiempo decidiendo qué implementar y cuándo. Obtendrás un endurecimiento de la seguridad estructurado que hace avanzar tu seguridad, mientras mantenemos el marco de referencia actualizado a medida que cambian el comportamiento de los atacantes y las capacidades de Microsoft. 

Un ciclo de retroalimentación continuo para la resiliencia de la identidad. Cuando nuestro SOC detecta una amenaza de identidad activa mediante Managed Identity Threat Detection and Response (ITDR), esos hallazgos se envían directamente a ISPM para cerrar las brechas específicas que hicieron posible el ataque. La prevención y la detección no son programas separados. Funcionan juntas dentro de la plataforma de Huntress en un ciclo continuo: ITDR detiene las amenazas activas e indica dónde deben reforzarse las defensas a continuación, mientras que ISPM cierra esas brechas antes de que los atacantes puedan volver a aprovecharlas.

El resultado es resiliencia de la identidad: menos puntos de entrada, menos tiempo para que los atacantes operen y una defensa que se vuelve más difícil de vencer con cada incidente.

Como lo expresó un cliente: 

"Cuando apoyas a una empresa que ha crecido de alrededor de 40 personas a más de 150 en un año, con un equipo de TI de solo dos personas, necesitas una seguridad que pueda mantener el ritmo. Managed ITDR nos ha dado confianza al detener amenazas activas basadas en identidad, y ahora Managed ISPM nos da esa misma confianza al encontrar y corregir brechas de seguridad de identidad antes de que generen incidentes."

— Tarah Martin, IT Support Admin, Meade

Qué nos dicen los datos sobre la oportunidad

Aproximadamente el 35% de los incidentes basados en identidad a los que respondió nuestro SOC de ITDR en los últimos seis meses podrían haberse evitado con políticas de ISPM totalmente implementadas. Esperamos que esa cifra llegue al 80% en los próximos tres meses, a medida que agreguemos controles adicionales.

Esos no son incidentes causados por adversarios sofisticados que usan técnicas novedosas. Son incidentes que comenzaron con una política de MFA débil, una cuenta con privilegios excesivos o una configuración que se desvió de donde debía estar.

La cuenta de demostración que usó Scott no tenía MFA activado. Era propietaria de una aplicación con permisos excesivos. Los usuarios estándar podían acceder al portal de Azure. Si alguna de esas cosas hubiera sido diferente, el resultado podría haber cambiado.

Las brechas que hicieron posible la escalada de cinco minutos de Standard Steve son comunes. Y se pueden corregir. El problema siempre ha sido asegurarse de que realmente se corrijan y se mantengan así.

Para eso está hecho Managed ISPM.

Trabajemos juntos para cerrar las brechas que los atacantes adoran explotar. Inicia una prueba gratuita o reserva una demo para comenzar.