Los IoA son algunos eventos que podrían revelar un ataque
activo antes de que los indicadores de compromiso se hagan visibles.
El uso de los IoA permite pasar de una limpieza/recuperación
reactiva a un modo proactivo, en el que se interrumpe y bloquea a los atacantes
antes de que consigan su objetivo, como el robo de datos, ransomware, exploit,
etc.
Las IoA se centran en detectar la intención de lo que un atacante está tratando de lograr, independientemente del malware o exploit utilizado en un ataque. Al igual que las firmas AV, un enfoque de detección basado en IoC no puede detectar las crecientes amenazas de intrusiones sin malware y exploits de día cero. Por ello, las soluciones de seguridad de nueva generación están adoptando un enfoque basado en IoA.
Diez indicadores de ataque (IoA)
Las siguientes actividades de ataque más comunes podrían haber sido utilizadas, individualmente o en combinación, para diagnosticar un ataque activo:
1) Equipos internos con destinos maliciosos
Los hosts internos que se comunican con destinos conocidos como maliciosos o con un país extranjero en el que no se realizan negocios.
Ejemplo de HP ArcSight Dashboard que muestra los host del cliente que se comunican con Feeds (IP, Dominio, URL) del sitio web "ransomwaretracker.abuse.ch".
Imagen Tomada de gbhackers
Ejemplo de
inteligencia global sobre amenazas de McAfee.
Imagen
Tomada de gbhackers
2) Equipos internos que se comunican por puertos no
estándar
Equipos internos que se comunican con equipos externos utilizando
puertos no estándar o con discrepancias de protocolo/puerto, como el envío de
shells de comandos (SSH) en lugar de tráfico HTTP o HTTPS a través de los
puertos 80 o 443, los puertos web por defecto.
Ejemplo de
host interno que utiliza los puertos 21 (FTP), 445 (SMB), 137 (NETBIOS-NS) y
135 (RPC) para salir a Internet.
Imagen
Tomada de gbhackers
3) Servidores públicos/DMZ que se comunican con hosts
internos
Servidores públicos o hosts de zona desmilitarizada (DMZ)
que se comunican con hosts internos. Esto permite saltar del exterior al
interior y viceversa, permitiendo la exfiltración de datos y el acceso remoto a
activos como RDP (Remote Desktop Protocol), Radmin, SSH.
Ejemplo de
Informe que monitoriza el Top 10 de Tráfico desde la Zona "DMZ" a la
Zona "Interna/Cliente".
Imagen
Tomada de gbhackers
A partir de este informe, el analista de seguridad debe
investigar los servidores destacados que se comunican con hosts internos a
través de protocolos como RDP (TCP/3389) y SSH (TCP/22).
4) Detección de malware fuera de horario
Las alertas que se producen fuera del horario comercial
estándar (por la noche o los fines de semana) podrían indicar un host
comprometido.
Ejemplo de
alertas IPS en tiempo no laborable.
Imagen
Tomada de gbhackers
5) Escaneos de red realizados por hosts internos
Los escaneos de red por parte de hosts internos que se
comunican con múltiples hosts en un corto espacio de tiempo podrían revelar que
un atacante está moviéndose lateralmente dentro de la red.
Estos incidentes se detectan desde las defensas de red
perimetrales, como cortafuegos e IPS.
Ejemplo de
Informe de Exploraciones de Red que filtra de zona "Interna" a zona
"Interna.
Imagen
Tomada de gbhackers
6) Múltiples eventos de alarma de un único host
Múltiples eventos de alarma desde un único host o eventos
duplicados a través de múltiples máquinas en la misma subred durante un periodo
de 24 horas, como fallos de autenticación repetidos. ESTE ES UN CASO DE USO
COMÚN.
Ejemplo de
panel de control que supervisa los "fallos de inicio de sesión de
usuario" de hosts individuales.
Imagen
Tomada de gbhackers
Nota: algunos eventos de inicio de sesión fallido de
aplicaciones de correo electrónico en teléfonos móviles pueden generar de más
de 500 eventos por minuto. Es común que este caso suceda cuando la contraseña
de una cuenta de usuario ha caducado, pero no se ha configurado la nueva
contraseña en sus dispositivos.
7) El sistema se reinfecta con malware
Después de limpiar el host infectado, el sistema se
reinfecta con malware en 5-10 minutos, las reinfecciones repetidas señalan la
presencia de un rootkit o un compromiso persistente. Este incidente puede
detectarse a partir de los eventos de la protección de seguridad Endpoint o antivirus.
Este es un
ejemplo de panel de control de malware.
Imagen
Tomada de gbhackers
Detección: Se deben crear al menos tres reglas en el SIEM
como las siguientes:
· La regla alerta cuando se encuentra un host
infectado y luego "Añadir a" la lista actual de hosts infectados y la
lista histórica de hosts infectados (almacenar al menos 1 semana).
· La regla alerta cuando se limpia el malware del
host infectado y se "elimina de” la lista actual de hosts infectados.
· La regla alerta cuando se encuentra un host
infectado en la "Lista histórica de hosts infectados" dentro de un
intervalo de tiempo específico. ¡QUE LOS SISTEMAS VUELVAN A ANALIZAR/INVESTIGAR
EL MALWARE!
8) Inicio de sesión múltiple desde diferentes regiones
Una cuenta de usuario intenta iniciar sesión en múltiples
recursos en pocos minutos desde o hacia diferentes regiones. Esto es una señal
de que las credenciales del usuario han sido robadas o de que un usuario está
tramando alguna travesura.
Ejemplo de
regla correlacionada que Las soluciones ideales pueden variar en función de las
condiciones de su red y de su política de seguridad.
Imagen
Tomada de gbhackers
Esta regla detecta un evento en la categoría de normalización
"login", con un resultado de evento igual a "exitoso" con
múltiples geo-localizaciones de origen, dentro de un rango de tiempo
especificado y los eventos son agrupados por usuario origen.
9) Los hosts internos utilizan mucho el protocolo SMTP
Los protocolos de correo electrónico como SMTP (Simple Mail
Transfer Protocol), POP3 o IMAP4 debes ser monitoreados. Algunos malware
utilizan estos puertos para enviar información a servidores maliciosos.
Ejemplo de
cliente infectado que utiliza el protocolo SMTP (TCP/25).
Imagen
Tomada de gbhackers
10) Los hosts internos realizan muchas consultas al DNS interno/externo
Muchas organizaciones tienen servidores DNS internos para
cachear registros y ofrecer el servicio DNS a sus hosts internos. En la
configuración DHCP se define como Servidor DNS Primario al Servidor DNS
Interno. Si encuentra que algunos hosts internos realizan consultas a DNS
externos como 8.8.8.8, 8.8.4.4 (Google DNS), debería realizar un escaneo de malware
en esos clientes.
En algunos
incidentes se detectó que el host interno consultaba muchas peticiones al
servidor DNS interno (> 1.000 eventos/hora).
Imagen
Tomada de gbhackers
Traducido de: gbhackers
No hay comentarios:
Publicar un comentario
Tus Comentarios son Importantes para Nosotros Siéntete Libre De Opinar