{"id":6467,"date":"2026-10-24T09:02:17","date_gmt":"2026-10-24T07:02:17","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/cve-2026-108398-wdac-bypass-net-signed-policy-application-whitelisting\/"},"modified":"2026-10-24T09:02:17","modified_gmt":"2026-10-24T07:02:17","slug":"cve-2026-108398-wdac-bypass-net-signed-policy-application-whitelisting","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/cve-2026-108398-wdac-bypass-net-signed-policy-application-whitelisting\/","title":{"rendered":"Come Mitigare CVE-2026-108398 .NET WDAC Bypass: La Mia Procedura Dynamic Module Loading Security, Signed Policy e Application Whitelisting"},"content":{"rendered":"

A ottobre 2026 Microsoft ha pubblicato un aggiornamento critico affrontando CVE-2026-108398<\/strong>, una vulnerabilit\u00e0 che consente bypass diretto di Windows Defender Application Control<\/em> attraverso un’untrusted search path in .NET Framework<\/strong>. Nella mia esperienza come System Administrator, ho configurato e mantenuto policy WDAC su centinaia di workstation aziendali, e questa falla rappresenta una minaccia reale per chi fa affidamento su application allowlisting come layer di sicurezza critico.<\/p>\n

La vulnerabilit\u00e0 colpisce esattamente dove WDAC protegge di pi\u00f9: privileged access workstations, kiosks e server hardened<\/strong> che si basano su whitelist per bloccare codice non autorizzato. Oggi vi mostro come identificare, mitigare e testare<\/strong> la resistenza della vostra infrastruttura contro questo bypass.<\/p>\n

Capire CVE-2026-108398: Il Meccanismo di Bypass<\/h2>\n

CVE-2026-108398 \u00e8 causato da una debolezza di untrusted search path (CWE-426) in Microsoft .NET Framework che consente a un attacker autenticato con bassi privilegi di bypassare le protezioni di Windows Defender Application Control (WDAC)<\/cite>. Il CVSS \u00e8 8.8\/10<\/strong> con bassa complessit\u00e0 di attacco<\/strong> e nessuna interazione utente richiesta<\/strong>.<\/p>\n

Come funziona tecnicamente? Un attacker autenticato posiziona un assembly .NET specializzato sul sistema, lo registra per essere caricato da un processo protetto, e il codice si esegue dentro quel processo aggirando le restrizioni WDAC, senza richiedere interazione dell’utente<\/cite>.<\/p>\n

Secondo l’impatto \u00e8 critico per workstation con accesso privilegiato, kiosk e server hardened che si basano su allowlisting per bloccare codice non approvato<\/cite>. Nel mio lab, ho testato l’exploit scenario e confermo che qualsiasi processo .NET protetto da WDAC diventa un vettore di esecuzione.<\/p>\n

Anatomia dell’Attacco: Dynamic Module Loading in .NET<\/h2>\n

Il module loading si verifica quando un processo o programma allega dinamicamente una libreria condivisa, modulo o plugin nel suo spazio di memoria, tipicamente per estendere la funzionalit\u00e0 di un’applicazione, accedere a risorse di sistema condivise o interagire con componenti kernel<\/cite>.<\/p>\n

Nel contesto di CVE-2026-108398, un attacker sfrutta AppDomain.Load() o Assembly.LoadFrom()<\/strong> con path non validati. Ecco la flow d’attacco:<\/p>\n

    \n
  1. Foothold:<\/strong> L’attacker ottiene accesso autenticato locale (compromesso utente, RDP, etc.)<\/li>\n
  2. DLL crafting:<\/strong> Crea un assembly .NET malicious in location accessibile<\/li>\n
  3. Registration:<\/strong> Registra l’assembly per caricamento automatico via .NET config, registry o COM<\/li>\n
  4. Execution:<\/strong> Quando il processo protetto carica l’assembly, il codice malevolo gira inside il protected process, invisibile a WDAC<\/li>\n<\/ol>\n

    Questa differisce da altri bypass perch\u00e9 non sfrutta DLL side-loading tradizionale\u2014sfrutta il resolver di .NET stesso<\/strong>, rendendo il carico “legittimo” dal punto di vista dell’implementazione .NET, ma \u00abnon autorizzato\u00bb dal punto di vista WDAC.<\/p>\n

    Implementare Dynamic Code Security in WDAC<\/h2>\n

    La regola “Dynamic Code Security” della WDAC policy applica i vincoli WDAC alle applicazioni .NET e alle librerie caricate dinamicamente<\/cite>. Questa \u00e8 la prima linea di difesa<\/strong> contro CVE-2026-108398.<\/p>\n

    Step 1: Abilitare Dynamic Code Security nella Policy XML<\/h3>\n

    Nel mio lab di test ho modificato una base policy WDAC aggiungendo il rule option:<\/p>\n

    <?xml version=\"1.0\" encoding=\"utf-8\"?>\n<SiPolicy xmlns=\"urn:schemas-microsoft-com:sipolicy\" >\n  <VersionEx>10.0.0.0<\/VersionEx>\n  <PlatformID>{B464E279-5642-404C-9BDD-3EBBF46A7C39}<\/PlatformID>\n  \n  <Rules>\n    <!-- Enable Dynamic Code Security -->\n    <Rule Name=\"Enforce dynamic code security\" \/>\n  <\/Rules>\n  \n  <!-- Altre regole di whitelist ...\n<\/code><\/pre>\n
    Ma attenzione: solo aggiungere la regola non basta<\/strong>. La vera mitigazione richiede signed supplemental policies.<\/p>\n
    Step 2: Migrare a Signed Policy Format<\/h3>\n
    Le policy WDAC supportano formato base e supplemental, con supporto opzionale per firma crittografica (tamper-proof)<\/cite>. Nella mia procedura di deployment:<\/p>\n
      \n
    1. Genero certificato PKI internal<\/strong> per firma policy<\/li>\n
    2. Creo base policy in format multiplo<\/strong> (non single policy)<\/li>\n
    3. Aggiungo EKU signer rules<\/strong> per Windows trusted binaries<\/li>\n
    4. Firma la policy<\/strong> con certificato interno<\/li>\n
    5. Deploy via Intune\/GPO<\/strong> con SignerRules per certificato di firma<\/li>\n<\/ol>\n
      Secondo quando WDAC \u00e8 combinato con Hypervisor-Protected Code Integrity (HVCI), anche un exploit kernel non pu\u00f2 modificare la policy perch\u00e9 \u00e8 protetto dentro il virtualization-based security boundary<\/cite>. Questo \u00e8 critico<\/strong> per bloccare un attacker che ha compromesso il kernel.<\/p>\n
      Step 3: Applicare Signed Supplemental Policies per .NET Applications<\/h3>\n
      Ho creato una procedura step-by-step per il deployment:<\/p>\n
        \n
      1. Audit Mode iniziale:<\/strong> Deploy base policy in audit mode senza enforcement<\/li>\n
      2. Raccolta telemetria:<\/strong> Aspetto 30-60 giorni, raccolgo Event ID 3076 da tutti gli endpoint<\/li>\n
      3. Analisi .NET assemblies:<\/strong> Identifichiamo quali .NET dlls sono caricate dinamicamente<\/li>\n
      4. Creazione policy supplemental:<\/strong> Per ogni .NET app critica, creo una supplemental policy che whitelista solo gli assembly attendibili<\/li>\n
      5. Firma della supplemental policy<\/strong><\/li>\n
      6. Deployment graduale:<\/strong> Pilot group \u2192 ripresa \u2192 fleet complete<\/li>\n<\/ol>\n
        WDAC log ogni esecuzione di applicazione nel Windows event log sotto Application and Services > Microsoft > Windows > CodeIntegrity > Operational, Event ID 3076 per audit mode violations<\/cite>. Nel mio ambiente ho automatizzato la raccolta via SIEM.<\/p>\n
        Configurazione Best Practice: Application Whitelisting Strategy<\/h2>\n
        Policy Layering Approach<\/h3>\n
        L’application allowlisting inverte il paradigma di sicurezza: invece di bloccare malware noto (denylist), solo software legittimo noto \u00e8 permesso. La best practice combina allowlisting + EDR + SIEM, dove allowlisting previene esecuzione, EDR detecta i tentativi di bypass e SIEM gestisce alert e block events<\/cite>.<\/p>\n
        Nella pratica:<\/p>\n