Autentisering kan lyckas för fel organisation
En angripare behöver inte utge sig för att vara den exakta domänen för en betrodd organisation för att skicka ett vilseledande meddelande. De kan driva en annan domän, konfigurera dess e-post korrekt och använda den för att göra vilseledande påståenden. En mottagare kan se framgångsrik SPF, DKIM och DMARC för den domänen medan meddelandet fortfarande försöker bedrägeri. Autentiseringsresultatet beskriver domänanvändning; det fastställer inte att domänen tillhör den organisation som läsaren har i åtanke eller att den begärda åtgärden är legitim.
RFC 9989 begränsar uttryckligen DMARC :s mål. Innehållsanalys och autentisering av andra enheter än domäner ligger utanför dess räckvidd, liksom visningsnamnsattacker. Denna gräns förklarar autentiserade nätfiske utan att antyda att autentiseringen har misslyckats tekniskt. Det lämpliga svaret kombinerar domänidentitet, meddelandekontext och oberoende företagsverifiering. Den här artikeln är defensiv vägledning och innehåller ingen nätfiskemall, leveransinstruktioner eller live-domäntestning.
Skilj autentisering från anknytning
Skriv ner domänen i den faktiska Från-adressen och den domän som mottagaren förväntade sig. Om de skiljer sig åt, komprimera dem inte eftersom visningsnamnet, logotypen eller ämnet ser bekant ut. En domänägare kan i allmänhet ordna autentisering för sin egen post, men det säger ingenting om deras relation till ett annat företag. Inte ens en riktig webbplats och en fungerande svarsadress etablerar det förhållandet. Frågan är tillhörighet och auktoritet, inte bara teknisk konsekvens.
RFC 5322, avsnitt 3.4, skiljer visningsnamnet från adressen. En välbekant etikett kan sitta ovanför en orelaterade domän i en e-postklient. Etiketten kan vara godartad, tvetydig eller vilseledande beroende på sammanhang; deklarera inte avsikt från enbart etiketten. Jämför adressen med en pålitlig organisationshistorik och verifiera den specifika affärsåtgärden genom en etablerad kanal utanför det tvivelaktiga budskapet.
Inspektera innebörden av ett godkänt resultat
Ett fristående SPF -pass kan gälla kuvertsändare domän, medan DKIM identifierar en signeringsdomän. DMARC lägger till en inriktning förhållande till den synliga From-domänen. Identifiera vilken sökväg som stöder det rapporterade resultatet. Om alla dessa identiteter tillhör den obekanta domänen kan resultatet bli internt konsekvent utan att validera det välbekanta varumärket eller individen som nämns i meddelandet. Det är ett viktigt fynd, inte en motsägelse att bortförklara.
Använd betrodda mottagarbevis istället för att acceptera ett påstående från avsändaren. RFC 8601 beskriver varför Authentication-Results konsumenter behöver en förtroendegräns. En skärmdump som innehåller ordet pass kanske inte avslöjar vem som utvärderade meddelandet eller vilken domän som passerade. Anteckna källa, tid och relevanta identitetsfält. Om bevisen är otillräckliga, bevara osäkerheten istället för att hävda att meddelandet antingen gick igenom eller misslyckades definitivt.
Utvärdera den begärda åtgärden separat
Identifiera vad avsändaren vill att mottagaren ska göra. Risken kan vara en ändrad betalningsdestination, avslöjande av konfidentiell information, installation av programvara, en inloggning på en okänd plats eller en ändring av ett etablerat arbetsflöde. Domänautentisering godkänner inte någon av dessa åtgärder. Ett tekniskt giltigt meddelande kan fortfarande innehålla en falsk premiss, en obehörig begäran eller en destination som inte är relaterad till den påstådda verksamheten.
Inspektera inte en misstänkt länk genom att logga in eller ange information. Använd organisationens etablerade analys- och rapporteringsprocess, med kvalificerad personal och lämpliga verktyg när djupare inspektion är nödvändig. Detta utkast hävdar inte att visuell inspektion av en URL kan bevisa säkerhet, och inte heller att varje obekant domän är skadlig. En legitim ny leverantör och en angriparägd domän kan båda vara obekanta; affärsverifiering är det som löser förhållandet.
Använd mottagarens försvar utan att överdriva dem
Microsofts e-autentiseringsöversikt beskriver sammansatt autentisering som en del av en bredare bedömning, snarare än en enkel ersättning för SPF , DKIM och DMARC . Detta stöder ett skiktat tillvägagångssätt: mottagarsystem kan kombinera identitetssignaler med annan information när de bestämmer hur post ska hanteras. Det garanterar inte upptäckt av alla autentiserade nätfiskemeddelanden eller definierar en annan leverantörs aktuella filtreringsbeteende.
En mottagare kan acceptera, sätta i karantän, skräp eller avvisa meddelanden enligt sina egna kontroller och policy. Dra inte slutledning av säkerhet från placering i inkorgen eller illvilja från ett enda filtreringsresultat. Likaså en offentlighet blockeringslista Resultatet är inte en allmän anseende dom. Använd leverantörsdiagnostik som bevis med en känd omfattning och tid. Bevara skillnaden mellan en maskins klassificering och företagsägarens behörighet att godkänna den begärda åtgärden.
Ett arbetsblad för anknytning och åtgärd
Skapa ett kalkylblad med den anspråkade organisationen, förväntad betrodd domän, faktisk Från-domän, visningsnamn, autentiserad domän eller domäner, betrodd mottagarresultat och begärd åtgärd. Lägg till beviskällan för den förväntade domänen, inte bara den observerade domänen. Registrera om företaget har en etablerad relation med avsändaren och om den specifika åtgärden passar den relationen. Behåll ett olöst alternativ istället för att tvinga alla obekanta avsändare till en angriparkategori.
Den andra halvan av arbetsbladet registrerar den oberoende verifieraren, tidigare känd kontaktväg, ställd fråga, svar och beslutsägare. Undvik att använda ett telefonnummer eller en alternativ adress som endast introduceras av det misstänkta meddelandet. Redigera onödig personlig information i den delade kopian samtidigt som domänens likhet och skillnad bevaras. Ett kalkylblad som ersätter varje adress med samma platshållare kan inte visa varför autentiseringen inte kunde etablera anknytning.
Fiktiv diagnos: en korrekt autentiserad ny domän
Föreställ dig att ett fiktivt driftteam får en förfrågan som påstår sig komma från en bekant utrustningsleverantör. Avsändaren använder en annan domän som inte finns i teamets godkända leverantörspost. Betrodda mottagarbevis visar hypotetiskt anpassat DKIM och ett DMARC pass för den olika domänen. Mottagaren ser ett välbekant visningsnamn och antar att autentiseringsresultatet bekräftar leverantörens identitet. Det gör den inte: observationen gäller den olika domänen.
Det föreslagna svaret är att pausa den begärda ändringen och verifiera den med leverantören genom en tidigare etablerad kontakt. Om leverantören avslår begäran kan organisationen dirigera bevisen genom sin godkända incidentprocess utan att lägga till den okända domänen till en godkännandelista. Om leverantören bekräftar en legitim domänändring, bör den bekräftelsen gå in i det normala arbetsflödet för leverantörsunderhåll i stället för att tyst ändra förtroende baserat på ett e-postmeddelande. Ingen riktig leverantör, domänregistrering, meddelandeleverans eller verifieringssamtal var inblandad i detta fiktiva exempel.
Bevara användbara kontroller och kräva originalbevis
De IC3 BEC rådgivande, publicerad 2020, stöder oberoende verifiering av ovanliga affärsförfrågningar och kontoskydd. Det citeras för dessa defensiva principer, inte för en aktuell attackstatistik eller ett påstående om en namngiven organisation. Autentisering, mottagarskydd och affärsprocesskontroller bör förstärka varandra. Ta inte bort autentisering eftersom den inte kan fastställa avsikt, och ge inte förtroende bara för att den godkänns.
Katalogen kräver ett redigerat missbruksscenario med identitetsbevis, kontrollgräns och oberoende affärsverifiering. Det ursprungliga beviset förblir öppet; det fiktiva scenariot är inte en ersättning. Ingen misstänkt slutpunkt besöktes, inga inloggningsuppgifter samlades in och ingen tredje part kontaktades. Granskning av mänsklig specialist, aktuell källans tillämplighet, produktionsvägar, visuell tillgänglighet och ägarfrigivning förblir också öppna. En publicerbar version behöver auktoriserade bevis som visar den exakta skillnaden mellan autentisering av en domän och att lita på organisationen eller åtgärden den påstår sig representera.