Windows bloqueja controladors vulnerables des de fa anys i gairebé ningú no ha mirat què hi ha dins d'aquella llista. Nosaltres ens la vam descarregar aquest matí i la vam comptar: 1.713 regles de bloqueig, de les quals 1.702 identifiquen el fitxer pel seu hash.
Fa quatre dies vam escriure aquí que memory integrity s'activa sola als equips nous i a bona part del parc. Això és la continuació incòmoda d'aquell post. Activar-la està bé —insistim que l'activis—, però convé saber exactament què encens, perquè el que encens és, majoritàriament, una llista de hashos.
Què ens vam descarregar i què vam comptar
Microsoft publica la llista de controladors vulnerables com una política d'App Control descarregable des de aka.ms/VulnerableDriverBlockList. Dins del ZIP hi ha quatre fitxers; el que importa és DriverPolicy_Enforced.xml, mig megabyte d'XML. El vam baixar el 6 d'octubre del 2026 i vam comptar els elements a mà. Aquests són els números, i qualsevol els pot repetir en cinc minuts:
- ·1.713 elements
<Deny>en total. - ·1.702 en porten l'atribut
Hash: bloquegen un binari concret, byte a byte. - ·11 bloquegen per nom de fitxer. Onze. De mil set-centes tretze.
- ·218 elements
<Signer>: bloquejos per certificat, que és la part que podria no caducar. Hi tornarem, perquè només de vegades no caduca.
La política s'identifica a si mateixa com a Microsoft Windows Driver Policy, versió 10.0.29545.0. Si quan llegeixis això el número ha canviat, millor: vol dir que s'ha actualitzat.
Si vols repetir el compte a la teva màquina, descomprimeix el ZIP i compta sobre l'XML. Dues línies de PowerShell:
$x = [xml](Get-Content .\DriverPolicy_Enforced.xml)
$d = $x.SiPolicy.FileRules.Deny
"Deny: {0} | por hash: {1} | por nombre: {2} | Signer: {3}" -f `
$d.Count, ($d | ? Hash).Count, ($d | ? FileName).Count, $x.SiPolicy.Signers.Signer.CountEl que Microsoft diu de la seva pròpia llista
La part més honesta d'aquest assumpte no la diem nosaltres: la diu Microsoft, a la mateixa pàgina des d'on et descarregues el fitxer. Van seguides, en una nota al peu que gairebé ningú no obre:
«The vulnerable driver blocklist isn't guaranteed to block every driver found to have vulnerabilities.»
La llista no garanteix bloquejar tots els controladors en què es trobin vulnerabilitats.
«It's often necessary for us to hold back some blocks to avoid breaking existing functionality…»
Sovint han de retenir bloquejos per no trencar funcionalitat existent.
«The blocklist included in this article and in the associated downloadable files usually contains a more complete set of known vulnerable drivers than the version in the OS and delivered by Windows Update.»
La llista que et descarregues sol ser MÉS completa que la que portes posada al sistema operatiu.
La tercera és la que ens va deixar callats una estona. Les 1.713 regles que acabem de comptar no són les que té el teu portàtil. Les que té el teu portàtil solen ser, per admissió del fabricant, un subconjunt. Sobre el ritme, Microsoft és precisa i convé citar-la sencera: «The blocklist is updated quarterly», i a més «blocklist updates are delivered through the monthly Windows updates as part of the standard servicing process». És a dir: revisió completa cada trimestre, degoteig cada mes. La pàgina que publica el fitxer duia data de l'1 de maig del 2026 el dia que vam escriure això.
479 mostres que carreguen amb memory integrity posada
Existeix un catàleg públic i comunitari de controladors signats dels quals es pot abusar: LOLDrivers. No és un butlletí de fabricant i convé dir-ho clar: el manté la comunitat, qualsevol hi pot contribuir i els seus camps són anotacions, no certificacions. Dit això, és la millor foto pública que hi ha, i té un camp que ho canvia tot: LoadsDespiteHVCI —«carrega tot i HVCI», és a dir, tot i memory integrity—.
Ens vam baixar el JSON el mateix dia i el vam comptar igual que el de Microsoft. 702 controladors catalogats, 2.407 mostres. El camp LoadsDespiteHVCI està emplenat en 2.145 (262 estan sense anotar i les hem deixat fora del denominador, que és el més honest). D'aquestes 2.145, 479 estan marcades com a mostres que carreguen igual: un 22,3%. A nivell d'entrada —no de mostra—, 230 dels 702 controladors del catàleg tenen almenys una mostra així: gairebé un terç.
El contrast que importa: 45% contra 18%
El catàleg separa dues famílies: controladors legítims però vulnerables (el driver d'una utilitat de diagnòstic, d'un antivirus vell, d'una eina d'overclocking) i controladors maliciosos, escrits o manipulats expressament per a això. Quan separes el compte per família, surt això:
| Família | Mostres anotades | Carreguen amb HVCI | % |
|---|---|---|---|
| Legítims però vulnerables | 1.819 | 332 | 18,3% |
| Maliciosos (fets per a això) | 326 | 147 | 45,1% |
| Total | 2.145 | 479 | 22,3% |
Gairebé una de cada dues mostres de controlador fetes expressament per a això se salta memory integrity, contra menys d'una de cada cinc de les que simplement tenien una fallada. La diferència admet dues lectures i cap no és tranquil·litzadora. La primera: qui escriu el driver sap quina protecció tens posada i optimitza contra ella. La segona, més incòmoda i probablement més certa: un controlador maliciós entra en aquest catàleg perquè algú el va veure funcionant en un incident real; els que memory integrity va aturar no generen incident, no es reporten i no es cataloguen. Si és la segona, el 45% no mesura perícia de l'atacant: mesura el que va arribar a veure'ns.
Sigui quina sigui la lectura, el número que t'emportes és el mateix i és bo: sobre les 2.145 mostres anotades del catàleg, memory integrity atura'n 1.666. Un 77,7%. Això és moltíssim per a una cosa que ve de sèrie i no costa res. Però un 77,7% és un filtre, i un filtre no és un perímetre.
Per què un hash envelleix i un certificat no tant
Un hash identifica aquell fitxer. Canvia un byte, recompila, torna a signar amb un altre certificat comprat o robat, i tens un binari que fa exactament el mateix i el hash del qual no és a cap llista del món. Per això 1.702 regles de hash envelleixen des del minut u: cobreixen el passat amb una precisió excel·lent i el futur amb cap.
Aquí és on esperàvem trobar el contrapès, i el vam trobar a mitges. Vam anar als 218 bloquejos per signant pensant que serien la part sòlida —cremar un certificat tomba tot el que s'ha signat amb ell, passat i futur— i en comptar-los va sortir una altra cosa: només 50 cremen un publicador sencer. Els altres 168 van lligats a un FileAttrib amb nom de fitxer i rang de versió, i dels 156 que declaren versió màxima, 79 estan topats a una versió concreta (de l'estil MaximumFileVersion="1.12.802.2023"). Traduït: puges el número de versió i la regla ja no t'abasta. El mecanisme que no caduca existeix i està fet servir en 50 casos de 218.
Dues línies de lletra petita que canvien el teu procediment
Si només t'emportes dues frases operatives d'aquest post, que siguin aquestes dues, totes dues de la documentació oficial:
- 1Aplicar la política no treu de la memòria el que ja s'ha carregat. Literal: «If any vulnerable drivers are already running that the policy would block, you must reboot your computer for those drivers to be blocked». Si el controlador ja és a dins, continua a dins fins que l'equip reiniciï. La teva finestra de reinici és part de la teva seguretat, t'agradi o no.
- 2La regla ASR de drivers vulnerables no fa el que et penses. Microsoft ho escriu així: «The ASR rule doesn't block a driver already existing on the system from loading». Impedeix que una aplicació escrigui el driver al disc; no impedeix que carregui el que ja hi és. I la frase continua, perquè Microsoft no deixa el forat obert: «however enabling Microsoft vulnerable driver blocklist or applying this App Control policy prevents the existing driver from loading». És a dir, aquell forat el tapa la llista, no l'ASR. Són dos controls diferents i molta gent es pensa que té tots dos quan només n'ha activat un.
Llavors, què sí?
El que una llista no pot fer per definició és notar que un controlador signat, legítim i que carrega perfectament està fent alguna cosa que no toca a les tres de la matinada. Això no es bloqueja: es detecta, i algú ho ha de mirar. És exactament la diferència entre una prevenció i una detecció i resposta gestionada, i per què fa temps que diem que tenir l'eina no és tenir el servei.
Les quatre coses que demanaríem veure si això surt en una revisió, per ordre de dificultat:
- ✓Memory integrity activada i censada. No «activada als nous»: censada equip a equip, amb la llista dels que no la tenen i el motiu escrit al costat. Un percentatge no és un inventari.
- ✓La llista descarregable per sobre de la del sistema, en mode auditoria primer. Microsoft avisa que bloquejar drivers pot tombar equips; es prova en un grup i es llegeixen els esdeveniments de bloqueig en auditoria —el 3076 de
CodeIntegrity/Operational, que és el que et diu què s'hauria bloquejat— abans de forçar res. Compte amb la confusió habitual: el 3099 només confirma que la política ha carregat, no què hauria trencat. - ✓Una alerta per càrrega de controlador de kernel no habitual, no per nom conegut. El nom el canvien; el fet que un servei instal·li un driver a les 03:40 en un portàtil d'administració, no.
- ✓Algú de guàrdia que rebi aquesta alerta. Una detecció a les 03:40 que es llegeix a les 09:00 és un informe forense, no una resposta. Aquesta és la part que no es compra amb una casella.
El que NO estem dient
No estem dient que apaguis memory integrity: just el contrari. Una protecció que filtra quatre de cada cinc mostres conegudes val moltíssim i és gratis. Tampoc estem dient que Microsoft ho faci malament; de fet, el que fa bé és escriure a la seva pròpia pàgina el que la seva llista no cobreix, que és més del que fan molts. I tampoc estem dient que un programa de seguretat es resolgui comprant una altra eina.
El que estem dient és més petit i més incòmode: si la teva resposta a «i els drivers vulnerables?» és «tenim memory integrity», acabes de respondre amb 1.702 hashos que envelleixen i un subconjunt d'ells. És una bona resposta a mitges. L'altra meitat té nom i cognoms i no és un producte: és algú mirant què carrega, i algú despert quan salta.
Fonts i mètode (tot reproduïble): recomptes propis fets el 6 d'octubre del 2026. Les 1.713 regles <Deny>, les 1.702 per hash, les 11 per nom i els 218 <Signer> surten de comptar els elements de DriverPolicy_Enforced.xml (política Microsoft Windows Driver Policy 10.0.29545.0), descarregat d'aka.ms/VulnerableDriverBlockList. Les cites literals i la cadència trimestral, de Microsoft recommended driver block rules (Microsoft Learn, data de l'article 1-maig-2026). Els 702 controladors, 2.407 mostres i 479 marcades LoadsDespiteHVCI surten del JSON públic de LOLDrivers, catàleg COMUNITARI (no de fabricant): els seus camps són anotacions de la comunitat i les 262 mostres sense anotar queden fora del denominador. Els percentatges són nostres, calculats sobre aquestes xifres.
Saps què carrega al kernel dels teus equips quan no hi ha ningú mirant?
A everyWAN operem EDR/MDR gestionat amb guàrdia 24x7: la detecció de matinada s'atén de matinada, no l'endemà al matí. I no et venem una eina més si ja tens la que necessites: no som resellers de ningú.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN