Environ 36 % de toutes les violations de données enregistrées dans l’Union européenne et aux États-Unis sont le résultat d’attaques de phishing. Les e-mails de phishing semblent souvent provenir de sources légitimes, telles que "admin@micr0soft.com" ou "Administrateur IT email@google.com," et comportent des objets et des contenus conçus pour attirer l’attention des utilisateurs, comme des informations sur les salaires, la paie, etc.
Dans certains cas, les attaquants usurpent des adresses e-mail pour faire croire que le message provient d’une source de confiance, par exemple « votre_patron@votresociete.com ». Comme le client de messagerie reconnaît l’adresse de l’expéditeur comme étant celle de votre responsable informatique, il peut afficher automatiquement la photo du contact, renforçant ainsi l’illusion de légitimité. Cela facilite grandement la tâche des cybercriminels qui cherchent à inciter les utilisateurs à agir dangereusement : saisie d’identifiants, lancement d’applications malveillantes ou encore transfert d’argent vers un compte inconnu.

Quels sont les protocoles en place pour nous protéger du phishing ?
DMARC, DKIM et SPF : protégez-vous des usurpations d’identité
Le Simple Mail Transfer Protocol (SMTP) est un protocole utilisé pour envoyer des messages électroniques. Il a été créé en 1982, sans considération aucune pour la sécurité des e-mails. À l’origine, la sécurité devait être assurée par d’autres moyens. Aujourd’hui, le trafic SMTP entre serveurs de messagerie peut être chiffré et authentifié à l’aide du protocole TLS. Le protocole SMTP d’origine ne prévoyait lio aucun moyen d’authentification des e-mails.
Sachant que l’e-mail demeure une cible de choix pour les menaces de cybersécurité telles que le spam, le phishing et l’usurpation d’identité, trois protocoles ont été développés pour renforcer la sécurité des e-mails :
1. Sender Policy Framework (SPF) : protocole qui vérifie si un serveur de messagerie est autorisé à envoyer des e-mails pour un domaine donné, en utilisant le DNS.
2. DomainKeys Identified Mail (DKIM) : ce protocole permet de signer numériquement les e-mails, prouvant qu’ils proviennent d’un serveur de messagerie autorisé. Les signatures DKIM permettent aux fournisseurs de messagerie de vérifier l’authenticité du domaine de l’expéditeur.
3. Domain-based Message Authentication, Reporting, and Conformance (DMARC) : ce protocole détermine la manière de gérer les e-mails qui échouent aux vérifications SPF ou DKIM. Il permet de déterminer l’action appropriée à entreprendre lorsqu’un e-mail ne parvient pas à s’authentifier.

Exemple de flux d’e-mails
1. Le serveur A envoie une requête DNS pour trouver le serveur MX (Mail Exchange) de notreentreprise.com.
2. Le serveur A envoie un e-mail de user@entreprise.com à user2@notreentreprise.com via l’un des serveurs MX (Serveur B).
3. Le serveur B vérifie l’e-mail :
• Vérification que l’e-mail provient d’un serveur autorisé (vérification SPF).
• Vérification de la signature DKIM de l’e-mail.
• Suivi des actions préconisées par la stratégie DMARC.
Par exemple, si le serveur A n’est pas répertorié dans les enregistrements SPF, et que l’e-mail ne comporte pas de signature DKIM ou que la signature DKIM est non valide, et que le domaine entreprise.com a une stratégie DMARC définie sur « Rejeter », alors le serveur B doit rejeter l’e-mail.
Si nous avons :
SPF :
ourcompany.com. 3600 IN TXT "v=spf1 mx -all"

MX :
ourcompany.com. 300 IN MX 10 s1.ourcompany.com.
ourcompany.com. 300 IN MX 10 s2.ourcompany.com.

DMARC :
_dmarc.ourcompany.com. 2861 IN TXT "v=DMARC1 ; p=reject ; fo=1"
Nous nous attendons à ce que tous les e-mails provenant de sources non répertoriées dans nos enregistrements MX soient rejetés.
Mais que se passe-t-il si le serveur de réception est configuré pour ignorer ces stratégies ? Et si ce n’est pas vous qui décidez (en tant qu’administrateur de MX) ? Ou si vous avez un serveur de messagerie supplémentaire sans le savoir et que vous ne savez pas comment il fonctionne ?
Voyons cela de plus près.

Microsoft Exchange Online
Vous pouvez configurer et utiliser Exchange Online comme serveur de messagerie. Dans ce cas, vous n’avez pas besoin de serveurs Exchange sur site ni de solution antispam tierce.
Si vous utilisez Exchange Online sans serveurs sur site ou MX tiers, ce scénario ne s’applique pas à vous. Ce scénario couvre deux cas :
• Environnement hybride : si vous disposez d’une installation Exchange sur site et que vos installations Exchange en ligne et sur site communiquent via des connecteurs.
• Utilisation d’un serveur MX tiers : si vous utilisez une solution antispam tierce ou de sécurité des e-mails.
Serveur MX tiers
Si votre MX est pointé vers le MX d’un tiers, vous devez vous reporter à cet article de Microsoft pour configurer votre instance EXO.

Par exemple, au lieu de :
ourcompany.com. 300 IN MX 10 ourcompany.protection.outlook.com
vous avez
ourcompany.com. 300 IN MX 10 s1.ourcompany.com

Hébergement hybride
Un article complet est disponible icisur ce qu’est le mode de démarrage UEFI et comment il doit être configuré. Si vous n’avez pas de serveur MX et que tout le trafic passe par *.protection.outlook.com, il n’y a aucun risque de mauvaise configuration.
Mais que se passe-t-il si vous utilisez votre propre serveur MX ? Par défaut, l’assistant de configuration hybride crée des connecteurs entrants et sortants standard pour l’échange de données entre Exchange Online et Exchange sur site.
Je n’ai trouvé aucune référence à l’article sur les MX tiers dans la documentation sur l’environnement hybride. J’ai trouvé une mention des MX tiers dans la documentation Transport Routing :
Si vous décidez de conserver votre enregistrement MX pointé vers votre organisation sur site : tous les messages envoyés à un destinataire de l’une ou l’autre organisation seront d’abord acheminés par votre organisation sur site. Un message adressé à un destinataire dans Exchange Online sera d’abord acheminé via votre organisation sur site, puis remis à l’utilisateur dans Exchange Online. Cette méthode peut être utile pour les organisations qui disposent de stratégies de conformité exigeant que les messages envoyés à une organisation et reçus d’une organisation soient examinés par une solution de journalisation. Si vous choisissez cette option, Exchange Online Protection ne pourra pas analyser efficacement les messages indésirables.

Quel est le problème ?
Le point le plus important à noter est que si l’enregistrement MX du domaine du destinataire pointe vers une autre solution de sécurité des e-mails en amont d’Office 365, alors Honor DMARC ne sera pas appliqué.
Comme vous utilisez d’autres MX que ceux de Microsoft, tous les e-mails seront vérifiés par ce MX tiers. Cela ne devrait pas poser de problème, n’est-ce pas ?
Non. Si vous n’avez pas restreint votre organisation Exchange Online pour n’accepter que les e-mails provenant de votre service tiers, ou si vous n’avez pas activé l’amélioration du filtrage pour les connecteurs, n’importe qui peut vous envoyer un e-mail via notreentreprise.protection.outlook.com ou notreentreprise.mail.protection.outlook.com, et la vérification DMARC (SPF et DKIM) sera ignorée.

Connecteurs entrants
Pour comprendre comment cela fonctionne, nous devons examiner les configurations des connecteurs entrants.
Hébergement hybride
Enabled : True
ConnectorType : OnPremises
ConnectorSource : HybridWizard
Comment :
SenderIPAddresses : {}
SenderDomains : smtp :* ;1
TrustedOrganizations : {}
ClientHostNames : {}
AssociatedAcceptedDomains : {}
RequireTls : True
RestrictDomainsToIPAddresses : False
RestrictDomainsToCertificate : False
TlsSenderCertificateName : *.ourdomain.com
Éléments importants de cette configuration : pour quels serveurs ce connecteur sera-t-il utilisé ? Pour toutes les adresses IP et tous les domaines.
SenderIPAddresses : {}
SenderDomains : smtp :* ;1
Que faire des connexions qui ne relèvent pas du champ d’application ? Rien.
RestrictDomainsToIPAddresses : False
RestrictDomainsToCertificate : False

Cela signifie que si vous n’avez que ce type de connecteur, les connexions à notreentreprise.protection.outlook.com ou notreentreprise.mail.protection.outlook.com ne sont pas restreintes par votre serveur Exchange sur site.
Les notes de cet article sur les MX tiers nous amènent à constater un point important :
Si vous avez déjà un connecteur entrant OnPremises pour le même certificat ou les mêmes adresses IP d’expéditeur, vous devez tout de même créer le connecteur entrant du partenaire (les paramètres RestrictDomainsToCertificate et RestrictDomainsToIPAddresses ne s’appliquent qu’aux connecteurs de partenaire). Les deux connecteurs peuvent coexister sans problème.

Cela signifie que notre configuration n’est pas sécurisée par défaut.
Informations importantes sur les connecteurs de partenaires

Si vous souhaitez configurer des connecteurs entrants pour des serveurs MX tiers, vous pouvez utiliser PowerShell ou l’interface graphique. Vous pouvez utiliser deux types d’authentification : par "domaine de l’expéditeur" ou par "adresse IP".
Si vous disposez d’un connecteur de partenaire avec SenderIPAddresses : {}, par exemple, un connecteur de partenaire avec authentification par "domaine de l’expéditeur", toutes les connexions (à l’exception des adresses IP des connecteurs où cette adresse spécifique est définie) passeront par ce connecteur.
Si vous créez un connecteur de partenaire avec authentification par adresse IP et avec RestrictDomainsToIPAddresses, toutes les connexions « sans » connecteur seront bloquées.
Si vous essayez de créer un connecteur via l’interface graphique, vous ne pouvez pas définir RestrictDomainsToIPAddresses dans le cas où l’authentification se fait par l’adresse IP, car il n’existe pas d’option « Rejeter les messages électroniques s’ils ne sont pas envoyés à partir de cette plage d’adresses IP ». Cela ne peut être fait qu’avec PowerShell. Ou vous devriez utiliser la vérification par domaine de l’expéditeur.
Et préciser : Rejeter les messages électroniques s’ils ne sont pas envoyés à partir de cette plage d’adresses IP

Comment vous protéger ?
Renforcement
Si vous utilisez un MX tiers, vous devez configurer au moins un connecteur entrant supplémentaire, conformément aux recommandations de Microsoft.
Dans le cas d’une configuration hybride, vous devez créer un connecteur partenaire avec la même adresse IP et le même certificat que ceux utilisés dans le connecteur OnPremises, comme suit :
New-InboundConnector -Name "Reject mail not routed through MX (third-party service name)" -ConnectorType Partner -SenderDomains * -RestrictDomainsToCertificate $true -TlsSenderCertificateName *.domain.com -RequireTls $true
ou
New-InboundConnector -Name "Reject mail not routed through MX (third-party service name)" -ConnectorType Partner -SenderDomains * -RestrictDomainsToIPAddresses $true -SenderIpAddresses <#static list of on-premises IPs or IP ranges of the third-party service>

Vous pouvez également implémenter :
• Filtrage amélioré pour les connecteurs dans Exchange Online.
• Prévention des pertes de données (DLP)
• Règles de transport, par exemple pour supprimer tous les e-mails qui ne proviennent pas de vos serveurs MX.
POC
Vous pouvez utiliser le code ci-dessous pour vérifier par vous-même.
Important :
• TO est une adresse réelle. L’adresse e-mail doit exister du côté d’Exchange Online si vous n’utilisez pas un schéma hybride.
• Serveur que vous pouvez obtenir à partir du résultat des requêtes :

dig yourdomain.onmicrosoft.com
ou
dig yourdomain.mail.onmicrosoft.com

Exemple de code PowerShell :
$from="user1@yourdomain.com"
$to = "user2@yourdomain.com"
$server = "yourdomain.mail.protection.outlook.com"

$SMTPMessage = New-Object System.Net.Mail.MailMessage($from,$to)
$SMTPMessage.Subject = "Misconfiguration in the M365 tenant"
$SMTPMessage.Body = "From user@yourdomain.com"
$SMTPClient = New-Object Net.Mail.SmtpClient($server, 25)

try
$SMTPClient.Send($SMTPMessage)
Write-Host (Get-Date).ToUniversalTime()
Write-Output "Email sent successfully to $to. From $from"
catch [System.Net.Mail.SmtpException]
Write-Host (Get-Date).ToUniversalTime()
Write-Output "SMTP Exception : $_"
catch [System.Exception]
Write-Host (Get-Date).ToUniversalTime()
Write-Output "General Exception : $_"

Les alertes et événements dépendent de votre configuration
Action / Erreur Signification
Un e-mail a été envoyé à une adresse e-mail aléatoire Exchange hybride ou connecteur sortant spécial pour tous les e-mails non disponibles dans Exchange Online.
550, b’5.4.1 Recipient address rejected : Access denied Cette adresse e-mail n’existe pas dans Exchange Online. Peu fiable
550, b""5.7.51 TenantInboundAttribution ; There is a Partner connector configured that matched the message’s recipient domain. The connector had either the RestrictDomainsToIPAddresses or RestrictDomainsToCertificate set Vous avez correctement configuré les connecteurs entrants. Vous êtes protégé