jueves, 25 de agosto de 2016

Geolocalizacion Ip en capturas Wireshark y un mapa del tesoro

Estimados amigos de Inseguros !!!

En el proceso de respuesta a incidentes o en una investigación de un suceso solemos analizar ficheros de capturas de red, en el mejor de los casos de que podamos disponer de ellos.


En ocasiones podemos delimitar tráfico anómalo mediante la geolocalización de nuestras conexiones.

En un fichero de captura largo puede ser difícil realizar mediante la tabla de endpoints, y puede que mediante un mapa podamos realizar una discriminación visual y centrarnos en datos sospechosos.

Vamos a habilitar una pequeña función en Wireshark que nada más que consiste en cargarle una base de datos MaxMind en formato DAT de geolocalización y añadir la ruta en Wireshark.





Aparte de parecerme curioso, voy a ver que hace algún "despistado" de por ahí dándome cera xD.

Espero que os sirva de ayuda, gracias por leerme !!!

miércoles, 24 de agosto de 2016

Crea tus reglas automáticas de Firewall mediante capturas PCAP con Wireshark.

Estimados amigos de Inseguros !!!

En el capítulo de hoy vamos a ver una funcionalidad muy interesante de la mano del producto Wireshark.

Como todos sabéis, Wireshark es un sistema para la captura y análisis de redes. Yo particularmente lo uso mucho en mi día a día, bien sea para detectar tráfico anómalo, ver posibles cuellos de botellas, malos usos de la red, respuesta a incidentes, etc.


Hablando con un cliente sobre la segmentación de la red, el cliente no se animaba a crear vlans restrictivas en los distintos departamentos. El problema era que los miembros de "diseño" accedían a MIL aplicaciones, puertos, servicios de la DMZ, y esto multiplicado por muchos departamentos. Crear las vlans con permiso de tráfico entre ellas total no es muy efectivo de cara a la seguridad. Es más lo más efectivo es que no sean Vlans sino redes distintas, pero bueno...

Cuando le presenté la idea al cliente casi me besa, bueno realmente me beso, pero queda feo que yo diga eso :-)

La idea es muy sencilla. Capturamos un poco de tráfico en horario de producción, seleccionamos una máquina tipo. Indicamos al usuario que intente acceder a todo tipo de herramientas. Que si al ERP, que si a la aplicación de la cámara, al correo, no se que, no se cuantos. Lo invitamos a un cafe y le damos una patadita xD.

Ahora es el turno de usar Wireshark. Podemos ir identificando el tráfico y crear las reglas de Firewall apropiadas para el servicio que se ha usado. Pongamos este ejemplo gráfico que seguro es más descriptivo.


Como se aprecia en la captura de imagen, he seleccionado un paquete TCP que es parte de un flujo de conexión a una web por el puerto 80.

Ahora nos situamos en la parte superior, en Tools y pulsamos sobre Firewall ACL Rules.


Tenemos la posibilidad de elegir el formato de salida de la regla que vamos a crear, pudiendo elegir entre:


Voy a usar la regla del estilo Windows que son muy claritas.

El sistema me presenta 4 reglas, dos genéricas para abrir los puertos que intervienen en la comunicación del paquete que le he marcado, y otras dos más restrictivas vinculando la dirección IP concreta.


Como estamos hablando de un cliente TIPO, vamos a usar solo las dos primeras reglas. Tenemos la opción de que la regla sea deny o allow, dependiendo de la configuración por defecto que hayamos marcado en el firewall. Si nuestra última línea del firewall será DENY ALL, configuramos ALLOW, como es lógico.

Si hacemos esto con varios clientes, en distintos tiempos, podemos hacer una conjunto de reglas en base al uso que detectamos, y si no lo teníamos, documentar los servicios a los que acceden los usuarios/departamentos.

El día D, habilitamos el Firewall para la Vlan, y esperamos que los usuarios no se quejen mucho. Siempre saldrá algún servicio de esos que se hacen una vez al mes, y ademas, será viernes, pero bueno es una aproximación para organizar el tráfico entre vlans en un entorno medio complejo, y que vive aún en el /16 de hace 15 años.

Espero que os haya servidor de ayuda, gracias por leerme.

PD: Si has leido el post, has intentado usar la Tool, y no te aparece, tranquilo !!! yo hago el blog para ayudar XD. Tienes que bajar la versión DEV. de Wireshark.

martes, 23 de agosto de 2016

Vete al Infierno !!! DNS SINKHOLE 127.0.0.1 para Windows

Estimados amigos de Inseguros !!!

Como sabéis ando un poco enredado con el mundo del Threat Intelligence y su uso defensivo en las organizaciones.


Básicamente recopilo información de sensores propios y externos, y uso esta información en mis sistemas.

Para el caso de direcciones IP que están dando "guerra" en Internet, el proceso de uso es muy sencillo, incorporas esta inteligencia en tus sistemas perimetrales, firewalls, y cortas el tráfico.

También podemos hacer uso de la inteligencia cargando reglas en nuestros IDS/IPS sean de perímetro o internos.

Podemos usar la inteligencia de los hashes para sistemas de FIM (File Integrity Monitor) o mejor dicho HIDS (Host Ids).

Cualquier IOC (Indicators of Compromise) que nos caiga en las manos podremos usarlo de manera proactiva en nuestros sistemas.


En el episodio de hoy vamos a ver que podemos hacer con recursos IOC del tipo Dominio.

Vamos a usar un maravilloso Script del SANS en concreto editado por el señor Jason Fossen para manejar un servidor DNS Windows.

Lo primero que vamos a hacer es repasar una configuración básica de seguridad de un DNS en una infraestructura Active Directory típica.

Lo normal es tener uno o varios servidores DNS integrados en Active Directory para nuestra red local. Los nombres de los equipos, servidores, webs,etc. Como es normal, nuestro servidor DNS no conoce TODA la infraestructura de Internet, por ejemplo, www.elcorteingles.com por lo que por defecto el servidor se configura para realizar búsquedas autoritativas contra otro servidor DNS. Si no hemos cambiado nada, iremos a los reenviadores por defecto, los servidores ROOT de Internet. Si hemos prestado un poco de cuidado con esto, tendremos puestos nuestros favoritos, los del ISP, Google, o quien sabe !!!

La práctica del SinkHole (traducido es SUMIDERO) es simplemente cargar un fichero en una zona del DNS con registros DNS maliciosos, y hacer que apunten a una dirección IP inválida, por ejemplo 0.0.0.0 o 127.0.0.1 o un servidor con una advertencia.



Mis seguidores de Twitter de vez en cuando leen que publico una lista de dominios maliciosos en formato SNORT para implementar en los IDS.

Voy a crear una lista de dominios maliciosos que están dando la guerra en Internet en las últimas 24 horas, recopilados de mi sistema de Threat Intelligence.

Con este fichero, vamos a cargar los registros en un servidor DNS y de esta manera protegeremos a nuestros usuarios del acceso o mejor dicho la comunicación contra esos dominios.

Para tener una política segura de DNS deberíamos filtrar todo el tráfico DNS saliente de todos los equipos salvo los servidores DNS autorizados. De esta manera evitamos que una pieza de malware implemente su propio servidor DNS o una simple consulta hardcoreada contra un servidor dns concreto externo.

También sería interesante crear el servidor DNS que hará de SinkHole en una DMZ, sin transferencia de zona ni nada, y configurar los servidores DNS internos de Active Directory para que reenvíen al servidor SinkHole. Este resolvería "negativamente" las peticiones maliciosas, y reenviaría a su vez las peticiones DNS normales de navegación a los servidores públicos empleados. Es decir, estaríamos metiendo un salto más en nuestras consultas DNS.
Si no quieres realizar esta tarea, no pasa nada, pero recuerda que tus clientes suelen apuntar a dos servidores DNS internos, y que esta zona SinkHole no se va a replicar entre servidores, por lo que en escenarios en los que el DNS primario no está operativo y los clientes acceden al servidor secundario el sistema no ejecutaría el SinkHole, a no ser que realices el proceso de carga en los dos... Todo esto sin ideas o pistas que lanzo para que comprendas en profundidad como funciona el asunto.

Ahora vamos a las teclas. Hemos descargado el script desde la web del Sans. Ejecutamos una sentencia de prueba:

.\Sinkhole-DNS.ps1 -Domain "cacadevaca.com" -SinkHoleIP "127.0.0.1"

Ahora vamos a realizar lo mismo, pero ejecutamos un fichero concreto:


El resultado es el siguiente:


Como puedes acceder si vas a las propiedades del registro, el TTL del mismo es de 1 hora.

El proceso de creación y actualización del SinkHole debe ser constante, ya que la longevidad o duración de los dominios comprometidos suele ser baja, y mediante el TTL bajo obligamos a los clientes a no usar la posible Cache local del recurso.

Imagina un servidor importante público comprometido, y que durante 3 horas se ha dedicado a distribuir malware. Imagina que se ha detectado y se ha incorporado a una blacklist. Si el incidente ha durado 3 horas, no tiene sentido bloquear el acceso al recurso durante 24 horas, ya que estaríamos interfiriendo en el servicio.

Si por cualquier cosa quieres volver atrás a como tenías tu servidor DNS tranquilo, puedes ejecutar:
.\Sinkhole-DNS.ps1 -DeleteSinkHoleDomains y como todos los registros están en el mismo fichero de zona, se borrarán sin problemas ni interferencias con tus dominios ya configurados.

Podemos realizar un script que vaya a mi repositorio de dominios maliciosos, descargue el fichero, ejecute la actualización del SinkHole y actualice el servidor:

Invoke-WebRequest -Uri https://github.com/kinomakino/snort_rules/blob/master/agosto.csv -OutFile maleantes.txt  

.\Sinkhole-DNS.ps1 -DeleteSinkHoleDomains

.\Sinkhole-DNS.ps1 -InputFile .\maleantes.txt -IncludeWildCard -SinkHoleIP "10.1.1.1"

Si queremos darle más juego al SinkHole, podemos hacer que los dominios apunten a una ip válida en la red, un servidor linuxero que tengamos por ahí. Podemos presentar una web informando al usuario que se ha detectado un tráfico anómalo y se ha procedido a bloquear su conexión a red. Podemos enganchar un Fail2ban que acceda a log de ese server, y ejecutar un BAN en remoto en los sistemas firewalls internos para esa IP y un correo al sysadmin.


Como has podido comprobar, la potencia de usar un SinkHole es inmensa, y es muy sencillo de implementar en entorno Windows y más fácil aún en entornos BIND.

Solo tienes que decidir tu lista de fuentes de reputación favorita y empezar con el proceso.

Si tienes alguna duda, ya sabes !!!

Espero que te haya gustado, gracias por leerme !!!

PD: El fichero agosto.csv publicado está actualizado a fecha hoy.



lunes, 22 de agosto de 2016

Creación de nombres automática para fakes account.

Estimados amigos de Inseguros !!!

El otro día leyendo este artículo del señor Dark Operator se me ocurrieron varias ideas y sobre todo me gustó mucho el artículo. Para darle el sentido en castellano y mi visión os voy a recrear el concepto con mis ejemplos propios.


El concepto es sencillo. Imagina un entorno de post-explotación de un sistema en el que quieres introducir un usuario con persistencia en el sistema. La típica intrusión en un dominio Windows o un Wordpress, y la creación de uno o varios usuarios para poder acceder a posteriori, o para demostrar la intrusión.

En pequeños sistemas la creación de un usuario puede ser detectada ya que seguramente el administrador de un vistazo detecte el usuario "intruso" en cuestión.

En sistemas grandes con miles de usuarios, el proceso manual es casi imposible.

Podemos usar la página Fake Name Generator  para mediante un setting básico de campos, crear un listado de 100,1000, 10000 usuarios que podamos usar para importar en nuestro sistema comprometido.

El sistema nos ofrece la posibilidad de usar un csv,txt, etc o directamente generar las instrucciones en formato SQL.


El resultado podría ser algo parecido a esto:


Ahora podríamos emplear este csv en la importación por ejemplo en un sistema Windows. El artículo original muestras unas powershell que no creo necesarias. Con esta simple sentencia y respetando el formato del CSV podemos realizar la importación:

Import-Module ActiveDirectory
$Users = Import-Csv -Delimiter ";" -Path ".\userslist.csv"
foreach ($User in $Users)
{
    $OU = "OU=Employees,DC=lab-os,DC=com"
    $Password = $User.password
    $Detailedname = $User.firstname + " " + $User.name
    $UserFirstname = $User.Firstname
    $FirstLetterFirstname = $UserFirstname.substring(0,1)
    $SAM =  $FirstLetterFirstname + $User.name
    New-ADUser -Name $Detailedname -SamAccountName $SAM -UserPrincipalName $SAM -DisplayName $Detailedname -GivenName $user.firstname -Surname $user.name -AccountPassword (ConvertTo-SecureString $Password -AsPlainText -Force) -Enabled $true -Path $OU
Podemos ver los usuarios creados en el directorio activo:


Como medida de seguridad, si sospechamos que hemos tenido una intrusión de este tipo podemos usar PowerShell para comprobar la fecha de creación del usuario para detectar este tipo de historias.

Podrías ser así:

Get-ADUser -filter * -properties passwordlastset | sort-object passwordlastset | select-object Name, passwordlastset | Export-csv -path c:\kinotest\listos.csv

Aunque realmente miramos por la fecha de la última contraseña, pero nos sirve.

Espero que os haya gustado el recurso.

Gracias por leerme !!!


lunes, 1 de agosto de 2016

Inteligencia colectiva Ofensiva y defensiva. El video de la charla en PaellaCon

Estimados amigos de Inseguros !!!

Si os interesa el mundo del Threat Intelligence, los IOC´s, los frameworks y herramientas relacionados, y sobre todo, echar un buen ratico, os animo a ver el video de la charla que di al respecto en PaellaCon.

Espero que os guste !!!