AppLocker, App Control for Business (WDAC) y la distribución de aplicaciones empresariales — antes de que las bloquee el «control de ejecución»

«Instalé la aplicación en el equipo del cliente, pero no arranca. Al hacer doble clic no pasa nada»: en los proyectos de desarrollo por encargo de aplicaciones Windows, este tipo de consulta llega con una frecuencia cada vez mayor. Al investigar la causa, resulta que lo que detenía la aplicación, sin mostrar siquiera un cuadro de error, era el control de ejecución de aplicaciones que cada vez más clientes tienen implementado.

Windows dispone de varios mecanismos para permitir que solo se ejecuten las aplicaciones autorizadas: AppLocker, App Control for Business (durante mucho tiempo llamado WDAC, Windows Defender Application Control) y, para el uso personal, Smart App Control. En el contexto de la seguridad se suele explicar «desde el lado de quien lo implementa», pero este artículo cambia de perspectiva y lo aborda desde el lado de quien desarrolla y distribuye la aplicación. Repasamos los patrones típicos por los que una aplicación empresarial propia resulta bloqueada en el entorno del cliente, qué registro hay que consultar para confirmarlo cuando ocurre un bloqueo, y qué medidas puede tomar de antemano el lado de desarrollo y distribución. Al final resumimos también los puntos clave, desde la perspectiva de sistemas de información, para quien evalúe implementarlo en sus propios equipos.

1. Conclusiones principales

• El control de ejecución debe entenderse en cuatro categorías diferenciadas: SmartScreen, que advierte y deja elegir; AppLocker, que controla mediante reglas por usuario o grupo; App Control for Business, que se aplica a toda la máquina; y Smart App Control, que actúa automáticamente para el uso personal (tabla de decisión del capítulo 2).
• La idea de que «AppLocker es exclusivo de Enterprise» está desactualizada. Desde la KB 5024351, en Windows 10 versión 2004 en adelante y en todas las ediciones de Windows 11 ya no se necesita una edición específica para aplicar la directiva.¹
• App Control for Business puede usarse en todas las ediciones cliente de Windows 10/11 y en Windows Server 2016 en adelante. Microsoft recomienda usar App Control en lugar de AppLocker siempre que sea posible.²
• El eje de las medidas del lado de la distribución es la firma de código. Firme con información de emisor coherente no solo el exe, sino todos los binarios, incluidas las DLL, y el instalador (capítulo 5). Con la difusión de Smart App Control, ha empezado a haber casos en los que una aplicación sin firmar no funciona ni siquiera en un PC personal.³
• La prueba de un bloqueo se puede confirmar en el registro de eventos. Con AppLocker, el punto clave es el evento 8004 de «AppLocker - EXE and DLL»; con App Control, el evento 3077 de «CodeIntegrity - Operational» (tabla de decisión del capítulo 4).⁴⁵
• Un script de PowerShell puede no «bloquearse», sino «ejecutarse en modo restringido». En un entorno con App Control, un script que no cumple la directiva se ejecuta en modo de lenguaje restringido (Constrained Language Mode), lo que produce un fallo confuso: «funciona, pero solo falla una parte del proceso».⁵
• Quien lo implementa debe empezar por el modo de auditoría. Tanto AppLocker como App Control disponen de un modo que, en lugar de bloquear, registra «lo que se habría bloqueado»; corresponde a los eventos 8003 y 3076.⁴⁵

2. Diferenciar los cuatro mecanismos

Empecemos con el mapa general. Como los nombres se parecen y se confunden con facilidad, los distinguimos por «quién los administra», «sobre qué unidad actúan» y «cómo actúan».

2.1. SmartScreen — el único mecanismo que detiene mediante una «advertencia»

SmartScreen es un mecanismo que «advierte sobre lo que tiene mala reputación», y por defecto el usuario puede continuar. Sin embargo, en entornos administrados puede haber activada una directiva que prohíbe precisamente continuar tras la advertencia, en cuyo caso SmartScreen también actúa, en la práctica, como un bloqueo (este tema se trató en «Windows SmartScreen y la firma de código»).

Desde el punto de vista de quien distribuye, las características de SmartScreen son que actúa por defecto aunque no exista un administrador que escriba reglas, y que el motivo del bloqueo no es una directiva, sino la «reputación». Por eso el tratamiento también es distinto al de los otros tres mecanismos: en lugar de pedir al cliente que escriba una regla de permiso, la solución pasa por la firma y la acumulación de reputación. Los apartados 2.2 a 2.4 que siguen tratan mecanismos que bloquean en lugar de advertir.

2.2. AppLocker — el veterano que permite controlar por usuario

AppLocker es un control de ejecución introducido en Windows 7 que define reglas a partir de atributos del certificado de firma de código (el editor), atributos de archivo derivados de los metadatos de firma (nombre de archivo original y versión) o del hash, y la ruta del archivo. La directiva puede aplicarse a todo el equipo o a usuarios y grupos concretos.²

Los requisitos de edición son un punto donde abundan los malentendidos. La documentación actual es clara: desde la KB 5024351, en Windows 10 versión 2004 en adelante y en todas las ediciones de Windows 11 no se necesita una edición específica para aplicar las directivas de AppLocker. En versiones anteriores (Windows 10 previo a la 2004, incluido Windows Server 2019), se mantiene la restricción tradicional: la aplicación mediante distribución por Directiva de grupo solo está disponible en las ediciones Enterprise y Server, mientras que la distribución mediante MDM funciona en todas las ediciones.¹

Si se ordena «qué se puede hacer en Pro» separando si se pueden crear reglas de si las reglas creadas realmente se aplican (se hacen cumplir), el resultado es el siguiente. Que estas dos cosas sean distintas es la razón por la que sobrevive la idea antigua.¹

Se suele creer erróneamente que «en un entorno Pro ni siquiera se pueden crear reglas», pero la creación es posible en cualquier edición. Lo que antes estaba diferenciado era la aplicación, y aun así, con distribución MDM, ya entonces era posible aplicarla también en Pro. Los tipos de regla disponibles (archivo ejecutable, instalador de Windows, script, DLL, aplicación empaquetada) no varían según la edición.¹ Cabe señalar que, sea cual sea la edición, si el servicio de identidad de la aplicación (AppIDSvc, Application Identity) no está en ejecución, las reglas no se evalúan (capítulo 6).

Sin embargo, AppLocker tiene una advertencia importante. La propia Microsoft indica explícitamente que AppLocker no cumple los criterios de servicio (servicing criteria) del MSRC como función de seguridad. Es decir, aunque se encuentre un método de evasión, este no se trata como una vulnerabilidad de seguridad propiamente dicha.²

2.3. App Control for Business — la opción principal como función de seguridad

App Control for Business es el nombre actual del mecanismo que apareció en Windows 10 como «Device Guard» e «integridad de código configurable (WDAC)». La directiva se aplica a toda la máquina y afecta a todos los usuarios del dispositivo. Las reglas pueden basarse en atributos del certificado de firma, atributos de archivo o hash, la evaluación del Intelligent Security Graph (ISG) de Microsoft, el proceso que inició la instalación (instalador administrado o managed installer), la ruta del archivo (desde Windows 10 1903) y el proceso de origen de la ejecución.²

Este mecanismo está diseñado como una función de seguridad definida por los criterios de servicio del MSRC. Sus condiciones de uso también son amplias: la directiva se puede crear y aplicar en cualquier edición cliente de Windows 10/11, o en Windows Server 2016 en adelante. La distribución puede hacerse mediante MDM como Intune, Configuration Manager o PowerShell. También se puede distribuir mediante Directiva de grupo, pero solo en el formato de directiva única (single policy) que funciona en Windows Server 2016/2019.²

Sobre cuál usar, la indicación de Microsoft es clara: si se puede implementar con App Control, debe usarse App Control, ya que este sigue recibiendo mejoras mientras que AppLocker solo recibe correcciones de seguridad, sin funciones nuevas. AppLocker resulta adecuado cuando conviven versiones antiguas de Windows y se quiere distribuir la misma directiva, cuando se trata de PC compartidos que necesitan reglas distintas por usuario o grupo, y como complemento de App Control para añadir restricciones por usuario.²

2.4. Smart App Control — el control de ejecución que se activa «por su cuenta» en los PC personales

Smart App Control es una función de protección de Windows 11 orientada a usuarios particulares. Al intentar ejecutar una aplicación, comprueba si un servicio de seguridad en la nube puede predecir la seguridad de esa aplicación, y bloquea las aplicaciones consideradas maliciosas y aquellas sin firma válida cuya confianza no puede confirmarse. En los equipos nuevos comienza en modo de evaluación, y Windows decide automáticamente si activarlo o desactivarlo según si conviene a ese usuario (en perfiles con más probabilidad de bloqueos frecuentes, como los desarrolladores, se desactiva automáticamente).³

El significado para quien distribuye es sencillo: ha llegado la época en que, incluso en PC fuera de la administración empresarial —es decir, en equipos de pequeñas empresas o autónomos clientes—, el control de ejecución viene activado por defecto. Aunque ningún administrador haya escrito una sola directiva, una aplicación sin firmar puede resultar bloqueada. La propia guía de Microsoft para desarrolladores menciona firmar la aplicación con un certificado válido como forma de evitar el bloqueo.³

3. Patrones típicos en los que su aplicación resulta bloqueada

A continuación se listan, por causa, los patrones que se dan realmente en el desarrollo por encargo y la distribución de paquetes.

El patrón común es que quien distribuye no está proporcionando de forma estable la base sobre la que se permite la ejecución (firma, ruta, hash). Aunque el área de sistemas de información del cliente quiera escribir una regla de editor, si la firma solo cubre parte de los binarios no tiene más remedio que usar una regla de hash, y esa regla se rompe cada vez que usted publica una nueva versión. Aunque parezca que la responsabilidad del bloqueo recae en quien lo implementa, en la práctica la causa de que las reglas sean frágiles suele estar del lado de la distribución.

4. Confirmar lo ocurrido mediante los registros

Si la causa de que «no arranque» es el control de ejecución, se puede confirmar con el registro de eventos, sin necesidad de suponer. Hay dos sistemas de registro a consultar.

4.1. Eventos de AppLocker

Consulte Registros de aplicaciones y servicios\Microsoft\Windows\AppLocker, en el Visor de eventos.⁴ Para quien lo abre por primera vez, dejamos anotado el recorrido.

Visor de eventos (en el menú Inicio, escriba «Visor de eventos», o ejecute eventvwr.msc desde Ejecutar) > Registros de aplicaciones y servicios > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

En un entorno en inglés es Applications and Services Logs > Microsoft > Windows > AppLocker. Si prefiere evitar la interfaz gráfica, puede abrir PowerShell como administrador y leerlo con esta línea (también es la forma más rápida de pedírselo al cliente):

# Extraer los bloqueos (8004) y las auditorías (8003) de AppLocker de las últimas 24 horas
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

El evento registra la ruta del archivo, si se permitió o se bloqueó, el tipo de regla aplicada (ruta, hash o editor) y su nombre, y el SID del usuario o grupo de la regla.⁴ Aun así, hay que tener cuidado al interpretarlo. En una operación de tipo lista de permitidos (allowlist), la mayoría de los bloqueos no se deben a que se haya coincidido con alguna regla de denegación, sino a un rechazo implícito por no coincidir con ninguna regla de permiso. En ese caso, el evento 8004 solo confirma «el hecho del bloqueo y el archivo afectado»; el nombre de la regla no sirve de pista. Cuando se trata de una regla de denegación explícita, el nombre de la regla es directamente la causa, pero en un rechazo implícito hay que cotejarlo con la directiva vigente para averiguar «qué regla de permiso falta».

4.2. Eventos de App Control for Business (WDAC)

Los bloqueos de App Control aparecen en otro lugar: Registros de aplicaciones y servicios\Microsoft\Windows\CodeIntegrity\Operational. El control de exe, DLL y controladores va aquí; el control de MSI, scripts y COM va al registro «AppLocker - MSI and Script» mencionado antes: así se reparte.⁵

Visor de eventos > Registros de aplicaciones y servicios > Microsoft > Windows > CodeIntegrity > Operational (en inglés, Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# Ver juntos los bloqueos (3077) y auditorías (3076) de App Control y su información de firma correspondiente (3089)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

Cuando no está claro cuál de los dos mecanismos causó el bloqueo, lo más fiable es colocar estos dos registros lado a lado en el mismo intervalo de tiempo y cotejarlos.

El evento 3089 se pasa por alto con frecuencia, pero es importante. Se genera un registro por cada firma del archivo, y en un archivo sin firmar se genera un único registro con cero firmas. Aquí se puede confirmar un fallo del lado de la distribución, como «se supone que estaba firmado, pero se trata como no firmado» o «queda la firma de un certificado antiguo».⁵

El comportamiento de los scripts requiere una atención especial. El evento 8029 indica que «se bloqueó un script», pero la aplicación real depende del comportamiento del host del script; por ejemplo, PowerShell no detiene por completo un script que no cumple la directiva, sino que lo ejecuta en modo de lenguaje restringido (Constrained Language Mode).⁵ Como la creación de objetos .NET queda ampliamente restringida, se produce un fallo a medias: «el script en sí funciona, pero solo falla una línea intermedia». Si su aplicación incluye scripts, desconocer este comportamiento alarga la investigación (los aspectos prácticos de la firma de scripts se tratan en «La directiva de ejecución de PowerShell y la firma de scripts»).

Además, el registro «AppLocker - MSI and Script» no existe en la edición Windows Server Core.⁵ Téngalo en cuenta al investigar aplicaciones desplegadas en servidores.

5. Medidas del lado de la distribución — hacer que la aplicación sea «fácil de reglamentar»

En lugar de reaccionar después de un bloqueo, lo correcto es distribuir de forma que el área de sistemas de información del cliente pueda escribir una regla de permiso estable. No hay tanto que hacer.

1. Firme con Authenticode todos los binarios. No solo el exe, sino también las DLL de compilación propia, el instalador (MSI o exe de configuración) y los scripts incluidos. Como la regla de editor se basa en los metadatos de firma (editor, nombre de producto, nombre de archivo, versión), si está firmado se puede escribir una regla que resiste las actualizaciones, del tipo «se permite este producto de este editor, sin importar la versión».² Elija un certificado emitido por una entidad de certificación de confianza y basado en RSA. Un certificado autofirmado o de una CA interna no funciona en los PC de clientes que no confían en esa CA, y tampoco es compatible con Smart App Control. Además, como la verificación de firma de Smart App Control no admite firmas ECC (curva elíptica), si firma con un certificado ECC puede acabar tratándose, en un PC personal, como si no estuviera firmado.⁶ La misma restricción existe en App Control: las reglas basadas en el firmante solo admiten RSA (hasta 4096 bits), y los archivos con firma ECDSA no se pueden permitir mediante una regla de editor (el evento de información de firma 3089 muestra VerificationError = 23).⁷ Si elige el certificado pensando que «ECC es más nuevo y más fuerte», el resultado es contraproducente desde el punto de vista del control de ejecución.
2. Añada siempre un sello de tiempo. Así la validez de la firma se mantiene aunque el certificado caduque. El procedimiento práctico de firma y su relación con SmartScreen se resumen en otro artículo.
3. Mantenga estables la información del editor y el recurso de versión de los archivos. Si al renovar el certificado cambia el sujeto (el nombre de la organización), la regla de editor se rompe. Si cambia la denominación de la empresa o el origen del certificado, incluya un aviso previo al cliente en las notas de la versión. Otro punto que se pasa por alto es que el «nombre de producto», el «nombre de archivo original» y la «versión» de la regla de editor no se toman del certificado, sino del recurso de versión (información de ensamblado) de cada archivo. Si deja esos campos vacíos, o cambia el nombre de producto o del ejecutable en cada versión, las reglas centradas en un producto o archivo concreto se rompen aunque el firmante sea el mismo.
4. Acerque la ubicación de los ejecutables a lo estándar. Instale bajo Program Files y evite el diseño que extrae exe/DLL a %TEMP% o %APPDATA% en tiempo de ejecución para arrancarlos desde ahí. Un diseño que se ejecuta en una ubicación con permiso de escritura es, por naturaleza, incompatible con un entorno basado en reglas de ruta.
5. Revise el diseño de la actualización automática. Firme también el propio programa de actualización, de modo que actualizar sea un flujo cerrado que «sustituye un binario firmado por otro binario firmado». Cuando la distribución se hace mediante Intune o Configuration Manager, si el cliente ha configurado ese agente de distribución como instalador administrado (managed installer), se vuelve posible permitir los binarios que entran a través del instalador. No es algo que actúe automáticamente —requiere una configuración explícita del lado del administrador—, pero si tiene preparado un MSI compatible con instalación silenciosa puede ofrecer esa opción al cliente (el diseño seguro de la actualización automática se trata en «La seguridad de las actualizaciones automáticas»).
6. Prepare de antemano la información para el caso de un bloqueo. Si el «manual de implementación» detalla el sujeto de la firma, la lista de binarios necesarios para la ejecución y la ruta de instalación, el área de sistemas de información del cliente podrá escribir la regla solo con eso. Ante un problema, si indica los ID de evento del capítulo 4 al pedir que lo revisen, basta con un solo intercambio.

Estos seis puntos también sirven directamente como preparación frente a Smart App Control. Un binario firmado y con reputación acumulada tiene menos probabilidades de caer en el bloqueo automático de un PC personal.³

5.1. Al obtener por primera vez un certificado de firma de código

Como quedarse en «hay que firmar» no permite avanzar, dejamos anotado el siguiente paso para quien todavía no tiene un certificado.

Cómo elegir el certificado. Lo que se puede usar es un certificado de firma de código emitido por una entidad de certificación pública (CA comercial). Un certificado autofirmado o de una CA interna no se puede verificar en los PC de clientes que no confían en esa CA, así que no sirve para distribuir. Entre los certificados de CA pública existen el OV, con verificación de la existencia real de la empresa, y el EV, con una revisión más estricta, pero desde el punto de vista de las reglas de editor de AppLocker o App Control se puede escribir la regla igual con cualquiera de los dos. App Control tiene una opción de regla que exige firma EV (Required:EV Signers), pero la documentación indica explícitamente que no es compatible por el momento, así que hoy no hay motivo para elegir EV pensando en el control de ejecución.⁷

Sobre el coste. El importe varía según la CA y el período de validez, por lo que hay que solicitar presupuesto, pero conviene conocer la estructura del desglose para poder comparar. Desde el 1 de junio de 2023, según los requisitos del CA/Browser Forum, es obligatorio generar y almacenar la clave privada, tanto en OV como en EV, en hardware de nivel equivalente o superior a FIPS 140-2 nivel 2 (un HSM o un token USB).⁸ Es decir, el coste incluye no solo el «certificado en sí», sino también el «token o HSM, o la tarifa de uso de un servicio de firma en la nube ofrecido por la CA». Si quiere firmar automáticamente en CI/CD, un servicio de firma en la nube resulta más fácil de integrar que un token físico, así que consulte también el modo de operación de la firma al pedir presupuesto.

El comando de firma mínimo. Se usa signtool, incluido en el Windows SDK.

:: Firmar (con hash SHA-256 y sello de tiempo RFC 3161)
signtool sign /fd sha256 /tr <URL del servidor de sellado de tiempo> /td sha256 /a MyApp.exe

:: Verificar la firma (valida con la directiva de Authenticode y muestra el detalle)
signtool verify /pa /v MyApp.exe

/fd es el algoritmo de hash del archivo, /tr la URL del servidor de sellado de tiempo RFC 3161, /td el algoritmo de hash del sello de tiempo, y /a la opción para que se seleccione automáticamente el certificado adecuado del almacén. Use la URL del servidor de sellado de tiempo que indique la CA a la que compró el certificado. Si firma con la clave de un token o un HSM, la especificación del CSP/KSP figura en el manual de la CA. Tanto la DLL como el instalador se firman con el mismo comando, así que lo más fiable es aplicarlo todo junto al final de la compilación.

Qué se rompe al renovar el certificado. La regla de editor se basa en la información del emisor de la firma (cadena de certificados y sujeto). Por eso, los siguientes cambios hacen que la regla del cliente deje de coincidir sin previo aviso.

• Cambiar la denominación de la empresa (por ejemplo, cambiar el sujeto del certificado de Komura Soft LLC a 合同会社小村ソフト). Aunque sea la misma empresa, si la cadena de texto es distinta, se trata de un editor distinto.
• Cambiar de CA. La regla de nivel Publisher de App Control combina el «certificado de la CA intermedia (PCA) + el CN del certificado hoja», así que si cambia la CA, cambia la PCA y deja de coincidir.⁷
• Cambiar el nombre del ejecutable o del producto. La regla de nivel FilePublisher incluye, además de lo anterior, el nombre de archivo original (OriginalFileName) y la versión mínima.⁷

En todos los casos el síntoma es el mismo: en el momento en que se sustituye por la versión actualizada, la aplicación deja de arrancar únicamente en ese entorno. Y como desde el punto de vista del cliente es «se actualizó y se rompió», no se sospecha que la causa esté en la firma. Al renovar o cambiar el certificado, incluya en las notas de la versión un aviso con la información de firma anterior y la nueva (sujeto, CA emisora), para que el área de sistemas de información del cliente pueda añadir la regla.

6. Puntos clave para quien la implementa (sistemas de información)

Para el lado que implementa el control de ejecución en sus propios equipos, en este artículo nos limitamos a los puntos esenciales.

1. Elija la tecnología. El criterio general es App Control for Business. En PC compartidos que necesiten control por usuario, o en entornos con sistemas operativos antiguos mezclados, combínelo con AppLocker.² Para equipos de uso fijo, como terminales de tipo quiosco, resulta más sencillo restringir primero mediante el shell (véase «El modo Quiosco y el acceso asignado de Windows») y a partir de ahí definir las reglas, que quedan más simples.
2. Empiece siempre por el modo de auditoría. En el «solo auditoría» de AppLocker se registran los eventos 8003 y 8006, y en el modo de auditoría de App Control los eventos 3076 y 8028, con «lo que se habría bloqueado de haberse aplicado».⁴⁵ El procedimiento de recopilar hasta completar un ciclo de operación antes de pasar a la aplicación es exactamente el mismo que con la firma SMB o la restricción de NTLM. Si usa AppLocker, tenga en cuenta un requisito previo: la directiva de AppLocker no se evalúa si el servicio de identidad de la aplicación (AppIDSvc) no está en ejecución, y en ese caso tampoco aparecen eventos aunque active el modo de auditoría. Antes de empezar la auditoría, configure el inicio automático de este servicio en los equipos afectados.
3. Lleve un registro de las excepciones. Las aplicaciones antiguas que se sigan usando sin firmar quedan registradas como excepción mediante una regla de hash. Esa lista es, en sí misma, el listado de «lo que algún día habrá que renovar», así que revísela cada año junto con la gestión de activos.

El paso 2, «empezar por el modo de auditoría», lo dejamos aquí con el flujo mínimo, para no tener que remitir a otro artículo.

Con AppLocker (3 pasos)

1. Active el modo de auditoría. En el editor de administración de Directivas de grupo (localmente, secpol.msc), abra Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas de control de aplicaciones > AppLocker, haga clic con el botón derecho en AppLocker y elija Propiedades. Marque «Configurado» para cada colección de reglas (archivos ejecutables, instalador de Windows, scripts, aplicaciones empaquetadas) y seleccione «Solo auditoría». Cree también las reglas predeterminadas para cada colección y configure, en los equipos afectados, el servicio de identidad de la aplicación (AppIDSvc) en inicio automático (si no está en ejecución, la directiva no se evalúa y tampoco se generan eventos).

2. Recopile los eventos. Hasta que se complete un ciclo de operación, recopile el evento 8003 (exe/DLL) de Microsoft-Windows-AppLocker/EXE and DLL y el 8006 (scripts y MSI) de MSI and Script.⁴ Aquí hay que tener cuidado: el comando de PowerShell del capítulo 4 fija el nombre del registro en «EXE and DLL», así que tal cual no recoge el 8006 de scripts y MSI. Como los registros están separados, es necesario recorrer los dos de la siguiente manera:

    # Recopilar de dos registros, en modo de auditoría, "lo que se habría bloqueado de haberse aplicado"
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   Se incluye -ErrorAction SilentlyContinue porque Get-WinEvent devuelve un error cuando un registro no tiene ni un solo evento coincidente. Si también controla aplicaciones empaquetadas, añada de la misma forma Packaged app-Deployment / Packaged app-Execution. Compruebe que se recogen incluso los procesos por lotes mensuales o anuales.

3. Cambie a modo de aplicación. Incorpore a las reglas de permiso lo detectado en 8003 y 8006, y luego, en la misma pantalla de propiedades, cambie a «Aplicar reglas». Tras el cambio, vigile los eventos 8004 (bloqueo de exe/DLL) y 8007 (bloqueo de scripts y MSI).

Con App Control for Business el flujo es el mismo: distribuya con la opción de regla 3 (Enabled:Audit Mode) incluida en el XML de la directiva (configúrela con el App Control Policy Wizard o con el cmdlet Set-RuleOption), recopile 3076 y 8028, y después elimine esa opción para cambiar a modo de aplicación. Microsoft también recomienda verificar primero el impacto con Enabled:Audit Mode.⁷

7. Resumen

• El control de ejecución debe entenderse distinguiendo entre SmartScreen, que «advierte», y AppLocker, App Control for Business y Smart App Control, que «bloquean» (aunque SmartScreen también actúa, en la práctica, como un bloqueo bajo una directiva de administración que prohíbe continuar tras la advertencia).
• Las restricciones de edición de AppLocker ya se han relajado (Windows 10 2004 en adelante y todas las ediciones de Windows 11), y App Control ya podía usarse en todas las ediciones cliente desde el principio. Ya no es válido decir «a mi cliente no le afecta porque tiene Pro».¹²
• Con Smart App Control, el control de ejecución ha llegado incluso a los PC personales que nadie administra. Un producto distribuido sin firmar puede, solo por eso, no funcionar.³
• Confirme el bloqueo mediante el registro de eventos: en AppLocker el punto clave es el 8004 (registro EXE and DLL); en App Control, el 3077 y la información de firma del 3089 (registro CodeIntegrity - Operational).⁴⁵
• Las medidas del lado de la distribución son: firma coherente en todos los binarios, sello de tiempo, ubicación de instalación estándar, actualización automática firmada, e información proporcionada en el manual de implementación. Hacer que la aplicación sea fácil de reglamentar para el cliente es, en esencia, toda la defensa contra los bloqueos.
• Quien lo implementa debe recopilar un ciclo completo en modo de auditoría (8003 / 3076) antes de pasar a la aplicación. Este procedimiento es el mismo que para cualquier otro refuerzo de seguridad.

Artículos relacionados

• Por qué aparece «Windows protegió su PC»
• Diseño de seguridad de las actualizaciones automáticas: por qué HTTPS no basta
• Cómo elegir el método de distribución de aplicaciones Windows: MSI/MSIX/ClickOnce/xcopy/actualizador propio
• La directiva de ejecución de PowerShell y la firma de scripts — guía práctica para dejar atrás el «tapar con Bypass»
• Guía para gestionar falsos positivos de Windows Defender
• El modo Quiosco y el acceso asignado de Windows
• La realidad después del fin de soporte de Windows 10 — tabla de decisión entre ESU, LTSC y renovación de equipo

Áreas de consultoría relacionadas

En KomuraSoft LLC nos encargamos del desarrollo y la modificación de aplicaciones empresariales que funcionan en entornos de control de ejecución (AppLocker / App Control for Business), del diseño de la distribución y la actualización automática con firma de código integrada, y de la investigación de casos en los que una aplicación no arranca en el entorno del cliente.

• Desarrollo de aplicaciones Windows
• Modernización y mantenimiento de software Windows existente
• Investigación de fallos y análisis de causas
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿No se puede usar AppLocker en la edición Pro?

Esa idea está desactualizada. Desde la KB 5024351, en Windows 10 versión 2004 en adelante y en todas las ediciones de Windows 11 ya no se necesita una edición específica para aplicar (enforce) las directivas de AppLocker. La antigua restricción de que 'la aplicación mediante distribución por Directiva de grupo solo funciona en las ediciones Enterprise y Server' sigue vigente únicamente en versiones de Windows 10 anteriores a la 2004 y hasta Windows Server 2019 (incluso en ese caso, la distribución mediante MDM funciona en todas las ediciones). En entornos de pymes con equipos Pro como base, AppLocker ya es una opción viable.

¿Debería comprar un certificado de firma de código EV?

Desde el punto de vista de las reglas de editor (publisher rules) de AppLocker o App Control for Business, tanto un certificado OV (validación de organización) como uno EV permiten crear reglas basadas en la información del firmante. Además, la idea de que 'con EV la advertencia de SmartScreen desaparece desde el primer momento' ya no es correcta: actualmente, incluso los archivos firmados con EV deben considerarse bajo el mismo supuesto de acumulación de reputación que los firmados con OV (este punto se trata en el artículo aparte 'Windows SmartScreen y la firma de código'). Lo importante no es el tipo de certificado, sino firmar con un sujeto (subject) coherente todos los binarios —no solo el exe, sino también las DLL y el instalador—, añadir sello de tiempo y mantener estable la información del emisor incluso al renovar el certificado. Las reglas de editor se escriben confiando en esa información del firmante, así que si el estado de la firma varía de una versión a otra, las reglas del cliente se rompen.

Parece que mi aplicación fue bloqueada en el entorno del cliente, pero no encuentro nada en los registros. ¿Dónde debo mirar?

La causa más frecuente es que hay que revisar dos sistemas de registro distintos. Los bloqueos de exe/DLL por AppLocker aparecen en el evento 8004 del registro 'AppLocker - EXE and DLL' (8003 en modo de auditoría), mientras que los scripts y MSI aparecen en el evento 8007 del registro 'AppLocker - MSI and Script' (8006 en modo de auditoría). Por otro lado, los bloqueos de App Control for Business (WDAC) aparecen en el evento 3077 del registro 'CodeIntegrity - Operational' (3076 en modo de auditoría), y la información de firma correspondiente se registra en el evento 3089. Además, si un script, un MSI o un objeto COM son bloqueados por App Control, aparecen en los eventos 8029, 8036 y 8040 del registro 'AppLocker - MSI and Script'. Cuando no sepa cuál de los dos mecanismos está actuando, coteje por hora tanto CodeIntegrity - Operational como los registros de AppLocker.

¿Qué se necesita para que Smart App Control no bloquee mi aplicación?

En la práctica, la firma de código. Al ejecutar una aplicación, Smart App Control comprueba, mediante un servicio de seguridad en la nube, si puede predecir de forma fiable la seguridad de la aplicación y si esta cuenta con una firma válida, y bloquea las aplicaciones consideradas maliciosas o las no firmadas cuya confianza no puede confirmarse. Microsoft también indica a los desarrolladores, como medida para evitar bloqueos, firmar la aplicación con un certificado válido. Sin embargo, hay que prestar atención al algoritmo de firma: la verificación de firma de Smart App Control no admite firmas de curva elíptica (ECC), por lo que solo las aplicaciones firmadas con certificados basados en RSA pueden autorizarse para ejecutarse. Smart App Control no es una función de administración empresarial, sino una protección para usuarios particulares de Windows 11 que se activa o desactiva automáticamente según el modo de evaluación, así que, desde el lado de la distribución, es más seguro asumir que 'un ejecutable sin firmar puede no funcionar en un PC personal'.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.