La part que de debò fa mal de l'informe que IDC Frontier va publicar aquest mateix matí no és el ransomware. És l'ordre de les frases. Van explotar una vulnerabilitat d'un programari de codi obert que feia servir el sistema d'autenticació del seu portal de clients. Des del sistema d'autenticació van arribar a la consola de gestió. I des de la consola de gestió van obtenir permisos d'administrador sobre el pla de virtualització. Quatre salts, i a l'últim hi havia les màquines de 495 empreses i administracions. La pregunta que deixa sobre la taula no va del Japó: quants salts hi ha, en el teu cas, entre un formulari de login publicat a internet i la credencial que pot esborrar les teves còpies?
Què diu l'informe, amb les seves paraules
IDC Frontier és un proveïdor japonès de datacenter i cloud, filial de SoftBank. El 7 d'octubre del 2026, cap a les 3:40 de la matinada, els servidors virtuals de part de la seva «regió Est del Japó 1» —les zones tesla, henry, pascal i joule— van deixar de funcionar i no es podien rearrencar. El recompte d'afectats no ha canviat des d'aleshores: 495 empreses i administracions. El que sí que ha anat canviant, informe rere informe, és l'explicació. Avui, 27 d'octubre, n'han publicat el setè, amb el qual donen per tancada la investigació i amb la causa confirmada.
Dues frases. A la primera som a la vora pública, en un formulari de login que qualsevol pot carregar. A la segona ja som a la capa que arrenca i atura les màquines de tothom. Entre l'una i l'altra no hi havia res que l'informe consideri digne d'esment. Dues coses sí que les descarta, i convé dir-les abans de seguir: la investigació no va trobar sortida de dades des dels servidors virtuals dels clients, i l'empresa afirma no haver contactat amb l'atacant ni haver pagat ni negociat cap rescat.
Els quatre salts
Val la pena desmuntar-ho en trams, perquè cada tram té un equivalent exacte en una infraestructura de vint màquines. Dos avisos abans de la taula. La tercera columna no surt de l'informe: és el que nosaltres mirem quan revisem una plataforma. I el quart salt tampoc no hi surt: l'informe descriu tres fronteres i confirma que les màquines es van aturar i es van xifrar. Que l'atac arribés a més als punts de restauració ho diu l'atacant, no l'empresa; el posem a la taula perquè és la frontera que a nosaltres ens sembla decisiva, no perquè hi estigui acreditada.
El salt quatre és el que converteix un incident en una catàstrofe. Els tres primers et deixen sense servei; el quart et deixa sense marxa enrere. I és, de molt, el més barat de trencar, perquè a la majoria de plataformes la còpia la fa la mateixa consola que gestiona la màquina, amb el mateix compte, i viu al mateix ferro. És la variant d'infraestructura d'una cosa que ja hem explicat en la seva versió d'identitat: el servidor de còpies ficat al mateix domini és la mateixa dependència circular amb un altre vestit.
El número que importa no és 495
Els 495 són els afectats. La xifra interessant és una altra, i ha trigat tres setmanes a estabilitzar-se. El 8 d'octubre, al tercer informe, el proveïdor va dir que les dades de les quatre zones eren difícilment recuperables o restaurables. El 14 d'octubre, al cinquè, va matisar: s'havia confirmat que les dades de còpia estaven fora de perill i se'n podien extreure les de 194 clients. L'informe d'avui recull que el 20 d'octubre aquesta xifra va pujar a 206.
Dos-cents sis de quatre-cents noranta-cinc. Quatre de cada deu. Per als altres sis de cada deu, el que el proveïdor va posar per escrit ja el 8 d'octubre és que preparin un entorn a part i reconstrueixin allà amb la còpia que tingui cada client pel seu compte. No és una frase cruel ni un intent d'escapolir-se: és, literalment, l'única sortida que queda quan el punt de restauració viu dins del radi de l'incident. Avui, amb SoftBank al darrere, acompanyen aquest trasllat i estan operant ells mateixos la plataforma per compte del client mentre el portal continua tancat; però la restauració continua sortint de la còpia que cadascú tingués.
Convé ser honest amb el que aquest 206 no diu. No sabem quants dels 289 restants tenien contractat el servei de snapshot i el van perdre, i quants senzillament no el tenien. L'informe no ho desglossa. Però per a la decisió que cal prendre tant se val: des de la cadira del client, «la meva còpia no existia» i «la meva còpia existia i se'n va anar amb la resta» són el mateix dilluns al matí.
I després hi ha el rellotge. Avui mateix publicàvem que, de més de vuit-centes intervencions amb clients mesurades sobre el terreny, només quatre es van acostar a l'objectiu de 24 a 48 hores que cada empresa atacada tenia documentat: el que de debò triga una recuperació. Aquí, tres setmanes després, el lliurament de les dades de còpia va començar el 17 d'octubre i el portal de gestió encara no ha reobert: de moment les operacions les executa el mateix proveïdor per compte del client. Els dos rellotges expliquen la mateixa història des d'extrems diferents.
El que l'atacant va escriure a la consola
Un parèntesi, amb l'etiqueta ben posada. Des del 7 d'octubre van circular per X captures del que semblava la mateixa consola d'IDCF, amb un missatge en anglès de l'atacant que ITmedia aboca al japonès com a «hem pres la infraestructura» i «el vostre núvol és nostre», i un inventari del dany: 239 hipervisors assolits, 225 magatzems de dades xifrats, més de 16.600 discos de màquina virtual, 3,6 PB d'emmagatzematge primari, 41,5 PB de capacitat de còpia perduda i 554.153 snapshots destruïts, tot plegat en set minuts. Preguntada per això, l'empresa va respondre que havia vist diverses imatges que semblen coincidir amb el que es va arribar a mostrar a la seva consola, però no ha confirmat cap de les xifres, i l'informe d'avui tampoc no les recull.
Les tractem com el que són: la versió de l'atacant, sense verificar, i amb tot l'interès del món a sonar enorme. Però hi ha un detall que no depèn de si el número és 554.153 o la meitat. Si l'esborrat dels punts de restauració es fa des de la capa que els crea, el temps que triga no té res a veure amb la quantitat: és una operació de catàleg. Tant li fa que siguin cinc-cents mil o cinc mil. Per això cap estratègia que consisteixi a «ja ho veurem a la monitorització i ho aturarem» no aguanta el plantejament. No hi ha finestra de detecció que valgui contra una crida a una API d'esborrat massiu. L'únic que funciona és que aquesta crida no pugui arribar a la còpia.
La frase que no és a l'informe
L'informe diu «una vulnerabilitat d'un programari de codi obert». No diu quin. No hi ha nom de producte, ni versió, ni identificador de vulnerabilitat. És una decisió defensable mentre quedi algú sense pedaç, i tampoc no és obligació seva publicar-ho. Però deixa un buit amb conseqüències: cap lector no pot comprovar si aquest mateix component corre també a casa seva.
Cosa que té la seva ironia, perquè la segona mesura que anuncien perquè no es repeteixi és exactament això: centralitzar a tota la companyia la informació de composició del programari, que fins ara gestionava cada departament pel seu compte, i automatitzar l'encreuament amb els butlletins de vulnerabilitats. Un inventari de dependències, vaja. El mateix que cal per respondre la pregunta de si una biblioteca concreta és dins d'alguna cosa que tu vas instal·lar sense saber-ho: l'inventari que no té una línia per a la biblioteca que t'importa.
El pla de prevenció l'ha escrit la víctima
Aquesta és la part aprofitable de debò. Un pla de mesures publicat després de pagar l'incident val més que qualsevol catàleg de bones pràctiques, perquè està escrit per algú que ja sap què li va fallar. Aquestes són les seves, resumides de l'informe d'avui, convertides en preguntes que pots fer al teu proveïdor —o fer-te a tu mateix si el proveïdor ets tu:
- Qui mana en seguretat. Ells han creat una organització independent dedicada només a això, amb experts externs i la gent de seguretat que ja tenien, reunida. La pregunta traslladada: a casa teva, la seguretat és la feina d'algú, o l'estona que li sobra a qui manté la producció?
- Pla i freqüència de l'anàlisi de vulnerabilitats, per escrit a la normativa interna, i amb l'abast ampliat al programari de codi obert. El segon punt és el rellevant: l'anàlisi que no mira les dependències de tercers no hauria trobat això.
- Inventari de composició del programari unificat (en diuen SBOM) i encreuat automàticament amb els avisos de vulnerabilitat. Sense això, la pregunta «ens afecta?» es respon a mà i tard.
- Substituir el sistema d'autenticació propi per un proveïdor d'identitat extern. Textualment, «renovar el sistema d'autenticació que va ser la causa de la intrusió». Mantenir el teu propi login és mantenir la teva pròpia superfície d'atac, amb el teu propi calendari de pedaços.
- Restringir l'accés al portal a les adreces IP del client i fer obligatori el segon factor. Dos controls de manual que, aplicats al pla de gestió i no només al correu, haurien encarit moltíssim el salt número dos.
Fixa't en el que no hi ha en aquesta llista: ni una sola tecnologia nova, ni un producte per comprar. És una llista de fronteres i de propietaris. El que era car de debò no era l'eina; era decidir que el portal de clients i el pla de virtualització no es toquen.
Quan això NO vol dir contractar un segon proveïdor
El reflex d'aquests dies és «cal ser a dos núvols». Gairebé sempre és la resposta equivocada, i és caríssima. Duplicar proveïdor duplica contractes, equips, procediments i superfície d'atac, i no resol el problema si els dos núvols pengen de la mateixa font d'identitat o s'administren des del mateix portàtil: això és un únic domini de fallada amb dues factures.
El que sí que canvia el final de la història és molt més barat, i cap en una frase: una còpia que visqui fora del pla de control que gestiona la màquina. Un altre compte, un altre lloc, retenció que no es pugui escurçar des de dins, i restaurada sencera almenys un cop sobre ferro diferent de l'original. Aquesta còpia és la diferència entre ser un dels 206 i ser un dels altres. No cal un segon proveïdor per tenir-la; cal que no la faci la mateixa credencial que la pot esborrar.
I un aclariment que ens toca de ple: nosaltres també som el proveïdor d'algú. Tenim ferro propi al datacenter, consoles de gestió i portals. Aquesta llista de cinc punts no és una cosa que mirem només cap enfora quan auditem un tercer; és la que ens apliquem, i la frontera entre el salt tres i el salt quatre és la que més ens ha fet repensar coses. Escriure un post assenyalant un proveïdor caigut sense dir això seria bastant barat.
On encaixa això en el que fem
La part de la nostra feina que parla d'això és disaster recovery: on és la segona còpia, amb quina credencial s'escriu, quant es triga a aixecar-la i sobre quin ferro. Portem còpies gestionades amb Proxmox Backup Server i Veeam, amb filosofia 3-2-1 i retenció immutable, precisament perquè el salt quatre no existeixi. L'altra meitat és zero trust, que és com anomenem això dels salts dos i tres: que el pla de gestió no sigui accessible per haver passat un login, que les identitats del portal i de la plataforma no siguin la mateixa, i que cap permís escali sol. Si vols que dibuixem amb tu aquests quatre salts sobre la teva infraestructura concreta —i especialment el quart—, escriu-nos.
Fonts. Els fets confirmats (data i hora de l'atac, les quatre zones, els 495 clients, la vulnerabilitat en el programari de codi obert del sistema d'autenticació del portal, l'escalada a administrador del pla de virtualització passant per la consola de gestió, els 206 clients amb dades de còpia extraïbles, l'absència de fuga de dades dels servidors virtuals de clients, les consultes indegudes a informació de registre de fins a 71 empreses —amb noms o correus de fins a 31— i les 4 contrasenyes d'accés modificades) procedeixen del setè informe oficial d'IDC Frontier, publicat el 27 d'octubre del 2026; la xifra intermèdia de 194 clients i la valoració de «difícilment recuperable» són dels seus informes del 14 i del 8 d'octubre, recollits al mateix document. El pla de mesures està resumit dels apartats 4 (organització de seguretat independent, anàlisi de vulnerabilitats ampliada al codi obert i SBOM centralitzat) i 5 (reobertura del portal: proveïdor d'identitat extern i restricció per IP del client amb MFA obligatòria) d'aquest informe. La indicació de preparar un altre entorn i restaurar des de la còpia que conservi cada client és del tercer informe, del 8 d'octubre. Les xifres de l'atacant (239 hipervisors, 225 magatzems de dades, més de 16.600 discos de VM, 3,6 PB, 41,5 PB de capacitat de còpia, 554.153 snapshots i set minuts) procedeixen de captures difoses a les xarxes socials, recollides per ITmedia NEWS el 9 d'octubre del 2026: no estan verificades, l'empresa només ha dit haver vist imatges que semblen coincidir amb el que es va mostrar a la seva consola i no ha confirmat els números; les citem com a versió de l'atacant i l'argument del post no en depèn. La dada del 7 d'octubre a les 3:40 i el recompte de 495 apareixen també a la cobertura de Security NEXT. El nostre —la taula dels quatre salts, la lectura del pla de la víctima com a llista de preguntes i el criteri sobre el segon proveïdor— és la nostra manera de treballar, no una recomanació de l'informe citat. Foto: «Cage Quelle EMC HostCo GmbH» de Virtuo Doc, Wikimedia Commons, CC BY-SA 4.0.
Microsoft 365
ES 
CAT 
EN