Ningú va explotar res: qui verifica que ets tu abans de restablir el teu MFA

El divendres 7 d'agost, Levi Strauss & Co. va presentar un 8-K a la SEC per explicar que un tercer no autoritzat va accedir a tres ordinadors propietat de l'empresa mitjançant enginyeria social i es va endur informació corporativa. El document no esmenta cap CVE ni cap versió sense pedaç: l'únic vector que declara és aquest. No hi ha res aquí que es pogués haver tancat el dimarts anterior aplicant actualitzacions, i aquesta és exactament la part que ens interessa. La feina amb què la majoria mesurem la seguretat —posar pedaços, actualitzar, reiniciar— no hauria canviat res.

Escrivim això des d'una posició incòmoda. L'avís conjunt de CISA i l'FBI sobre Scattered Spider, referència AA23-320A, descriu un grup que ataca grans empreses i els help desks d'IT que aquestes empreses tenen contractats. Nosaltres som un help desk d'IT contractat: donem suport gestionat 24x7 a empreses. Quan algú truca dient que ha perdut el mòbil i no pot entrar al correu, qui decideix què passa a continuació és una persona del nostre equip. L'avís parla de companyies grans, i convé dir-ho per no inflar l'alarma; però el procediment que descriu s'executa igual en una empresa de trenta persones, amb menys gent per verificar i més confiança prèvia. Així que aquest article va, en primer lloc, del nostre propi procediment.

El que diu el 8-K i el que no diu

Convé ser precisos, perquè en dos dies aquesta història ja s'explicava de diverses maneres. El text que Levi Strauss va registrar diu que un tercer no autoritzat va accedir i va exfiltrar determinada informació corporativa després d'entrar en tres ordinadors d'empresa mitjançant un atac d'enginyeria social. Hi afegeix que la resposta va contenir l'accés, que no hi va haver interrupció de les operacions, que la companyia creu que no es van veure afectades dades de consumidors i que no considera que l'incident tingui un impacte material. La investigació continua oberta amb ajuda externa.

I ara el que no diu, que és igual d'important: no diu com va ser l'enginyeria social. No sabem si va ser una trucada, un missatge per Teams, un correu o una barreja. No hi ha atribució: cap grup no ho ha reivindicat, i les relacions que alguns mitjans han apuntat amb campanyes de suplantació telefònica són hipòtesis, no un fet confirmat. Nosaltres no hem participat en la resposta a aquest incident i no tenim informació privilegiada de res. Si algú t'explica el guió exacte de la trucada, se l'està inventant.

Amb això n'hi ha prou per al que aquí importa. Tres ordinadors. Cap vulnerabilitat pel mig. Una empresa amb pressupost de seguretat de multinacional. I un vector que no era tècnic.

El 65% ja no entra per un CVE

L'informe anual de resposta a incidents de Unit 42, la unitat de Palo Alto Networks, publicat el 17 de febrer del 2026 sobre els més de 750 incidents greus que van atendre durant el 2025, hi posa la xifra: el 65% de l'accés inicial s'aconsegueix amb tècniques basades en identitat —robatori de credencials, evasió de l'MFA i configuracions errònies d'IAM—. I les debilitats d'identitat van tenir un paper material en gairebé el 90% de les investigacions que van fer. És el que es van trobar en entrar a netejar, no una projecció. Tampoc no és la primera xifra d'aquesta família que citem aquest estiu, i totes empenyen cap al mateix lloc.

Aquesta dada incomoda sobretot per on deixa l'esforç. Un cicle de pedaços decent costa diners, finestres de manteniment, reinicis nocturns i discussions amb qui no vol que li toquin el servidor. Tot això continua sent necessari i ho defensem cada setmana. Però cobreix la part minoritària del problema. La majoritària es decideix en tres minuts de conversa, sense registre tècnic, amb una persona cansada a l'altre costat que vol ajudar i tancar el tiquet.

La fallada no és de qui agafa el telèfon

L'avís AA23-320A, actualitzat el 29 de juliol del 2025, descriu el mètode amb una sequedat que agraïm: els atacants es fan passar per empleats per convèncer el personal d'IT o del help desk que faciliti informació sensible, restableixi la contrasenya de l'empleat i traslladi el seu MFA a un dispositiu que ells controlen. I hi afegeix el detall que més ens va fer pensar: fan servir tècniques «per capes», amb diverses trucades i contactes previs l'únic objectiu dels quals és esbrinar quins passos exigeix un restabliment en aquella organització concreta.

Llegeix-ho una altra vegada. L'atacant no trenca el procediment: l'estudia. Truca a les nou, pregunta una ximpleria, penja. Truca a les onze amb una altra excusa i comprova si li demanen el número d'empleat. A la tercera ja sap què li preguntaran i porta les respostes. Contra això, la formació antiphishing de l'empleat serveix de poc: qui rep la trucada és dels nostres, i està fent la seva feina exactament com se li va demanar.

Aquí hi ha la tesi de tot l'article, i és una acusació al procediment, no a les persones: en moltíssimes organitzacions —també en moltes que s'auditen i es certifiquen— sonar convincent compta com a identitat. Saber el nom del cap, el departament, els quatre últims dígits del DNI o el dia que vas entrar a treballar no prova res, perquè tot això és a LinkedIn, en una filtració antiga o a la signatura de qualsevol correu. Si la teva verificació es basa en coses que es poden saber, la teva verificació és un qüestionari, no una prova.

El restabliment és la porta del darrere de qualsevol factor

Hi ha una resposta molt estesa a això que és correcta a mitges i per això resulta perillosa: «nosaltres ja tenim MFA resistent al phishing». Vam escriure fa unes setmanes sobre la retirada de l'SMS com a segon factor a Microsoft Entra i sobre per què les claus d'accés són millors. Ho continuen sent. Però un factor criptogràfic protegeix l'ús de la credencial, no la seva inscripció. Si el taulell de suport pot registrar un factor nou per a un compte a petició de qui truca, l'atacant no necessita trencar res: s'inscriu ell.

Dit d'una altra manera: la fortalesa de la teva autenticació és la del camí més feble per obtenir-la, i aquest camí gairebé mai no és el criptogràfic. És el formulari de «he perdut el mòbil». Val la pena mirar això amb la mateixa lupa amb què mirem l'accés privilegiat del proveïdor: fa uns dies explicàvem que l'agent de gestió remota del teu proveïdor d'IT és superfície d'atac, i això és el mateix problema vist des de l'altre costat del cable. Un dóna accés a l'equip; l'altre, a la identitat. A la pràctica, acaben al mateix lloc.

Vuit punts que demanem abans de restablir

Això és criteri nostre, no una norma que puguis citar en una auditoria. És el que considerem mínim perquè un restabliment de contrasenya o una reinscripció d'MFA no depengui de com de convincent soni una veu. Vuit punts, i cap no necessita comprar programari:

• Trucada de tornada al número del directori. No al número que apareix a la pantalla ni al que dicta qui truca. Si el número del directori està desactualitzat, el problema és el directori i cal arreglar-lo, no saltar-se el pas.
• Aprovació fora de banda d'un responsable identificat. Un segon humà, en un altre canal, que confirmi que aquella persona és qui diu. I amb nom: «ho va aprovar algú de RRHH» no serveix.
• Prohibir les dades «coneixibles» com a prova. DNI, data d'alta, nom del responsable, número d'empleat: serveixen per localitzar l'expedient, mai per autoritzar el canvi.
• Verificació en vídeo amb document per als comptes que ho mereixen. És incòmode i lent. També és l'única cosa que no es resol llegint un perfil públic.
• Llista curta de comptes que el suport no restableix mai per telèfon. Administració global, direcció, finances, qui signa pagaments. Per a aquests, presencial o amb un segon aprovador de la mateixa empresa.
• Avís automàtic a l'usuari legítim per un canal diferent. Si a algú li restableixen l'MFA i no ha estat ell, que se n'assabenti al mateix minut i sàpiga a qui trucar.
• Quarantena després de reinscriure un factor. Unes hores en què aquesta identitat no arriba al més sensible. Un empleat real que ha perdut el mòbil pot esperar a demà per entrar a la banca de l'empresa; un atacant amb pressa, no.
• Permís explícit per dir que no. Per escrit i signat per la direcció del client: ningú del suport no serà renyat per fer esperar un director que no es va poder verificar. Sense això, els set punts anteriors són decoració.

El vuitè és el que de debò decideix si això funciona, i és l'únic que no depèn de nosaltres. La pressió jeràrquica és l'eina principal de l'atac: qui truca exagera la urgència i el seu càrrec precisament perquè sap que a les set de la tarda ningú no vol ser qui li diu que no al director financer.

El preu, en minuts i en enfats

Un restabliment que avui es resol en tres minuts passa a trigar vint o trenta, i alguns no es resolen fins l'endemà. Algú s'enfadarà, i amb raó, perquè arriba tard a una reunió per culpa d'un procediment nostre. Aquest és el preu real i no el disfressarem: la seguretat de la identitat es paga en fricció, no en llicències.

Per això aquesta no és una decisió del departament d'IT. Un proveïdor no pot imposar fricció als usuaris del seu client sense que la direcció del client l'hagi acceptada abans per escrit, perquè a la tercera queixa la fricció desapareix i torna el «bé, aquest ja el conec». La conversa difícil, quan això es defineix bé, és acordar a qui es pot fer esperar.

Quatre dreceres que no prendrem

• Contractar més formació antiphishing i donar-ho per resolt. Ajuda amb el correu. El problema és un altre: aquí decideix el teu personal de suport, i el que li falta és un procediment que li permeti negar-s'hi.
• Refiar-nos de l'identificador de trucada. Falsificar el número d'origen és més difícil que fa dos anys: des del juny del 2025, i per l'Ordre TDF/149/2025, els operadors espanyols han de bloquejar les trucades internacionals que es presenten amb numeració espanyola. Però aquest bloqueig no cobreix el que s'origina dins d'Espanya ni converteix l'identificador en una prova. Que a la pantalla surti el número intern de l'empresa no autoritza res.
• Aplicar el procediment dur a tothom. Si verificar en vídeo costa igual per al becari que per al director financer, el becari deixa de trucar i s'ho apanya pel seu compte, que és pitjor. Gradua-ho pel que el compte pot fer.
• Donar per fet que un incident així es veu al tiquet. Un restabliment aprovat no genera cap alerta: és una operació legítima feta per gent legítima. Només es veu després, en el que el compte fa a continuació.

I després de la trucada

L'últim punt de la llista anterior és el que enllaça amb l'altra meitat de la feina. Si l'accés s'aconsegueix per la porta i amb les claus bones, cap barrera d'entrada no l'aturarà; el que queda és notar què passa després. Una bústia que de sobte crea una regla de reenviament, un compte que entra des d'un lloc nou vint minuts després d'un restabliment, un portàtil que comença a llegir carpetes compartides que mai no havia obert. Això és detecció i resposta gestionada, i és el segon control quan el primer s'ha saltat netament.

Amb un matís que anem repetint des que vam escriure sobre la fatiga d'alertes: una alerta de reinscripció d'MFA que arriba a una bústia que ningú no mira és exactament igual d'útil que no tenir-la. Si penses activar avisos per cada canvi de factor, decideix abans qui els llegeix un diumenge a la tarda i què en fa. Si la resposta és «ja ho veurem dilluns», millor no encendre'ls i no enganyar-se.

Res d'això no és cap novetat, i aquest és el problema. L'avís de CISA explica el mètode des del 2023, es va actualitzar fa un any llarg i continua descrivint amb precisió el que va passar divendres en una empresa moltíssim més gran que la majoria de les que atenem. Si no has escrit mai què es demana abans de restablir un MFA, avui és un bon dia. I si vols que ho revisem amb tu, en parlem i ho mirem amb el que ja tinguis escrit.