Tornar al Blog

L'Exchange que vas deixar encès: 21.899 servidors sense pedaç i el teu en pot ser un

Armari rack de paret en un quarto d'instal·lacions d'oficina, amb un servidor encès, pols a la safata, una escala plegada i un cubell de fregar al costat

El 31 d'agost del 2026, els escanejos diaris de la Shadowserver Foundation comptaven 21.899 adreces IP amb un Exchange Server sense el pedaç de CVE-2026-62911, publicat vint dies abans. És fàcil suposar que són empreses que no s'han mogut mai al núvol. Dels que ens trobem nosaltres, bona part són just el contrari: organitzacions que ja van migrar i que conserven un Exchange encès perquè algú va dir, fa anys, que calia per gestionar els usuaris.

Aquell servidor té una particularitat incòmoda: no apareix a les reunions. No allotja bústies, no té usuaris queixant-se, no genera tiquets. Només és allà, publicat a internet, amb la mateixa superfície d'atac que el dia que es va instal·lar. I des del 14 d'octubre del 2025 tampoc rep actualitzacions de seguretat, tret que algú les hagi pagat.

Què és CVE-2026-62911 i què no és

Microsoft el va publicar l'11 d'agost del 2026 i el descriu com una elevació de privilegis: un atacant capaç de capturar i reproduir material d'autenticació el pot reutilitzar per obtenir accés elevat. La classificació és CWE-294 —omissió d'autenticació per captura i repetició— amb una puntuació CVSS de 8.0. Afecta Exchange Server 2016 CU23, Exchange Server 2019 CU14 i CU15, i Exchange Server Subscription Edition RTM.

Aquí cal parar en una cosa que gairebé cap cobertura diu: les fonts no expliquen el mateix. El vector que publica Microsoft exigeix privilegis previs baixos i interacció d'un usuari. L'Oficina Federal de Seguretat alemanya, en canvi, descriu una prova de concepte que permet prendre el control de sistemes des d'internet sense autenticació prèvia, i les anàlisis de tercers van en aquesta línia. Un dels dos matisa de més. Nosaltres no resoldrem aquesta discrepància des de fora, però tampoc no l'amagarem: si estàs decidint la teva urgència de pedaçar amb la puntuació de 8.0 i el vector de Microsoft, estàs decidint amb la lectura més benèvola de les dues.

El que sí que està confirmat per una autoritat nacional: el NCSC dels Països Baixos va avisar que hi ha un exploit funcional que circula. A partir d'aquí, la finestra entre «això és teòric» i «això és un incident» la marca l'atacant, no tu.

El detall que fa aquesta fallada diferent

Si la lectura pública és correcta, el camí d'entrada és l'extrem que s'utilitza per moure bústies entre el teu Exchange i l'Exchange Online. Llegeix-ho un altre cop: la porta és la que vas obrir per migrar al núvol. Com més ordenada va ser la teva migració —híbrid ben muntat, endpoint de migració publicat, certificat en regla—, més probable és que aquella porta segueixi exactament on la vas deixar, quatre anys després que l'última bústia creués.

Els números per país reforcen la idea. Els Estats Units encapçalen la llista amb 6.200 servidors sense pedaç i Alemanya la segueix amb 5.100. Però la dada que de debò explica el fenomen la va publicar l'autoritat alemanya a finals d'agost, i és d'una sequedat difícil de millorar: només tenien constància de nou servidors Exchange 2016 o 2019 a tota Alemanya amb els pedaços del programa d'actualitzacions esteses instal·lats. Nou. La mateixa nota estimava que al voltant del 85% dels Exchange locals alemanys que veuen continuaven sent vulnerables; el denominador d'aquell percentatge no està especificat, així que el prenem com a ordre de magnitud i no com a cens.

«És que el necessito per gestionar els usuaris»

Aquesta frase va ser certa durant anys, i té fins i tot nom propi a la documentació de Microsoft: el problema de l'últim servidor Exchange. Amb sincronització de directori, els atributs de correu d'un usuari s'editen a l'Active Directory local i viatgen al núvol; i les úniques ordres suportades per tocar-los són les de l'Exchange local. Ni ADUC, ni ADSI Edit, ni utilitats de tercers. Per això milers de migracions van acabar amb la mateixa cantarella: «en deixem un per a gestió».

Va deixar de ser obligatori a l'abril del 2022. Des de l'actualització acumulativa de l'Exchange 2019 d'aquell mes —CU12 endavant— les eines d'administració es poden instal·lar soles, en qualsevol màquina unida al domini, i gestionar els destinataris des del PowerShell sense cap Exchange en marxa. Aquestes són les condicions que posa Microsoft, i cal complir-les totes:

  • 1Totes les bústies i carpetes públiques ja són a l'Exchange Online. Ni una de local.
  • 2Gestiones destinataris contra l'Active Directory i sincronitzes amb l'Entra Connect o amb la sincronització al núvol.
  • 3No fas servir el centre d'administració de l'Exchange local ni el seu control d'accés basat en rols (RBAC).
  • 4El teu equip està còmode gestionant destinataris només amb PowerShell.
  • 5No necessites auditoria ni registre de les accions de gestió de destinataris. Aquesta és la que sol descartar el pla, i gairebé ningú no la mira.
  • 6Tens un sol Exchange local, i només per a gestió de destinataris. Si te'n van quedar dos «per si de cas», aquesta via no és per a tu tal com està.

Aquí convé no quedar-se al 2022, perquè Microsoft ha mogut la recomanació. Al seu article de maig del 2026 sobre com retirar l'últim Exchange, qualifica aquesta via de les eines d'administració de «solució temporal»: et deixa apagar el servidor, però no desinstal·lar-lo, i sobretot deixa l'autoritat sobre els atributs ancorada al teu Active Directory. El problema de l'últim servidor continua obert, només que amb el llum apagat.

Apagar-lo i treure'l no són la mateixa decisió

La via que Microsoft descriu avui per acabar la feina és transferir al núvol l'autoritat sobre els atributs —marcant cada bústia sincronitzada com a gestionada al núvol, o passant l'objecte sencer al núvol— i llavors sí desinstal·lar el servidor amb Setup /m:Uninstall. És la diferència entre un servidor apagat que continua sent a l'Active Directory i una organització que ja no té Exchange local per mantenir.

I aquí va l'avís que Microsoft escriu amb majúscules i que es barreja constantment: si estàs gestionant destinataris amb les eines d'administració, NO desinstal·lis. El desinstal·lador esborra els contenidors de configuració i els grups de seguretat de l'Exchange a l'Active Directory, que són justament allò de què depenen aquelles eines per funcionar. En aquell escenari el servidor s'apaga, es neteja amb l'script que ve inclòs i es formata, però mai es passa pel desinstal·lador. Les dues rutes són legítimes; barrejar-les és el que trenca coses. Un avís de propina que és a la documentació i que gairebé ningú no veu venir: si ja vas executar la neteja i només vas apagar el servidor, per desinstal·lar-lo cal tornar-lo a encendre, i fer-ho com a administrador de domini, perquè el grup que et donava permís ja no existeix.

Si tries la via de les eines, dos detalls operatius que s'agraeixen abans i no després. El primer: així que apaguis el servidor, les ordres de creació i modificació trigaran uns 40 segons a respondre, perquè l'inicialitzador del registre d'auditoria intenta connectar-se a una màquina que ja no hi és; la demora desapareix en executar l'script de neteja d'Active Directory que ve amb les eines. El segon, més seriós: en apagar l'últim Exchange, el RBAC deixa de funcionar. Qui gestionava destinataris per pertànyer a un grup d'Exchange es queda sense permisos, i cal donar-li accés amb l'script que crea el grup de seguretat corresponent. Si això t'enxampa un dilluns al matí, no és un incident de seguretat: és un incident de recursos humans.

Quan NO cal apagar-lo

Aquest post no va d'apagar servidors per esport. Es tracta que cada servidor encès tingui una raó per escrit. Hi ha casos en què la resposta correcta és deixar-lo on és i tractar-lo com el que és: un sistema en producció, amb la seva finestra de pedaços i el seu propietari.

  • ·Fa de relé SMTP. És el cas més comú, i la mateixa documentació de Microsoft ho assenyala: si el teu últim Exchange s'utilitza per a alguna cosa més que gestionar destinataris —per exemple, recollir el correu de la fotocopiadora, de l'ERP o de l'aplicació de facturació—, no l'apaguis. Primer mou aquells remitents, i per a això cal saber quins són.
  • ·Necessites auditoria o RBAC. Si has de poder demostrar qui va canviar quina bústia i quan, la via de les eines d'administració no et serveix. Aquí mana el requisit de compliment, no la comoditat.
  • ·Et queden bústies locals. Aleshores no tens una neteja, sinó una migració a mitges. És un projecte diferent, amb un altre calendari, i mentre duri aquell servidor necessita pedaços al dia i protecció estesa de l'autenticació activada.

I si et quedes, cal dir la part del calendari que estreny. L'Exchange Server 2016 i 2019 van deixar de tenir suport el 14 d'octubre del 2025. Les actualitzacions esteses de seguretat només arriben a qui està inscrit i acaben el 31 d'octubre del 2026. És a dir: queden menys de dos mesos de xarxa de seguretat, i després cada nova fallada es queda sense pedaç per sempre. La sortida suportada és l'Exchange Server Subscription Edition, que a efectes d'instal·lació és una actualització acumulativa més des de 2019 CU14 o CU15 —comparteix codi amb la CU15—, però això s'ha de planificar ara, no el 30 d'octubre.

Què faríem aquesta setmana

Res d'això no és un projecte de tres mesos. És mig matí d'inventari i una decisió.

  • 1Comptar els Exchange que tens encesos. No els que et penses: els que responen. Un escombrat del teu rang públic i un altre de l'intern; el que aparegui i no sigui a l'inventari és l'interessant.
  • 2Comprovar la versió i si el pedaç de l'11 d'agost està aplicat. Si el servidor és 2016 o 2019 i ningú va contractar les actualitzacions esteses, el pedaç no va arribar: no és que no s'instal·lés, és que no es va oferir.
  • 3Preguntar què publica aquell servidor cap a internet i per què. Si la resposta honesta és «per a la migració que vam acabar el 2022», ja tens la feina de la setmana.
  • 4Mirar qui li envia correu per SMTP abans de tocar-lo. Impressores, ERP, escàners, scripts vells: són els que converteixen una aturada neta en una trucada a les vuit del matí.
  • 5Decidir per escrit: es queda amb propietari i finestra de pedaços, o es retira seguint el procediment. El que no val és la tercera opció, que és la que tenen aquells 21.899: segueix encès i no és de ningú.

És el mateix mecanisme del qual parlàvem en analitzar la retirada de l'EWS i per què la data que t'afectava no era la que sortia al titular, i el que apareix cada cop que una caiguda de Microsoft 365 revela que sis serveis diferents eren en realitat una sola dependència. La fallada gairebé mai és a la tecnologia. És que ningú tenia escrit què depenia de què.

Migrar no s'acaba quan creua l'última bústia

En els projectes de Microsoft 365 que fem, la part que més se subestima no és moure el correu: és desmuntar allò que es va muntar per moure'l. L'endpoint de migració, la relació de federació, el certificat, el connector d'enviament, el servidor. Tot això es crea amb pressa perquè hi ha una data de tall, i es queda per sempre perquè ningú té pressa per treure-ho.

Per això, quan entrem en un parc a fer manteniment o a revisar la seguretat, una de les primeres preguntes és la més avorrida: què hi ha encès que ja no cal. No és una pregunta d'estalvi. És que la superfície d'atac d'una empresa no la defineixen els sistemes que fa servir, sinó els que té. Darrere d'aquelles 21.899 adreces IP hi ha moltes organitzacions que ni tan sols saben que són a la llista. Aquest és exactament el problema: no és que hagin decidit córrer el risc, és que ningú no s'ho ha plantejat.

Fonts: recompte de 21.899 adreces IP exposades a 31 d'agost del 2026 i desglossament per país (6.200 als Estats Units, 5.100 a Alemanya), escanejos diaris de la Shadowserver Foundation recollits per Help Net Security i BleepingComputer; avís d'exploit funcional en circulació, NCSC-NL; els nou servidors amb pedaços ESU instal·lats i l'estimació del 85% de servidors locals vulnerables a Alemanya, publicació del BSI de finals d'agost del 2026 recollida per heise —el denominador del percentatge no està especificat a la font—; descripció, CVSS 8.0, classificació CWE-294 i versions afectades, avís de Microsoft de l'11 d'agost del 2026 i bases de dades de vulnerabilitats públiques. La hipòtesi sobre l'extrem de migració i la protecció estesa de l'autenticació prové d'anàlisis tècniques publicades per tercers; no l'hem verificada nosaltres i així la presentem. Procediment de les eines d'administració, avís de no desinstal·lar, demora de 40 segons i pèrdua de RBAC, i la ruta de transferència d'autoritat amb desinstal·lació posterior (article actualitzat el maig del 2026): documentació oficial de Microsoft Learn. Fi del suport estès de l'Exchange 2016 i 2019 (14 d'octubre del 2025) i final de les actualitzacions esteses de seguretat (31 d'octubre del 2026): anuncis de Microsoft.

Saps què queda encès de la teva última migració?

A everyWAN revisem l'híbrid que va deixar la teva migració a Microsoft 365, et diem què es pot retirar i què no, i ho retirem seguint el procediment suportat. Sense apagar res a cegues.

Microsoft 365 Modern Workplace Parlar amb nosaltres

Etiquetes:

Compartir:

Subscriu-te al nostre butlletí

Per rebre històries del món IT, novetats d'everyWAN i ofertes exclusives per a subscriptors, dona't d'alta a la nostra llista de correu

everyWAN
everyWAN