Disse 3 e-postoverskriftene beviser at en melding er falsk — slik sjekker du

Svindel er utbredt i samfunnet vårt, og hvis du ikke er forsiktig, kan du godkjenne en overføring bare fordi e-posten ser legitim ut. Dårlige aktører har perfeksjonert kunsten å gjøre logoene skarpe, matche avsenderens navn med dine leverandørers, og gi akkurat passe mengde hastverk til emnefeltet. Til slutt kan de lure selv de smarteste blant oss.

Men det egentlige problemet er at når du mottar en e-post, vurderer du vanligvis ektheten ved å bedømme det som er synlig. Jeg har en gang snakket om en sjekkliste å bruke før man åpner PDF-er, men det finnes også et sett med parametere å sjekke før man antar at en e-post er ekte. Den virkelige informasjonen å være oppmerksom på ligger ofte i metadataene.

Feltet «Fra» beviser ikke hvem som sendte e-posten

Autentisering bekrefter et domene, ikke et merke

Lær å mistenke visningsnavnet fordi det, i det store og hele, egentlig ikke beviser noe som helst. Selvfølgelig er det generelt iøynefallende, spesielt hvis du bruker Gmail eller Outlook, men dette er bare på grunn av måten de fleste av disse e-postklientene er bygget på; de prioriterer bekvemmelighet fremfor verifisering.

Å motta en e-post som tydelig sier "PayPal Security" betyr ikke at PayPal har sendt den. Den faktiske avsenderen kan være noreply@paypa1-secure.ru, med liten "l" i PayPal erstattet med "1." Dette kan lure deg hvis du har det travelt. For å se den ekte avsenderen, sjekk Fra-overskriften for avsenderens e-post i vinkelparenteser. Dette alene kan imidlertid ikke gi en endelig bekreftelse på ekthet. Du må inspisere e-postkilden. I Gmail, åpne e-posten, klikk på de tre prikkene ved siden av svar-ikonet, og klikk Vis original; i Outlook på skrivebordet, gå til Fil -> Egenskaper -> Internett-overskrifter; i Apple Mail, gå til Vis -> Melding -> Alle overskrifter. På siden for den opprinnelige meldingen er de tre datadelene som betyr noe Fra, Returvei og Autentiseringsresultater (SPF, DKIM og DMARC-resultater).

Verdiene for SPF, DKIM og DMARC må være PASS. Dette alene beviser imidlertid fortsatt ikke ektheten. Men det forteller deg i det minste at avsenderens e-post ble autentisert korrekt, noe som betyr at den som sendte e-posten har teknisk kontroll over domenet. Husk, en kriminell kan registrere paypa1-secure.com, og hvis de konfigurerer SPF, signerer meldinger med DKIM, og publiserer en DMARC-policy, vil de lykkes med å bevise teknisk kontroll.

På dette laget er det primære tegnet på en falsk e-post feiljustering mellom overskrifter (Fra, Return-Path, SPF/DKIM-resultater). Bekreft at den synlige Fra-adressen samsvarer med domenet i Return-Path, og bekreft at SPF-IP-en godkjennes for det faktiske merkevarens domene. Hvis alt dette stemmer, er det stor sjanse for at e-posten ikke er falsk.

E-postklienten din jobber hardt for å fange phishing, men ingen filter er perfekte. Sofistikerte angrep, nylig registrerte domener og e-poster som rutes gjennom kompromitterte kontoer, slipper jevnlig forbi automatiserte forsvar.

«Mottatt»-kjeden viser hvor e-posten faktisk kom fra

Hver mailserver etterlater et fingeravtrykk som angripere sliter med å kontrollere

Når en e-postserver håndterer en melding, legger den til en Mottatt-linje øverst i headeren. En angriper kan forfalske Mottatt-linjer før e-posten forlater angriperens system. Imidlertid inkluderer også den innkommende e-postserveren en linje som en del av Mottatt-kjeden. Denne tilleggslinjen er det en angriper ikke vil kunne forfalske. Hvis det er en uoverensstemmelse, bør du mistenke e-posten.

Du ser fortsatt denne informasjonen på Kildevisning-siden for e-posten. Nedenfor er et eksempel på den første Mottatt-linjen der leverandøren min godtar e-posten:

Received: from a74-66.smtp-out.amazonses.com (a74-66.smtp-out.amazonses.com. [54.240.74.66]) 
by mx.google.com

Dette eksemplet er linjen som Google skriver, ikke den som avsenderen la til. Den forteller meg ganske enkelt at Google mottok e-posten fra IP 54.240.74.66 på smtp-out.amazonses.com. Nå, for at jeg skal se om dette gir mening, må jeg sjekke det mot andre synlige overskrifter i meldingen.

For denne spesifikke meldingen er den synlige avsenderen i overskriften noreply@windows.day. Return-Path er et Amazon-domene: amazonses.com. Fra den andre informasjonen jeg sjekket tidligere, kan jeg se at SPF bestod for den Amazon SES IP-en, 54.240.74.66, og DKIM bestod for windows.day. Alt er konsistent. Det er ganske vanlig at selskaper sender varsler ved bruk av Amazon SES-infrastruktur, så hele bildet stemmer.

Når en e-post er legitim, følger den et ruteveiledningsspor som inkluderer:

  1. Gjenkjennelig posttjeneste
  2. Autentisering som samsvarer med avsenderserveren
  3. Ingen tilfeldig hosting-leverandør i kjeden (bør være en gjenkjennelig e-posttjenesteplattform)

Falske e-poster vil vanligvis etterlate et spor der leverandøren din mottar meldingen fra en urelatert VPS, et merkelig domene eller en IP som ikke er knyttet til den påståtte avsenderen.

Mens alt dette generelt gjelder, merk at mer sofistikerte angrep også kan rutes gjennom kompromitterte legitime kontoer eller godt kjente skytjenester, så fraværet av disse advarselstegnene garanterer ikke 100 % legitimitet.

Message-ID og konvoluttavvik avslører lat eller massephishing

Infrastrukturdetaljer samsvarer sjelden med merket som blir etterlignet

Feltet Message-ID er en annen viktig overskrift som ikke bør ignoreres. Det er det første elementet du ser på Selskapsvisningssiden. Dette er en globalt unik ID som meldingssenderens server genererer. Vanligvis kommer den i form av en lang streng som avsluttes med @domene-komponenten. Du må være oppmerksom på dette domenet.

Du bør forvente at en melding som kommer fra amazon.com, skal ha en Message-ID som slutter med Amazons domene. I stedet for Amazon er det et faresignal hvis du får noe som @cheapmailer.hosting123.net; ikke overse det.

Det finnes imidlertid noen andre ledetråder i meldingens ID som viser at en melding ikke er autentisk:

  1. Mangler helt Message-ID.
  2. Identiske Message-ID-formater på tvers av ikke-relaterte phishing-e-poster.
  3. Utdaterte eller merkelige X-Mailer-overskrifter.
  4. En eksponert X-Originating-IP som peker til et bolig- eller lavkostnads hostingområde.

Grunnen til at Message-ID er et kraftig verktøy for å oppdage svindel-e-post, er at selv om sofistikerte angripere kan rydde det opp, prioriterer massephishingoperasjoner ofte volum fremfor finesse.

Message-ID er en av de enkleste headerne for en angriper å forfalske, så en overbevisende Message-ID bør aldri tas som bevis på ekthet; dens verdi ligger nesten utelukkende i å fange late eller automatiserte phishing-kampanjer som ikke gidder å sette den riktig.

Samle de tre overskriftene

Den fellesnevneren for de tre overskriftene jeg har beskrevet er at de alle er knyttet til hvordan en melding blir transportert. De tar ikke hensyn til hvordan meldingen blir presentert. Transportelementet er imidlertid avgjørende fordi presentasjon kan kopieres mye lettere. I tillegg etterlater transportelementer rester som fungerer som markører for å finne ut om noe er legitimt.

Selvfølgelig, hvis du får for mye spam, er det lurt å ta praktiske skritt for å redusere mengden, fordi jo mer det er, desto mer sannsynlig er det at noe kan falle igjennom sprekkene.

Relaterte artikler