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 !!!



viernes, 29 de marzo de 2019

Detección de Lazagne... easy baby.

Estimados amigos de Inseguros !!!

No es nada nuevo si hablamos de la herramienta Lazagne. Una conocida herramienta "juanckers" que ejecutada en el equipo de nuestra víctima, vuelca las claves guardadas que tiene de distintos sitios tan curiosos como los que indica en su repositorio: navegadores, wifis, vnc, putty, etc etc...


La verdad que la detectan todos los antivirus, o la gran mayoría, pero en kiosko, puestos de mediamarkt y cosas así, es muy efectiva, sobre todo con Pendrives Rubber .. etc.

No voy a explicar más sobre esto, pero sí que vamos a intentar ver una manera sencilla de detectar su ejecución.

Para ello nos vamos a nuestro Windows a defender, habilitamos las opciones de auditoría avanzadas, y en concreto, la auditoría de acceso a ficheros tanto correcta como incorrecta.


Luego nos vamos al fichero sobre el que queremos aplicar la auditoría, y elegimos: C:\Users\kinomakino\AppData\Local\Google\Chrome\User Data\Default\Login Data o cualquiera que sea tu usuario. 

Con esto y un bizcocho, tendremos un log muy simpático cada vez que alguien o algo acceda al susodicho recurso. Por lo que si en nuestro gestor de logs levantamos una alerta para cuando el proceso que lee el fichero sea distinto a Chrome... tenemos la detección hecha.



Simple, sencillo, eficaz !!

Y recuerda... vamos por los malos... MUA HAHAHAHA

Gracias por leerme.

miércoles, 13 de marzo de 2019

Gestión de incidentes... Episodio 1. El incidente...

Estimados amigos de Inseguros !!!

La gestión de incidentes es algo que puede dar para varios libros, el DFIR (Data forensic & Incident Response) pero desde el blog quiero daros unas pinceladas, unas opiniones y algunas guías de cómo podemos abordar este proceso tan interesante y puede que a su vez complejo.

Voy a empezar desde lo más bajo, lo más simple, un incidente. Cuando hablamos de incidente, más allá de las nomenclaturas, definiciones, taxonomías y demás historias, vamos a hablar en términos generales para un sysadmin, un responsable de informática como TU, que no tienes porque trabajar en el vertical de la seguridad pero si te gusta.

Imagina el caso de un Ransomware en una empresa, ¿has vivido alguno? lo hayas sufrido en primera persona, en segunda, seas tú el responsable, el técnico, el amigo al que llaman... al final, creo que todos hemos vivido alguna situación relacionada con el Ransomware.

Creo que podemos coincidir sin duda, en que algo común en las empresas en las que pasa, es que se produce un desmadre !!!


El primer punto de desmadre o desconcierto si queremos emplear alguna palabra más acertada es la parte no técnica. A quién llamamos? cómo actuamos? cómo se ha producido? qué pasos damos?

Es normal que esto pase. La gente está parada, hemos perdido o sospechamos que vamos a perder información y estamos "jodidos"...

Si la empresa es pequeña, llamarán al usuario-avanzado-informático que hará lo que pueda, y en paralelo llamarán a una empresa de informática o gurú-freelance para que les ayude.

Si la empresa es mediana, lo mismo, primero al departamento, luego apoyos.

Si la empresa es algo más que mediana, lo mismo el incidente lo detecta programación, se lo pasa a sistemas, estos a seguridad o al pobre que se dedica a la seguridad, a la empresa x, a la y y por si acaso a la Z.

Unos hacen unas cosas, otros recomiendan, asesoran, presupuestan !!!!. este punto es importante.

Es normal en tiempos de crisis que llegue una empresa a "ayudar" y hacer el agosto. Mezclar la fase de urgencia, de remediación, con la consolidación de sistemas, o mejor dicho, implementación de nuevos sistemas es algo habitual. Me explico: tienes un ransomware, lo vas a perder todo, pero aprovecha para mejorar TODA tu infraestructura informática, que es mala o inexistente, pero hazlo ya !!! a prisa !!! porque tienes un ransomware y no queremos que vuelva a pasar !!!!

En la mayoría de los casos habrá que realizar mejoras, pero hay que separar las fases.

Sin haberlo estudiado, con sentido común, lo normal es separar el problema actual del Ransomware, ver como ha entrado, y una vez haya pasado el temporal proponer acciones de mejora.

Comprar antivirus de gama alta, renovar el firewall, aprovechar para replicar en la nube el pequeño servidor, mil copias de seguridad de distinta índole no sirve de nada, si el problema lo tenían con una clave débil en un RDP, o en un Wifi...

Coincides conmigo en que tenemos que ser profesionales ante un incidente. Hay que tener en cuenta una cosa, y es que vamos a vivir pocos incidentes SERIOS en nuestra vida profesional, esto no es una cosa que pasa todos los días y aprendes, sino que debes aprender a "ciegas" o confiar en profesionales muy preparados.

Otro problema muy importante en los incidentes es su detección. Detectar un Ransomware es sencillo, evidente, aparente. trazar su entrada es muy "facilico" también, pero hay datos que avalan que los incidentes de seguridad en las empresas son detectados, de media, 150 días después...

Pongo el caso reciente del ministerio de no se donde de no se qué país...


Calculan que ha estado 3 meses comprometido el sistema...

Recuerdo otro incidente famoso que todo el mundo conoce, Wannacry. Un fallo de seguridad infantil, tontico, sin mucho mérito, provocó un caos monumental, y que he dicho siempre que Telefónica gestionó con maestría.

Recuerdo tener amigos y clientes que me llamaban porque otros informáticos les habían aconsejado apagar internet. no conectarse a internet porque si usaban telefónica, era MUY probable que se infectaran. Hablo de empresas GORDAS recomendando a empresas GORDAS apagar Internet, sin haber estudiado e investigado NADA.

Como es normal, esto es algo que requiere de departamentos complejos o empresas dedicadas, pero dentro de nuestras posibilidades, podemos gestionar estos incidentes o supuestos incidentes de una manera organizada apoyándonos en un software como el que vamos a relatar en las serie.



Vamos a poner otro ejemplo de incidente menos "cantoso" pero que seguro has manejado: un e-mail con spear phishing, con un ataque dirigido hacía alguien de la empresa. O aún más sencillo... un intento de ataque que para el IPS.

Imagina que tu UTM, Firewall, Next Gen o máquina de café te informa de que ha parado un exploit contra un servicio expuesto a las 7:00 am. Perfecto... el correo funciona !!! me llegan notificaciones.

Me llega otro intento a las dos horas. Soy una Pyme y no tengo SIEM ni nada de esto...

A las 3 horas, tercer exploit que detectó. Esto es algo normal, solo si tienes logs ves estas cosas, pero... y si compruebas que la dirección de origen es de una ip de tu ciudad... podrías sospechar que hay alguien "cercano" intentando darte caña? no es lo mismo un ataque así que uno de una botnet que se sabe que recorre internet a diario en busca de...

Realizar esa pequeña comprobación de la ip de origen frente a fuentes públicas puede ayudarte en ponerte alerta.

Esto es una gestión de incidente !!! abres tu ticket, documentas, le pasas un análisis de whois, blacklist, etc y ejecutar una remediación técnica, bloqueas la ip 7 días. Todo esto lo documentas en un software de tickets "dedicado" a los incidentes, y a correr.

Espero que te vayas animando en descubrir algo más de la gestión de incidentes y que profesionalices en la medida de tus posibilidades estas acciones.

En próximos artículos hablaremos de procesos y software que nos ayude en el camino.

Como siempre, gracias por leerme !!!




lunes, 11 de marzo de 2019

Matriz del Mitre...

Estimados amigos de Inseguros !!!

Tanto si te dedicas a la seguridad ofensiva, al famoso Red Team, como si tus problemas son los logs, la respuesta a incidentes y la parte defensiva, el Blue Team, coincidiras conmigo en que la matriz del Mitre es algo que habrás visto en la redes, conferencias y demás.




Yo personalmente la menciono y trabajo en mis charlas, porque creo que es un framework, un marco de trabajo, una taxonomía, una biblioteca... podría darle bastantes calificativos.

En este post voy a presentaros algunos opiniones y explicaciones al más puro estilo murciano para centraros en este "mundillo" que seguro os apasiona.

En primer lugar, quien son MITRE.  Una organización, empresa, que indica en su texto de presentación: Nosotros solventamos problemas para hacer el mundo más seguro. Lejos de ser una consultora de informática, tienen distintas líneas de actuación, y solo una de ellas es la línea de trabajo dedicada a la ciberseguridad.

Desde hace 5 o 6 años han desarrollado varias matrices de datos, las conocidas como Attack en las que aglutinan conocimiento en base a técnicas, tácticas y procedimientos conocidos en el mundo del ciber...

Pero lo mejor es ver una imágen para que lo entiendas.



Como puedes ver, a la izquierda, podemos filtrar entre recursos por sistemas y desde hace poco para entornos móviles.

La matriz selecciona en distintas columnas las tácticas que se emplean, y en filar las técnicas exactas, pudiendo éstas estar en distintas tácticas. Por ejemplo, la fuerza bruta puede ser un elemento de acceso inicial, pero también de escalada de movimiento lateral.


Initial Access
Execution
Persistence
Privilege Escalation
Defense Evasion
Credential Access
Discovery
Lateral Movement
Collection
Exfiltration

Command and Control

El número de técnicas que documentan crece y es muy amplio, pero voy a dejaros dos pantallazos para que os hagáis una idea.


Si nos fijamos en la información que nos muestra, podemos ver la explicación de la técnica, como mitigar el ataque, como detectarlo !!! casi más importante que nada...

Nos muestra bibliografía relacionada, herramientas usadas, grupos de cibercriminales que las han usado, informes públicos en los que aparece esta táctica/técnica.

Al final, es una gran base de datos de conocimiento que podemos usar para muchos propósitos.

Una de las informaciones que manejo son Data Source. Qué fuentes de datos monitorizan o alertan de este ataque.

En el trabajo defensivo, el Blue Team, no solo debemos confiar en un Firewall/UTM, o en un Endpoint o EDR, o en un IDS/IPS, o en un WAF, o en... al final, debemos tener MUCHOS elementos de monitorización para detectar en mayor medida la cantidad de ataques, o intentos, o actividades maliciosas que ocurren en la red y que muchas deben ser estudiadas.

Pongo en mis charlas siempre el ejemplo de imaginar que el atacante tiene la clave de un admin de la red. Ahí ya no valen el 90% de las protecciones "habituales" en la pyme... y luego a luego solo en SOC´s muy preparados.

En la matriz de Mitre podemos encontrar muchos data source: ['File monitoring', 'Process monitoring', 'Process command-line parameters'], ['Packet capture', 'Netflow/Enclave netflow', 'Malware reverse engineering', 'Process use of network'] ['WMI Objects'] etc etc etc

Un buen atacante sería aquel que conoce y controla todas las técnicas implicadas en la matriz, y un buen defensor sería aquel que tendría la manera de detectar/mitigar/parar estos ataques.

El camino es largo amigo... y más si tienes dos o tres elementos. Como he indicado, no creo que haya ningún SOC que sea capaz de darte un 100% de Mitre, no me refiero a la seguridad, porque Mitre no recopila TODO, recopila lo que sabe...

Volvemos al ruedo. Si usas un SIEM para aglutinar la información en un SOC, ya sea este externo, interno, toda una organización o un pequeño software en una VM que nadie ve, al final, tendrás que haberte visto liado con las taxonomías. Cómo categorizar los incidentes, o mejor, los eventos, porque muchas veces el paso de evente a incidente debería ser automático, y no que necesitará la ayuda de un analista... pero bueno, esto son otras cosas.

Imagina que tienes en tu SIEM aparejadas las alarmas con técnicas del Mitre, por ejemplo, cuando un fail2ban detecta una fuerza bruta en un ssh, manda un log al siem, y aparte de los datos típicos, añade : T1078 Valids Account. En esta técnica indica que los data sources que la monitorizan son los logs de autenticación, y la monitorización de procesos, en nuestro caso son los logs de la autenticación.

No podemos decir que para todos los servicios que requieran "account" que requieran login y password tengamos monitorización, pero si sabemos que para el SSH si.

Si vinculamos todas nuestras técnicas a "técnicas Mitre" podemos hacer un estudio mensual por ejemplo, y pedirle al sistema, en base a las alertas que has generado, dame los data sources que tengo.
Tendríamos una lista de Data source, que nosotros ya sabemos, pero estos se identifican dinámicamente según las apariciones de alertas. Digamos que es una vía más de control de si estamos haciendo las cosas bien.

Esta cuestión va dirigida a la auto-evaluación de nuestras capacidades, pero antes de seguir por ahí, vamos a hablar de otro recurso no-Mitre pero muy interesante, y luego seguimos con el Mitre.


Hablo de un proyecto muy interesante para medir las capacidades del SOC a varios niveles, no solo a nivel de la capacidad de correlación, monitorización, respuesta a incidentes, sino desde todos los planos. incluyendo el organizativo, empresarial, reporting, etc. El proyecto recopila una seria de preguntas en formato Excel guiado y mediante unas fórmulas nos da el grado de madurez del servicio.

Podemos descargar gratuitamente el proyecto desde https://www.soc-cmm.com/ y realizar nuestros "self assesment".

Pero ahora volvemos al Mitre, y al concepto de medir nuestras capacidades.

Tenemos un mapa Mitre sobre el que podemos "trabajar" ubicado en : https://mitre-attack.github.io/attack-navigator/enterprise/#

Por supuesto es un proyecto que podemos bajar a nuestros servidores y así "garantizar" la seguridad del mismo. Si hacemos uso de las numerosas api´s de consulta que hay ( yo uso la api https://github.com/Cyb3rWard0g/ATTACK-Python-Client/blob/master/notebooks/Usage_Basics.ipynb del señor @Cyb3rWard0g ) podemos hacer "chulas"

Por ejemplo, a mi se me ha ocurrido usar una capa sobre la matriz original, que según el grado de madurez del data source, busque las técnicas asociadas y coloree, según un gradiente, el mayor o menor estado de la monitorización. Bien para informes, para clientes, para control interno, para tener un mapa de ataques por técnicas Mitre, por lo que sea, podemos jugar con casi todo.

Un ejemplo de json sencillo:

{
    "domain": "mitre-enterprise",
    "name": "example",
    "gradient": {
        "colors": [
            "#ffffff",
            "#ff6666"
        ],
        "maxValue": 100,
        "minValue": 0
    },
    "description": "hello, world",
    "version": "2.1", 
    "techniques": [
{
"techniqueID": "T1213",
"score": 85
},
{
"techniqueID": "T1092",
"score": 15
},
{
"techniqueID": "T1200",
"score": 10
},
{
"techniqueID": "T1119",
"score": 20
},
{
"techniqueID": "T1160",
"score": 10
},
{
"techniqueID": "T1188",
"score": 10
},

Si subimos esta capa a la matriz navegable obtenemos algo así:


Podemos usar una tabla intermedia para construir el json que vaya incrementando el valor de la detección según los data sources, pero sobre elementos distintos, para no creernos que con monitorizar el ssh estamos cubiertos, ni mucho menos. Tanto la gestión como organización de esta información es algo tedioso, que necesita de bastante dedicación, y que solo para estructuras de SOC formales con personal cualificada tendrá sentido trabajar.

Otra cosa es que como he dicho, como atacante o defensor, usas este matriz para evaluarte y guiarte en tus estudios, o en tu trabajo. 

Sin duda,  ir aumentando el grado de "control" de las técnicas es algo básico tanto para Red como para Blue.

Espero que os haya gustado la medio explicación de la matriz de Mitre y que os sirve de inspiración las distintas vías de interacción que nos permita el framework.

Hay muchas aproximaciones que podemos hacer con la matriz, como por ejemplo, usar este magnífico recurso que correla eventos de Windows con posibles técnicas de ataque.

Tenemos otros recursos en forma de aplicaciones de entrenamiento, Caldera y RedCanary, similares a Infection Monkey que vimos aquí hace años. Son colecciones de ataques basados en las taxonomías de Mitre que nos ayudan a evaluarnos, de una manera ordenada.

Muchas gracias por leerme, un saludo !!!

viernes, 8 de marzo de 2019

Linux más seguro: claro que no guapiiii !!!

Estimados amigos de Inseguros !!!

Hoy voy a reflexionar o contar una pequeña anécdota laboral pero que realmente aporta valor en la reflexión de muchos de mis argumentos cuando discuto con algún fanboy/talibán de mi también querido Linux.



Me gusta lo mismo Mac, Windows, Linux... son herramientas con las que trabajo, es como a quien quiero más, a Papá o Mamá...


Por supuesto, tengo mis preferencias, prefiero MICROSOFT, pero lo que tengo claro es que los 3 son válidos, y siempre intento ser objetivo a la hora de usar unos u otros en beneficio del cliente/solución/necesidad, etc. Los que sólo reivindican uno u otro, sois unos pringuis, jejejeje.

Entonces ahora sigo con la reflexión.

Auditoría interna a empresa NORMAL, ni ibex35, ni banca, ni pyme, empresa NORMAL, con 150 equipos, no muchas medidas de seguridad, un montón de fallos, un montón de cosas que también hacían bien...si si, has leído bien, aunque esto no lo ponemos en los informes hay empresas que también hacen algunas cosas bien.


En esta empresa usaban una red Active Directory basada en 2012 server. Los equipos eran medio recientes con Windows 10. No es esa mirda de escenario de algunas demos con DC 2008, windows 7, smb1, wdigest y Mimimatz hasta la cocina porque no hay antivirus en el servidor. Esta empresa no era así, eran normales !!!! su sysadmin hacía las cosas normal, ni muy pro seguridad ni muy cafre.

Tenía un Wsus para actualizar los equipos y una herramienta de gestión y monitorización de equipos. Ahora es cuando un fanboy me diría un Nagios... un Zabbix.... NO, una RMM tools. Con sus indicadores, gestión de parches de aplicaciones cliente, soporte, etc... * no digo que las dos herramientas Software Libre que menciono no sean buenas, sino que no son RMM, son solo M*

Los equipos tenían un antivirus normalito, con su consola centralizada empresarial. La verdad es que el antivirus no era el más pelado, pero tampoco era un EDR, simplemente que aparte de por firmas, detectaba algún comportamiento raro, algo de Threat I... eso, que no era como ClamAv...

La empresa tenía departamento de programación y diseño (marketing), tanto para la web como para procesos internos de integración, reporting, tambien algo normal. En estos departamentos se usaban 3 equipos MAC para diseñadores y 4 linux, 3 debian y 1 ubuntu creo.

El resultado de la parte interna fué el esperado, cocina, clave del administrador y un porrón de servicios vulnerados.

La cuestión es, que es a donde voy, en cómo medimos la seguridad. Si me apuras, podría incluso medio aceptar que el diseño del kernel de linux y su funcionamiento puede ser un poco más seguro que el de Windows. Quizás borre esto algún día, pero la vida no es Kernel, la vida es MUY compleja.


Dentro del catálogo de recomendaciones generales que hicimos a dirección, encontramos que:

1.- los antivirus en linux/mac no existían. Y que no me digan que no hay virus en LINUX porque virus quizás no, pero cuando auditas un equipo que tiene un AV y te pilla la webshell, o la shell meterpreter, o la ejecución de algún exploit conocido, te complica más el asunto, y si tienen monitorización ponen al perro en guardia...

2.- las actualizaciones de los equipos regían por el criterio del usuario, osea, ninguno. Encontramos en el entorno Microsoft un relación de software más o menos bien controlado, mientras que en linux/mac, a pesar de usar la misma herramienta RMM, tenían disparidad de versiones, por las particularidades del diseñador/programador.

3.- los entornos no cumplian la LOPD ni la gestión centralizada del servicio de directorio,en este caso Active Directory, porque no tenían instalado los agentes. complejidad de contraseña, revocación, bloqueo de escritorio, GPO´s varias, NADA.

4.-en estos equipos se encontró un montón de software no controlado por permisos de instalación. Máquinas virtuales de pruebas al antojo del usuario eran la tónica general de estos sistemas. Normal, el programador levantaba su entorno de PRE. sin control ninguno. Insisto, eran una empresa normalita, no había team master, DEVops y ni versionado de aplicaciones.

Al final de las muchas recomendaciones que emitimos en el informe, y de los fallos que aparecieron, muchos estaban relacionados a cómo se gestionaban o como NO-gestionaban estos equipos.

Como es normal, para estos 4 casos que os pongo, si eres un buen sysadmin, tiene solución. Una buena monitorización, un directorio activo LDAP standard, Ansible, etc etc, pero hablo de la REALIDAD de las empresas. De las empresas en las que he trabajado que el usuario Linux suele ser el avanzado, el de departamento de informática, los programadores, y al final, son puntos habituales de fallos. ya sabes, dejale el root del servidor al programador y que haga lo que quiera...

Entonces, vuelvo a mi planteamiento inicial, Es más seguro Linux? en este caso NO. Como siempre, abogo porque la seguridad está en las manos de quien administra, pero insisto en que esta tendencia que indico en el post, no es de un o dos clientes, suele ser la tónica general respecto a linux, igual que tener un AD bien configurado no es la tónica general, también tengo que aclarar...

No obstante, las cosas están cambiando. Esta mañana he leído en Barrapunto que era el año del Escritorio basado en Linux...

Gracias por leerme.