Les cybercriminels d'aujourd'hui comprennent le fonctionnement des passerelles de messagerie. Ils savent que les passerelles analysent les en-têtes des messages, en inspectent le corps et examinent minutieusement les pièces jointes. Et lorsque quelque chose semble suspect, la passerelle de messagerie place les pièces jointes et les URL dans une sandbox afin d'observer leur comportement.
Comme les cyberpirates ont conscience de tout cela, ils ont modifié leur méthodologie d'attaque. Alors qu'ils privilégiaient auparavant les pièces jointes malveillantes, ils ont de plus en plus recours à des URL malveillantes. Selon notre dernier rapport Le facteur humain vol. 2 : phishing et menaces basées sur des URL, les URL sont désormais utilisées quatre fois plus souvent dans les emails malveillants que les pièces jointes.
Pour échapper à la détection, les cybercriminels dissimulent souvent les composants malveillants d'une URL derrière des barrières d'authentification ou une logique conditionnelle afin de les faire passer outre les mesures de sécurité. Une sandbox ne peut pas facilement imiter le comportement réel d'un utilisateur. Ainsi, sans cette interaction authentique de l'utilisateur, la sandbox pourrait ne jamais atteindre la partie malveillante de l'attaque. Et les cyberpirates ne se contentent pas de manipuler les URL. Ils trouvent également des moyens de contourner complètement l'infrastructure de protection de la messagerie en exploitant les relations de confiance dans les plates-formes de collaboration.
Vous trouverez ci-dessous trois cas d'utilisation réels que nous avons observés, dans lesquels des cyberpirates ont intentionnellement conçu leurs attaques de manière à contourner les protections existantes. Chacun démontre une stratégie de contournement différente.
Cas d'utilisation n° 1 : l'exploit de vérification de lien – caché derrière l'authentification
Dans ce premier cas d'utilisation, un cybercriminel inclut dans son email un lien qui semble légitime. Il peut s'agir, par exemple, d'un document partagé sur OneDrive, d'un fichier Dropbox ou d'une demande DocuSign.
Fonctionnement
Lorsque la sandbox de la passerelle de messagerie analyse l'URL, elle ne trouve qu'une page d'authentification qui demande aux utilisateurs de vérifier leur identité. Les utilisateurs sont invités à saisir une adresse email, à fournir un mot de passe, à résoudre un CAPTCHA ou à effectuer une autre vérification prouvant qu'ils sont humains.
Le contournement critique : cette URL initiale ne contient aucun code malveillant.
Du point de vue du système de sécurité, cette page ressemble à une page de vérification standard pour un service de partage de fichiers légitime. La sandbox détermine que l'URL est sûre et l'email est remis dans la boîte de réception du destinataire.
Ce n'est qu'après que l'utilisateur a cliqué sur le lien et saisi ses données d'authentification que le serveur Web autorise l'accès à la page malveillante. Cette page peut être un formulaire de collecte d'identifiants de connexion, un téléchargement de malware ou un site de phishing sophistiqué. L'attaque existe derrière l'exigence d'authentification. Elle est invisible pour l'analyse automatisée qui a déjà considéré l'email comme sûr.
Figure 1. Exemple d'exploit de vérification de lien.
L'implication
Même si la passerelle peut détecter l'URL malveillante connue derrière la page d'authentification, elle ne sera jamais en mesure d'analyser la page. L'URL initiale est véritablement propre. La passerelle ne réécrira donc pas l'URL pour une analyse future et transmettra le message. La menace ne se révèle qu'après la fin de l'analyse de sécurité et une fois que l'utilisateur a été convaincu de s'authentifier. Cette technique transforme efficacement les fonctionnalités de sécurité légitimes (pages d'authentification) en un mécanisme de contournement.
Cas d'utilisation n° 2 : le mirage de la sandbox – détecter le détecteur
Dans cette attaque plus sophistiquée, l'infrastructure Web du cybercriminel est spécialement conçue pour détecter si un visiteur est humain ou s'il s'agit d'un système de sécurité automatisé.
Fonctionnement
Lorsqu'un email contenant une URL malveillante atteint la passerelle, le système de sécurité l'ouvre dans un environnement sandbox afin d'analyser son comportement avant sa remise.
Cependant, le serveur Web du cyberpirate analyse les requêtes HTTP entrantes afin de faire la distinction entre les sandboxes et les utilisateurs réels. Les serveurs Web peuvent examiner les éléments suivants :
- Chaînes d'agent utilisateur. Les sandboxes utilisent souvent des agents utilisateur identifiables qui révèlent qu'il s'agit d'outils de sécurité automatisés.
- Adresses IP. Cela leur indique si une requête provient de plages IP de fournisseurs de sécurité connus ou d'un réseau de centre de données.
- En-têtes HTTP. Les modèles dans les en-têtes tels que Referer, Accept-Language et d'autres attributs de requête diffèrent entre les outils automatisés et les navigateurs authentiques.
- Exécution de JavaScript. Cela leur indique si le client exécute entièrement JavaScript, car certaines sandboxes peuvent charger des pages sans exécution complète du script.
- Modèles d'accès. Ils cherchent à savoir s'il s'agit d'un accès direct à l'URL ou d'un parcours naturel à partir d'une recherche ou d'un client de messagerie.
Figure 2. Workflow d'une requête de page Web.
Sur la base de cette analyse, si la requête semble provenir d'une sandbox, le serveur du cybercriminel redirige vers une page Web totalement inoffensive ou la diffuse.
Par conséquent, lorsque le système de sécurité analyse l'URL, il détermine que le contenu est sûr, et l'email est remis. En revanche, lorsqu'un utilisateur clique sur ce même lien depuis son terminal professionnel équipé d'un navigateur standard, le serveur du cyberpirate redirige vers le contenu malveillant ou le diffuse.
L'implication
Lorsque les cybercriminels utilisent une logique côté serveur pour faire la distinction entre les analyseurs de sécurité et les cibles humaines, l'analyse statique ou en un seul passage des URL ne suffit pas. Le simple fait de procéder à une inspection automatisée peut être détecté et exploité. Cela entraîne un jeu du chat et de la souris que les professionnels de la sécurité sont en train de perdre.
Cas d'utilisation n° 3 : la porte dérobée de Google Agenda – exploitant les écosystèmes de confiance
Ce vecteur d'attaque est particulièrement insidieux, car il n'implique pas l'envoi d'un email. Il peut donc contourner complètement les passerelles de protection de la messagerie.
Fonctionnement
Le processus se déroule comme suit :
- Reconnaissance initiale. Le cybercriminel identifie que l'entreprise XYZ utilise Google Workspace.
- Création de compte. Le cyberpirate crée un compte Gmail gratuit : badguy@gmail.com.
- Identification des cibles. Il obtient une liste d'adresses email des collaborateurs de l'entreprise XYZ.
- Création d'un événement de calendrier. Dans son compte @gmail.com, le cybercriminel crée une invitation de calendrier qui comprend :
- Les adresses email des collaborateurs ciblés
- Une URL de phishing intégrée aux détails de l'événement
- Une pièce jointe malveillante au format PDF (déguisée en documents de réunion)
5. L'étape critique. Au lieu de cliquer sur Envoyer l'invitation, le cyberpirate enregistre simplement l'événement de calendrier comme brouillon.
En quelques secondes, l'invitation de calendrier apparaît dans les calendriers de tous les collaborateurs ciblés de l'entreprise XYZ. Elle contient l'URL de phishing et la pièce jointe malveillante. Comme aucun email n'a été envoyé, la passerelle de protection de la messagerie ne détecte jamais la menace. Elle n'a jamais l'occasion d'analyser l'URL ou la pièce jointe.
Figure 3. Exemple d'exploit de Google Agenda.
Cette attaque exploite la relation de confiance inhérente à Google Workspace. Lorsque des invitations de calendrier sont créées au sein de l'écosystème Google, elles se synchronisent directement entre les comptes sans déclencher les mécanismes traditionnels de remise d'emails.
Les contrôles de sécurité conçus pour inspecter le trafic de messagerie sont complètement contournés, car la menace opère au niveau de la couche applicative, et non au niveau de la couche de transport d'emails.
Du point de vue de l'utilisateur, tout ce qu'il voit, c'est une invitation de calendrier légitime, par exemple pour un « bilan trimestriel des activités » ou une « réunion avec un fournisseur », qui présente une mise en forme professionnelle et des documents joints. Comme elle est arrivée via une application de confiance, il n'a aucune raison de soupçonner qu'elle ait contourné un quelconque contrôle de sécurité.
L'implication
Ce cas d'utilisation révèle une lacune critique : les entreprises qui s'appuient uniquement sur la protection de la passerelle de messagerie ne voient pas les menaces véhiculées par les outils de collaboration.
À mesure que le travail devient de plus en plus collaboratif et basé sur le cloud, les cybercriminels adaptent leurs techniques pour exploiter les relations de confiance entre les applications intégrées.
La voie à suivre
Pour vous défendre contre ces tactiques de contournement, vous devez changer radicalement votre approche en matière de sécurité. Plutôt que d'avoir un point d'inspection unique, vous avez besoin d'une protection complète et en profondeur. Voici ce qu'il faut rechercher :
1 : Protection avancée de la messagerie avec analyse continue
Vous avez besoin d'un système de sécurité qui va au-delà de l'inspection initiale de la page et qui assure une surveillance continue ainsi qu'une analyse après la remise. Cela inclut :
- Une réévaluation continue des URL, même après la remise des emails
- Une analyse comportementale qui détecte les anomalies dans les modèles d'interaction des utilisateurs
- Une protection au moment du clic qui analyse les URL au moment où les utilisateurs y accèdent, pas seulement lorsque les emails arrivent
2 : Protection de la collaboration intégrée au navigateur
Les menaces arrivent de plus en plus par le biais de plates-formes de collaboration plutôt que par email. C'est pourquoi vous avez besoin de contrôles de sécurité qui opèrent là où les utilisateurs interagissent avec le contenu : dans le navigateur. La protection native du navigateur peut :
- Analyser les redirections et les URL multi-imbriquées en temps réel, quelle que soit la manière dont elles ont été transmises
- Inspecter les menaces sur chaque page du parcours de l'utilisateur, pas seulement sur la page de renvoi initiale
- Détecter les comportements malveillants dans les invitations de calendrier, les documents partagés et les plates-formes de messagerie
3 : Défense centrée sur les personnes
Aucune technologie ne peut remplacer la sensibilisation à la sécurité. Vous devez former vos utilisateurs afin qu'ils comprennent :
- Pourquoi ils devraient se méfier des URL qui exigent une authentification immédiate — en particulier lorsque les identifiants de connexion sont fournis dans le message
- Comment reconnaître et signaler les invitations de calendrier inhabituelles provenant de parties externes
- Les contrôles de sécurité ne sont pas infaillibles, et leur jugement demeure une couche de défense essentielle.
Conclusion
Les cas d'utilisation détaillés ci-dessus ne sont pas théoriques : il s'agit de modèles d'attaque actifs observés dans des environnements d'entreprise réels. Si vous partez du principe que votre passerelle de messagerie offre une protection complète, vous opérez avec un angle mort dangereux.
Découvrez comment Proofpoint Prime Threat Protection offre une protection complète et multicouche contre ces tactiques de contournement intentionnelles.
