Qu’est-ce que l’usurpation de domaine ?
L’usurpation de domaine consiste à faire croire qu’un message, un site ou une résolution DNS provient d’un domaine légitime. L’attaquant imite l’identité visible ou technique afin d’obtenir des identifiants, un paiement ou une action urgente.
Types d’usurpation de domaine
Les techniques varient selon l’élément imité : adresse d’expéditeur, nom affiché, domaine ressemblant, DNS ou identifiant d’appel.
Usurpation de courriel
L’attaquant falsifie l’adresse From ou le domaine d’enveloppe pour donner au message l’apparence d’un expéditeur fiable.
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
Usurpation du nom affiché
Le nom visible peut imiter un dirigeant ou un service, même si l’adresse réelle appartient à un autre domaine.
Display: CEO John Smith <[email protected]>
Actual email: [email protected]
Many email clients show only display name prominently
Usurpation par domaine ressemblant
Une variante typographique, un mot ajouté ou un caractère homoglyphe peut produire un domaine visuellement proche de la marque.
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')
Usurpation DNS (empoisonnement du cache)
Une réponse DNS falsifiée associe un nom légitime à l’adresse de l’attaquant.
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)
Usurpation de l’identifiant d’appel (VoIP)
La falsification de l’identifiant d’appel peut compléter une campagne d’usurpation en donnant au contact téléphonique une apparence crédible.
Comment fonctionne l’usurpation de courriel
SMTP historique ne prouve pas à lui seul que l’expéditeur déclaré contrôle le domaine. Les contrôles SPF, DKIM et DMARC ajoutent cette vérification.
La limite du protocole SMTP
Les commandes SMTP acceptent un expéditeur déclaré sans authentification de domaine obligatoire. Les destinataires doivent donc appliquer des politiques complémentaires.
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
Manipulation des en-têtes
Un message peut afficher un From rassurant tout en utilisant une adresse Reply-To ou une enveloppe différente. Examinez les en-têtes reçus, pas seulement le nom présenté.
From: "CEO John Smith" <[email protected]>
Reply-To: [email protected]
User sees trusted sender
Replies go to attacker
Scénarios réels d’attaques par usurpation
Les campagnes exploitent souvent une relation de confiance et demandent une action qui semble urgente.
Compromission de messagerie professionnelle (BEC)
L’attaquant imite un dirigeant ou un fournisseur et demande un virement, une modification de coordonnées bancaires ou un document confidentiel.
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
Campagnes d’hameçonnage
Un domaine ou une marque connue est imité pour inciter la victime à saisir un mot de passe ou à confirmer une activité prétendument suspecte.
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
Fraude à la facture
Une fausse facture ou une modification de compte bancaire est envoyée depuis une identité qui ressemble à celle d’un fournisseur.
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
Diffusion de logiciels malveillants
Un message usurpant un éditeur peut présenter une pièce jointe ou une mise à jour malveillante comme un correctif urgent.
1. Spoof trusted software company
2. Email with "critical security update"
3. Attachment contains malware
4. User trusts "legitimate" sender and opens it
Détecter l’usurpation de domaine
Combinez l’analyse des en-têtes, les contrôles d’authentification, l’inspection visuelle et les signaux comportementaux.
Analyse des en-têtes de courriel
Comparez From, Return-Path, Reply-To, Received et Authentication-Results. Une divergence peut être légitime, mais elle doit être expliquée.
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]>
Vérification SPF/DKIM/DMARC
Vérifiez les résultats SPF et DKIM, leur alignement avec le domaine visible et la politique DMARC publiée.
Authentication-Results: recipient.com;
spf=fail smtp.mailfrom=paypal.com ← Spoofed
dkim=none ← Not signed
dmarc=fail ← Failed policy
Inspection visuelle
Examinez le domaine caractère par caractère, les liens, le certificat, la langue et les demandes inhabituelles.
Real: paypal.com
Fake: paypal-secure.com (extra word)
Fake: paypαl.com (Cyrillic character)
Fake: paypal.co (missing 'm')
Anomalies comportementales
Une demande inattendue, un changement de ton, un horaire inhabituel ou une destination de paiement nouvelle mérite une vérification indépendante.
Prévenir l’usurpation de domaine
La prévention repose sur l’authentification, la protection des variantes de marque, la sensibilisation et la surveillance continue.
Mettre en œuvre l’authentification des courriels (critique)
Publiez SPF, signez les messages avec DKIM et déployez DMARC progressivement. Commencez par observer les rapports, puis renforcez la politique quand les flux légitimes sont connus.
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)
Enregistrer des domaines défensifs
Réservez les fautes courantes, variantes et domaines ressemblants réellement susceptibles d’être utilisés contre la marque.
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
Surveiller les mentions de marque
Recherchez les nouveaux domaines, certificats et campagnes qui reprennent votre nom. Reliez chaque signal à une procédure de vérification.
Former les employés
Apprenez à vérifier l’adresse complète, les liens, les demandes urgentes et les changements de paiement par un canal indépendant.
Contrôles techniques
Utilisez des contrôles de messagerie, des protections de navigateur et des règles d’accès cohérentes.
p=reject (block spoofed email entirely)[EXTERNAL EMAIL] This email originated outside the organizationTechniques avancées d’usurpation
Les attaques avancées combinent IDN, sous-domaines trompeurs et détournement de DNS.
Attaques par homographes
Des caractères visuellement proches issus d’autres alphabets peuvent masquer un domaine différent.
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
Usurpation de sous-domaines
Un sous-domaine comme legitimate-bank.attacker.com peut donner l’impression que le domaine de confiance est legitimate-bank.
legitimate-bank.attacker.com
Appears as: legitimate-bank (subdomain of attacker.com)
Users see: "legitimate-bank" and assume it's safe
Attaque de l’homme du milieu par détournement DNS
Le détournement d’un routeur, d’un serveur DNS ou d’un compte d’administration peut modifier la résolution avant la connexion.
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
Aspects juridiques et réglementaires
La réponse dépend de la juridiction, de la preuve disponible et de la nature de l’usurpation. Conservez les journaux et demandez un conseil spécialisé.
Loi américaine de protection des consommateurs contre le cybersquatting (ACPA)
Aux États-Unis, l’ACPA prévoit certains recours contre l’enregistrement et l’usage abusif de domaines visant une marque.
Politique uniforme de règlement des litiges relatifs aux noms de domaine (UDRP)
La procédure UDRP permet, dans les conditions prévues par la politique, de contester certains enregistrements de domaine auprès d’un fournisseur habilité.
Sanctions pénales
La fraude, le vol d’identité, l’accès non autorisé et la distribution de logiciels malveillants peuvent relever du pénal selon les faits et la juridiction.
Répondre à une usurpation de domaine
Agissez rapidement, mais préservez les éléments de preuve avant de supprimer les messages ou de modifier les configurations.
Si votre domaine est usurpé
1. Mettre en œuvre DMARC avec p=reject
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"2. Alerter les clients et partenaires
- Informer de la campagne d’usurpation
- Fournir les indicateurs à rechercher
- Donner un canal de signalement
3. Signaler aux autorités
- FBI IC3 (États-Unis)
- Services locaux de lutte contre la cybercriminalité
- Anti-Phishing Working Group (apwg.org)
4. Demander le retrait
- Signaler les sites d’hameçonnage aux hébergeurs
- Signaler les domaines aux registrars
- Utiliser le signalement Google Safe Browsing
5. Surveiller les rapports DMARC
- Identifier les sources d’usurpation
- Suivre le volume et les tendances des attaques
Si vous découvrez un domaine ressemblant
Vérifiez son contenu et son usage, documentez la similarité et utilisez les procédures d’abus, de registre ou de retrait appropriées.
Tester vos défenses
Les tests doivent utiliser des adresses et des environnements autorisés et ne jamais viser des tiers sans permission.
Tester la protection contre l’usurpation de courriel
Envoyez un test contrôlé et confirmez la décision du destinataire, l’alignement DMARC et les rapports reçus.
# 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
Vérifier la configuration DMARC
Vérifiez que le nom d’hôte DMARC publie une politique attendue, que les rapports sont accessibles et que les paramètres correspondent au plan de déploiement.
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]"
Vérifier SPF et DKIM
Interrogez les enregistrements, testez un message réel et confirmez que les sélecteurs DKIM et les domaines d’enveloppe sont alignés.
# SPF
dig example.com TXT | grep spf
# DKIM (check common selectors)
dig google._domainkey.example.com TXT
dig default._domainkey.example.com TXT
Utiliser des outils en ligne
Les outils peuvent accélérer l’inspection, mais leurs résultats doivent être interprétés avec les journaux, les en-têtes et le contexte de votre domaine.