sábado, 11 de mayo de 2019

Gestión de incidentes... Episodio 2. La detección...



Estimados amigos de Inseguros !!!

Seguimos con esta serie de artículos relacionados con el amplio mundo de la gestión de incidentes.

En el capítulo 1 introdujimos los conceptos básicos y más bien la necesidad.
Al final este post iba a versar sobre 4 integraciones de 20 productos, pero creo que puedo aportar más dando mi visión y experiencia global, más que con unas cuantas guías, que las pondré !!! pero mejor ir paso a paso.



Somo informáticos, nos gusta la tecnología y probar programitas y cacharros es lo que más. La sensación de instalar un nuevo software, de hacer los primeros pasos, a mi dilata experiencia, toda via me motiva, me gusta !!! Pero como informáticos que somos, debemos recordar que lo primero de todo es hacer un buen análisis de requisitos de qué queremos hacer, luego haremos un análisis funcional, y luego diseñaremos la solución tecnológica. 

Conozco MIL pilotos de software que nunca llegan a solución por eso, porque se prima el programa...

Por desgracia, y por eso lo decía, muchos de nosotros orientamos nuestras soluciones a que nos gusta más WIndows que Linux, o al revés, o a que yo tengo mucho conocimiento sobre una tecnología y NECESITO ponerla donde sea !!! No amigo, no, esto no debería ser así.

Cuando hablamos de la gestión de incidentes, el primero punto debería ser establecer cómo vamos a detectar estos incidentes. Con qué herramientas.

Al final, estas herramientas no dejan de ser eventos (logs), muestras ( pcap, ficheros, memoria...) y sobre todo la correlación que existe entre ellas. Imagina un radar de una autovía, y la típica foto de que te  han cazado a 200km/hora. y aparecen dos coches, uno adelantando a otro. Serviría dicha foto como muestra de la infracción? NO.

Presuponemos que el vehículo de la izquierda adelantaba al de la derecha, por eso saltó el radar, y el que iba "lento" o legal era el de la derecha, pero puede que no sea así !!!! en este caso, el dato de la imágen y el radar no nos sirve, deberíamos tener video en ese contexto....

En este caso, si salta el radar, a quien debería sancionarse?

Podría ponerme 200 ejemplos más del contexto, de la relación entre fuentes, de la correlación pero creo que ya hemos hablado bastante en Inseguros en los capítulos de OSSIM.

Pero ahora vamos más allá. como comenté en el post de la matriz de MITRE, tenemos enumerados la mayoría de procesos de ataques, las tácticas y técnicas, y tenemos los data source que las detectan.

Con esta información, debemos hacer mapa de qué herramientas y tecnologías serían necesarias para llegar al máximo número de data source, y tener claro un plan de trabajo a medio plazo en el que vayamos incorporando fuentes de información.

Tener un IDS no es tener un SOC, ni tampoco es tener un IDS con un SIEM, por supuesto, tener una consola centralizada de alarmas de antivirus tampoco, vamos poco a poco.



Enumeramos los distintos data source a día de hoy. Ahora vamos a empezar a crear supuestos, los use-cases.

Vamos a imaginar un ataque a una empresa. Comienza con un ataque de deautenticación *1 a la red wifi*2 para forzar eso, que clientes legítimos se desconecten a la red y así poder capturar las credenciales o el handshake. Una vez conseguimos acceso a la red wifi, realizamos un ataque de arp-spoofing*3 simple para esnifar tráfico del cliente, o más fácil aún, vamos a realizar un Man In the middle del DNS*4, vamos a suplantarlo para conocer los accesos y poder establecer otro tipo de ataque. Conociendo accesos típicos a una web interna, vamos a intentar montar un web similar*5 y con un proxy inverso capturar credenciales.

Hasta aquí un ataque de primero de hacker de los 2000, pero vamos a desgranar cómo debería ser la monitorización, qué fuentes serían necesarias para detectar este ataque.

*1 Monitorización de la plataforma de WIfi y correlación de eventos para detectar multiples peticiones deauth.
*2 WIFI IDS para detectar rogue AP y nuevos elementos en la red Wifi.
*3 Switches gestionables con detección de arp broadcast storm o similar.
*4 hay varias técnicas de detección para suplantación dns, depende si se cambia en el adaptador cliente, o es un envenamiento DNS, DHCP, etc. En la mayoría de los casos vas a necesitar monitorización total de red.
*5 detectar la navegación de usuarios a sitios con certificados no válidos, como cuando se usa ssltrip y herrmientas de proxy.

Como puedes comprender, desarrollar una estrategia de monitorización es muy complicada para casos de uso muy sencillo. Si a estos casos de uso le sumamos complejidad en el ataque, la monitorización se hace MUY compleja.

En el caso de los IDS de toda la vida, o como vimos en el episodio de OSSIM, se suele guardar el fragmento de pcap que ha saltado la alerta, pero en el caso de uso comentado, debería analizar el tráfico de red PASADO, almacenado, es decir, no el que genera el evento, sino 1 semana de estudio, un día, una hora, lo que necesitemos.

Cómo guardamos el tráfico de red de una empresa para monitorizar después? IMPOSIBLE, podrías guardar x horas, minutos, o días, pero el tráfico es gigante. Hay que trabajar con herramientas como puedan ser BRO o Logtash que generen eventos relacionados con el tráfico. Por ejemplo, en este caso del DNS, no tiene sentido tener un MEGA pcap para ver las peticiones UDP 53. Mejor será tener ese sistema automatizado y preguntar por ese datos, consultas UDP 53, no el PCAP entero.

Cuantos más indicadores "transformemos" del pcap a eventos, más capacidad de usar esa información tendremos. Bro tiene muchas capacidades ya dispuestas, por ejemplo, detectar los mensajes OSCP para detectar el código de error del certificado del caso *5.

Estos son los elementos que presenta el Mitre.
Access Tokens
Anti-virus
API monitoring
Application Logs
Asset Management
Authentication logs
Binary file metadata
BIOS
Browser extensions
Data loss prevention
Detonation chamber
Digital Certificate Logs
DLL monitoring
DNS records
EFI
Email gateway
Environment variable
File monitoring
Host network interface
Kernel drivers
Loaded DLLs
Mail server
Malware reverse engineering
MBR
Named Pipes
Netflow/Enclave netflow
Network device logs
Network intrusion detection system
Network protocol analysis
Packet capture
PowerShell logs
Process command-line parameters
Process monitoring
Process use of network
Sensor health and status
Services
SSL/TLS inspection
System calls
Third-party application logs
User interface
VBR
Web application firewall logs
Web logs
Web proxy
Windows Error Reporting
Windows event logs
Windows Registry
WMI Objects

Algunos son muy evidentes, pero otros? Detonation chamber ? Se refiere a algún tipo de sandbox que inspeccione el contenido del fichero adjunto en un ataque de Phishing.

Las peticiones DNS !!! en los servidores Windows por defecto no se registran, en este artículo aprendimos a registrar estos eventos en servidores DNS Windows,
pero también imagina la cantidad de registros que se van a generar...

Seguro que si repasas todas las fuentes de datos te saldrán mil dudas.

Otra cuestión a tener en cuenta es el propio dato, la calidad del dato. Tenemos un sistema consolidado por el tiempo, para el tiempo? para que cuando un evento me dice las 22:00 sea utc o utc+2 ?. 

Tenemos la misma política de retención de eventos en un log de Apache que en un log de un AP wifi?

Tenemos el campo ip_source en todos sitios, o en algunos es ip_src y en otros es una MAC? tenemos que hacer transformaciones específicas para homogenizar el dato? es decir , construir un modelado de datos para que tenga sentido comparar peras con peras, y no con manzanas...

Imagina un sistema con firewalls de 5 fabricantes, y que cada uno llama a sus datos de una manera distinta...

Aparte, si integras este modelado de datos con estándares de compartición como pueda ser STIX

Imagina un antivirus que te dice: amenaza X detectada en PC-JOSE , la fecha y el nombre del binario. Esa amenaza puede ser un malware en un js de navegación , o la ejecución de Mimikatz !!! Si es la ejecución de una powershell sospechosa, o un CMD, debería tener el comando exacto y los parámetros... y la fuente de la amenaza, si es una web, un proceso remoto en una red local...

También deberíamos tener el fichero en caso de existir, para poder hacer aunque sea un análisis dinámico...

PC-jose es el nombre netbios? DNS? el nombre que se le dió en la consola antivirus...

A mi ya se me están viniendo a la cabeza varios data-source en este mini user-case que es una mera detección de un antivirus. Use-case a millones, tantos, como representar todas las posibilidades reales en un proceso de hacking... infinitos diría yo !!!


A la hora de trabajar con los eventos, con la correlación, debemos usar lenguajes que nos permitan generar alertas y realizar búsquedas de supuestos. 

Cuando realizamos una gestión de incidentes, una respuesta a incidentes, se trabaja con supuestos, vas analizando la información que tienes y vas suponiendo, por ejemplo, si ves indicadores de compromiso o IOC´s relativos a navegación web, debes pensar que ha sido una intrusión por esta vía, deberás revisar en profundidad los logs de acceso y navegación. No vas a ponerte a leer todos los logs del sql-server del servidor de nóminas si no se ha visto implicado, a priori... 

Para trabajar con estos supuestos, con estas búsquedas de IOC´s, usar sistemas con lenguajes "compatibles" como pueda ser el proyecto SIGMA para la definición de búsquedas en los SIEM´s más populares es una ventaja, ya que te permite trabajar en entornos multi SIEM, que aunque parezca una locura, existen. El mismo SOC proveedor puede trabajar con N tecnologías SIEM.

Para la gestión de IOC´s tengo varios favoritos, pero hemos iniciado el artículo diciendo que no iba a hablar de software, para eso tenemos la tercera entrega.

De momento quédate con la idea del data-source. Si vas a trabajar con un fabricante X y tienes fuentes de información Y y Z, comprueba la facilidad que vas a tener de integrar esta información, de cómo vas a poder "meter" pero también "sacar".

En el próximo programa hablaremos de escenarios específicos con software que conoces como The Hive, splunk, MIPS, Alien Vault, Qradar, ELK etc.

Gracias por leerme.




miércoles, 8 de mayo de 2019

Servidor de salto: el host bastión de toda la vida con nombre guay

Estimados amigos de Inseguros !!!

Hablando el otro día con un amigo discutíamos la mejor manera de segmentar una red Active Directory para evitar ataques convencionales como propagación de Ransomware, ataques de obtención de contraseñas y demás bondades.


Volvió a sonar algo que lleva muchos años siendo una buena práctica, pero que no siempre se encuentra en las pymes. Hablo de esas empresas con 2 o 4 informáticos, con mucha carga de "otras" cosas y poco tiempo para ese cuidado fino del sistema. Al final si las cosas medio van... la seguridad siempre es un después, y está asociada a máquinas con nombres de star trek.

Hablo del host bastión. Esto es algo que empecé a leer allá por los 2000 con los primeros directorios. Si nos vamos a la RAE se define bastión como: Construcción o recinto fortificado para resistir ataques enemigos. En seguridad informática podría ser un equipo configurado con mucho nivel de seguridad. Podría ser igual que una DMZ, al final es lo mismo, es un equipo aislado. La cuestión es que suele emplear para usar este equipo como pasarela de administración del resto de servidores, por eso lo de salto.

Siendo más claros, es un Windows al que petas de seguridad, y solo administras tu red desde ese equipo.

Más o menos todos sabemos por dónde nos vienen los ataques en redes Windows, las tácticas suelen ser las mismas, cambian las técnicas concretas, pero las líneas maestras siempre son las mismas.

En este post voy a intentar describir algunos procesos de fortificación o más bien ideas sobre cómo acometer este proyecto.

Lo primero que vamos a hacer o deberíamos es segmentar la red de los "informáticos". Una vlan enrutada por un firewall para poder elegir qué puertos son accesibles para que redes. Ningún usuario de la empresa debería poder acceder a esta lan/vlan, pero nosotros a todas las redes si... o no?

Acceder a un servidor de nóminas con el pc con el que veo gatitos en Internet no es muy buena idea.

Si vas a las charlas de mi maestro Carlos o has visto el ciber kill chain one two three de Microsoft, verás como el primer paso suele ser comprometer un equipo, y realizar tanto escalado horizontal y vertical: de máquina y de permisos. El mejor sitio por donde empezar es tú equipo.

 Si las estadísticas indican que el 90% de los ataques comienzan con un Phishing, seguido de ataques al navegador y por último software, vamos a por ello.

Con la red de administradores segmentada, vamos a montar un windows, mejor físico que virtual, pero en los tiempos que corren esto es inviable, que usaremos para administrar AD.

Configuramos las GPO locales para que SOLO los usuarios administradores puedan acceder al servidor, tanto por login como por RDP. Mejor enumerar los usuarios que pueden, y no hacerlo como se suele hacer por grupos administrativos. Al final, definir el usuario en vez del grupo da más granularidad y evita el despiste de usuarios que por cualquier motivo, son dios en AD.

A este equipo, le quitamos la navegación por Internet por supuesto. Bueno, lo suyo sería que ni fuera del dominio, pero esto es también inviable, porque si sois 4 tip@s administrando esto, gestionando los cambios de password (no vayas a usar un genérico que está prohibido por ley).

Ahora vamos con el firewall de Windows. Hay mil guías y recomendaciones para aislar equipos en una red WIndows a nivel de puertos. Esta guía es la buena: https://docs.microsoft.com/es-es/windows/security/threat-protection/windows-firewall/mapping-your-deployment-goals-to-a-windows-firewall-with-advanced-security-design Pero no voy a entrar en esto, porque reconozco que te puedes enjardinar, pero con el RDP SI.



Te vas a cualquier servidor, creas una regla que permita el RDP SOLO al equipo bastionado, al que va a hacer de máquina de la muerte xD y a alguno equipo más... no sea que la picies xD. Exporta la regla desde el menú. Ahora vete a tu editor de políticas y crea una política de seguridad específica para tus servidores miembro, no solo para los controladores de dominio, ya sabes. Aplica esa regla de seguridad al firewall de Windows.

En este punto, valoraría que la comunicación entre el host bastionado y los members servers fuera mediante IPSEC. Implementar IPSEC en una red Windows son dos clicks, porque usamos una directiva de seguridad relajada en la que los servidores hablan IPSEC siempre y cuando sea posible. De esta manera, si tienes sistemas no-Microsoft que no admitan el IPSEC, no hay problema.

Nuestra operativa diaria para administrar el DNS de la empresa no debe ser meternos en el DNS SERVER y administrarlo, al final, si tenemos una máquina bastión con las plantillas administrativas, me conecto a la consola DNS remotamente, nada de entrar al DC por RDP y dejar las claves en memoria...

Una de las cosas a nivel de máquina que podemos hacer, si hemos decidido usar un Windows 10 es pasar la guía básica de seguridad, en la que me va a detectar fallos o mejoras de seguridad.

Y hable de algo parecido en mi 4º artículo, hayá por el 2012.

Para proteger la gestión de las contraseñas, ya sabes, los ataques basados en pass-the-hash, y básicamente, mimikatz y compañía, podemos usar Credential Guard. Básicamente es un subsistema para LSA en el que se aprovecha de la tecnología de virtualización, la ISOLATION, para aislar el almacenamiento de la contraseña fuera del proceso LSA en memoria, lo que hace imposible dumpear las claves de LSASS.exe ...Como usa virtualización, necesita los mismos requisitos que para montar hyper-v, extensión de la CPU, y como dato negativo, el equipo debe ser físico, no contempla que haya virtualización nested...

Pablo González habló muy bien hace unos años de esta tecnología aquí.

Dentro de la seguridad del RDP, tenemos MIL COSAS por hacer.

Los nuevos Windows 10 en escenarios de directorio 2016 implementan el Hello Business, una solución de 2FA nativa para Microsoft pero requiere de despliegues mixtos en Azure y quizás algo más complejo que el propósito del post.

Una de ellas, algo viejo ya, es la seguridad a nivel de red NLA que establece una autorización previa basada en Kerberos ( si estás en dominio) o mediante TLS antes de realizar el login contra el RDP.

Ahora tenemos la posibilidad de elegir entre dos modos de conexión por RDP a nuestros servers, Windows Defender Remote Credential GuardRestrictedAdmin

Windows Defender Remote Credential Guard

Como puedes comprobar, es más seguro Restricted Admin Mode ya que fuerza a NO usar NTLM y te impide mecanismos de SSO contra otros servicios. Por ejemplo, si usamos el Server Manager de 2016 para administrar un sistema con esta característica, no podremos. Tendremos que hacer login, es más tedioso, pero más seguro.

Al final, en la práctica, basta con activar el modo en el servidor miembro destino, y usar el delimitador mstsc /restrictedAdmin tal que así.

Otra cuestión básica de fortificación es eliminar servicios innecesarios en ese equipo de salto, como por supuesto spooler de impresión, tráfico de SMB, clientes DHCP y todo tipo de servicios que consideréis innecesarios. Esta guía es muy buena si el equipo es server.

Al final, queda claro el sistema bastión o de salto. Microsoft va un paso más allá, y añade el concepto de PAW, privileged Access Workstation en donde especifica una serie de guías detalladas a nivel de UEFI, GPO´s, hardware dedicado de criptología TPM y todo un conjunto de escenarios para desplegar este tipo de equipos bastionados. Dentro de una red Windows el equipo PAW sería el propio de salto, pero imaginaros un entorno de máxima seguridad en el que tengamos un entorno de salto para Amazon, añadiremos una escenario seguro de salto para el equipo de salto xD

Figure showing how accessing an administrative jump server from a PAW adds no path for the attacker into the administrative assets

Para entornos de máxima seguridad en el que tenemos directorios en Azure, se recomiendan estrategias avanzadas de host bastión o de salto, basadas en confianzas de dominios y dominios delegados para administración. Imagina el sysadmin de una sede regional tocando el erp de Azure internacional...

Al final, el objetivo de este post es que penseis en estos escenarios de seguridad, en el que cualquier que sea el caso, no es lógico usar el mismo equipo para bajar películas o ver videos, que para navegar por el banco, o administrar la red de la empresa.

Sea cual sea nuestro tamaño o recursos, debemos llegar a más o menos cotas de aislamiento.

Para cada tecnología o concepto he puesto un link con los pasos exactos y mejores explicaciones de las que pueda dar yo, al final, mi intención es transmitiros la necesidad y aglutinar un poco mi experiencia, los detalles, como siempre, los sacamos por ahí.

Gracias por leerme !!!


martes, 30 de abril de 2019

CON CON CON: Conferencias a montón...

Estimados amigos de Inseguros !!!

Voy a meterme en uno de esos jardines tropicale como suele ser costumbre, pero si no lo hiciese así no sería yo.

Mejor no. Como me han llovido tantas críticas, lo borro. que cada uno luche por lo que pueda.

Un saludo

sábado, 30 de marzo de 2019

Ni Kali Ni Parrot. Windows para pentesting con COMMANDO from Fire eye...

Estimados amigos de Inseguros !!!

Fué liberar ayer la herramienta y planificarme un hueco para el sábado para probarla.

Ya ha salido en varios medios, pero sospecho que ninguno la ha instalado y todos hablan de la misma nota de prensa, más que nada ,porque hablan de lo mismo y usan las mismas capturas...

Como buen freak que soy, voy a darle un vistazo, y como soy viejuno, voy a escribir un post por si a alguien le sirve, o a mi mismo cuando el Alzheimer incipiente aparece.


Commando no es una distribución Windows para pentesting, es una serie de herramientas preconfiguradas que se se instalan en un Windows Existente ( es decir, no te regalan la licencia del Windows) pero que viene cargada de un montón de utilidades super interesantes, con lo que hace muy cómodo el setting inicial de una máquina de pentesting.



Las instrucciones de instalación las tenemos muy amablemente explicadas en la página del proyecto.

Como indican, después de dos clicks y un buen rato tenemos todas las herramientas a nuestra disposición.






Muchas de las herramientas que nos instala son habituales, pero otras muchas no tanto, como por ejemplo todas las herramientas administrativas de windows...Ya sabes, si quieres conectarte a hackear el DNS de un server...mejor por GUI xDD

Otras herramientas como screentogif, editores de texto, gestores de contraseñas, todo eso walkaround necesario para nuestro trabajo...

Una de las recomendaciones generales que tienes que tener en cuenta es que esto baja todas las defensas del sistema, por lo que no es una buena idea instalar este set de herramientas en tu Windows nativo...

Otra de las cosas que me he percatado, como siempre, es que a veces los planteamientos que leemos en internet no son ciertos :-).  Mi instalación del sistema no contiene los mismos elementos que indican desde el proyecto:


Al final por eso es mejor hacer que leer. Varios problemas con Chocolatey, el "ansible" windosero xD me han hecho perder varias horas hasta conseguir instalar todos los scripts. Al final, imagino que el script está diseñado para máquinas muy "virgenes", si ya tienes settings y paquetes complejos instalados, no gestiona muy bien con la definición de versiones y fallos.

Al final, un ratico interesante para descubrir esta "herramienta" que sin duda usará más en detalle.

Gracias por leerme como siempre !!!



Related Posts Plugin for WordPress, Blogger...