A los adversarios les encanta complicarles la vida a los defensores. Una de las mejores maneras para que los atacantes operen sin ser detectados es deshabilitar las herramientas de seguridad en un dispositivo comprometido.
A veces, los usuarios hacen el trabajo duro por ellos. Cuando un usuario frustrado desactiva un servicio de seguridad que parece estar interfiriendo con su trabajo, crea la misma oportunidad para los atacantes. Lo mismo ocurre con las acciones involuntarias, como una actualización fallida.
Lamentablemente, muchos responsables de seguridad tampoco comprueban que las herramientas de seguridad críticas estén en funcionamiento, creando así un evidente punto ciego. La mayoría de las Organizations recurren a revisiones periódicas de cumplimiento que dejan estas brechas completamente abiertas entre auditorías. Con demasiada frecuencia, una organización solo descubre si las herramientas de seguridad estaban en funcionamiento después de una brecha de seguridad, cuando ya es demasiado tarde.
Por eso nos complace presentar comprobaciones de postura avanzadas en el cliente Okta Verify para macOS y Windows. Este Artículo destacado transforma cada flujo de autenticación en un sistema de vigilancia de herramientas persistente. Al ejecutar una consulta SQL de osquery en el momento en que una cuenta intenta autenticarse, los administradores pueden verificar que las herramientas de seguridad obligatorias no solo estén implementadas, sino que también se estén ejecutando activamente. Si las defensas no están presentes, el dispositivo no puede entrar.
A continuación, veremos cómo aprovechar este Artículo destacado, pero primero analicemos por qué es importante.
La brecha que se esconde a plena vista
La mayoría de las organizaciones cuentan con una lista bien definida de las herramientas que se supone que debe tener cada extremo gestionado, desde agentes EDR hasta dispositivos MDM y otros. Si bien el conjunto exacto de herramientas varía de una Organizations a otra, cada categoría de herramienta de seguridad cumple una función constante que es crucial para un entorno bien protegido.
El problema es que el hecho de haber implementado algo no significa que siga funcionando. Los agentes fallan y los servicios se desactivan, a veces por usuarios que quieren acelerar su laptop y otras veces por malware que sabe exactamente qué proceso terminar primero. Un cliente VPN lanza una actualización que deja el servicio inservible, y el equipo no se entera hasta que, semanas después, se observa un patrón en las solicitudes de asistencia técnica. Ninguno de estos aparece en el monitoreo regular a menos que se busque específicamente la ausencia de procesos, y la mayoría de los equipos no lo hace.
Este problema se ve agravado por el hecho de que la mayoría de las comprobaciones de cumplimiento solo verifican la presencia de la herramienta de seguridad una vez, incluso si posteriormente deja de cumplir con la normativa. Las comprobaciones de postura avanzadas invierten este proceso: la comprobación se ejecuta en cada evento de autenticación, por lo que una herramienta que deja de funcionar a las 9:00 a. m. provocará que se deniegue el acceso al usuario a las 9:05 a. m.
Deterioro de la defensa en el mundo real
Los adversarios saben que si logran cegar sus operaciones de seguridad, ya habrán conseguido un objetivo importante. Estas acciones son tan frecuentes que MITRE ATT&CK tiene una táctica completa para ello llamada Deterioro de la defensa, que consta de 18 técnicas diferentes. Una de las técnicas más comunes es T1685: Deshabilitar o modificar herramientas, que es en lo que se centra nuestra consulta de supervisión de herramientas que aparece a continuación.
Si bien los adversarios desactivan muchas categorías de herramientas de seguridad, el uso de eliminadores de EDR se ha vuelto habitual durante las intrusiones de ransomware, y los operadores suelen desactivar los EDR antes del cifrado. Por ejemplo, los operadores del ransomware Gentlemen utilizan su malware "GentleKiller" para deshabilitar procesos de telemetría como osqueryd.exe. De forma similar, el ransomware Reynolds utiliza una técnica de “Traiga su propio controlador vulnerable” (BYOVD, por sus siglas en inglés), convirtiendo un controlador vulnerable en un arma para eliminar los procesos locales del agente EDR en una amplia gama de plataformas. Al impedir que los dispositivos con herramientas deshabilitadas se autentiquen en sus recursos protegidos (aplicaciones y datos), puede detener a estos atacantes antes de que logren cifrar los datos.
El patrón watchdog
La consulta de detección que presentamos en esta publicación —que puede encontrar en el repositorio okta/customer-detections — aborda esto como una “comprobación de estado digital” para el dispositivo de un usuario. En lugar de buscar un único proceso, la consulta actúa como un cuadro de mando. La consulta otorga al dispositivo un punto por cada categoría de herramienta de seguridad obligatoria que esté en ejecución, y el dispositivo “aprueba” solo si su puntuación total alcanza el objetivo. A cada categoría de herramienta de seguridad se le asigna su propia expresión de tabla común (CTE, por sus siglas en inglés) que devuelve un 1 si un proceso relevante está activo y un 0 si no lo está. El resultado final agrega todas las categorías, lo que garantiza que la verificación solo permita la autenticación cuando se hayan tenido en cuenta todas las herramientas obligatorias.
Aquí tiene un ejemplo de cómo se podría evaluar un dispositivo…
¿Se está transmitiendo la telemetría? Sí, entonces la puntuación es 1
¿El dispositivo ejecuta EDR? Sí, por lo tanto, la puntuación es 1
¿El dispositivo ejecuta MDM? Sí, por lo tanto, la puntuación es 1
¿El dispositivo ejecuta DLP? Sí, por lo tanto, la puntuación es 1
¿El dispositivo ejecuta VPN/ZTNA? No, entonces la puntuación es 0
¿El dispositivo ejecuta seguridad DNS? Sí, entonces la puntuación es 1
¿El dispositivo ejecuta la gestión de vulnerabilidades? Sí, entonces la puntuación es 1
Puntuación: ¡6 de 7 fallaron! Por lo tanto, no se le concedería acceso al dispositivo.
Existen siete categorías, cada una de las cuales abarca a los principales proveedores en ese ámbito, tanto para macOS como para Windows:
CON telemetría_en_ejecución COMO (
-- Supervisor de Fleet Orbit + demonio osquery
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN ('osqueryd', 'orbit', 'osqueryd.exe', 'orbit.exe')
),
edr_running AS (
-- CrowdStrike Falcon | SentinelOne | VMware Carbon Black Cloud |
-- Microsoft Defender for Extremo | Elastic Security | Palo Alto Cortex XDR |
-- FireEye/Trellix | Sophos | Trend Micro | ESET
SELECT COALESCE(COUNT(*), 0) AS total
FROM processes
WHERE name IN (
'com.crowdstrike.falcon.Agent', 'CSFalconService.exe', 'falcon-sensor',
'SentinelAgent', 'SentinelAgent.exe', 'sentineld',
'cbagentd', 'CbDefense.exe',
'wdavdaemon', 'MsMpEng.exe', 'MsSense.exe',
'elastic-agente',
'CyveraConsole', 'CyServer.exe',
'xagt', 'xagt.exe',
'SophosScanD', 'SAVAdminService.exe',
'iCoreService', 'Ntrtscan.exe',
'esets_daemon', 'ekrn.exe'
)
),
Los cinco CTE restantes siguen el mismo patrón para MDM, DLP, VPN/ZTNA, seguridad DNS y gestión de vulnerabilidades. Todos ellos contribuyen a un único paso de puntuación:
final_score AS (
SELECT
CASE WHEN telemetry_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN edr_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN mdm_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dlp_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vpn_ztna_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN dns_security_running.total > 0 THEN 1 ELSE 0 END
+ CASE WHEN vuln_scanner_running.total > 0 THEN 1 ELSE 0 END
Puntuación AS
FROM telemetry_running, edr_running, mdm_running, dlp_running,
vpn_ztna_running, dns_security_running, vuln_scanner_running
)
Select
CASO CUANDO puntuación = 7 ENTONCES 1 SINO 0
END AS security_tools_healthy
FROM final_score;
Algunos aspectos a tener en cuenta sobre la estructura de esta consulta:
Mide la cobertura de la categoría. La lógica CASE WHEN total > 0 THEN 1 alrededor de cada categoría es lo que limita cada señal a 1 antes de sumarlas todas. Sin ello, una sola herramienta que genere cinco procesos contribuiría con 5 a la puntuación en lugar de 1, y un dispositivo al que le falten cuatro categorías de herramientas aún podría aprobar teniendo un agente EDR muy ocupado. El límite máximo garantiza que se mida lo que realmente se está verificando: la cobertura de la categoría, no el recuento de procesos.
Normaliza los diferentes proveedores en una señal consistente. Esta consulta utiliza CTE independientes en lugar de una cláusula WHERE más simple para normalizar entre diferentes proveedores de herramientas. Independientemente de si un dispositivo ejecuta CrowdStrike o SentinelOne, la categoría EDR siempre arroja un “1”. Una cláusula WHERE monolítica devolvería un recuento de procesos en bruto, lo cual pasa por alto el objetivo: no importa cuántos procesos genere el EDR, solo se le reconoce como una herramienta.
Cubre tanto macOS como Windows. Uno de los desafíos a la hora de escribir comprobaciones de postura multiplataforma es que las herramientas de macOS a menudo no tienen un equivalente en Windows, y viceversa. Esta comprobación gestiona lo siguiente: los dispositivos macOS obtienen una puntuación de 1 para MDM a través de JamfDaemon, kandji-daemon, mosyled o addigy-agente; los dispositivos Windows obtienen una puntuación de 1 para el proceso MDM de Intune, Microsoft.Management.Services.IntuneWindowsAgent.exe. Lo mismo se aplica a los nombres de procesos EDR específicos de cada plataforma. Dado que cada categoría está diseñada para abarcar ambas plataformas dentro de la misma CTE, el umbral se mantiene en una puntuación de 7 en ambos sistemas operativos, por lo que no es necesario crear variantes de la consulta específicas para cada plataforma.
Haga que funcione para usted
No todas las Organizations implementan las siete categorías de herramientas. Por ejemplo, algunos utilizan su EDR para la gestión de vulnerabilidades y otros pueden gestionar la seguridad DNS en la capa de red en lugar de en el extremo. La lista de nombres de procesos en cada CTE abarca a los principales proveedores de cada categoría para permitir que la verificación funcione en diferentes organizaciones con pocas o ninguna modificación. Sin embargo, esta consulta es un punto de partida, no una configuración final. Antes de implementar esta comprobación en modo de aplicación, debe personalizarla para su entorno y probarla.
En primer lugar, localice la consulta de detección específica dentro del repositorio okta/customer-detections. Recomendamos clonar el proyecto.
A continuación, ajuste la consulta a su entorno específico. Revise cada CTE y confirme que el nombre del proceso de su proveedor esté en la lista; si no lo está, agréguelo. Luego, reduzca el umbral para que coincida con la cantidad de categorías que realmente necesita. (Por ejemplo, una pila de cinco herramientas debería usar =5, no =7). Recomendamos ejecutar la comprobación localmente utilizando osqueryi para verificarla. Perfeccione los nombres de los procesos y ajuste el umbral de puntuación hasta que se alinee perfectamente con la pila de seguridad que requiere su organización.
Ejecute la consulta en modo de supervisar en su flota durante una semana. Esto le indicará qué categorías registran un valor de cero en dispositivos reales, lo cual suele ser la primera señal de que una herramienta se ha desviado del estado esperado.
Ejecute la consulta en modo de aplicación una vez que esté seguro de que funciona como se espera.
Cerrando el círculo
Aunque este control de las herramientas no parezca glamuroso, es una base fundamental que vale la pena tener implementada. Esta comprobación le permite verificar que la pila de seguridad que ha pagado e implementado se está ejecutando realmente en todos los dispositivos que están a punto de autenticarse en su entorno.
En los próximos días, exploraremos qué sucede cuando se utilizan comprobaciones de postura avanzadas para un desafío completamente diferente.
