Vad är domänförfalskning?
Domänförfalskning innebär att en angripare utger sig för att vara en legitim domän, organisation eller avsändare för att lura användare eller system. Angriparen kan förfalska e-postens avsändaradress, skapa en visuellt likadan domän eller manipulera DNS-svar. Målet är ofta att stjäla inloggningsuppgifter, pengar eller annan känslig information.
Typer av domänförfalskning
E-postförfalskning
Avsändaren i ett e-postmeddelande manipuleras så att meddelandet ser ut att komma från en betrodd domän. Utan SPF, DKIM och DMARC kan den mottagande servern ha svårt att skilja ett äkta meddelande från ett förfalskat.
Legitimate:
From: [email protected]
Actual sender: PayPal's mail servers
Spoofed:
From: [email protected]
Actual sender: attacker's server
Without SPF/DKIM/DMARC, appears legitimate
Förfalskat visningsnamn
Angriparen använder ett betrott namn, till exempel en chef eller supportavdelning, men skickar meddelandet från en annan adress. Många e-postklienter visar visningsnamnet tydligare än den faktiska adressen.
Display: CEO John Smith <[email protected]>
Actual email: [email protected]
Many email clients show only display name prominently
Förväxlingsbar domänförfalskning
En domän registreras med en stavning eller teckenuppsättning som liknar den legitima domänen. Skillnaden kan vara ett extra ord, ett utbytt tecken eller en internationell bokstav som ser likadan ut.
Legitimate: paypal.com
Lookalikes:
paypa1.com (1 instead of l)
paypal-secure.com (added word)
paypai.com (typo)
paypаl.com (Cyrillic 'а' instead of Latin 'a')
DNS-förfalskning (cacheförgiftning)
DNS-cacheförgiftning innebär att falska DNS-svar lagras hos en resolver. En användare kan då skickas till en angripares IP-adress trots att webbläsaren visar den förväntade domänen.
User types: bank.com
DNS poisoned: Returns attacker's IP instead of real bank
User arrives at: Fake bank.com (phishing site)
User thinks: They're on real site (URL shows bank.com)
Förfalskning av nummerpresentation (VoIP)
Vid VoIP kan angriparen förfalska det telefonnummer som visas för mottagaren. Det används ofta tillsammans med förfalskad e-post för att skapa ett mer trovärdigt bedrägeri.
Så fungerar e-postförfalskning
Bristen i SMTP-protokollet
SMTP skapades när internet var mer slutet och kräver inte alltid att avsändaren bevisar rätten att använda en domän. En server kan därför acceptera ett godtyckligt MAIL FROM-värde om ytterligare autentisering saknas.
SMTP Conversation:
Client: HELO attacker.com
Server: 250 Hello
Client: MAIL FROM: <[email protected]>
Server: 250 OK (accepts without verification)
Client: RCPT TO: <[email protected]>
Server: 250 OK
Client: DATA
From: [email protected]
Subject: Urgent wire transfer needed
→ Server delivers it
Manipulering av rubriker
Angriparen ändrar From- eller Reply-To-rubriken så att meddelandet ser legitimt ut. Reply-To kan leda svar till angriparen även när den synliga avsändaren verkar betrodd.
From: "CEO John Smith" <[email protected]>
Reply-To: [email protected]
User sees trusted sender
Replies go to attacker
Verkliga scenarier
Företagskapning (BEC)
Angriparen studerar företagets organisation och skickar sedan ett brådskande betalnings- eller överföringskrav från en förfalskad chefsadress. Mottagaren kan hinna genomföra betalningen innan bedrägeriet upptäcks.
1. Attacker researches company structure
2. Spoofs CEO's email to CFO
3. "Urgent wire transfer needed for acquisition"
4. CFO transfers funds thinking it's legitimate
5. Company loses millions
Nätfiskekampanjer
Ett meddelande ser ut att komma från en bank eller teknikleverantör och varnar för misstänkt aktivitet. Länken leder till en förväxlingsbar webbplats där användaren uppmanas att ange inloggningsuppgifter.
1. Spoof bank or tech company domain
2. Send emails about "suspicious activity"
3. Link goes to lookalike domain
4. User enters credentials on fake site
5. Attacker steals credentials
Fakturabedrägeri
En angripare förfalskar en leverantörs domän och skickar en uppdaterad faktura med angriparens bankuppgifter. Betalningen går då till fel mottagare medan den riktiga leverantören förblir ovetande.
1. Attacker spoofs supplier's domain
2. Sends updated invoice with attacker's bank details
3. Victim pays attacker instead of real supplier
4. Legitimate supplier never receives payment
Spridning av skadlig kod
Ett meddelande som utger sig för att komma från en betrodd programvaruleverantör innehåller en påstådd säkerhetsuppdatering. Bilagan eller länken kan i stället installera skadlig kod.
1. Spoof trusted software company
2. Email with "critical security update"
3. Attachment contains malware
4. User trusts "legitimate" sender and opens it
Upptäcka domänförfalskning
Analys av e-postrubriker
Granska Return-Path, Received och Authentication-Results. Jämför den faktiska sändande servern med domänens godkända servrar och leta efter oväntade hopp eller avvikande IP-adresser.
From: [email protected]
Return-Path: <[email protected]> ← Red flag
Received: from unknown.net [1.2.3.4] ← Not PayPal's servers
Real email would have:
Received: from mx.paypal.com [verified PayPal IP]
Return-Path: <[email protected]>
Kontroll av SPF/DKIM/DMARC
Kontrollera om SPF godkänner den sändande IP-adressen, om DKIM-signaturen är giltig och om DMARC-policyn godkänner domänens anpassning. Ett fail- eller none-resultat är en viktig varningssignal.
Authentication-Results: recipient.com;
spf=fail smtp.mailfrom=paypal.com ← Spoofed
dkim=none ← Not signed
dmarc=fail ← Failed policy
Visuell granskning
Kontrollera varje tecken i domännamnet, toppdomänen och länken bakom en knapp. Var särskilt uppmärksam på bindestreck, siffror, homoglyfer och IDN-tecken som liknar latinska bokstäver.
Real: paypal.com
Fake: paypal-secure.com (extra word)
Fake: paypαl.com (Cyrillic character)
Fake: paypal.co (missing 'm')
Avvikande beteenden
Oväntade brådskande krav, ändrade betalningsuppgifter, ovanliga språkfel och begäran om att kringgå ordinarie rutiner bör behandlas som varningssignaler även när avsändarnamnet ser korrekt ut.
Förebygga domänförfalskning
Implementera e-postautentisering (kritiskt)
Publicera en korrekt SPF-post, signera utgående e-post med DKIM och införa DMARC med rapportering. Börja med p=none för övervakning och gå sedan mot p=quarantine eller p=reject när legitima sändare är verifierade.
example.com. IN TXT "v=spf1 include:_spf.google.com -all"
Authorizes which servers can send for your domain
Cryptographically signs outgoing emails
Receivers verify signature using DNS public key
Tampered emails fail verification
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
Tells receivers to reject emails that fail SPF/DKIM
Provides reports on spoofing attempts
p=none Monitor only (start here)
p=quarantine Send failures to spam
p=reject Block failures completely (goal)
Registrera defensiva domäner
Registrera vanliga stavfel, relevanta toppdomäner, bindestrecksvarianter och pluralformer när de är viktiga för varumärket. Detta minskar utrymmet för angripare att skapa trovärdiga lookalikes.
Primary: company.com
Register:
- Common typos: conpany.com, compamy.com
- Different TLDs: company.net, company.org, company.co
- Hyphenated: com-pany.com, company-inc.com
- Plurals: companies.com
Övervaka varumärkesomnämnanden
Övervaka nya registreringar, certifikat, DNS-förändringar och webbplatser som använder företagets namn. Snabba varningar gör att en förväxlingsbar domän kan hanteras innan den hinner användas i en kampanj.
Utbilda medarbetare
Lär personalen att kontrollera hela adressen, bekräfta ovanliga betalningskrav via en separat kanal och rapportera misstänkta meddelanden. Övningar bör omfatta både e-post och telefonbedrägerier.
Tekniska kontroller
Använd säkra DNS-tjänster, DNSSEC där det är lämpligt, stark multifaktorautentisering och begränsade administrativa behörigheter. Filtrering, säkra e-postklienter och tydliga betalningsrutiner ger ytterligare skydd.
p=reject (block spoofed email entirely)[EXTERNAL EMAIL] This email originated outside the organizationAvancerade förfalskningstekniker
Homoglyfattacker
En homoglyfattack använder tecken från olika alfabet som ser lika ut, exempelvis kyrilliskt a i stället för latinskt a. Punycode och webbläsarens säkerhetsvarningar kan hjälpa till att upptäcka sådana namn.
Latin 'a' vs Cyrillic 'а' (U+0430)
Latin 'o' vs Cyrillic 'о' (U+043E)
googlе.com (Latin 'e' replaced with Cyrillic 'е')
Looks identical to: google.com
googlе.com → xn--googl-6nd.com (encoded)
Browsers show: ⚠️ xn--googl-6nd.com
Förfalskning av underdomäner
En angripare kan lägga ett legitimt varumärke längst till vänster i en domän som egentligen kontrolleras av angriparen, till exempel legitimate-bank.attacker.com. Läs alltid domänen från höger till vänster för att hitta den registrerade huvuddomänen.
legitimate-bank.attacker.com
Appears as: legitimate-bank (subdomain of attacker.com)
Users see: "legitimate-bank" and assume it's safe
Man-in-the-middle med DNS-kapning
Om en DNS-server, router eller registrar komprometteras kan angriparen ändra upplösningen till en falsk webbplats. Ett giltigt TLS-certifikat kan fortfarande förekomma, så ett hänglås ensamt bevisar inte att webbplatsen är legitim.
1. Attacker compromises DNS server or router
2. Changes bank.com resolution to attacker's IP
3. Serves fake bank site
4. Uses valid SSL cert (from Let's Encrypt, free)
5. User sees https://bank.com with padlock
6. User thinks it's safe, enters credentials
Juridiska och regulatoriska aspekter
Amerikanska lagen mot cybersquatting (ACPA)
ACPA är en amerikansk lag som kan ge varumärkesinnehavare civilrättsliga åtgärder och skadestånd när domäner registreras eller används i ond tro. Juridisk bedömning bör göras av kvalificerad rådgivare.
UDRP (policy för tvistlösning om domännamn)
UDRP är ICANN:s policy för tvistlösning om domännamn. En varumärkesinnehavare kan lämna in ett ärende till en godkänd tvistlösningsleverantör och i vissa fall få domänen överförd eller raderad.
Straffrättsliga påföljder
Förfalskning kan ingå i bedrägeri, identitetsbrott eller dataintrång. Påföljderna beror på jurisdiktion, skadans omfattning och vilka andra lagar som har överträtts.
Hantera domänförfalskning
Om din domän förfalskas
Samla e-postrubriker, DNS-data, kopior av webbplatsen och tidsstämplar. Kontakta registrar, värdtjänst och berörda e-postleverantörer, publicera en tydlig varning och överväg juridiska åtgärder.
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Om du upptäcker en förväxlingsbar domän
Dokumentera bevisen, kontrollera om domänen används aktivt och rapportera den till registrarens abuse-adress. Vid varumärkesintrång kan en UDRP-process eller annan rättslig åtgärd vara relevant.
Testa ditt skydd
Testa skyddet mot e-postförfalskning
Skicka kontrollerade testmeddelanden till egna adresser och kontrollera om de blockeras eller märks. Använd aldrig externa mottagare utan uttryckligt tillstånd.
# Send test spoofed email to yourself
swaks --to [email protected] \
--from [email protected] \
--server test-smtp-server.com \
--header "Subject: Test Spoofed Email"
# Check if it's delivered or blocked
# Check authentication results in headers
Kontrollera DMARC-konfigurationen
Verifiera att DMARC-posten finns på rätt namn, att rapportadressen fungerar och att policyn motsvarar organisationens beredskap. Granska rapporterna för okända sändare och återkommande fel.
dig _dmarc.example.com TXT
# Should return policy (p=reject ideally)
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"
Verifiera SPF och DKIM
Kontrollera att SPF inte överskrider uppslagsgränsen och att alla legitima sändare finns med. Verifiera DKIM-selektorer, DNS-nycklar och signaturer för varje e-postplattform.
# SPF
dig example.com TXT | grep spf
# DKIM (check common selectors)
dig google._domainkey.example.com TXT
dig default._domainkey.example.com TXT
Använd onlineverktyg
Använd etablerade DNS- och e-postanalysverktyg för att kontrollera poster och rubriker. Behandla externa resultat som diagnostik och bekräfta alltid ändringar i den egna konfigurationen.