Phishing en mail headers

[Flamesz]

tl;dr: hoe bevestig je dat je gephished word met behulp van email headers?

Ik heb vandaag een test phishing mail ontvangen, toen ik de mail kreeg vond ik 'm direct onbetrouwbaar en checkte ik de mailheaders.
Toen ik deze checkte merkte ik eigenlijk geen idee heb wat ik in de headers moet checken om zeker te zijn dat deze legitiem is.
Het eerste wat ik wel herkende is dat het return-path email adres wel een legitiem adres binnen de organisatie is, wat googlen vertelde mij dat return email adressen niet gespoofed kunnen worden naar een ander domein dan van waaruit de email verzonden is, al weet ik niet of deze informatie up-to-date is, of dat hier al een weg omheen is gevonden.

Verder zag ik in de header dat er geen SPF is meegezonden, met in de analyse door mxtoolbox.com daarbij de melding "[e-mail] does not designate permitted sender hosts". Googlen op deze melding geeft geen nuttige resultaten voor het detecteren van phishing.
Als ik een legitieme mail vanuit de organisatie check, heeft deze echter ook geen SPF, dit doet mij denken dat de organisatie geen SPF gebruikt.

Als laatste nuttige informatie in de header zag ik dat "X-MS-Exchange-Organization-AuthSource" ook een legitiem domein binnen de organisatie gebruikt.

Deze drie elementen in de header deden mij dus geloven dat de mail echt van binnen de organisatie kwam, en dus waarschijnlijk geen phishing mail is.
Nu blijkt dus dat het dus ook geen echte phishing mail is, maar een test phishing mail vanuit de organisatie.

Mijn vraag is nu dus, had ik aan iets in de headers moeten zien dat dit geen legitieme mail was, of was deze door de headers te herkennen als legitiem?

Zou ik bij een echte echte phishing mail door op de zelfde manier de headers te checken deze wel als phishing wel herkennen, of zou ik dan ongeveer hetzelfde kunnen zien?

Reden dat ik dit vraag is dat het mij een slechte opzet lijkt voor een phishing test om dan de mails vanaf een legitiem emailadres te sturen, of dat het toch echt gewoon aan mij ligt dat ik er in getrapt ben.

[mcDavid]

SPF is niet iets wat je terugvindt in de mailheaders, maar een DNS record. Wat je kunt doen is een dig op de TXT records van de domeinnaam waarvanuit de mail verstuurd is.

bijv:

code:

dig example.com TXT

Dit geeft een lijstje aan headers terug waaronder ééntje begint met "v=spf...". Dat is het SPF record. Hierin staan een aantal IP-adressen. Eén daarvan zou overeen moeten komen met het IP-adres waar de email vandaan komt. Is dat niet het geval, dan is het vrijwel zeker phishing. Maar als het goed is heeft je mailclient dat al voor je gechecked en zou de mail dus als spam aangemerkt zijn.

Als iemand buiten je organisatie een succesvolle phishing poging wilt doen zijn er dus 2 mogelijkheden:

1) Hij moet eerst (onrechtmatig?) toegang krijgen tot de mailservers van jouw organisatie, om vanaf daar de phishingmail te versturen. Als dit lukt is het praktisch niet te detecteren (iig niet mbv uitsluitend SPF), maar gezien je eerst een server moet hacken is het normaliter praktisch onuitvoerbaar. In jouw geval is deze methode gebruikt, gezien de verzender die toegang al op een legitieme manier had.
2) hij moet de mail vanaf een ander domein sturen. Dit gebeurt het vaakst. Er wordt dan een domeinnaam geregistreerd die lijkt op die van jouw organisatie en van daaruit wordt de mail verstuurd, in de hoop dat dit je niet opvalt. Of er wordt bijv. vanuit een gmail of hotmail adres gemaild in de hoop dat je dit aanziet voor iemands persoonlijke e-mail adres.

Daadwerkelijk een mailadres spoofen is praktisch zinloos als er een SPF-record is ingesteld, want dan komt het gegarandeerd in je spamfolder terecht.

[Flamesz]

mcDavid schreef op dinsdag 20 november 2018 @ 17:12:
SPF is niet iets wat je terugvindt in de mailheaders, maar een DNS record. Wat je kunt doen is een dig op de TXT records van de domeinnaam waarvanuit de mail verstuurd is.

bijv:

code:

dig example.com TXT

Dit geeft een lijstje aan headers terug waaronder ééntje begint met "v=spf...". Dat is het SPF record. Hierin staan een aantal IP-adressen. Eén daarvan zou overeen moeten komen met het IP-adres waar de email vandaan komt. Is dat niet het geval, dan is het vrijwel zeker phishing. Maar als het goed is heeft je mailclient dat al voor je gechecked en zou de mail dus als spam aangemerkt zijn.

Als iemand buiten je organisatie een succesvolle phishing poging wilt doen zijn er dus 2 mogelijkheden:

1) Hij moet eerst (onrechtmatig?) toegang krijgen tot de mailservers van jouw organisatie, om vanaf daar de phishingmail te versturen. Als dit lukt is het praktisch niet te detecteren (iig niet mbv uitsluitend SPF), maar gezien je eerst een server moet hacken is het normaliter praktisch onuitvoerbaar. In jouw geval is deze methode gebruikt, gezien de verzender die toegang al op een legitieme manier had.
2) hij moet de mail vanaf een ander domein sturen. Dit gebeurt het vaakst. Er wordt dan een domeinnaam geregistreerd die lijkt op die van jouw organisatie en van daaruit wordt de mail verstuurd, in de hoop dat dit je niet opvalt. Of er wordt bijv. vanuit een gmail of hotmail adres gemaild in de hoop dat je dit aanziet voor iemands persoonlijke e-mail adres.

Daadwerkelijk een mailadres spoofen is praktisch zinloos als er een SPF-record is ingesteld, want dan komt het gegarandeerd in je spamfolder terecht.

Dus als er spf is en het domein word gespoofed zou de mail direct in de spambox moeten gaan.
Een TXT lookup van ru.nl levert echter geen SPF op, dus het lijkt dat SPF hier niet van toepassing is.
Het zou wellicht ook een wat minder nuttige test zijn als alle mails in een dergelijke test ook direct in de spam verdwijnen.

Maar een gebrek aan SPF betekent dus dat het domein dat in de test is gebruikt dus ook gespoofed kan worden, toch?
Als dat gebeurt, heb ik dan nog verder een handgreep om een gespoofde mail te herkennen?

[mcDavid]

Die zijn er legio. Je kunt bijv. een reverse-dns lookup doen op het IP-adres waar de mail vandaan komt, en kijken of die van de organisatie is. Maar daarvoor moeten wel de juiste RDNS records ingesteld staan.
Je kunt ook kijken of er een DKIM header in de mail staat en dit proberen te verifiëren, maar daar is ook de nodige configuratie van DNS-records en de mailserver voor nodig. Daarnaast bestaat er nog DMARC, maar daarvoor moet je eerst een SPF record hebben...

Maar zo te lezen heeft jouw organisatie dat allemaal niet erg goed op orde (lijkt me dat ze dat beter éérst aan kunnen pakken voordat ze testmailtjes gaan sturen, maargoed), dus dan wordt het al snel een lastig verhaal.

Daarnaast, als de afzender uit de organisatie zelf komt, en jullie eigen mailserver gebruikt, gaat dat natuurlijk allemaal niets helpen. Dan lijkt zijn mail (wat headers of ip-adressen betreft) net zo vertrouwd als iedere andere mail van die server. Dat is eigenlijk een beetje vals spelen als je het mij vraagt. Al bestaat natuurlijk, zeker in een grote organisatie, ook de kans dat iemand van binnenuit rottigheid probeert uit te halen.

[Voor 13% gewijzigd door mcDavid op 20-11-2018 17:43]