El token que no demana MFA: les apps connectades al teu Microsoft 365

Més de set-centes organitzacions van quedar potencialment exposades l'agost del 2025 i a cap li van robar una contrasenya. Ningú va saltar un segon factor, ningú va explotar un CVE a la seva infraestructura. L'atacant es va endur els tokens OAuth d'un xatbot comercial que aquestes empreses havien connectat al seu CRM temps enrere, i amb ells va demanar les dades per l'API, educadament, exactament igual que feia aquella aplicació cada matí. El 13 de juliol del 2026 Microsoft va publicar el mapa complet d'un any llarg d'aquesta tècnica. Val la pena llegir-lo encara que no tinguis Salesforce, perquè la peça que falla no és de Salesforce: és el consentiment, i aquesta també la tens tu.

Gestionem tenants de Microsoft 365 i fa anys que empenyem els clients cap al mateix: MFA obligatori, accés condicional, i darrerament fora l'SMS i dins les passkeys. Aquesta feina calia fer-la i la tornaríem a fer. Però ara ve la part incòmoda, i preferim dir-la nosaltres: res d'això no toca aquesta mena d'atac. No perquè estigui mal muntat, sinó perquè l'atac no passa per l'inici de sessió.

Un any, dues cadenes i cap contrasenya

L'informe de Microsoft cobreix de mitjans del 2025 a mitjans del 2026 i descriu dues cadenes d'atac contra instàncies de SaaS de clients: l'abús de consentiment a base de trucades de telèfon i el compromís de proveïdors integrats. Cap de les dues no és un error de programari; totes dues són abusos d'un mecanisme que funciona exactament com està dissenyat. Veuràs per aquí que van ser «tres vies», comptant els permisos mal configurats d'usuaris convidats: això ve de la cobertura de premsa. Al text de Microsoft, l'accés de convidat és a les recomanacions de bastionatge, no pas entre les cadenes d'entrada.

Fixa't en el que tenen en comú. No hi ha una contrasenya robada al client final. No hi ha un inici de sessió estrany des d'un país estrany. En tots dos casos, l'atacant entra fent servir una autorització que la mateixa víctima va concedir, mesos o anys abans, probablement una tarda de dimarts i probablement sense pensar-s'ho dues vegades.

L'MFA respon a una altra pregunta

Un token OAuth no és una contrasenya. És un permís ja signat. Quan un usuari prem «Accepta» en aquella pantalla de consentiment que gairebé ningú llegeix, la plataforma emet a l'aplicació un passi per actuar en nom seu, i a més un token de refresc perquè pugui renovar-lo sola, sense tornar a molestar ningú. A partir d'aquí l'aplicació crida l'API tantes vegades com vulgui. No hi ha pantalla de login. No hi ha repte d'MFA. No hi ha inici de sessió interactiu que pugui semblar sospitós, perquè no hi ha inici de sessió.

Dit de la manera més curta que se'ns acut: l'MFA protegeix el moment en què algú demostra qui és. El consentiment decideix què pot fer un tercer en nom teu a partir d'aleshores. Són dues preguntes diferents, i el sector fa cinc anys que contesta en massa la primera. La segona gairebé ningú no l'ha revisada mai.

Ara tradueix-ho al teu tenant

A Microsoft 365 això es diu «aplicacions empresarials», i per sota, entitats de servei. Cada eina que algú ha connectat alguna vegada —el signador de PDF, el CRM, l'app de fitxatges, el connector de la gestoria, l'assistent de reunions que resumeix les actes— hi té la seva fitxa amb els seus permisos. Hi ha dues famílies, i la diferència importa molt més del que sembla:

• Permisos delegats: l'aplicació actua en nom d'un usuari i hereta el que aquell usuari pot fer. La lletra petita, que ha canviat fa poc i convé tenir al dia: per defecte qualsevol usuari pot concedir els permisos que no requereixen aprovació d'administrador, però els tenants nous arrenquen amb la política gestionada per Microsoft («deixa que Microsoft gestioni els teus ajustos de consentiment»), que ja exclou el més llaminer: Mail.Read, Mail.ReadWrite, Files.Read.All, Sites.Read.All, els permisos de calendari i de xat, i l'EWS, l'IMAP i el POP a l'Exchange Online. Traduït: en un tenant creat fa poc un usuari ja no pot regalar la seva bústia; en un del 2019 que ningú no ha tocat, depèn de quin ajust tingui posat. Comprova-ho abans de donar res per fet.
• Permisos d'aplicació: l'aplicació actua sola, sense usuari al darrere. No hi ha ningú a qui demanar un MFA. I com que no hi ha usuari, les polítiques d'accés condicional que vas escriure per a la teva gent no li apliquen. Existeix accés condicional per a identitats de càrrega de treball, sí, però requereix llicències específiques i —això és el que gairebé ningú no sap— la mateixa documentació avisa que no cobreix aplicacions SaaS de tercers ni aplicacions multiinquilí. Justament les d'aquesta història.

I ara el detall que ens sembla el més interessant de tota la documentació, perquè va just en sentit contrari. Al costat d'aquesta política gestionada ve activada de sèrie una altra, la de clients de correu, que torna exactament aquests permisos de correu a l'usuari per a sis aplicacions concretes: Apple Mail, Thunderbird, Spark, eM Client i els clients de correu d'Android i de Samsung. És a dir, que la porta que Microsoft va tancar a la política principal la deixa ajustada per a mitja dotzena de clients populars, i cap no és teu ni l'administres tu. No diem que estigui malament —és una decisió d'usabilitat raonable i són aplicacions conegudes—, diem que probablement no ho sabies, que surt a la documentació oficial i que és la mena de cosa que cal mirar abans d'afirmar que al teu tenant ningú no pot concedir accés a la seva bústia.

I no s'acaba aquí: els permisos delegats i d'aplicació no són l'única via d'accés. La mateixa documentació de Microsoft recorda que també concedeixen accés els rols de directori, l'RBAC de l'Exchange per a aplicacions i el consentiment específic de recurs del Teams. És a dir: hi ha més d'una llista per mirar, i no són a la mateixa pantalla.

L'inventari que gairebé ningú té

La versió de clic és al centre d'administració de l'Entra, a Aplicacions empresarials → Totes les aplicacions → l'aplicació que sigui → Permisos, amb dues pestanyes: consentiment d'administrador i consentiment d'usuari. Avís important que surt a la documentació i sorprèn tothom el primer cop: els consentiments de la pestanya d'usuari no es poden revocar des del portal. Per a això cal anar al Graph o al PowerShell. I com que aquella pantalla és una fitxa per aplicació, es navega fatal quan n'hi ha dues-centes, nosaltres sempre comencem per la llista completa:

Connect-MgGraph -Scopes "Directory.Read.All","Application.Read.All"

# Precargamos las entidades de servicio en memoria: si no, se hace
# una llamada a Graph por cada concesion y acabas con throttling
$sp = @{}
Get-MgServicePrincipal -All | ForEach-Object { $sp[$_.Id] = $_.DisplayName }

# Consentimientos delegados del tenant: quien los dio, a quien y para que
Get-MgOauth2PermissionGrant -All | ForEach-Object {
    [pscustomobject]@{
        App      = $sp[$_.ClientId]
        Alcance  = $(if ($_.ConsentType -eq 'AllPrincipals') { 'TODO EL TENANT' } else { 'un usuario' })
        Permisos = $_.Scope
    }
} | Sort-Object App | Export-Csv .\consentimientos.csv -NoTypeInformation -Encoding UTF8

Aquesta consulta contesta tres coses de cop: quines aplicacions tenen permís, si el permís el va donar un administrador per a tota l'organització o un usuari solt per a ell mateix, i quins abasts concrets inclou. La primera vegada que l'executes en un tenant d'una empresa de cinquanta persones sol sortir una llista més llarga del que ningú esperava, amb un parell de noms que ja no reconeix ni qui els va autoritzar. I aquí comença la conversa que interessa.

Els permisos d'aplicació, els que actuen sense usuari, van en una altra consulta, i aquesta triga una estona perquè recorre totes les entitats de servei del directori:

# Permisos de aplicacion: los que no necesitan a nadie delante.
# Ojo: saldran tambien muchas apps de primera parte de Microsoft;
# el trabajo esta en las que NO reconozcas.
Get-MgServicePrincipal -All | ForEach-Object {
    $roles = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $_.Id
    if ($roles) {
        # Editor = tenant que publica la app, NO es el publicador verificado
        [pscustomobject]@{ App = $_.DisplayName; Editor = $_.PublisherName; Asignaciones = $roles.Count }
    }
} | Sort-Object Asignaciones -Descending

Què mirar a cada línia

Tenir la llista no és tenir la feina feta. Aquests són els criteris amb què la recorrem, i uns quants surten tal qual de la guia d'investigació de Microsoft. Un avís abans de continuar, perquè ens sembla de justícia dir-ho: els filtres bonics —ús a la comunitat, última autorització, nombre d'usuaris que la van autoritzar— viuen al Defender for Cloud Apps i al govern d'aplicacions, que no entra a qualsevol pla. Si la teva llicència no ho inclou, el criteri serveix igual; el que canvia és que la informació la treus del Graph i del registre d'auditoria en comptes d'una pantalla que t'ho dona mastegat.

• Permisos que no encaixen amb el que fa l'aplicació. L'exemple que fa servir la mateixa documentació és una app de rellotge amb accés total a totes les bústies. Sona a acudit fins que el trobes.
• Aplicacions autoritzades per molt pocs usuaris. Contraintuïtiu però molt útil: com més comuna i més usada és una aplicació, més probable és que sigui legítima. Una que va autoritzar una sola persona mereix una mirada.
• Data d'última autorització antiga. Sol assenyalar aplicacions que ja ningú no fa servir i que ningú no trobarà a faltar si desapareixen. Són el millor lloc per començar a netejar, perquè el risc de trencar res és baix.
• Nom, editor o web amb pinta estranya —així, en aquests termes, ho planteja la guia—. No és una prova de res per si sola, però combinada amb permisos alts canvia l'ordre de la cua. L'exigència d'editor verificat és una altra cosa i viu a la configuració de consentiment, no en aquesta pantalla.
• Qui va donar el consentiment i quan. És al registre d'auditoria. Si el nom que apareix ja no treballa a l'empresa, tens dos problemes i no un.

El botó que no fa el que et penses

Aquí hi ha, per a nosaltres, el més important de tot l'article, i és una frase de la documentació de Microsoft que haurien d'emmarcar: els canvis en la configuració de consentiment d'usuari només afecten els consentiments futurs; els ja concedits continuen intactes i els usuaris conserven l'accés amb els permisos que es van donar abans.

Traducció a la vida real: si demà desactives el consentiment d'usuari i te'n vas a dinar tranquil, has tancat la porta per la qual ja va entrar tothom que hi havia d'entrar. El que estava concedit continua concedit. És una mesura d'higiene futura, no una neteja. La neteja és l'altra, l'avorrida: revisar la llista aplicació per aplicació i treure el que sobra.

I quan revoquis, dos matisos més que també són a la documentació i que convé tenir clars abans de dir a un client «ja està resolt». El primer: revocar el permís no impedeix que l'usuari torni a consentir el proper cop que l'aplicació l'hi demani; si vols que no torni, cal impedir el consentiment o treure l'aplicació del mig. El segon, de física de tokens: un token d'accés ja emès viu el que li queda de vida —Microsoft documenta un valor aleatori d'entre 60 i 90 minuts, i dues hores per a clients tipus Teams i Microsoft 365 en tenants sense accés condicional—, així que el tall no és instantani. El tall real arriba quan l'aplicació intenta renovar i ja no pot.

Tancar la porta sense tancar el negoci

La recepta de manual és «desactiva el consentiment d'usuari» i a una altra cosa. Nosaltres l'apliquem, però no el dilluns a les nou i sense avisar, i aquí ens mullarem en contra del que es llegeix per aquí. Dues raons. La primera és d'operació: trenques integracions que la gent fa servir cada dia i que no apareixen en cap inventari teu, perquè ningú no et va demanar permís per muntar-les. La segona és més de fons, i és la que de debò ens preocupa: si bloqueges el camí i no n'ofereixes cap, l'alternativa que troba l'usuari sempre és pitjor. S'endú el fitxer al seu compte personal, es reenvia el correu al seu Gmail, s'instal·la l'eina al portàtil de casa. Has guanyat a la pantalla de consentiment i has perdut la dada.

Per això l'ordre que seguim és aquest, i l'ajust dur va al final i acompanyat. Primer l'inventari, que a més és l'única part que no trenca res. Segon, la neteja del que ja no es fa servir, començant pel que fa un any que no s'autoritza. Tercer, endurir per damunt del que ja portes de sèrie: passar de la política gestionada per Microsoft a la d'editor verificat més permisos que tu hagis classificat com de baix impacte, que no són el mateix encara que totes dues sonin igual al desplegable. I quart, el flux d'aprovació d'administrador, perquè quan algú necessiti una eina nova tingui un botó per prémer i una persona que li contesti en un termini raonable. Sense aquest quart pas, els tres primers duren sis setmanes.

Hi ha un detall més de la campanya que no volem que passi desapercebut, perquè és el que més s'assembla al que li pot passar a una pime demà. Una de les dues cadenes comença amb una trucada de telèfon. Algú es fa passar pel suport informàtic i aconsegueix que un empleat autoritzi una aplicació amb nom creïble. És el guió de sempre, amb un altre objectiu: ja no volen la contrasenya, volen l'«Accepta». Contra això no hi ha ajust que valgui si la gent no sap què està signant; i per això a la formació d'usuari li tenim més respecte que a la meitat dels productes que es venen per a això. El mateix que explicàvem del wifi d'hotel i les credencials de Microsoft 365: la baula atacada és la persona, no el protocol.

El que no et direm

No et direm que desconnectis les integracions. Seria un titular còmode i una ximpleria: el valor de tenir el CRM parlant amb el correu és real i l'hem muntat nosaltres moltes vegades. Tampoc no et direm que Microsoft ho fa malament. El mecanisme de consentiment és correcte i és infinitament millor que l'alternativa, que era repartir contrasenyes. El que falla no és el mecanisme, és que ningú no el tracta com el que és: una llista de tercers amb clau de casa teva, que s'hauria de revisar igual que revises qui té accés VPN o qui continua sent administrador de domini.

Una última cosa, i és la que més ens costa escriure: no tenim una xifra de quantes aplicacions amb permís de lectura de correu hi ha al tenant mitjà d'una pime espanyola. No ho hem mesurat i no ens ho inventarem. El que sí que podem explicar és la cara que es posa a l'altra banda de la taula quan obrim aquella pantalla per primer cop amb un client al davant i apareix una aplicació que va autoritzar algú que ja no hi treballa. Mai no hem hagut d'explicar per què aquella revisió valia la pena; s'explica sola.

Gestionem entorns de Microsoft 365 amb l'inventari d'aplicacions connectades dins de la revisió periòdica, no com una emergència quan el proveïdor de torn surt en un titular; i ho fem amb el mateix criteri amb què plantegem un model Zero Trust, que al capdavall diu això mateix: cap accés permanent per defecte, ni tan sols el d'una aplicació que un dia et va resultar útil. No venem llicències de ningú ni tenim comissió per integrar una eina o una altra, així que quan diem «aquesta app sobra» és perquè sobra.

Tanquem amb la pregunta que de debò importa, i no és si tens MFA. És aquesta: si demà el proveïdor d'una de les aplicacions que tens connectades al tenant sortís en un titular, quant trigaries a dir quins permisos li vas donar, qui els hi va donar i a quines dades podia arribar? Si la resposta passa per «caldria mirar-ho», la feina de què parla aquest article està sense fer. Es fa en un matí, i és molt millor fer-la un dimarts qualsevol que el dia del titular.

I si la teva llista de deures d'agost ja venia plena, avisem: el 31 d'agost venç el termini real de l'EWS a l'Exchange Online, que també va d'aplicacions amb accés al teu correu. Es fan bé tots dos d'una asseguda, perquè la llista de partida és pràcticament la mateixa.

Fonts (verificades): les dues cadenes d'atac, les dates i els incidents de Salesloft Drift (agost del 2025), Gainsight (novembre del 2025) i Klue (juny del 2026) provenen de l'anàlisi «Defending SaaS-based applications against ShinyHunters OAuth abuse» publicat per Microsoft Security el 13 de juliol del 2026, i de la seva cobertura a The Hacker News, d'on surten les xifres de més de 700 organitzacions potencialment exposades i més de 200 instàncies afectades. La campanya d'agost del 2025 i la seva finestra del 8 al 18 d'agost estan documentades per Google Threat Intelligence. El que fa referència a Microsoft 365 surt de la documentació oficial: el consentiment d'usuari per defecte, les polítiques de consentiment i l'advertiment que els canvis només afecten consentiments futurs, de «Configurar com els usuaris donen el consentiment a les aplicacions»; la política gestionada per Microsoft com a valor per defecte d'un tenant nou, la llista exacta de permisos que exclou i la política de clients de correu activada de sèrie amb les seves sis aplicacions (Apple Mail, Thunderbird, Spark, eM Client, Android i Samsung), d'«Administrar directives de consentiment d'aplicacions»; la revisió i revocació de permisos, la impossibilitat de revocar els consentiments d'usuari des del portal, l'avís que revocar no impedeix tornar a consentir i la menció als rols de directori, l'RBAC de l'Exchange i el consentiment específic de recurs del Teams, de «Revisar els permisos concedits a aplicacions empresarials»; els criteris d'investigació d'aplicacions sospitoses, d'«Investigar i corregir aplicacions OAuth de risc»; el requisit de llicència i l'exclusió d'aplicacions SaaS de tercers i multiinquilí, d'«Accés condicional per a identitats de càrrega de treball»; i la durada del token d'accés (valor aleatori de 60 a 90 minuts, i dues hores per a clients com el Teams i el Microsoft 365 en tenants sense accés condicional), de «Tokens d'accés a la plataforma d'identitat de Microsoft». Són criteri i opinió nostres, no de les fonts: que l'MFA i el consentiment responen a preguntes diferents, l'ordre en quatre passos, l'objecció a desactivar el consentiment d'usuari sense oferir alternativa i tot el que no et direm.