L'avís que van rebre els clients de Kiteworks el divendres 25 de setembre no demanava aplicar cap pedaç. Demanava apagar. I amb això el problema va sortir del departament de sistemes: ningú de guàrdia no té autoritat per deixar l'empresa sense el canal per on entra la documentació de clients durant tot un matí de dissabte.
Kiteworks és una plataforma de transferència segura de fitxers: el lloc per on moltes empreses mouen documentació amb clients, asseguradores, hospitals o administracions. El seu CISO, Frank Balonis, va escriure als clients que havien rebut «intel·ligència d'amenaces creïble de les forces de l'ordre que indica que un atac als sistemes de Kiteworks pot ser imminent aquest cap de setmana» (traducció nostra). En una declaració posterior hi va afegir que no li constava cap compromís i que la mesura es prenia «per excés de precaució». La nota de premsa de la companyia, aquell mateix dia, ho va atribuir a «autoritats federals d'intel·ligència».
Sis hores al correu, nou a la nota de premsa
Val la pena aturar-se aquí, perquè les dues xifres circulen barrejades. El correu a clients, que va publicar primer el mitjà alemany Heise, deia literalment: «recomanem encaridament que apaguis el teu sistema Kiteworks durant sis hores» (traducció nostra), amb la finestra ajustada a cada fus: de 4:00 a 10:00 del dissabte a l'Europa central, de les 22:00 del divendres a les 4:00 del dissabte a Nova York. La nota de premsa pública que la companyia va penjar al seu web aquell mateix dia parlava d'«una finestra d'apagada preventiva de nou hores aquest cap de setmana, en la seva zona horària local».
L'ajust per fusos horaris explica que les hores absolutes siguin diferents a cada país; no explica que la durada canviï. Els investigadors de Sophos, que van veure les informacions aquell mateix dia, van descriure la finestra com «de 02:00 a 08:00 UTC del 26 de setembre, si no abans»: sis hores una altra vegada. Tres de les quatre fonts diuen sis; la que diu nou és la pública. No és una xifra inventada per ningú, però sí que és la que va arribar als titulars, i no és la que va haver d'executar qui era a l'altre costat.
La resta de l'avís sí que és unívoca, i és la part que importa per al teu pla:
- →Abastava les instal·lacions autogestionades —en local, a AWS i a Azure— i també les allotjades per la mateixa companyia, on el client no havia de fer res. I es demanava apagar encara que el sistema no fos accessible des d'internet, que és tant com dir que no hi havia manera d'acotar-ho per exposició.
- →No hi havia CVE, ni pedaç, ni indicadors de compromís publicats. La companyia remetia a la seva versió al dia —«totes les vulnerabilitats conegudes estan corregides a la versió actual 9.5.1»—, que és una altra manera de dir que no hi havia res conegut per aplicar.
- →Kiteworks va declarar que no tenia indicis que els seus sistemes ni els dels seus clients estiguessin compromesos, i que l'avís era «preventiu, no una resposta a una bretxa confirmada» (traducció nostra). El 27 de setembre va aixecar la recomanació per a tots els clients.
Un detall més, que explica per què el mercat es va prendre seriosament un correu sense CVE: Kiteworks abans es deia Accellion, i la plataforma de transferència de fitxers d'Accellion va ser una de les que es van endur per davant campanyes d'extorsió massiva. El sector ja sap com acaba aquesta pel·lícula, i per això milers d'empreses van apagar per un correu d'un divendres.
Algú ho ha de signar, i aquest algú no és el de guàrdia
Un avís de pedaç es resol a la finestra de manteniment i el signa qui porta la plataforma. Amb un d'apagar, la cadena s'improvisa: el tècnic truca al responsable d'IT, el responsable d'IT busca la direcció, la direcció pregunta quant de risc hi ha de debò, i l'única resposta honesta disponible és «no ho sabem, no hi ha CVE». A aquella hora ja s'ha perdut mitja finestra.
Jake Knott, de la firma de seguretat watchTowr, ho va resumir a Computer Weekly: «No hi ha CVE conegut, ni pedaç, ni detalls tècnics addicionals disponibles; però ningú no demana a tota la seva base de clients que desendolli sistemes de producció durant el cap de setmana per una intuïció» (traducció nostra). Les dues meitats de la frase són veritat alhora: la informació era insuficient per avaluar i suficient per preocupar.
Qui sí que ho va signar va ser Balonis, i ho va posar per escrit el 28 de setembre, quan ja havia passat tot: «Dir als clients que desconnectin sistemes de producció no és una decisió que cap fabricant prengui a la lleugera, i sabíem exactament què els estàvem demanant […] Tornaríem a prendre la mateixa decisió demà» (traducció nostra). És la frase d'algú que tenia l'autoritat clara abans de necessitar-la. Aquesta és tota la diferència, i no es compra: s'escriu en fred. No la llista d'accions —això ja ho tens al pla de continuïtat que probablement ningú no ha assajat—, sinó les tres línies anteriors a les accions: amb quina qualitat d'informació acceptem aturar, qui ho autoritza i a qui s'avisa. Escrites un dimarts qualsevol, eviten la discussió del dissabte.
A l'agost vam explicar el revers d'aquesta mateixa moneda: els teus servidors els pot apagar algú amb qui no has signat res, quan una fallada al centre de dades d'un proveïdor del teu proveïdor retira màquines de servei sense preguntar-t'ho. Aquí el botó el tens tu i el prems voluntàriament. La incomoditat és la contrària i el buit de govern és el mateix.
Les hores apagat tenen un forat, i el reomplen els teus usuaris
Aquesta part no apareix a cap de les notes, i és la que més ens preocuparia si l'avís arribés a un client nostre demà. Quan apagues la plataforma per on s'intercanvien fitxers, la feina que en depenia continua dempeus. Si hi ha un lliurament compromès per dilluns, algú enviarà aquell fitxer igualment, i l'enviarà per on pugui: el seu compte personal de correu, un servei gratuït de transferència, un llapis USB. Has contingut un risc hipotètic i n'has obert un de real del qual, a més, no queda registre enlloc.
Una apagada preventiva ben feta inclou el canal substitut, i l'inclou per escrit i amb nom: quin és, qui l'autoritza, quin límit de mida i de sensibilitat té, si va xifrat, on queda el registre i quan s'esborra el que s'hi va pujar. Sembla burocràcia fins que l'alternativa apareix a la safata personal d'algú. I si la resposta honesta és «no tenim un altre canal», això també és un resultat de l'exercici, i canvia la conversa: passa de seguretat a disseny.
Apagar té procediment; engegar, més
Operem Proxmox VE amb Ceph en producció i portem còpies amb Proxmox Backup Server i Veeam, així que aquesta part la diem des del teclat. Seguir un avís com el de Kiteworks significa entrar a l'appliance i apagar-lo des de dins, i aquí hi ha tres coses que mosseguen en una aturada de cap de setmana no assajada.
- 1L'alta disponibilitat fa la seva feina, i la seva feina és la contrària de la teva. Si atures la màquina des del mateix Proxmox —
qm stopo el botó de la interfície—, l'estat sol·licitat passa astoppedi no hi ha sorpresa. Si l'apagues des de dins del sistema convidat, que és just el que demana un avís de fabricant, el gestor veu un servei en estatstartedque ha deixat de córrer i el torna a aixecar. Abans d'entrar-hi:ha-manager set vm:100 --state stopped. - 2La còpia d'aquesta matinada s'executa igualment. Copiar una màquina aturada és el més consistent que hi ha a nivell de disc; el problema és d'aplicació, quan el servei es va aturar a mitges dins d'una màquina que continua viva. I hi ha un efecte de segon ordre que s'oblida: un cap de setmana sencer de còpies d'un sistema apagat empeny fora de retenció els punts bons. Es decideix abans: o es desactiva aquesta nit, o s'etiqueta.
- 3La monitorització cridarà, i amb raó. Sense un manteniment declarat a Zabbix (o al que facis servir) abans d'aturar, la guàrdia rep desenes d'avisos d'un incident que vas provocar tu. I compte amb el detall: a Zabbix el manteniment suprimeix el problema, però les notificacions només callen si l'acció té marcat «Pause operations for suppressed problems».
I l'engegada és on apareix l'inventari real de dependències. Ningú no descobreix que l'aplicació necessitava la base de dades trenta segons abans fins que aixeca els dos serveis alhora un diumenge. Si has d'aturar per precaució, l'ordre de tornada és tan part del procediment com el d'anada, i la manera barata d'aprendre-ho és amb una màquina que no faci mal.
Què van trobar dins de la finestra
El final de la història és el que menys s'ha explicat. Durant el cap de setmana, treballant amb les autoritats, Kiteworks va trobar i corregir una vulnerabilitat crítica que abans no es coneixia. Segons el que es va publicar el 29 de setembre, estava «confinada a una capacitat que està habilitada en menys de l'1 % de la base de clients», no hi ha evidència que s'hagi explotat mai amb finalitats malicioses i, en aquella data, no tenia CVE assignat.
És fàcil llegir aquesta dada com una crítica: més del 99 % dels clients va aturar producció per una cosa que no els tocava. Nosaltres ho llegim a l'inrevés. En el moment de decidir, ningú —ni el fabricant— podia separar l'1 % de la resta, perquè la granularitat arriba sempre després de la troballa. El que el cas demostra és que les decisions de continuïtat es prenen amb informació incompleta, i que el pla que només funciona quan saps què passa serveix de poc.
Hi ha també una asimetria que ja vam mesurar en un altre cas i que aquí va sortir bé per poc: aturar és ràpid, tornar no ho és. Fa dues setmanes vam escriure sobre un intermediari que va trigar 101 minuts a desconnectar un proveïdor i nou dies a reconnectar-lo. Kiteworks va aixecar la seva recomanació en dos dies. La pròxima vegada que algú et demani apagar «unes hores», la pregunta útil no és quantes: és qui decideix que ja es pot tornar, i amb quina comprovació.
La pàgina que li falta al teu pla
Tot això cap en una pàgina i surt d'una reunió d'una hora, sempre que a dins hi hagi la gent que pot decidir. Per a cada plataforma de la qual depens de debò, el full ha de respondre quatre coses, i cap d'elles no és tècnica.
Qui. Nom i suplent, i fins a quantes hores pot signar sense pujar un nivell. «Ho decidiríem entre tots» no és una resposta; el dissabte vol dir que no decideix ningú.
Amb què. Quina evidència és suficient: un correu del fabricant sense CVE? un avís d'un CERT? només amb indicadors? Escrit abans, perquè el criteri improvisat acaba sent el del qui està més nerviós.
Per on es treballa mentrestant. El canal substitut autoritzat, amb el seu límit i el seu registre, i qui avisa els clients que durant aquelles hores el lloc de sempre no respon. Si no ho dius tu, ho interpreten ells.
Què es mira en tornar. Una apagada conté, però no investiga: si hi havia alguna cosa a dins, continua a dins quan encens. Revisar accessos, comptes nous i tasques programades abans d'obrir el servei al món és la meitat del procediment que gairebé mai s'escriu.
El que no afirmem
- ✗No sabem si la fallada que van trobar és la que temia la intel·ligència. Ningú no ho ha afirmat públicament; la mateixa companyia no ha donat detalls tècnics de la fallada. Els dos fets coincideixen en el temps i això no prova que siguin el mateix.
- ✗No hi va haver bretxa confirmada. La companyia va declarar que no tenia indicis de compromís ni als seus sistemes ni als dels seus clients, i la seva monitorització durant la finestra no va mostrar activitat anòmala. Aquest post no parla d'un atac, sinó de com es decideix.
- ✗Tampoc no diem que apagar sigui la resposta correcta per defecte. En la majoria dels avisos no ho és. El que defensem és que la decisió estigui escrita abans que arribi el correu, i que inclogui com es treballa mentrestant.
Fonts (verificades el 30 de setembre del 2026): la finestra de nou hores en zona horària local, l'abast (on-premises, AWS i Azure, més les instàncies allotjades), la referència a la versió 9.5.1 i la declaració que no hi ha indicis de compromís — Kiteworks, «Precautionary Shutdown Advisory», 25 de setembre del 2026; les sis hores del correu a clients, les finestres per fus horari, la petició d'apagar també els sistemes no accessibles des d'internet i el crèdit a Heise com a primer mitjà a publicar-ho — BleepingComputer, 25 de setembre del 2026; la citació del CISO Frank Balonis al correu, la seva declaració posterior, la frase de Jake Knott (watchTowr), el període de sis hores del dissabte 26 i l'anterior nom de la companyia — Computer Weekly, 25 de setembre del 2026; la finestra de 02:00 a 08:00 UTC del 26 de setembre i la recomanació del Counter Threat Unit de seguir la guia del fabricant — Sophos; la restauració dels sistemes, l'absència d'activitat anòmala durant la finestra i les citacions de Balonis del 28 de setembre — Kiteworks, 28 de setembre del 2026; la troballa i la correcció durant la finestra, el «menys de l'1 % de la base de clients», l'absència d'evidència d'explotació i de CVE assignat, i l'aixecament de la recomanació el 27 de setembre — The Hacker News, 29 de setembre del 2026; el comportament del gestor d'alta disponibilitat — documentació de Proxmox VE.
Qui signaria a la teva empresa una aturada de sis hores?
Ens asseiem una hora amb qui decideix i amb qui opera, i sortim amb aquest full escrit per a les teves plataformes crítiques. Si cal, després el provem amb una de debò, que és quan apareixen les dependències que ningú no recordava. És disaster recovery i, per a la part de què es revisa en encendre, ciberseguretat.
Parlar amb everyWAN
Microsoft 365
ES 
CAT 
EN