Godkendelse kan lykkes for den forkerte organisation
En angriber behøver ikke at efterligne det nøjagtige domæne for en betroet organisation for at sende en vildledende besked. De kan betjene et andet domæne, konfigurere dets e-mail korrekt og bruge det til at fremsætte vildledende påstande. En modtager kan observere vellykket SPF, DKIM og DMARC for det pågældende domæne, mens meddelelsen stadig forsøger at svindle. Godkendelsesresultatet beskriver domænebrug; det fastslår ikke, at domænet tilhører den organisation, læseren har i tankerne, eller at den anmodede handling er legitim.
RFC 9989 begrænser eksplicit DMARC mål. Indholdsanalyse og autentificering af andre enheder end domæner er uden for dets omfang, ligesom angreb med visningsnavne. Denne grænse forklarer autentificeret phishing uden at antyde, at godkendelse har fejlet teknisk. Det passende svar kombinerer domæneidentitet, beskedkontekst og uafhængig virksomhedsbekræftelse. Denne artikel er defensiv vejledning og indeholder ingen phishing-skabelon, leveringsinstruktioner eller live-domænetest.
Skelne autentificering fra tilknytning
Skriv domænet ned i den faktiske Fra-adresse og det domæne, som modtageren forventede. Hvis de adskiller sig, må du ikke skjule dem, fordi det viste navn, logo eller emne ser bekendt ud. En domæneejer kan generelt arrangere autentificering af deres egen post, men det siger intet om deres forhold til en anden virksomhed. Selv en rigtig hjemmeside og en fungerende svaradresse etablerer ikke dette forhold. Spørgsmålet er tilknytning og autoritet, ikke blot teknisk sammenhæng.
RFC 5322, afsnit 3.4, adskiller visningsnavnet fra adressen. En velkendt etiket kan sidde over et ikke-relateret domæne i en mail-klient. Etiketten kan være godartet, tvetydig eller vildledende afhængigt af konteksten; erklær ikke hensigt fra etiketten alene. Sammenlign adressen med en pålidelig organisationsoptegnelse og bekræft den specifikke forretningshandling gennem en etableret kanal uden for det tvivlsomme budskab.
Undersøg betydningen af et bestået resultat
Et selvstændigt SPF -pas kan vedrøre konvolutafsender domæne, mens DKIM identificerer et signeringsdomæne. DMARC tilføjer en justering forhold til det synlige Fra-domæne. Identificer, hvilken sti der understøtter det rapporterede resultat. Hvis alle disse identiteter tilhører det ukendte domæne, kan resultatet være internt konsistent uden at validere det velkendte brand eller den kendte person i meddelelsen. Det er et vigtigt fund, ikke en selvmodsigelse at bortforklare.
Brug pålidelige modtagerbeviser i stedet for at acceptere en afsender-leveret påstand. RFC 8601 beskriver hvorfor Authentication-Results forbrugere har brug for en tillidsgrænse. Et skærmbillede, der indeholder ordet pass, afslører muligvis ikke, hvem der har evalueret beskeden, eller hvilket domæne der har bestået. Registrer kilde, tidspunkt og relevante identitetsfelter. Hvor beviserne er utilstrækkelige, bevar usikkerheden i stedet for at hævde, at beskeden enten bestod eller fejlede definitivt.
Evaluer den anmodede handling separat
Identificer, hvad afsenderen ønsker, at modtageren skal gøre. Risikoen kan være en ændret betalingsdestination, videregivelse af fortrolige oplysninger, installation af software, et login på et ukendt sted eller en ændring af en etableret arbejdsgang. Domænegodkendelse godkender ikke nogen af disse handlinger. En teknisk gyldig meddelelse kan stadig indeholde en falsk forudsætning, en uautoriseret anmodning eller en destination, der ikke er relateret til den påståede virksomhed.
Undersøg ikke et mistænkeligt link ved at logge på eller indtaste oplysninger. Brug organisationens etablerede analyse- og rapporteringsproces med kvalificeret personale og passende værktøj, når dybere inspektion er nødvendig. Dette udkast hævder ikke, at visuel inspektion af en URL kan bevise sikkerhed, eller at ethvert ukendt domæne er ondsindet. En lovlig ny leverandør og et domæneejet angriber kan begge være ukendte; forretningsverifikation er det, der løser forholdet.
Brug modtagerforsvar uden at overdrive dem
Microsofts e-mail-godkendelsesoversigt beskriver sammensat godkendelse som en del af en bredere vurdering snarere end en simpel erstatning for SPF , DKIM og DMARC . Dette understøtter en lagdelt tilgang: modtagersystemer kan kombinere identitetssignaler med anden information, når de beslutter sig for, hvordan post skal håndteres. Det garanterer ikke detektering af enhver godkendt phishing-meddelelse eller definerer en anden udbyders aktuelle filtreringsadfærd.
En modtager kan acceptere, sætte i karantæne, skrammel eller afvise beskeder i henhold til sin egen kontrol og politik. Udled ikke sikkerhed fra indbakkeplacering eller ondsindethed fra et enkelt filtreringsresultat. Tilsvarende en offentlighed blokeringsliste Resultatet er ikke en universel dom om omdømme. Brug udbyderdiagnostik som bevis med et kendt omfang og tid. Bevar sondringen mellem en maskines klassificering og virksomhedsejerens bemyndigelse til at godkende den anmodede handling.
Et arbejdsark til tilknytning og handling
Opret et regneark med den påståede organisation, forventet betroet domæne, faktisk Fra domæne, vist navn, godkendt domæne eller domæner, betroet modtagerresultat og anmodet handling. Tilføj beviskilden for det forventede domæne, ikke kun det observerede domæne. Registrer, om virksomheden har et etableret forhold til afsenderen, og om den særlige handling passer til dette forhold. Behold en uafklaret mulighed i stedet for at tvinge enhver ukendt afsender ind i en angriberkategori.
Den anden halvdel af arbejdsarket registrerer den uafhængige verifikator, tidligere kendte kontaktrute, stillede spørgsmål, svar og beslutningsejer. Undgå at bruge et telefonnummer eller en alternativ adresse, der kun introduceres af den mistænkelige besked. Rediger unødvendige personlige oplysninger i den delte kopi, mens du bevarer domænelighed og forskel. Et regneark, der erstatter hver adresse med den samme pladsholder, kan ikke demonstrere, hvorfor godkendelse ikke kunne etablere tilknytning.
Fiktiv diagnose: et korrekt autentificeret nyt domæne
Forestil dig, at et fiktivt driftshold modtager en anmodning, der hævder at komme fra en velkendt udstyrsleverandør. Afsenderen bruger et andet domæne, der ikke er i teamets godkendte leverandørregistrering. Betroet modtagerbevis viser hypotetisk tilpasset DKIM og et DMARC -pas for det forskellige domæne. Modtageren ser et velkendt visningsnavn og antager, at godkendelsesresultatet bekræfter leverandørens identitet. Det gør den ikke: observationen vedrører det forskellige domæne.
Det foreslåede svar er at sætte den ønskede ændring på pause og bekræfte den med leverandøren gennem en tidligere etableret kontakt. Hvis leverandøren afslår anmodningen, kan organisationen dirigere beviserne gennem sin godkendte hændelsesproces uden at føje det ukendte domæne til en tilladelsesliste. Hvis leverandøren bekræfter en legitim domæneændring, bør denne bekræftelse indgå i den normale leverandør-vedligeholdelsesworkflow i stedet for lydløst at ændre tillid baseret på én e-mail. Ingen reel leverandør, domæneregistrering, meddelelseslevering eller verifikationsopkald var involveret i dette fiktive eksempel.
Bevar nyttige kontroller og kræve originale beviser
De IC3 BEC rådgivende, udgivet i 2020, understøtter uafhængig verifikation af usædvanlige forretningsanmodninger og kontobeskyttelse. Det er citeret for disse defensive principper, ikke for en aktuel angrebsstatistik eller en påstand om en navngiven organisation. Autentificering, modtagerbeskyttelse og kontrol af forretningsprocesser bør forstærke hinanden. Fjern ikke godkendelse, fordi den ikke kan bestemme hensigten, og giv ikke tillid, blot fordi den bestået.
Kataloget kræver et redigeret misbrugsscenarie med identitetsbevis, kontrolgrænse og uafhængig virksomhedsverifikation. Det originale bevis forbliver åbent; det fiktive scenarie er ikke en erstatning. Intet mistænkeligt slutpunkt blev besøgt, ingen legitimationsoplysninger blev indsamlet, og ingen tredjepart blev kontaktet. Gennemgang af menneskelig specialist, aktuel kildeanvendelse, produktionsruter, visuel tilgængelighed og ejerudgivelse forbliver også åbne. En publicerbar version kræver autoriseret bevis, der viser den nøjagtige sondring mellem autentificering af et domæne og tillid til den organisation eller handling, den hævder at repræsentere.