La lliçó anterior va recórrer els atacs tècnics i va acabar amb una observació: la majoria de les cadenes d'atac no comencen amb un exploit, sinó amb una persona que fa alguna cosa raonable en un moment equivocat. Aquesta lliçó s'ocupa d'aquest vector. L'enginyeria social no ataca sistemes: ataca els mecanismes de decisió de les persones, i ho fa amb tècniques que fa segles que funcionen i que la tecnologia només ha abaratit. Veuràs per què el factor humà és el vector dominant, quins principis d'influència exploten els atacants, el catàleg complet de tècniques —de la pesca de credencials o phishing massiu al frau del CEO dirigit a la Sara, passant pel vishing, el quishing i el consent phishing—, com desmuntar un correu maliciós indicador per indicador llegint-ne les capçaleres, i les defenses: les tècniques del correu (SPF, DKIM i DMARC) i les de procés, que en frau són les que realment aturen els diners. Tot amb un principi de fons que convé fixar des d'ara: si la teva defensa depèn que 38 persones encertin sempre, no tens defensa.

1. Per què el factor humà és el vector dominant
2. Els principis d'influència que exploten els atacants
3. Catàleg de tècniques d'enginyeria social
4. Anatomia d'un correu de phishing dirigit a Nimbus
5. Llegir les capçaleres: Received, SPF, DKIM i DMARC
6. Defenses tècniques del correu
7. Per què Nimbus necessita DMARC també per protegir els seus clients
8. Defenses de procés: verificació, suport i cultura de report
9. Simulacres de phishing i les seves mètriques

Un atacant que vol entrar a Nimbus té dos camins:

L'asimetria és demolidora i explica tota la resta:

• L'atacant necessita encertar un cop; el defensor, sempre. Amb 38 persones, centenars de correus al dia i un cicle de decisions sota pressió, la probabilitat acumulada que algú faci clic alguna vegada tendeix a un.
• No cal vulnerar res. Si la Sara introdueix la seva contrasenya en una pàgina falsa, no hi ha hagut intrusió: hi ha hagut una autenticació perfectament vàlida des del punt de vista del sistema.
• Salta per sobre de gairebé tots els controls tècnics. El tallafoc no veu res anòmal, l'antivirus no veu fitxer, el WAF veu trànsit HTTPS normal. És exactament el mite 2 de 02-01.
• Escala. Enviar cent mil correus no costa pràcticament res; personalitzar-ne deu per a objectius concrets costa unes hores.

Tres precisions importants que canvien l'enfocament:

1. L'enginyeria social no explota l'estupidesa, explota el funcionament normal del cervell humà. Cooperar amb qui sembla legítim, respondre ràpid al que és urgent i obeir l'autoritat són comportaments adaptatius i necessaris perquè una empresa funcioni. Un equip entrenat per desconfiar de tot no treballa.
2. Les víctimes més freqüents no són les menys formades, sinó les més ocupades i les més serioses a l'hora d'ajudar. El Rubén, que atén desenes de tiquets al dia i la missió del qual és ajudar, és un objectiu estructuralment vulnerable: la seva feina consisteix a fer el que li demanen desconeguts.
3. Qualsevol hi pica el dia equivocat. Professionals de seguretat experimentats cauen en proves internes quan el correu arriba en el moment just. Aquest fet té una conseqüència directa sobre com es dissenyen les defenses: no es pot construir un sistema l'únic control del qual sigui el criteri humà.

La conclusió de disseny: les persones són una capa de detecció valuosa —sovint la primera i l'única que veu un atac nou—, però mai no han de ser l'única capa de prevenció. La defensa contra l'enginyeria social és la combinació de filtratge tècnic, processos que no depenen del criteri individual i una cultura que fa fàcil reportar.

Els missatges d'enginyeria social eficaços no s'improvisen: apliquen de forma sistemàtica un grapat de ressorts psicològics ben coneguts. Reconèixer-los és la millor defensa individual, perquè desplaça la pregunta de «sembla real?» a «per què tinc pressa?».

Els atacs eficaços combinen principis, i la combinació clàssica és autoritat + urgència + confidencialitat:

«Sóc la Marta. Estem tancant la ronda de finançament i necessito que facis avui una transferència al despatx d'advocats. No ho comentis amb ningú fins que s'anunciï. Et passo les dades.»

Per què aquesta combinació és tan eficaç, desmuntada peça a peça:

• L'autoritat fa que qüestionar la petició es percebi com una insubordinació.
• La urgència elimina el temps de verificar.
• La confidencialitat —l'element més verinós— desactiva l'únic control que funcionaria: preguntar a un company. Ningú no confirmarà la petició amb l'Iván si li han demanat que no ho comenti.

La regla defensiva que se'n deriva: quan un missatge combina pressa amb secret, la probabilitat de frau és altíssima. Una organització sana mai no exigeix saltar-se un procediment per confidencialitat. I si de debò ho fes, aquest seria el problema. Aquesta regla, escrita i difosa, val més que qualsevol formació general.

• Al final del dia o abans de vacances, quan la càrrega cognitiva és màxima i la tolerància als tràmits, mínima.
• Quan la petició coincideix amb alguna cosa que s'està esperant. Si la Sara està tramitant de debò una factura d'un proveïdor, un correu sobre aquesta factura passa tots els filtres mentals. Per això l'OSINT i el compromís previ d'una bústia són tan rendibles per a l'atacant.
• En una situació nova, on no hi ha procediment establert: la primera vegada que es contracta un proveïdor, la primera migració, el primer dia d'un empleat.

BEC i el frau de canvi de compte bancari. És el que mou més diners i el que menys sembla un atac informàtic. La variant perillosa no és la suplantació matussera, sinó la bústia realment compromesa: l'atacant entra al correu d'un proveïdor de Nimbus, llegeix la conversa durant setmanes, aprèn el to, els imports i el calendari, i en el moment exacte respon dins del fil real amb una factura autèntica en la qual només ha canviat l'IBAN. No hi ha cap domini semblant per detectar, no hi ha cap fallada d'SPF: el correu ve del remitent veritable.

Contra això només funciona el procés. Cap indicador tècnic no salva la Sara aquí. El que la salva és una regla: tot canvi de dades bancàries es verifica per telèfon, al número que ja teníem en fitxa, mai al que apareix al correu.

MFA fatigue. Ataca el punt feble del segon factor per notificació push: l'aprovació és un botó sense context. L'atacant, que ja té la contrasenya, llança intents repetits fins que la víctima accepta perquè pari, o accepta mig adormida creient que és una fallada de sincronització. La defensa és al mecanisme mateix —number matching, límit d'intents, context a la notificació— i es detalla a 02-05.

Consent phishing. El més elegant i el pitjor entès. L'atacant no roba la contrasenya: registra una aplicació amb un nom plausible i envia un enllaç legítim del proveïdor d'identitat. La víctima veu la pantalla real del seu proveïdor, amb el cadenat correcte, i concedeix permisos. Conseqüències:

• L'MFA no protegeix, perquè la víctima s'autentica de debò.
• Canviar la contrasenya no revoca res: el consentiment sobreviu.
• L'accés és persistent mitjançant un token de refresc, i sovint passa desapercebut durant mesos.

La defensa és administrativa: desactivar el consentiment lliure d'usuari, exigir aprovació de l'administrador per a aplicacions noves i revisar periòdicament les aplicacions autoritzades al tenant de correu de Nimbus.

Aquest és el correu que rep la Sara un dijous a les 17:40. Està construït amb tot el de l'apartat 2. Analitza'l abans de llegir-ne el desmuntatge.

És l'habilitat pràctica més rendible de tota la lliçó, i gairebé ningú no l'ensenya bé.

La regla: el domini real són les dues últimes etiquetes abans de la primera barra. Tot el que va davant són subdominis que controla qui posseeix el domini real. Qualsevol pot crear banc.laevaempresa.example.eldomini.example.

Compara:

Consell operatiu: en un correu dubtós no es fa clic per comprovar. Es passa el ratolí per sobre i es llegeix la barra d'estat, o millor: s'escriu l'adreça coneguda al navegador. Si el missatge era legítim, l'avís també serà dins de l'aplicació.

Les capçaleres són la part del correu que l'atacant controla pitjor. Saber llegir-les converteix una sospita en un diagnòstic.

Cada servidor pel qual passa un correu afegeix una capçalera Received al principi. Per tant es llegeixen de baix cap amunt per seguir el recorregut cronològic.

Què se'n treu, d'aquí:

• El correu va néixer a 203.0.113.99 (línia inferior), no a la infraestructura de Nimbus.
• ESMTPA al primer salt indica que l'emissor es va autenticar en aquest servidor de sortida: algú té un compte en aquest proveïdor, dada útil per a una denúncia.
• unknown significa que la resolució inversa de la IP no coincideix amb el nom declarat: senyal de baixa reputació.
• Només són fiables les capçaleres afegides per servidors que tu controles (les de dalt). Les inferiors les pot falsificar l'atacant, així que es fan servir com a indici, no com a prova.

El punt clau que gairebé tothom passa per alt: SPF i DKIM, per separat, no protegeixen contra la suplantació del From visible. Un atacant pot publicar SPF i DKIM vàlids per al seu propi domini i tot i així posar From: Marta <[email protected]>. El que lliga les tres peces és DMARC, mitjançant el requisit d'alineació: el domini del From ha de coincidir amb el de l'SPF o el del DKIM.

Traducció línia a línia:

• spf=fail: la IP 198.51.100.203 no és entre les autoritzades pel domini del sobre.
• dkim=none: no hi ha cap signatura. No és que sigui invàlida: no existeix.
• dmarc=none (p=NONE ... dis=NONE): el domini de l'atacant o no publica DMARC o el publica en mode passiu; dis=NONE indica que no s'ha aplicat cap disposició, és a dir, el correu s'ha lliurat.

I aquí hi ha la lliçó incòmoda: el correu va arribar igualment a la safata d'entrada de la Sara tot i fallar SPF i no tenir DKIM. Per dos motius: el domini de l'atacant és seu i el pot configurar com vulgui, i el filtre de Nimbus no estava configurat per actuar sobre aquestes fallades. Un compromís raonable —enviar a quarantena el que falla SPF i afegir un avís visible— hauria canviat el desenllaç.

Compara-ho amb un correu legítim:

spf=pass, dkim=pass amb el selector sel2026, i dmarc=pass amb política p=REJECT: el domini del From està alineat i, si no ho estigués, el destinatari hauria rebutjat el missatge.

Anatomia del registre, camp a camp:

L'error més comú: acabar en ~all (softfail) «per si de cas» i deixar-ho així per sempre. ~all diu al destinatari «això és sospitós, però accepta-ho». La majoria de les bústies el lliuren igualment. Es comença amb ~all durant la posada en marxa i s'acaba en -all; si no, SPF és decoratiu.

Dues limitacions que cal conèixer:

1. SPF es trenca amb el reenviament. Si un client reenvia un correu de Nimbus, la IP emissora passa a ser la del seu servidor i SPF falla. Per això DKIM és imprescindible: sobreviu al reenviament.
2. Límit de 10 consultes DNS. Encadenar molts include: supera el límit i el resultat passa a ser permerror, que equival a no tenir SPF. Cal revisar-ho cada vegada que s'afegeix un proveïdor.

Nimbus signa cada correu sortint amb una clau privada; el destinatari recupera la clau pública del DNS i verifica.

Què aporta DKIM que SPF no pot: garanteix la integritat (el cos i les capçaleres signades no s'han alterat) i sobreviu al reenviament, perquè no depèn de la IP. La signatura es veu a la capçalera DKIM-Signature del missatge. El detall de com funciona una signatura digital s'estudia a 03-03 i 03-04; aquí n'hi ha prou de saber llegir el resultat.

El desplegament correcte, per fases, que és on fracassen la majoria de les implantacions:

Per què no es pot saltar la fase 1. Nimbus envia correu des d'almenys cinc llocs: el servidor propi, el proveïdor de correu transaccional (recordatoris de cita), l'eina de facturació, la plataforma de màrqueting i potser el CRM. Passar directament a p=reject bloqueja els recordatoris de cita dels pacients, cosa que seria un incident de disponibilitat autoinfligit. Els informes rua de la fase 1 revelen exactament quins emissors existeixen —inclosos els que ningú no recordava— abans d'endurir res.

Fins aquí, DMARC semblava una defensa per a Nimbus. És la meitat de la història i la menys important.

Nimbus envia diàriament recordatoris de cita a pacients de clíniques. Aquests pacients estan acostumats a rebre correus de nimbusreservas.example. Si Nimbus no publica DMARC amb política de rebuig, qualsevol pot enviar correus que es mostrin com a procedents de Nimbus, i arribaran a la safata d'entrada d'aquests pacients.

L'escenari concret:

1. Un atacant envia a deu mil adreces un correu amb From: [email protected].
2. El missatge diu: «La seva clínica ha actualitzat la política de pagaments. Confirmi les seves dades bancàries per mantenir la cita.»
3. Com que Nimbus no publica DMARC, el correu es lliura sense cap avís.
4. Els pacients que hi cauen, hi cauen en nom de Nimbus.

Les conseqüències, ordenades per gravetat:

• Dany reputacional directe a l'actiu A-20: les clíniques en culparan Nimbus, amb raó.
• Deteriorament de l'entregabilitat: quan un domini es fa servir massivament per a frau, la seva reputació cau i els recordatoris legítims comencen a anar a correu brossa. Nimbus perdria el seu canal operatiu principal.
• Exposició contractual i reguladora: els clients preguntaran quines mesures hi havia, i «cap» és una resposta difícil de sostenir quan la mesura costa un registre DNS.

La formulació que convé recordar: SPF, DKIM i DMARC no protegeixen la teva safata d'entrada; protegeixen el teu domini de ser usat contra altres. Són mesures d'higiene cap enfora, no de defensa cap endins. I per això són especialment importants per a un SaaS que envia correu en nom dels seus clients.

Nota addicional per al cas de Nimbus: si en el futur els clients volen que els recordatoris surtin des del seu domini ([email protected]), caldrà documentar com deleguen l'enviament —normalment amb un subdomini delegat i el seu propi DKIM— sense trencar el seu DMARC. És una conversa tècnica que convé tenir abans de vendre la funcionalitat.

Nota sobre implicacions legals: un correu fraudulent enviat en nom de Nimbus a pacients dels seus clients pot tenir implicacions en matèria de protecció de dades i de relació contractual amb el client. Davant d'un cas real, valora-ho amb el responsable de compliment i amb assessoria jurídica; el tractament s'aborda a 06-03.

Les defenses tècniques aturen volum. El que atura el frau dirigit és el procés, perquè un procés no es cansa, no té pressa i no es deixa impressionar per l'autoritat.

La regla d'or, redactada per penjar-la a la paret:

Tota petició de pagament, de canvi de dades bancàries o de credencials que arribi per escrit es verifica per un canal diferent, fent servir un contacte que ja teníem, abans d'executar-la. Sense excepcions per urgència i sense excepcions per jerarquia.

Les quatre paraules que fan que funcioni:

• Canal diferent: si va arribar per correu, es verifica per telèfon o en persona. Respondre al correu no val: pot estar controlat.
• Contacte que ja teníem: el número de la fitxa del proveïdor o del directori intern, mai el que apareix al missatge.
• Abans d'executar-la: verificar després de transferir és una autòpsia.
• Sense excepcions: una regla amb excepcions per urgència es converteix en una regla que només s'aplica quan no cal. I la urgència és justament el ressort de l'atac.

Procediment concret per a Nimbus (propietària del procés: la Sara):

Un detall que evita la fallada més habitual: cal donar permís explícit i per escrit per dir que no a la direcció. Si la Sara sap que la Marta la donarà suport per retardar un pagament per verificar-lo, verificarà. Si tem la reprimenda, no ho farà. La regla no la protegeix si la cultura la contradiu.

El Rubén és l'objectiu estructural: rep peticions de desconeguts i la seva funció és ajudar. Necessita un procediment que li permeti ajudar sense decidir sota pressió.

Escenari típic de vishing: trucada al suport de Nimbus. «Hola, sóc en Carlos, el nou administrador de Clínica Turia. Sóc a consulta amb pacients esperant i no puc entrar al tauler. Em pots restablir la contrasenya o donar-me accés temporal? És urgent, tinc la sala plena.»

Aquí hi ha autoritat (administrador del centre), urgència (pacients esperant) i simpatia. I una petició que sona perfectament raonable.

Procediment de verificació en tres nivells:

Les tres regles que sostenen el procediment:

1. La trucada de tornada al número de fitxa ho resol gairebé tot. Trenca l'atac sense necessitat que el Rubén jutgi si la història és creïble.
2. Mai no es demana ni s'accepta un codi de verificació. Cap suport legítim —ni el de Nimbus, ni el del banc, ni el del proveïdor cloud— no demana el codi que acaba de rebre l'usuari. Si algú el demana, és un atac, sense més anàlisi.
3. La pressió és un indicador, no una raó. Com més pressa hi posa l'interlocutor, més a poc a poc cal anar. Convé entrenar una frase concreta: «És clar, ara mateix et truco jo al número que tenim en fitxa i ho resolem.»

Aquest apartat és el que evita més incidents, perquè el temps entre el clic i l'avís determina el desenllaç.

Instruccions per a qualsevol empleat de Nimbus, per ordre:

1. Avisa immediatament. Canal únic i conegut: [email protected] o missatge directe a la Lucía. Abans d'intentar arreglar-ho pel teu compte.
2. Si vas introduir una contrasenya, canvia-la al lloc real —escrivint l'adreça a mà— i avisa igualment. Si la reutilitzaves en un altre lloc, canvia-la també allà.
3. Si vas aprovar una notificació MFA que no havies demanat, avisa'n: significa que algú té la teva contrasenya.
4. Si vas obrir un adjunt, desconnecta l'equip de la xarxa (wifi i cable) i no l'apaguis: apagar-lo destrueix evidència útil. Espera instruccions.
5. Si vas fer una transferència, truca al banc immediatament: hi ha una finestra d'hores per intentar la retrocessió.
6. No esborris el correu. És l'evidència que permet buscar a qui més li va arribar.

I la regla cultural, que és la més important de tota la lliçó:

A qui reporta no se'l culpa. Mai. Sota cap circumstància.

El raonament, que convé poder explicar a la direcció: si castigues qui informa, el següent no informarà. Un clic reportat en 5 minuts és un incident contingut; el mateix clic reportat al cap de tres setmanes —o no reportat— és una bretxa. El comportament que vols reforçar no és «no picar» (impossible de garantir) sinó «avisar ràpid» (perfectament assolible). Una organització que celebra els reports n'obté més, i amb ells detecció primerenca gratis.

Corol·lari pràctic: els resultats individuals dels simulacres no es publiquen, no es comparen i no entren a l'avaluació de l'acompliment. Es fan servir de forma agregada per mesurar el programa, no les persones.

Un simulacre és un enviament controlat de correus de phishing benignes al mateix equip, per mesurar i entrenar. Ben fets són l'eina de sensibilització més eficaç; mal fets generen ressentiment i destrueixen la confiança. El programa formatiu complet es desenvolupa a 06-05; aquí només el necessari per entendre'ls com a defensa.

Per què la taxa de report importa més que la de clic. La taxa de clic mesura una cosa que mai no arribarà a zero: sempre hi haurà algú ocupat en el moment equivocat. La taxa de report mesura una cosa que sí que pots portar molt amunt i que aporta un valor operatiu directe: cada report és una alerta primerenca. Un equip amb 12 % de clic i 55 % de report està molt més ben defensat que un amb 6 % de clic i 3 % de report, perquè al segon ningú no s'assabenta de res.

El temps fins al primer report és igualment crític: si el primer avís arriba als 6 minuts, la Lucía pot buscar el missatge a totes les bústies, eliminar-lo i blocar el domini abans que la majoria l'obri. Un sol empleat atent protegeix els altres 37.

Bones pràctiques:

• Anunciar el programa, no els enviaments. Tothom ha de saber que hi haurà simulacres periòdics; ningú no ha de saber quan.
• Dificultat progressiva. Començar amb esquers genèrics i pujar gradualment cap a l'escenari dirigit, perquè la millora sigui mesurable.
• Formació immediata en el moment del clic, breu (dos minuts) i sense to acusador: quins indicadors tenia aquest correu concret.
• Mesurar sempre la taxa de report, no només la de clic. Si la teva plataforma no la mesura, canvia de plataforma.
• Resultats agregats, mai individuals ni lligats a l'acompliment.
• Tancar el cicle: compartir amb tot l'equip els indicadors del correu utilitzat. El que ensenya no és l'enviament, és l'explicació posterior.

Pràctiques que fan mal i cal evitar:

• Fer servir esquers cruels: falses primes, falsos acomiadaments, falses notícies mèdiques. Aconsegueixen taxes de clic altíssimes i destrueixen la confiança en el programa i en RH durant anys.
• Publicar qui hi va picar. Converteix el simulacre en un càstig públic i garanteix que ningú no torni a reportar res.
• Mesurar només el clic i presentar-lo a direcció com si fos el nivell de seguretat de l'empresa.
• Fer un simulacre a l'any. És una foto, no un programa. Trimestral és un ritme sostenible per a Nimbus.
• Suplantar persones reals de l'equip sense acord previ. Fer servir el nom de la Marta en un esquer pot danyar la relació de confiança interna; es pot fer, però ha d'estar acordat i explicat després.

Errors comuns:

• Creure que la formació resol el problema. Redueix la taxa de clic, no la porta a zero. La formació és una capa; el procés i el filtratge són les altres dues.
• Confiar a «reconèixer les faltes d'ortografia». Els correus dirigits actuals estan ben escrits, en un català o castellà correcte i amb context real de l'empresa. Aquest consell està obsolet i dona falsa confiança.
• Culpar qui reporta. L'error més car de tots: destrueix l'única font de detecció primerenca que té una pime.
• Publicar DMARC en p=none i donar-ho per fet. Sense política de rebuig, DMARC només informa. Milers de dominis fa anys que són en p=none.
• Verificar responent al mateix correu. Si la bústia està compromesa, respon l'atacant. El canal alternatiu és el que defineix la verificació.
• Demanar el codi de verificació a un usuari a suport. Legitima l'atac de vishing més comú. Mai, en cap cas.
• Pensar que el consent phishing l'atura l'MFA. No l'atura: la víctima s'autentica de debò i concedeix permisos voluntàriament.
• Blocar el QR com un problema menor. El quishing trasllada l'atac al mòbil personal, fora de l'abast de tots els controls corporatius.
• Dissenyar el procediment de pagaments sense la persona que paga. Un procediment que la Sara no pot complir en el seu dia a dia no es compleix.

Consells:

• Ensenya una sola habilitat tècnica a tot l'equip: llegir un domini de dreta a esquerra. És la que atura més atacs per minut de formació.
• Instal·la el bàner de correu extern aquesta setmana. Cost zero, eficàcia alta contra el frau del CEO.
• Escriu la regla de verificació de pagaments en una pàgina, amb llindars concrets, i fes que la Sara i la Marta la signin. Un procediment sense propietari ni llindars no s'aplica.
• Dona a l'equip una frase d'escapada entrenada per al telèfon: «Et truco jo al número que tenim en fitxa». Tenir la frase preparada evita el bloqueig davant de la pressió.
• Revisa avui les aplicacions OAuth autoritzades al correu corporatiu de Nimbus i desactiva el consentiment lliure d'usuari.
• Comprova els teus tres registres amb dig ara mateix: SPF (-all), DKIM (selector actiu) i DMARC (p= i rua=). És un diagnòstic de tres minuts.
• Mesura la taxa de report des del primer simulacre i presenta-la a direcció com a mètrica principal, per davant de la taxa de clic.

L'Iván rep aquest missatge un dimarts al matí:

Es demana: (a) enumera tots els indicadors de frau que hi trobis; (b) explica el detall més perillós d'aquest correu en concret, que el fa més difícil de detectar que el de la Sara; (c) indica què ha de fer l'Iván, pas a pas; (d) digues quina defensa tècnica de les de l'apartat 6 l'hauria marcat i quina no.

Nimbus ha estat a punt de perdre 14.200 € en un frau de canvi d'IBAN. La Marta et demana un procediment d'una pàgina que la Sara pugui aplicar de debò.

Es demana:

1. Redacta la regla general en una sola frase.
2. Defineix una taula de llindars i verificacions per a: proveïdor nou, canvi d'IBAN de proveïdor existent, pagament superior a 3.000 €, canvi de compte de nòmina i devolució a un client.
3. Especifica què es registra de cada verificació i on.
4. Indica tres formes concretes en què el procediment podria fallar a la pràctica i com prevenir-les.
5. Explica què ha de fer la Sara si la Marta en persona li demana saltar-se el procediment.

Nimbus fa el seu primer simulacre trimestral. S'envia als 38 empleats un correu que suplanta el proveïdor de correu transaccional demanant revalidar credencials.

Es demana: (a) calcula i interpreta les mètriques de l'apartat 9.1; (b) digues quina és la dada més preocupant del quadre i per què; (c) proposa cinc accions concretes per al trimestre següent, ordenades per impacte esperat; (d) explica què no s'ha de fer amb aquests resultats, en particular amb la dada de Suport.

Solució 1

(a) Indicadors presents:

1. Domini semblant al remitent: github-security-alerts.example no és el domini real del proveïdor. És un domini propi de l'atacant, amb aspecte corporatiu.
2. Enllaç emmascarat: https://github.com.security-alerts.example/.... Llegit de dreta a esquerra, el domini real és security-alerts.example; github.com només n'és un subdomini. És el mateix truc del correu de la Sara, aquí més eficaç perquè incorpora un .com que indueix a llegir malament.
3. Urgència amb amenaça: «suspensió automàtica en 24 hores» — por + urgència.
4. Pretext tècnicament creïble i personalitzat: esmenta el repositori real, un commit i un fitxer amb número de línia. Gairebé amb seguretat obtingut per OSINT si el repositori va ser públic alguna vegada, o simplement inventat amb noms plausibles.
5. Petició d'iniciar sessió des de l'enllaç: els avisos legítims demanen anar al lloc, no ofereixen la porta.
6. Salutació en minúscula i sense cognom (Hola ivan): suggereix plantilla generada a partir de la part local del correu.
7. Emissor incoherent: smtp7.envio-masivo.example no és infraestructura del proveïdor suplantat.

(b) El detall més perillós: SPF, DKIM i DMARC passen tots. I això és correcte, perquè l'atacant ha configurat bé el seu propi domini. Aquí hi ha la lliçó essencial:

L'autenticació de correu verifica que el missatge ve realment del domini que diu el From. No verifica que aquest domini sigui de fiar. Un dmarc=pass d'un domini registrat ahir per un estafador és un pass perfectament vàlid.

Molts usuaris i no pocs tècnics interpreten «autenticació superada» com «correu legítim». És un error de categoria, i aquest correu l'explota. El correu de la Sara fallava SPF i era fàcil; aquest ho passa tot i és difícil.

(c) Què ha de fer l'Iván:

1. No prémer l'enllaç.
2. Obrir el navegador i escriure a mà l'adreça del proveïdor real. Si hi hagués una alerta de secret exposat, hi seria.
3. Reportar el correu al canal oficial sense esborrar-lo, perquè la Lucía el pugui buscar a la resta de bústies i blocar el domini.
4. Independentment que el correu sigui fals, comprovar si de debò hi ha un secret a config/settings.py. El pretext pot ser inventat, però el problema podria existir; i si existeix, cal rotar la credencial, no només esborrar-la del codi (continua a l'historial de Git).
5. Si per qualsevol motiu va arribar a introduir credencials: canviar la contrasenya al lloc real, revocar sessions i tokens actius, i avisar immediatament.

(d) Defenses tècniques:

• L'haurien marcat: l'avís de domini semblant al d'un proveïdor habitual; la reescriptura i comprovació d'enllaços en el clic (la destinació és un domini registrat fa poc i de baixa reputació); la reputació del domini, per edat de registre; i el bàner de correu extern, que almenys recorda que no és intern.
• No l'haurien marcat: SPF, DKIM ni DMARC, perquè l'atacant els compleix per al seu propi domini. Tampoc el filtre d'adjunts: no hi ha adjunt. I un antivirus no hi veu res, perquè no hi ha fitxer.

Solució 2

1. Regla general:

«Cap ordre de pagament, canvi de dades bancàries o alta de beneficiari s'executa només amb una petició escrita. Es verifica sempre per un canal diferent, amb un contacte que ja era a la nostra fitxa, i es deixa constància de qui va verificar, quan i amb qui va parlar. La urgència no eximeix; la jerarquia tampoc.»

2. Taula de llindars:

3. Registre. Al sistema de gestió, al costat de l'assentament: data i hora de la verificació, nom de qui va verificar, nom i telèfon de l'interlocutor, canal usat, i resultat. Sense registre, la verificació no ha passat a efectes d'auditoria (06-04).

4. Tres formes de fallar i la seva prevenció:

5. Si la Marta en persona demana saltar-se el procediment. La Sara l'ha d'aplicar igualment, i aquesta és precisament la raó de ser de la regla: el procediment protegeix també la Marta, perquè impedeix que algú que la suplanti aconsegueixi un pagament. La formulació pràctica: «És clar, ho tramito ara mateix; només necessito la confirmació de la segona signatura, com en tots els pagaments.» Perquè això sigui possible, la Marta ha d'haver declarat per escrit i davant de tot l'equip que ningú no serà renyat per aplicar el procediment a la direcció. Sense aquest suport explícit, cap procediment antifrau no sobreviu al primer contacte amb la jerarquia.

Solució 3

(a) Mètriques:

(b) La dada més preocupant. No és el 29 % de clic: és la combinació de taxa de report de l'11 % i 47 minuts fins al primer avís. Raonament: el clic sempre existirà, però en un atac real aquests 47 minuts són la diferència entre esborrar el correu de 38 bústies abans que la majoria l'obri i descobrir l'incident setmanes després per les seves conseqüències. A més, sis persones van lliurar credencials i només una de les que van interactuar va avisar: significa que les altres cinc sabien o sospitaven que alguna cosa anava malament i no ho van dir. Això apunta a un problema de cultura, no de coneixement, i la cultura és el que cal arreglar primer.

(c) Cinc accions, per impacte esperat:

1. Comunicar i fer visible el canal de report, amb un botó de «Reportar phishing» al client de correu i un missatge explícit de la direcció: reportar sempre s'agraeix, picar mai no se sanciona. Ataca directament la mètrica pitjor.
2. Sessió de 30 minuts amb l'anàlisi del correu real utilitzat, indicador per indicador, inclosa la lectura del domini de dreta a esquerra. Tancar el cicle és el que converteix el simulacre en formació.
3. MFA resistent al phishing a tots els comptes, prioritzant els administratius. Amb un MFA adequat, aquestes sis credencials lliurades no haurien bastat per entrar. És la mesura que més redueix l'impacte amb independència de la taxa de clic (02-05).
4. Activar el bàner de correu extern i l'avís de domini semblant, si no ho estan. Cost gairebé nul, efecte immediat sobre el reconeixement.
5. Sessió específica i de suport amb l'equip de suport, no per la seva taxa de clic sinó perquè la seva exposició és estructuralment més gran: juntament amb la sessió, dotar-los del procediment de verificació d'identitat de l'apartat 8.2, que els treu la càrrega de decidir.

(d) Què NO fer:

• No publicar ni comunicar qui hi va picar, ni en agregat per persona ni en una llista.
• No assenyalar Suport com «el departament problemàtic». Els seus tres clics de quatre persones reflecteixen que la seva feina consisteix a obrir missatges de desconeguts i ajudar-los: és una dada sobre el disseny del lloc de treball, no sobre les persones. Tractar-ho com una falta personal garanteix que suport no torni a reportar res, justament l'equip que veu més atacs.
• No vincular els resultats a l'avaluació de l'acompliment ni a incentius.
• No presentar a direcció només la taxa de clic. L'indicador principal ha de ser la taxa de report i el temps fins al primer avís, que són les que mesuren la capacitat real de reaccionar.
• No donar el problema per resolt amb un correu informatiu. Sense canvis en MFA, en filtratge i en el procediment, el proper simulacre donarà resultats gairebé idèntics.

Has estudiat el vector que encapçala gairebé totes les estadístiques d'incidents. Saps per què el factor humà és dominant: l'asimetria és aclaparadora —l'atacant necessita encertar un cop, el defensor sempre— i l'atac no vulnera res, sinó que aconsegueix que algú faci voluntàriament el que se li demana. Has vist que l'enginyeria social no explota la ignorància sinó el funcionament normal del criteri humà, i que els objectius més freqüents són els més ocupats i els més disposats a ajudar, com el Rubén, la feina del qual consisteix literalment a ajudar desconeguts. D'aquí la conclusió de disseny que estructura tota la lliçó: les persones són una excel·lent capa de detecció i una pèssima única capa de prevenció.

Has après els principis d'influència —autoritat, urgència, escassetat, reciprocitat, prova social, simpatia, por i coherència— i la combinació més perillosa, autoritat més urgència més confidencialitat, el tercer ingredient de la qual existeix per desactivar l'únic control que funcionaria: preguntar a un company. Has recorregut el catàleg de tècniques, del phishing massiu al BEC des d'una bústia realment compromesa, el frau de canvi d'IBAN dirigit a la Sara, l'smishing, el vishing, el quishing, el baiting, el tailgating, l'MFA fatigue i el consent phishing que ni l'MFA ni el canvi de contrasenya no aturen. Has desmuntat un correu complet amb els seus dotze indicadors i has après l'habilitat més rendible de totes: llegir un domini de dreta a esquerra. I has après a llegir capçaleres: la cadena Received de baix a dalt, i el significat exacte de spf=fail, dkim=none i dmarc=none, juntament amb la lliçó que dona l'exercici de l'Iván —que un dmarc=pass acredita el domini, no l'honradesa de qui el va registrar.

En defenses tècniques has vist SPF amb el seu -all decisiu, DKIM amb el seu selector i la seva capacitat de sobreviure al reenviament, i DMARC com la peça que lliga les anteriors mitjançant l'alineació, amb un desplegament per fases que no es pot saltar sense deixar sense recordatoris els pacients de les clíniques. I has entès el que gairebé ningú no explica: que aquests tres registres no protegeixen la teva bústia, protegeixen el teu domini de ser usat contra altres, cosa que en el cas de Nimbus significa protegir els pacients dels seus clients. En defenses de procés t'endús la regla de verificació per canal alternatiu amb contacte de fitxa, el procediment de tres nivells per al suport del Rubén, el què fer si hi has picat, i la regla cultural que sosté tota la resta: a qui reporta no se'l culpa mai, perquè el comportament que es pot garantir no és «no picar», sinó «avisar ràpid». Els simulacres t'han donat les mètriques correctes, amb la taxa de report i el temps fins al primer avís per davant de la taxa de clic.

Conegut el catàleg complet d'atacs —tècnics a 02-02 i humans aquí— toca ordenar la resposta. A la lliçó següent, Mesures de Protecció en Ciberseguretat (02-04), recorrerem el catàleg de defenses organitzat per les capes de la defensa en profunditat: perímetre i xarxa, endpoint, dada, aplicació i cicle de desenvolupament, i registre i observabilitat; amb un exemple de flux de CI que analitza dependències i secrets, i amb el més útil per a una pime: una taula de les dotze mesures de més retorn per a Nimbus i un pla per fases de 30, 90 i 180 dies.