El 30 de juliol vam escriure aquí sobre VMSA-2026-0006 i, entre les dades de l'avís, vam copiar una frase de Broadcom: no tenia informació que suggerís explotació in the wild de cap d'aquelles cinc fallades. Rapid7, que va analitzar l'avís el mateix dia, ho va formular encara més ample: ni explotació ni escaneig per als dos 9,8 de vCenter. Les dues coses eren certes el 29 de juliol. Cinc dies després, el 3 d'agost, els primers vCenter compromesos van començar a connectar-se amb la infraestructura de l'atacant.
Això no és una correcció d'aquell post: la dada era correcta i ho continua sent amb la seva data al davant. El que ha canviat és el pes que donem a aquesta mena de frase quan algú la fa servir —i es fa servir molt— per justificar que la finestra de manteniment pot esperar al setembre. Operem VMware i Proxmox en producció i no venem llicències de cap dels dos, així que aquí no hi ha res a col·locar. Hi ha un calendari, uns números amb els seus matisos i una pregunta que gairebé ningú sap respondre en menys de mitja hora.
El calendari, dia a dia
El 12 d'agost, la firma alemanya QUIRSO va publicar el que va trobar arran d'una resposta a incident: una campanya activa contra sistemes vCenter accessibles des d'internet, atribuïda de manera temptativa a un actor de tipus APT, que explota
La forma d'aquesta corba importa més que el total. Hi ha un dia de pic i una setmana en què ja hi és gairebé tot, sense degoteig previ de mesos. Qui planifiqui els seus pedaços per trimestres competeix contra una campanya que va col·locar el 95 % de les seves víctimes conegudes en els set dies següents a l'avís —i que a data de l'informe encara sumava: divuit adreces més entre el 6 i el 12 d'agost—.
Què no diuen aquests 361
Els investigadors mateixos posen tres límits a la seva xifra, i ens sembla la part més honesta de l'informe:
- 361 IP no són 361 empreses. Ho diuen amb totes les lletres: d'aquestes adreces no se'n pot inferir el nombre d'organitzacions víctima, perquè una IP no equival necessàriament a una empresa ni a un sistema físic. N'hi pot haver diverses darrere d'una, i una empresa darrere de diverses.
- Trobar
reverse_ssh no prova res per si sol. És una eina de codi obert legítima —shell inversa sobre SSH, reenviament de ports, transferència de fitxers— i els mateixos autors avisen que la seva presència no s'ha de tractar, sense més, com a prova d'activitat maliciosa. Cal correlacionar-la amb altres indicis. - Els indicadors encara no estan publicats. QUIRSO diu que els indicadors propis de l'atacant i el material de detecció addicional sortiran més endavant, coordinats amb les forces de seguretat per no interferir en una investigació en curs. De moment hi ha una regla YARA per caçar
reverse_ssh i poc més. Si esperaves una llista d'IP per posar al tallafocs avui mateix, no n'hi ha.
Un número que ve amb els seus propis límits val molt més que un número rodó sense ells. Ho diem perquè els pròxims dies aquest 361 apareixerà en presentacions comercials convertit en «361 empreses hackejades», i no és això el que diu l'informe.
La frase de l'avís que cal aprendre a llegir
«En el moment de la publicació no hi ha constància d'explotació ni d'escaneig». Aquesta formulació, l'ampla, és de Rapid7; l'avís de Broadcom en diu la meitat —que no té informació que suggereixi explotació in the wild— i és la que vam reproduir nosaltres. Totes dues eren veritat el 29 de juliol. El que falla és la lectura que en fem: es llegeixen com un pronòstic quan són una foto de la telemetria de qui escriu, el dia que escriu. El seu valor caduca pràcticament a l'instant en què s'imprimeix, perquè el mateix avís és el que posa tothom a mirar el mateix lloc.
Els investigadors ho diuen amb la reserva al davant: encara que l'atacant pogués tenir coneixement previ de la fallada, la forta correlació entre la data de divulgació i la de l'inici de l'explotació apunta que la mateixa divulgació va ser el punt de partida de la campanya. És l'asimetria de sempre, ara amb dates sobre la taula. L'avís avisa els dos costats alhora, i només un dels dos ha de demanar una finestra de manteniment, coordinar-se amb el proveïdor de l'aplicació de facturació i esperar el dimarts vinent.
Que ningú ho llegeixi com una crítica a publicar avisos: sense aquest document no hauries pogut pedaçar res. El que no val és fer servir el «no hi ha constància» com a argument per endarrerir. La nostra regla, des de fa temps, és tractar aquesta frase com a informació sobre el passat i calcular la urgència amb l'única cosa que sí que és una propietat de la fallada: si cal autenticar-se, si cal interacció i des d'on es pot arribar al servei. Els dos 9,8 de vCenter d'aquest avís no demanen credencials; la resta és aritmètica.
Les tres paraules que fan tota la feina: «accessible des d'internet»
El 9,8 del CVSS assumeix que l'atacant té accés de xarxa al servei, i qui té aquest accés ho decideixes tu. Per això la campanya no va contra tots els vCenter del món, sinó contra els que contesten des d'internet: aquest és el filtre que separa les 361 adreces de la resta del parc mundial, i és l'única part de l'equació que tens a la mà un cop publicat l'avís.
La pregunta incòmoda, doncs, no és «ho hem pedaçat?». És «qui pot obrir una connexió TCP contra el nostre vCenter?». A la majoria de llocs on entrem, aquesta resposta no està escrita enlloc: es reconstrueix mirant regles de tallafocs que va posar algú que ja no hi és, una regla temporal d'un projecte del 2023 i una VPN que en realitat dona accés a tota la VLAN de gestió. Reconstruir-la porta una tarda. Tenir-la escrita, i revisada, és literalment la feina de Zero Trust: el pla de gestió no té privilegis especials per ser intern, i qui no necessita arribar-hi no hi arriba.
I el contrapès honest, que també està escrit a les anàlisis d'aquest avís: restringir les interfícies de gestió a una xarxa interna o dedicada redueix l'exposició a internet, però no mitiga el risc d'un atacant que ja és dins de la teva xarxa. Treure el vCenter d'internet et treu del cens d'aquesta campanya concreta; no et treu del problema. Dit d'una altra manera: l'exposició explica qui va entrar a l'agost, no qui podria entrar el mes que ve des d'un portàtil ja compromès. Aquest matís ja ens va fer escriure sobre la consola de gestió d'un altre fabricant, i aquí torna amb dates.
Què mirar aquesta tarda si tens vSphere
- La versió exacta, no la de memòria. Amb PowerCLI, després de
Connect-VIServer, les variables $global:DefaultVIServer.Version i .Build. Les versions corregides que recullen les anàlisis de l'avís són 9.1.0.0300 per a la branca 9.1, 9.0.2.0100 per a la 9.0 i 8.0 U3k per a la 8.0; la revisió VMSA-2026-0006.1, del 3 d'agost, hi va afegir els pedaços exprés 8.0 U2f de vCenter i ESX per a qui sigui a l'Update 2, o sigui que no cal saltar d'update per tapar-ho. No hi ha workaround: o pedaces, o continues exposat. - L'exposició, mesurada des de fora. A la LAN tot hi arriba sempre, així que la prova es fa des d'una IP d'internet: contesta el vCenter? Contesta el servei de syslog, que és justament el component de la fallada? Si la resposta a alguna de les dues és «no ho sé», ja has trobat per on començar.
- Si vas estar exposat i sense pedaçar entre el 29 de juliol i avui, «ja està pedaçat» no tanca l'assumpte. Toca mirar tasques de cron que ningú recorda haver creat a l'appliance i, sobretot, connexions sortints: un vCenter no té cap motiu per iniciar sessions SSH cap a internet. Ja ho vam escriure amb un altre fabricant i l'argument no ha envellit: aplicar el pedaç no fa fora qui ja era a dins.
- Els registres d'aquest període, amb reserves. Al post del 30 de juliol vam dir que la fallada que menys puntuava del lot —la de registre insuficient a ESX— era la que decidiria si un informe posterior diu «això és el que va fer» o «això és el que creiem que va fer». Dues setmanes després hi ha gent escrivint exactament aquest informe. Si et toca, aquí tens el detall de l'avís complet.
- La data i l'hora de tot el que facis. Quina versió tenies, quan es va aplicar el pedaç, qui el va aplicar i què va quedar pendent. En un incident aquesta línia temporal val més que qualsevol eina, i és el primer que et demanaran.
La distància que de debò importa
De tot aquest episodi, el número que ens preocupa no és 361, sinó la distància entre «es publica un avís crític d'un producte que tenim» i «algú amb permisos ho està mirant». Aquesta vegada aquesta distància havia de ser menor de cinc dies, a l'agost i amb mitja plantilla de vacances. A la majoria d'organitzacions no depèn de l'equip tècnic, que se n'assabenta el primer dia, sinó de si hi ha un torn amb capacitat de decidir un canvi urgent sense esperar el comitè de setembre. És la part menys vistosa del suport 24×7 i la que decideix si surts en un recompte com aquest.
Cosa que no vol dir que avui toqui declarar una emergència a tot arreu. Si el teu vCenter mai no ha contestat des d'internet i vas pedaçar la primera setmana, no formes part de la població d'aquesta campanya, i un canvi d'emergència ara només et costarà atenció i errors. Ho diem encara que soni estrany venint de qui ven serveis de seguretat: no tot avís de 9,8 és el teu incendi. I tampoc és un argument per canviar d'hipervisor —Proxmox publica els seus propis avisos, amb els seus reinicis i les seves finestres—, perquè el que es trasllada d'una plataforma a l'altra és la feina, no el rellotge.
Fonts (verificades): la campanya activa contra vCenter accessible des d'internet, les 361 adreces IP víctima a 47 països, el primer contacte amb infraestructura de l'atacant el 3 d'agost (cinc dies després de l'avís), el pic de 151 adreces noves el 4 d'agost, les 343 de 361 assolides el 5 d'agost, els cinc països més afectats (185 de 361), l'ús de reverse_ssh, l'advertiment que una IP no equival a una organització, el que diu que la presència de reverse_ssh no és per si sola prova d'activitat maliciosa i l'ajornament dels indicadors per coordinació amb les forces de seguretat — informe de QUIRSO GmbH (12 d'agost del 2026) i la cobertura de The Hacker News, que és a més la font del detall de la tasca de cron que desplega la persistència. La descripció de CVE-2026-59310 (directory traversal al servidor syslog de vCenter, CVSS 9,8, sense autenticació), la data de l'avís VMSA-2026-0006 (29 de juliol del 2026), la frase «no hi ha constància d'explotació ni d'escaneig en el moment de la publicació», les versions corregides i l'observació que restringir les interfícies de gestió a xarxes internes redueix l'exposició a internet però no mitiga un atacant ja present a la xarxa: anàlisi de Rapid7. La lectura de la frase de l'avís com a foto i no com a pronòstic, la pregunta sobre qui pot obrir una connexió al vCenter, el criteri de quan NO declarar emergència i la regla de datar tot el que s'apliqui són nostres. Imatge: cronòmetre esportiu (rawpixel, CC0).
Saps qui arriba avui al teu pla de gestió?
A everyWAN mantenim infraestructura d'altres i portem la part de seguretat d'aquests entorns. La resposta a «qui pot arribar a vCenter, a l'hipervisor i a la consola de còpies» no s'hauria de reconstruir enmig d'un ensurt: s'escriu una vegada, es revisa i s'aplica amb Zero Trust, i després cal algú de guàrdia que la faci complir a l'agost amb suport 24×7. Si vols una opinió sense comissió al darrere, explica'ns què tens muntat.
Parlar amb everyWAN