SentinelOne Singularity: Análisis de Detección y Respuesta Autónoma

SentinelOne: la apuesta por la autonomía

SentinelOne se fundó en 2013 con una premisa diferente a la de CrowdStrike: en lugar de depender de una nube centralizada para la detección, el agente debía ser capaz de detectar y responder a amenazas de forma autónoma en el endpoint, incluso sin conexión a internet.

Esta filosofía de "agente inteligente" define la arquitectura de SentinelOne Singularity. El agente ejecuta modelos de machine learning localmente, correlaciona eventos en tiempo real con su tecnología Storyline, y puede remediar amenazas automáticamente sin intervención humana. La consola cloud agrega, gestiona y permite hunting, pero la detección y respuesta ocurren en el endpoint.

Arquitectura: inteligencia en el endpoint

El agente Singularity

El agente de SentinelOne es significativamente más pesado que el de CrowdStrike porque ejecuta modelos de IA localmente en el endpoint.

Componentes del agente:

• Static AI Engine. Analiza archivos antes de su ejecución. Modelos de machine learning clasifican ejecutables, scripts, documentos y otros archivos como benignos o maliciosos basándose en sus características estáticas (estructura PE, imports, entropía, strings).
• Behavioral AI Engine. Monitoriza la ejecución de procesos en tiempo real. Analiza secuencias de comportamiento (creación de procesos, acceso a archivos, conexiones de red, modificaciones de registro) para detectar patrones de ataque.
• Storyline Engine. Correlaciona automáticamente eventos relacionados en una narrativa temporal. Cada proceso y sus acciones (hijos, archivos, red, registro) se conectan en un Storyline que permite ver el ataque completo sin correlación manual.
• ActiveEDR. El componente que permite respuesta automatizada: kill de procesos, cuarentena de archivos, rollback de cambios, aislamiento de red.

Consumo de recursos:

El agente de SentinelOne consume típicamente entre 1% y 5% de CPU y entre 100 y 200 MB de RAM. Es más pesado que Falcon por la ejecución local de modelos de IA, pero esto le permite operar sin dependencia de la nube para detección.

Soporte de plataformas:

SentinelOne soporta Windows, macOS, Linux (múltiples distribuciones), y tiene agentes específicos para contenedores (Kubernetes) y workloads cloud. El soporte de Linux es particularmente robusto comparado con algunos competidores, con soporte para kernels recientes sin requerir compilación de módulos custom.

La consola Singularity

La consola Singularity es la interfaz web centralizada para gestión, investigación y hunting.

Vistas principales:

• Incidents. Incidentes agrupados automáticamente por Storyline. Cada incidente muestra severity, endpoints afectados, técnicas ATT&CK, estado de mitigación.
• Threats. Amenazas individuales detectadas. Cada amenaza muestra el veredicto del agente (malicious, suspicious), el motor que la detectó (Static AI, Behavioral AI, regla STAR), y las acciones tomadas.
• Activities. Log de todas las acciones realizadas (por analistas o automáticamente) sobre amenazas: quarantine, kill, rollback, network isolation.
• Deep Visibility. Interfaz de hunting para consultar telemetría raw.
• Ranger. Descubrimiento de dispositivos no gestionados en la red.

Storyline: la narrativa automática del ataque

La tecnología Storyline es el diferenciador técnico principal de SentinelOne. Mientras otros EDR presentan eventos individuales que el analista debe correlar manualmente, Storyline conecta automáticamente todos los eventos relacionados.

Cómo funciona

Cuando un proceso se crea, el agente le asigna un Storyline ID. Todos los eventos generados por ese proceso y sus descendientes (procesos hijo, archivos creados, conexiones de red, modificaciones de registro) heredan el mismo Storyline ID.

Ejemplo práctico:

1. outlook.exe recibe un email con adjunto .doc (Storyline ID: S-12345)
2. El usuario abre el adjunto: winword.exe se crea como hijo (hereda S-12345)
3. La macro ejecuta: cmd.exe /c powershell.exe -enc [base64] (hereda S-12345)
4. PowerShell descarga y ejecuta payload.exe (hereda S-12345)
5. payload.exe crea persistencia en registro (hereda S-12345)
6. payload.exe establece conexión C2 a IP externa (hereda S-12345)

Todos estos eventos, desde el email hasta la conexión C2, aparecen conectados en un único Storyline. El analista ve la cadena completa del ataque sin necesidad de buscar manualmente eventos correlacionados por timestamp o PID.

Storyline en la consola

La vista de Storyline en la consola muestra:

• Árbol de procesos. Visualización jerárquica de todos los procesos involucrados con sus relaciones padre-hijo.
• Timeline. Línea temporal con todos los eventos ordenados cronológicamente.
• Indicadores. Cada evento marcado con la técnica ATT&CK correspondiente (si aplica).
• Acciones del agente. Qué acciones tomó el agente automáticamente (kill, quarantine) y en qué momento del Storyline.
• Contexto de usuario y endpoint. Quién estaba logueado, qué grupos AD pertenece, qué software tiene instalado.

Limitaciones de Storyline

Storyline conecta eventos dentro de un endpoint. Si un atacante se mueve lateralmente a otro endpoint, se crea un nuevo Storyline en el segundo endpoint. La correlación cross-endpoint requiere la funcionalidad XDR de Singularity, que une Storylines de múltiples endpoints en un único incidente cuando detecta relaciones (misma IP C2, mismo hash, misma cuenta de usuario comprometida).

STAR Rules: detección personalizada

STAR (Singularity Threat Analysis Rules) es el sistema de reglas de detección personalizadas de SentinelOne. Permite a los equipos de detection engineering crear reglas que complementan las detecciones nativas del agente.

Sintaxis de STAR Rules

Las STAR rules se definen sobre la telemetría de Deep Visibility usando una sintaxis de query estructurada:

Ejemplo: detectar uso de certutil para descarga (T1105 Ingress Tool Transfer):

EventType = "Process Creation" AND
SrcProcName = "certutil.exe" AND
(SrcProcCmdLine contains "urlcache" OR
 SrcProcCmdLine contains "split" OR
 SrcProcCmdLine contains "verifyctl")

Ejemplo: detectar acceso sospechoso a LSASS (T1003.001):

EventType = "Open Remote Process Handle" AND
TgtProcName = "lsass.exe" AND
SrcProcName NOT IN ("csrss.exe", "services.exe", "svchost.exe", "wininit.exe")

Ejemplo: detectar escritura de ejecutable por script (posible dropper):

EventType = "File Creation" AND
TgtFileExtension IN ("exe", "dll", "scr", "sys") AND
SrcProcName IN ("powershell.exe", "wscript.exe", "cscript.exe", "mshta.exe")

Acciones de STAR Rules

Cada STAR rule define la acción a tomar cuando se cumple:

• Alert Only. Genera una alerta sin acción automatizada.
• Suspicious. Marca la amenaza como sospechosa en la consola.
• Malicious. Marca como maliciosa y ejecuta la política de mitigación configurada (que puede incluir kill, quarantine, rollback).

STAR vs detecciones nativas

Las detecciones nativas del agente (Static AI, Behavioral AI) están optimizadas para rendimiento y baja tasa de falsos positivos. Las STAR rules son más flexibles pero requieren tuning: una regla mal diseñada puede generar volúmenes masivos de falsos positivos o degradar el rendimiento del agente.

La práctica recomendada es usar STAR rules en modo Alert Only durante un período de evaluación, analizar los resultados, y escalar a Suspicious o Malicious solo tras validar la regla.

Deep Visibility: threat hunting

Deep Visibility es la interfaz de hunting de SentinelOne. Permite consultar la telemetría raw almacenada en la nube para buscar amenazas que no generaron alertas automáticas.

Tipos de eventos consultables

Categoría	Eventos
Procesos	Process Creation, Process Exit, Process Injection, Cross-Process Access
Archivos	File Creation, File Modification, File Deletion, File Rename
Red	DNS Query, Network Connection (TCP/UDP), HTTP Request
Registro	Registry Key Create, Registry Value Set, Registry Value Delete
Login	User Login (local, remote, network), Failed Login
Módulos	Module Load (DLL/SO)
Indicadores	Indicator Match (IOC feed match)

Queries de hunting

Buscar PowerShell con descarga:

EventType = "Process Creation" AND
SrcProcName = "powershell.exe" AND
(SrcProcCmdLine contains "Invoke-WebRequest" OR
 SrcProcCmdLine contains "wget" OR
 SrcProcCmdLine contains "DownloadFile" OR
 SrcProcCmdLine contains "Net.WebClient")

Buscar beaconing por intervalo:

EventType = "IP Connect" AND
NetConnCount > 50 AND
DstIP NOT IN RFC1918
| group by DstIP, EndpointName

Buscar ejecución desde rutas inusuales:

EventType = "Process Creation" AND
SrcProcImagePath contains "\\Users\\Public\\" AND
SrcProcImagePath endswith ".exe"

Retención de telemetría

La retención de telemetría en Deep Visibility varía según el plan:

Plan	Retención
Singularity Core	14 días
Singularity Control	14 días
Singularity Complete	14 a 30 días
Singularity Complete + Data Retention	Hasta 365 días

Para threat hunting de APT con persistencia prolongada, los 14 días del plan base son insuficientes. La retención extendida tiene coste adicional significativo.

Respuesta automatizada: mitigación y rollback

Acciones de mitigación

Cuando el agente detecta una amenaza (por Static AI, Behavioral AI o STAR rule), ejecuta automáticamente las acciones de la política de mitigación configurada:

Kill. Termina el proceso malicioso y todos sus descendientes.

Quarantine. Mueve los archivos maliciosos a una ubicación de cuarentena cifrada donde no pueden ejecutarse. Los archivos se pueden restaurar si la detección fue un falso positivo.

Remediate. Elimina los cambios realizados por la amenaza: archivos creados, claves de registro añadidas, tareas programadas creadas. Restaura el sistema al estado anterior a la ejecución del malware.

Rollback. La función más diferenciadora de SentinelOne. Revierte todos los cambios de archivos realizados por la amenaza usando snapshots de Volume Shadow Copy (VSS en Windows). Si un ransomware cifró archivos, el rollback restaura los archivos originales.

Cómo funciona el rollback

Pre-requisitos:

• Windows con VSS habilitado (el agente lo gestiona automáticamente).
• Suficiente espacio en disco para snapshots.
• La amenaza debe haber sido detectada y asociada a un Storyline completo.

Proceso:

1. El agente detecta la amenaza y mata el proceso.
2. Identifica todos los archivos modificados/creados/eliminados por procesos en el Storyline.
3. Para archivos modificados: restaura la versión anterior desde el snapshot VSS.
4. Para archivos creados por el malware: los elimina.
5. Para archivos eliminados por el malware: los restaura.
6. Revierte cambios en registro, tareas programadas, y otros artefactos de persistencia.

Limitaciones del rollback:

• Solo funciona en Windows (macOS y Linux no tienen VSS equivalente nativo integrado con el agente).
• Requiere que los snapshots existan. Si el malware eliminó los shadow copies antes de cifrar (técnica habitual de ransomware sofisticado que SentinelOne intenta prevenir), el rollback no es posible.
• No es instantáneo para volúmenes grandes de archivos afectados.

Network Isolation

El agente puede aislar el endpoint de la red, bloqueando todas las conexiones excepto la comunicación con la consola de SentinelOne. Esto permite al analista seguir investigando y remediando remotamente mientras el endpoint está contenido.

Singularity XDR: más allá del endpoint

SentinelOne Singularity XDR extiende la plataforma para ingestar telemetría de fuentes adicionales:

Singularity Data Lake. Almacén centralizado que ingesta datos de terceros: firewalls (Palo Alto, Fortinet), identity providers (Okta, Azure AD), cloud (AWS CloudTrail, Azure), email (Microsoft 365, Google Workspace). Los datos se normalizan y se pueden consultar junto con la telemetría de endpoint en Deep Visibility.

Singularity Marketplace. Catálogo de integraciones preconfiguradas con herramientas de terceros. Cada integración define qué datos se ingestainy cómo se normalizan.

Correlación XDR. Storylines de múltiples fuentes se correlacionan automáticamente. Un login anómalo en Okta, seguido de una descarga de malware detectada en el endpoint, seguido de movimiento lateral detectado en el firewall, se presenta como un único incidente XDR.

Purple AI: el asistente de hunting

Purple AI es el asistente de inteligencia artificial de SentinelOne para threat hunting. Similar a Charlotte AI de CrowdStrike, permite:

• Consultas en lenguaje natural que se traducen a queries de Deep Visibility.
• Resúmenes automáticos de incidentes y Storylines.
• Sugerencias de queries de hunting basadas en el contexto del incidente.
• Explicación de técnicas ATT&CK detectadas con recomendaciones de mitigación.

Purple AI es útil como asistente, pero como toda herramienta de IA generativa, las queries generadas deben validarse. Las consultas complejas con lógica específica del entorno del cliente siguen requiriendo conocimiento manual de la sintaxis de Deep Visibility.

Fortalezas y debilidades

Fortalezas técnicas

Autonomía del agente. La capacidad de detectar y responder sin conexión a la nube es un diferenciador real para endpoints con conectividad intermitente (laptops de viajeros, dispositivos en redes OT aisladas, endpoints en ubicaciones remotas).

Storyline. La correlación automática de eventos reduce significativamente el tiempo de investigación. Un analista SOC junior puede entender la cadena de ataque completa sin experiencia en correlación manual de eventos.

Rollback. Ningún otro EDR ofrece una función de rollback comparable. Para organizaciones sin backups granulares de endpoints, la capacidad de revertir los efectos de un ransomware es enormemente valiosa.

Soporte Linux/Container. El agente de Linux es robusto y soporta kernels modernos con eBPF. La protección de containers y Kubernetes es nativa, no un producto separado.

Debilidades y consideraciones

Consumo de recursos. El agente es más pesado que la competencia por la ejecución local de modelos de IA. En endpoints con recursos limitados (VDI, máquinas legacy), el impacto puede ser perceptible.

Complejidad de la consola. La consola de Singularity tiene una curva de aprendizaje pronunciada. Las múltiples vistas, filtros, y opciones de configuración pueden resultar abrumadoras para equipos pequeños. La formación inicial es necesaria para operar eficazmente.

Retención de telemetría. 14 días en el plan base es insuficiente para hunting de APT. La retención extendida tiene coste adicional que debe presupuestarse.

Falsos positivos en Static AI. El motor de IA estática puede generar falsos positivos con software legítimo que tiene características similares a malware (herramientas de administración, pentest tools, software personalizado). El tuning de exclusiones es un proceso continuo.

Caso de uso: detección y rollback de ransomware

Escenario: Un usuario ejecuta un archivo adjunto que contiene un ransomware de la familia LockBit.

Fase 1: Detección estática. El Static AI Engine analiza el ejecutable antes de su ejecución. Si el modelo lo clasifica como malicioso, lo bloquea preventivamente y lo envía a cuarentena. Fin del ataque.

Fase 2: Detección behavioral (si Static AI no lo detectó). El ejecutable se ejecuta. El Behavioral AI Engine observa:

• Enumeración de archivos en múltiples directorios
• Lectura y reescritura rápida de archivos con cambio de extensión
• Eliminación de shadow copies (vssadmin delete shadows)
• Escritura de nota de rescate en cada directorio

El agente detecta el patrón de ransomware y ejecuta kill + quarantine + rollback.

Fase 3: Rollback. El agente revierte los archivos cifrados a su versión pre-ataque usando los snapshots VSS. Los archivos creados por el ransomware (nota de rescate, ejecutable copiado) se eliminan. Las claves de registro de persistencia se revierten.

Resultado en la consola: El Storyline muestra toda la cadena desde la ejecución inicial hasta el rollback, con cada paso marcado con la técnica ATT&CK correspondiente y el timestamp. El analista puede verificar que el rollback fue completo y que no hay artefactos residuales.

Tiempo total: Desde ejecución del ransomware hasta rollback completo, típicamente entre 10 y 60 segundos para volúmenes moderados de archivos afectados.