Smishing (phishing par SMS) : comment identifier les attaques et se protéger ?

Qu’est-ce que le smishing ?

Vous connaissez certainement le phishing qui consiste à envoyer des emails malveillants pour inciter les destinataires à réaliser des actions sensibles, comme renseigner leurs identifiants de connexion VPN sur une fausse page d’authentification par exemple.

Le smishing est quasiment identique, à ceci près que l’attaquant n’envoie non pas des emails, mais des SMS, d’où le nom de smishing. Essentiellement, le smishing est ni plus ni moins que du phishing par SMS.

Globalement, le smishing est une technique d’ingénierie sociale qui, pour rappel, utilise un prétexte pour influencer ses victimes et les pousser à l’action, et ce via le canal SMS. Par ailleurs, le phishing par SMS ou par email, peut être utilisé pour des arnaques « en masse » ou des attaques plus ciblées comme nous le verrons dans la suite de l’article.

Plan détaillé de l’article :

Comment identifier une attaque de phishing par SMS (smishing) ?

Avant de détailler un cas concret de campagne de smishing en boite grise réalisé dans le cadre d’un pentest d’ingénierie sociale, revenons sur les quelques éléments devant être pris en compte pour identifier un SMS malveillant.

Numéro de l’expéditeur

Dans la majorité des attaques de phishing par SMS, le numéro de téléphone de l’expéditeur est totalement inconnu du destinataire, ce qui devrait suffire à tirer la sonnette d’alarme.

L’indicatif téléphonique – par exemple +33 pour la France, +1 pour les États-Unis et le Canada, ou encore +258 pour le Mozambique – peut être plus ou moins suspect.

Pour donner plus de poids aux SMS, l’attaquant peut tenter d’usurper un numéro familier de sa victime. Par exemple, il existe des plateformes permettant d’envoyer des SMS ou même de placer des appels depuis un numéro virtuel. L’attaquant peut ainsi choisir son numéro avant de lancer l’attaque.

Il va sans dire qu’un SMS est déjà plus crédible s’il semble venir d’un numéro local – c’est-à-dire géographiquement proche de nous, du même pays, voire de la même ville. Avec un peu de chance, l’attaquant peut même usurper un numéro proche d’un numéro connu de sa victime – avec seulement quelques chiffres de différence.

Usurper une marque familière est une autre alternative intéressante pour les attaquants. Il est par exemple fréquent de recevoir un SMS légitime de sa propre banque avec le nom de l’organisme affiché (par exemple « LCL ») à la place d’un numéro de téléphone.

L’attaquant peut également choisir d’envoyer les SMS en utilisant un nom plutôt qu’un numéro classique. Selon la nationalité des destinataires, certaines restrictions peuvent néanmoins s’appliquer, certains noms pouvant notamment être réservés dans certains pays pour éviter qu’ils ne soient usurpés. Alerte spoiler : ce n’est pas le cas partout !

Ce qu’il faut retenir :

• Le numéro de l’expéditeur n’est pas nécessairement un numéro étranger ou intrinsèquement suspect. Les attaquants peuvent usurper un numéro familier à leurs victimes pour abaisser leur niveau de vigilance.
• Il est possible dans certains cas d’usurper une marque connue et d’afficher un nom d’entité à la place du numéro de téléphone, ce qui rend les attaques encore plus crédibles.

En résumé, il ne faut pas se baser uniquement sur l’identité de l’expéditeur – que ce soit un nom de marque ou un numéro de téléphone – pour déterminer si un SMS est légitime ou non.

Contenu du SMS

Outre l’identité de l’expéditeur, qui est naturellement le premier élément auquel nous prêtons attention quand nous recevons un SMS, certains indices dans le corps du message lui-même doivent nous mettre en garde.

Le prétexte (Call-To-Sensible-Action)

La notion de prétexte n’est pas spécifique au Smishing, mais est un élément crucial de toute tentative d’ingénierie sociale, car c’est ce qui incite la victime à réaliser l’action sensible souhaitée par l’attaquant.

Par exemple, dans une attaque ciblée visant les employés d’une entreprise, l’attaquant peut prétexter une mise à jour VPN pour inciter ces derniers à renseigner leurs identifiants sur une fausse page de connexion sous son contrôle.

Pour remplir son objectif et pousser les utilisateurs à l’action, le prétexte doit utiliser différents leviers psychologiques pour tromper leur vigilance. Il s’appuie souvent sur une notion d’urgence (par exemple « veuillez mettre à jour sous 48h sous peine de désactivation du compte »), de curiosité (« untel vient de partager le dossier suivant avec vous »), de familiarité (notamment si l’attaquant usurpe un expéditeur familier), voire d’autorité (si l’expéditeur présumé se trouve être le manager ou le service IT de l’entreprise).

Dans le cas du Smishing, l’attaquant délivre son prétexte en envoyant un SMS à ses victimes. Le contenu du message en lui-même contient la demande, ce qui constitue l’essentiel du prétexte, mais d’autres éléments rentrent également en ligne de compte dans l’élaboration d’un bon prétexte (par exemple l’identité de l’expéditeur, la période à laquelle le SMS est envoyé, etc.).

Les liens

Que ce soit pour distribuer un malware via une plateforme en ligne ou pour voler des identifiants de connexion, l’attaquant doit en général inclure, dans le corps du SMS, au moins un lien vers un domaine sous son contrôle. Aussi bien ficelé que soit le prétexte, bien analyser ce lien – ce qui prend quelques minutes tout au plus – peut faire toute la différence.

Pour analyser un lien, il faut tout d’abord comprendre la notion de nom de domaine et les différents niveaux qui le composent.

Prenons par exemple, le sous-domaine (légitime) login.microsoftonline.com. Il se décompose de la manière suivante :

• La partie « .com » correspond à ce que l’on appelle le domaine de premier niveau (ou TLD pour « Top-Level Domain »). À noter que certains TLD sont en deux parties (comme « .co.uk »), mais dans la majorité des cas, le TLD se situe après le dernier point.
• Directement sous le TLD « microsoftonline » se trouve le domaine de deuxième niveau (ou SLD pour « Second-Level Domain »). Ensemble, le SLD et le TLD forment ce qu’on appelle communément le nom de domaine (ici microsoftonline.com) – plus précisément il s’agit du « TLD + 1 » puisqu’il englobe le TLD, plus le niveau immédiatement inférieur (à savoir le SLD)… Nom d’un nom de domaine !
• Tout ce qui se situe ensuite (ici « login« ) identifie le sous-domaine. Le nombre de composants (de niveaux) n’est pas limité : auth.login.microsoftonline.com est un sous-domaine tout aussi valide.

Comme nous l’avons déjà dit, un lien de phishing pointe (la plupart du temps) sur un domaine malveillant – c’est-à-dire sur un domaine qui n’est pas le domaine légitime (par exemple oultook.com au lieu de outlook.com).

Outre l’inversion, le remplacement ou l’omission de caractères dans le nom de domaine légitime (une technique appelée « typosquatting »), les attaquants utilisent quelques autres astuces pour passer sous le radar.

Dans le même esprit, le « combosquatting » est la combinaison d’un mot clé et du domaine légitime (par exemple accounts–google.com au lieu de accounts.google.com). Modifier le TLD est une autre possibilité (par exemple gmail.co au lieu de gmail.com).

Dans tous les cas, il faut vérifier si le nom de domaine (au sens « TLD + 1 ») est légitime ou non. Petit test : que pensez-vous par exemple de paypal.securelogin.com ?

Ce qu’il faut retenir :

• Dans la majorité des cas, l’objectif de l’attaquant sera de vous faire effectuer une action sensible (télécharger un fichier ou s’authentifier sur un site web plus ou moins douteux par exemple). Pour ce faire, il utilisera certaines astuces psychologiques pour essayer de tromper votre vigilance et vous inciter à une action rapide.
• Analyser systématiquement les liens reçus par SMS (par mail ou autre soit dit en passant), et notamment leur nom de domaine (« TLD + 1 »).

Exemple d’attaque de smishing (phishing par SMS) réalisé lors d’un pentest d’ingénierie sociale

Maintenant que nous avons passé en revue les indices à relever pour identifier une tentative de smishing, nous allons les mettre en pratique à travers un scénario d’attaque, inspiré d’un de nos audits.

Campagne de Smishing en boite grise

Dans cet exemple, nous nous placerons en condition « boîte grise », à savoir que les numéros de téléphone professionnels des collaborateurs à cibler nous auront été fournis en amont par notre client, disons la société Koogivi.

À noter qu’en condition « boîte noire » – c’est-à-dire dans les conditions d’un attaquant externe n’ayant aucune information sur l’entreprise – la recherche des numéros à cibler nécessite une étape intermédiaire plus ou moins longue, ces derniers pouvant être potentiellement divulgués de plusieurs manières. Si une plateforme en ligne est piratée par exemple – ce qui arrive fréquemment – il n’est pas rare de retrouver des informations de contact (dont des numéros de portable) dans les fuites de données rendues publiques ou vendues sur le dark web. Plus simplement, les profils LinkedIn ou les signatures d’email peuvent contenir ce type d’information.

Reconnaissance

La phase de reconnaissance est une première étape importante de nos audits et plus généralement de toute cyberattaque, car elle permet d’inventorier les actifs exposés d’une entreprise et d’identifier les plus critiques. Elle peut également permettre d’identifier certains services externes qui sont également des portes d’entrée potentielles.

Par exemple, supposons que durant notre phase de reconnaissance, nous remarquions que l’entreprise Koogivi utilise Gandi comme serveur de messagerie (information révélée par les enregistrements MX par exemple). La page de connexion à la webmail est la suivante :

Il va sans dire que la webmail est un point d’entrée intéressant pour un attaquant, car y accéder permet de mettre la main sur des informations potentiellement sensibles – sans parler du fait que les mots de passe de la webmail peuvent donner accès à d’autres plateformes internes (ou externes) s’ils sont réutilisés ailleurs…

Mise en place du scénario

Une fois la plateforme cible identifiée, la prochaine étape consiste à cloner la page de connexion. Nous ne rentrerons pas (trop) dans les détails techniques pour cette fois, mais sachez que certaines techniques permettent aux attaquants de faire interagir leurs victimes, non pas avec un clone classique, mais avec la véritable application, contournant ainsi la plupart des méthodes de double authentification.

Le principe pour l’attaquant est de se placer au milieu de l’interaction entre sa victime et l’application légitime (pour résumer : en position de « man-in-the-middle ») comme sur le schéma ci-dessous :

Comme vous l’aurez remarqué, le domaine malveillant (« combosquatté ») que nous avons choisi est webmail–gandi.net qui usurpe le sous-domaine légitime webmail.gandi.net qui héberge la page de connexion légitime. En proxifiant le trafic entre la victime et l’application légitime, l’attaquant peut récupérer les identifiants de connexion, y compris les codes de double authentification s’il y en a.

Une fois le serveur malveillant configuré, la fausse page de connexion se présente comme suit :

Et voilà ! Il ne nous reste plus qu’à envoyer les SMS en utilisant un prétexte pertinent et convaincant pour inciter les destinataires à se connecter à la fausse webmail.

Exécution et analyse

En combinant tout ce que l’on vient de voir, voici à quoi l’attaque pourrait ressembler :

Le résultat est plutôt réaliste, mais ne nous laissons pas avoir si vite et passons en revue les quelques indices dont nous avons parlé dans cet article :

• L’ID expéditeur est « Koogivi » et non un numéro de téléphone classique. C’est certainement l’élément le plus convaincant du prétexte, mais comme nous l’avons dit plus haut, l’identité affichée au destinataire du SMS n’est pas une preuve infaillible.
• Le prétexte quant à lui joue sur la notion d’urgence de manière assez évidente (avec « [IMPORTANT] » et « quickly ») et sera d’autant plus crédible si Koogivi a l’habitude de communiquer par SMS avec ses employés. Si ce n’est pas le cas, un email sera peut-être plus efficace qu’un SMS (cela dit, pas forcément, en modifiant un peu le message pour prétexter une indisponibilité du service de messagerie, le choix du vecteur prendrait plus de sens). Dans tous les cas, le bon réflexe (plus facile à dire qu’à faire je vous l’accorde) serait de contacter le service IT de Koogivi pour s’assurer de la légitimité de la demande et en utilisant de préférence un canal alternatif (en personne ou par mail par exemple).
• Enfin le lien pointe sur un domaine mêlant combosquatting (combinaison de « gandi.net » qui est le domaine légitime et d’un mot clé pertinent avec le prétexte, à savoir « webmail » dans ce cas) et typosquatting (le sous-domaine légitime est « webmail.gandi.net » alors que le domaine malveillant est « webmail-gandi.net »). Le bon réflexe ? Porter son attention sur le nom de domaine (pensez « TLD + 1 ») qui dans notre cas est « webmail-gandi.net » et non simplement « gandi.net » (pour les plus aventureux, une rapide recherche WHOIS sur ce nom de domaine permet de voir que webmail-gandi.net n’est pas un domaine enregistré par la société « Gandi SAS »).

Comment se protéger contre le smishing (et le phishing en général) ?

Pour finir, récapitulons les quelques règles d’hygiène anti-*ishing que nous venons de voir.

Rapide parenthèse : pourquoi « *-ishing » ? Parce que les bonnes pratiques qui vont suivre sont applicables à pratiquement tous les vecteurs d’ingénierie sociale – que ce soit du phishing par email, par SMS (donc plus précisément du Smishing), par Teams ou par la poste (et j’en passe). Fermer la parenthèse.

De manière générale, nos recommandations couvrent principalement deux axes : un volet de sensibilisation et un volet orienté technique.

Sensibilisation aux risques

Commençons par les bons réflexes auxquels tous les collaborateurs doivent être sensibilisés. Tout d’abord, pour détecter les attaques de Smishing, il faut systématiquement prendre le temps d’analyser les indices clés, à savoir :

• L’identité de l’expéditeur : qui m’envoie ce message ? Comme nous l’avons vu, il peut s’agir d’un numéro de téléphone (peut-être même un contact déjà enregistré) ou une marque (type « LCL » ou « Koogivi »). Dans tous les cas, il ne faut pas s’y fier aveuglément. Surtout si la demande est sensible, il vaut mieux prévenir que guérir et contacter l’expéditeur supposé – s’il n’est pas totalement inconnu au bataillon (auquel cas, il va sans dire qu’il vaut mieux passer son chemin et ignorer voire supprimer le SMS) ; de préférence en utilisant un canal alternatif pour s’assurer que la demande est bien légitime (par mail par exemple ou en personne si possible).
• Le prétexte (et au-delà l’action demandée) : la demande est-elle sensible – peut-elle avoir des répercussions de sécurité (paranoïa est-tu là) ? Par exemple, me demande-t-on de me connecter quelque part en suivant un lien donné ou me demande-t-on de télécharger un fichier sur mon ordinateur ? Quelles astuces psychologiques sont utilisées pour m’inciter à l’action ? Y a-t-il une notion d’urgence notamment ? Attention tout de même ! Je ne dis pas qu’une demande sensible indique nécessairement une tentative de *-ishing, mais qu’il faut être vigilant dès qu’une action sensible nous est demandée par SMS, par email, par téléphone ou autre.
• Le lien (ou les liens) : qu’il semble pointer vers un site interne (usurpant un domaine de l’entreprise) ou vers un site externe (par exemple la webmail Gandi ou OVH), il faut prendre un peu de temps pour se demander si le nom de domaine (le fameux « TLD + 1 ») est légitime ou non. Avoir en tête les astuces courantes (typosquatting, combosquatting, modification du TLD, etc.) qu’utilisent les attaquants peut certes s’avérer utile, mais le meilleur réflexe est sans doute de ne pas suivre un lien reçu par SMS (mail ou autre) et de préférer utiliser les favoris de notre navigateur (encore faut-il en avoir au moins pour les applications courantes). Un autre bon réflexe à adopter, par exemple avant de rentrer ses identifiants quelque part, est de toujours vérifier dans la barre de navigation l’adresse de l’application sur laquelle le lien nous a redirigé après avoir cliqué – le mieux étant de ne pas cliquer évidemment, mais si clic il y a, ce n’est pas (encore) trop tard tant que le formulaire de connexion n’est pas envoyé. Des différences (plus ou moins subtiles) dans l’interface peuvent (et doivent) aussi alerter. Pour la petite anecdote, il peut nous arriver de désactiver certains boutons de l’interface pour forcer telle ou telle action.

L’erreur est humaine et il suffit que le prétexte résonne avec ce que la destinataire attend ou est en train de faire pour que l’attaque réussisse. Vous ne me croirez peut-être pas, mais tout le monde peut se faire avoir et je dirais même plus : adopter cet état d’esprit est un des moyens les plus sûrs de rester vigilant et de ne pas pécher par excès de confiance. Dans tous les cas, il faut également sensibiliser les collaborateurs aux bons réflexes pour réagir en cas d’attaque :

• La communication est clé. Lors d’une attaque, prévenir ses collègues pour leur éviter de se faire piéger par exemple peut faire la différence. Pour la petite histoire, lors d’une campagne de phishing, un de nos clients nous a fait part d’avertissements sur Slack échangés en interne quelques minutes seulement après l’envoi des emails. Excellent réflexe ! Il va sans dire que pour que cela fonctionne, il faut toutefois que des moyens de communication soient déjà en place et que les collaborateurs aient l’habitude de les utiliser.
• La communication pendant l’attaque est importante, mais la communication après l’attaque l’est au moins autant. Par exemple, si un collaborateur rentre ses identifiants là où il n’aurait pas dû (certes encore faut-il le savoir), il faut réagir au plus vite pour empêcher que la compromission ne se propage. Révoquer la session compromise (en se déconnectant) et changer son mot de passe sont de bons réflexes, tout comme prévenir le service technique pour qu’ils puissent investiguer en est un autre. Dans tous les cas, ne rien faire avantage l’attaquant. Encore une fois, pour que cela fonctionne, il est nécessaire qu’il y ait une culture de bienveillance pour ne pas stigmatiser les collaborateurs. Tout le monde peut se faire avoir (et statistiquement certaines attaques réussiront, il faut s’y préparer).

Mesures techniques anti-phishing

Maintenant que nous avons vu les éléments de sensibilisation à destination des collaborateurs, passons aux mesures techniques permettant de réduire le risque de smishing :

• Mettre en place la double authentification sur les applications sensibles. Bien que certaines techniques permettent de la contourner (phishing en man-in-the-middle par exemple), sécuriser l’authentification avec un second facteur reste une étape indispensable. Si l’attaquant met la main sur des identifiants– par un moyen quelconque (phishing par clone, fuite de donnée, achat sur le dark web par exemple) – le mot de passe seul ne suffira pas en présence de la double authentification.
• Utiliser un gestionnaire de mot de passe (type 1Password, KeePass, etc.) permettra d’avoir des mots de passe robustes et uniques par plateforme. Outre la robustesse, la non-réutilisation des mots de passe est importante, car dans le cas contraire, si un attaquant récupère un mot de passe (valide sur n’importe quel site), il peut potentiellement s’en servir pour compromettre plusieurs comptes (sur des sites complètement différents). La possibilité d’associer les identifiants générés permet aussi indirectement de détecter les sites frauduleux comme le montre la capture suivante où l’identifiant (de test) est proposé par l’extension navigateur du gestionnaire de mots de passe sur le site légitime (à gauche), mais pas sur le site malveillant (à droite) :

Comme on peut le voir, le gestionnaire de mots de passe supporte également l’authentification multifacteur (le code 2FA sera généré par 1Password dans ce cas). Pour parler plus spécifiquement du smishing, la mise en place d’un gestionnaire de mots de passe sur mobile dépend des accès souhaités. Il est peut-être préférable que certaines applications ne soient accessibles que depuis un ordinateur par exemple.

La distinction entre téléphone professionnel et personnel doit être également prise en compte. Il n’est pas souhaitable que les mots de passe d’applications sensibles soient stockés sur un appareil personnel, sans doute moins sécurisé qu’un appareil à usage professionnel.

Pour conclure, certains bons réflexes doivent être adoptés par tous les collaborateurs dans un climat bienveillant. En parallèle, des mesures techniques permettent de limiter le risque de smishing et plus globalement de phishing.

Auteur : Benjamin BOUILHAC – Pentester @Vaadata