L'autenticazione può riuscire per l'organizzazione sbagliata
Un utente malintenzionato non ha bisogno di impersonare il dominio esatto di un'organizzazione attendibile per inviare un messaggio ingannevole. Possono gestire un dominio diverso, configurarne correttamente la posta elettronica e utilizzarlo per fare affermazioni fuorvianti. Un ricevitore può osservare il successo SPF, DKIM E DMARC per quel dominio mentre il messaggio tenta ancora una frode. Il risultato dell'autenticazione descrive l'utilizzo del dominio; non stabilisce che il dominio appartenga all'organizzazione che il lettore ha in mente o che l'azione richiesta sia legittima.
RFC 9989 limita esplicitamente gli obiettivi di DMARC . L'analisi del contenuto e l'autenticazione di entità diverse dai domini non rientrano nel suo ambito, così come lo sono gli attacchi ai nomi visualizzati. Questo confine spiega autenticato phishing senza suggerire che l'autenticazione sia tecnicamente fallita. La risposta appropriata combina l'identità del dominio, il contesto del messaggio e la verifica aziendale indipendente. Questo articolo costituisce una guida difensiva e non contiene modelli di phishing, istruzioni di consegna o test del dominio in tempo reale.
Distinguere l'autenticazione dall'affiliazione
Annotare il dominio nell'indirizzo del mittente effettivo e il dominio previsto dal destinatario. Se differiscono, non comprimerli perché il nome visualizzato, il logo o l'oggetto sembrano familiari. Un proprietario di dominio generalmente può organizzare l'autenticazione per la propria posta, ma ciò non dice nulla sulla sua relazione con un'altra azienda. Anche un vero sito web e un indirizzo di risposta funzionante non stabiliscono tale relazione. La questione è l’affiliazione e l’autorità, non semplicemente la coerenza tecnica.
RFC 5322, sezione 3.4, separa il nome visualizzato dall'indirizzo. Un'etichetta familiare può trovarsi sopra un dominio non correlato in un client di posta. L'etichetta può essere benigna, ambigua o ingannevole a seconda del contesto; non dichiarare l'intento solo dall'etichetta. Confronta l'indirizzo con un record aziendale attendibile e verifica l'azione aziendale specifica attraverso un canale stabilito al di fuori del messaggio discutibile.
Esaminare il significato di un risultato positivo
Un pass SPF autonomo può riguardare il mittente della busta dominio, mentre DKIM identifica un dominio firma. DMARC aggiunge un allineamento relazione al dominio Da visibile. Identificare quale percorso supporta il risultato riportato. Se tutte queste identità appartengono al dominio non familiare, il risultato può essere internamente coerente senza convalidare il marchio o l’individuo familiare nominato nel messaggio. Questa è una scoperta importante, non una contraddizione da spiegare.
Utilizzare prove del destinatario attendibili anziché accettare un'asserzione fornita dal mittente. RFC 8601 descrive il perché Authentication-Results i consumatori hanno bisogno di un confine di fiducia. Uno screenshot contenente il passaggio di parola potrebbe non rivelare chi ha valutato il messaggio o quale dominio è passato. Registra la fonte, l'ora e i campi di identità pertinenti. Laddove le prove sono insufficienti, preservare l’incertezza invece di affermare che il messaggio è passato o è fallito in modo definitivo.
Valutare separatamente l'azione richiesta
Identificare ciò che il mittente vuole che il destinatario faccia. Il rischio potrebbe essere una destinazione di pagamento modificata, la divulgazione di informazioni riservate, l'installazione di software, l'accesso in un luogo sconosciuto o un'alterazione di un flusso di lavoro stabilito. L'autenticazione del dominio non approva nessuna di queste azioni. Un messaggio tecnicamente valido può comunque contenere una falsa premessa, una richiesta non autorizzata o una destinazione estranea all'attività rivendicata.
Non controllare un collegamento sospetto effettuando l'accesso o inserendo informazioni. Utilizzare il processo di analisi e reporting stabilito dall'organizzazione, con personale qualificato e strumenti adeguati quando è necessaria un'ispezione più approfondita. Questa bozza non sostiene che l'ispezione visiva di un URL possa dimostrarne la sicurezza, né che ogni dominio sconosciuto sia dannoso. Un nuovo fornitore legittimo e un dominio di proprietà di un utente malintenzionato potrebbero non essere familiari; la verifica aziendale è ciò che risolve il rapporto.
Usa le difese del ricevitore senza sopravvalutarle
Panoramica sull'autenticazione della posta elettronica di Microsoft descrive l'autenticazione composita come parte di una valutazione più ampia, piuttosto che come una semplice sostituzione di SPF , DKIM e DMARC . Ciò supporta un approccio a più livelli: i sistemi riceventi possono combinare segnali di identità con altre informazioni quando decidono come gestire la posta. Non garantisce il rilevamento di ogni messaggio di phishing autenticato né definisce l'attuale comportamento di filtraggio di un altro provider.
Un destinatario può accettare, mettere in quarantena, eliminare o rifiutare i messaggi in base ai propri controlli e policy. Non dedurre la sicurezza dal posizionamento della posta in arrivo o dalla dannosità da un singolo risultato del filtraggio. Allo stesso modo, un pubblico lista bloccata Il risultato non è un verdetto universale sulla reputazione. Utilizzare la diagnostica del provider come prova con un ambito e un tempo noti. Mantieni la distinzione tra la classificazione di una macchina e l'autorità del proprietario dell'azienda ad approvare l'azione richiesta.
Un foglio di lavoro di affiliazione e azione
Crea un foglio di lavoro con l'organizzazione dichiarata, il dominio attendibile previsto, il dominio Da effettivo, il nome visualizzato, il dominio o i domini autenticati, il risultato del destinatario attendibile e l'azione richiesta. Aggiungi la fonte dell'evidenza per il dominio atteso, non solo per il dominio osservato. Registra se l'azienda ha una relazione consolidata con il mittente e se l'azione specifica si adatta a tale relazione. Mantieni un'opzione irrisolta anziché forzare ogni mittente sconosciuto nella categoria degli aggressori.
La seconda metà del foglio di lavoro registra il verificatore indipendente, il percorso di contatto precedentemente noto, la domanda posta, la risposta e il titolare della decisione. Evitare di utilizzare un numero di telefono o un indirizzo alternativo introdotto solo dal messaggio sospetto. Elimina le informazioni personali non necessarie nella copia condivisa preservando l'uguaglianza e la differenza del dominio. Un foglio di lavoro che sostituisce ogni indirizzo con lo stesso segnaposto non può dimostrare perché l'autenticazione non è riuscita a stabilire l'affiliazione.
Diagnosi fittizia: un nuovo dominio correttamente autenticato
Immagina che un team operativo immaginario riceva una richiesta che dichiara di provenire da un fornitore di apparecchiature familiare. Il mittente utilizza un dominio diverso che non è presente nel record dei fornitori approvati dal team. Le prove del ricevitore attendibile mostrano ipoteticamente DKIM allineato e un passaggio DMARC per quel dominio diverso. Il destinatario vede un nome visualizzato familiare e presuppone che il risultato dell'autenticazione confermi l'identità del fornitore. Non è così: l'osservazione riguarda il diverso ambito.
La risposta proposta è quella di mettere in pausa la modifica richiesta e verificarla con il fornitore attraverso un contatto precedentemente stabilito. Se il fornitore rifiuta la richiesta, l'organizzazione può inoltrare le prove attraverso il processo di incidente approvato senza aggiungere il dominio sconosciuto a una lista consentita. Se il fornitore conferma una modifica legittima del dominio, tale conferma dovrebbe entrare nel normale flusso di lavoro di manutenzione del fornitore anziché modificare silenziosamente la fiducia in base a un'e-mail. In questo esempio fittizio non è stato coinvolto alcun fornitore reale, registrazione di dominio, consegna di messaggi o chiamata di verifica.
Preservare controlli utili e richiedere prove originali
IL Avviso IC3 BEC, pubblicato nel 2020, supporta la verifica indipendente delle richieste commerciali insolite e delle protezioni degli account. Viene citato per questi principi difensivi, non per una statistica attuale sugli attacchi o per un reclamo su un'organizzazione nominata. L'autenticazione, la protezione dei destinatari e i controlli dei processi aziendali dovrebbero rafforzarsi a vicenda. Non rimuovere l'autenticazione perché non può determinare l'intento e non garantire la fiducia semplicemente perché passa.
Il catalogo richiede uno scenario di abuso redatto con prove di identità, limiti di controllo e verifica aziendale indipendente. Quella prova originale rimane aperta; lo scenario immaginario non è un sostituto. Non è stato visitato alcun endpoint sospetto, nessuna credenziale raccolta e nessuna terza parte contattata. Rimangono aperte anche la revisione specialistica umana, l'applicabilità della fonte attuale, i percorsi di produzione, l'accessibilità visiva e il rilascio del proprietario. Una versione pubblicabile necessita di prove autorizzate che dimostrino l'esatta distinzione tra l'autenticazione di un dominio e la fiducia nell'organizzazione o nell'azione che afferma di rappresentare.