24 juillet 2026Sécurité

Smishing : campagnes récentes contre les PME romandes et comment répondre

Les campagnes de smishing ciblant les PME suisses se multiplient depuis le second semestre 2024, avec des SMS imitant La Poste, les services fiscaux cantonaux et les banques. Voici ce que les DSI et RSSI romands doivent savoir pour détecter, contenir et notifier.

Par ZRS-Holding Sàrl·11 min de lecture·7 lectures
Partager

Un vecteur sous-estimé, des conséquences bien réelles

En novembre 2024, une fiduciaire vaudoise de 35 collaborateurs a vu trois employés cliquer sur un SMS imitant une notification de La Poste pour un colis bloqué. Le lien conduisait à une page de phishing collectant numéros de carte et identifiants e-banking. Résultat : deux comptes Microsoft 365 compromis, 4 600 CHF prélevés sur un compte d'entreprise, et une obligation de notification au Préposé fédéral à la protection des données (PFPDT) faute d'avoir pu exclure une exfiltration de données personnelles de clients.

Le phishing par SMS — smishing — représente aujourd'hui l'un des vecteurs d'entrée les plus efficaces contre les organisations de moins de 150 employés, précisément parce que la surface de contrôle est fragmentée : numéros mobiles personnels utilisés à des fins professionnelles, absence de filtre anti-spam dédié sur les réseaux mobiles, et confiance instinctive accordée au canal SMS.

Anatomie des campagnes récentes en Romandie

Vecteurs et leurres identifiés (2024-2025)

Le Centre national pour la cybersécurité (NCSC) a publié plusieurs alertes entre le T3 2024 et le T1 2025 signalant des vagues de smishing en Suisse romande. Les leurres documentés incluent :

  • Faux avis de livraison PostCH/DHL : URL raccourcies (bit.ly, tinyurl.com) redirigeant vers des pages imitant post.ch, avec collecte de numéro de carte pour frais de douane fictifs de 2,90 CHF.
  • Fausses notifications fiscales cantonales : SMS prétendant provenir du canton de Vaud ou de Genève, demandant la confirmation d'un RIB pour remboursement d'impôt. L'URL contient souvent le mot « ch » ou « vaud » pour tromper un regard rapide.
  • Usurpation d'identité bancaire : messages imitant UBS, Raiffeisen ou PostFinance signalant une transaction suspecte à valider via un lien. Ces campagnes ciblent les comptes d'entreprise, pas uniquement les particuliers.
  • Smishing RH : SMS envoyé à des responsables RH ou comptables, prétendant provenir du CEO ou d'un partenaire, demandant de valider un virement urgent ou de mettre à jour un IBAN dans le système de paie.

Techniques d'obfuscation et d'évasion

Les campagnes actuelles contournent les outils de filtrage classiques par plusieurs moyens. Les domaines utilisés ont une durée de vie courte (souvent moins de 48 heures), ce qui rend les listes noires peu efficaces. Le protocole HTTPS est systématiquement activé sur les faux sites (certificat Let's Encrypt obtenu en minutes), neutralisant le réflexe « vérifier le cadenas ». Certaines pages de phishing détectent l'User-Agent mobile et adaptent leur rendu ; d'autres redirigent les navigateurs desktop vers un site légitime, compliquant l'analyse statique.

Sur le plan téléphonique, les attaquants exploitent des SIM MVNO enregistrées hors UE ou des services de SMS bulk légitimes détournés, rendant le blocage opérateur difficile. Des campagnes utilisent également l'envoi depuis des numéros suisses avec indicatif +41, augmentant le taux de clic.

Cibles privilégiées dans le tissu économique romand

Les secteurs les plus touchés selon les signalements NCSC et les remontées terrain : fiduciaires et cabinets comptables (accès à des données fiscales sensibles et à des comptes multi-clients), cabinets médicaux et laboratoires (données de santé à haute valeur), bureaux d'études et ingénierie (propriété intellectuelle, accès VPN), et MSP (accès délégué à des dizaines d'environnements clients). Pour un attaquant, compromettre un MSP vaudois de 8 collaborateurs donnant accès à 40 PME clientes est beaucoup plus rentable que d'attaquer ces 40 PME individuellement.

Cadre légal : obligations sous la nLPD et au-delà

Qualification de l'incident au regard de la nLPD

La nouvelle Loi fédérale sur la protection des données (nLPD), en vigueur depuis le 01.09.2023, impose à tout responsable du traitement d'annoncer au PFPDT les violations de données susceptibles d'entraîner un risque élevé pour la personnalité ou les droits fondamentaux des personnes concernées, dans les meilleurs délais (art. 24 nLPD). La loi ne fixe pas de délai en heures, contrairement au RGPD européen (72 h), mais la pratique et l'interprétation du PFPDT convergent vers une notification rapide, idéalement sous 72 heures dès la connaissance de la violation.

Un incident smishing constitue une violation notifiable dès lors qu'un compte professionnel compromis contient des données personnelles de tiers (clients, patients, employés). Même si aucune exfiltration n'est confirmée, l'impossibilité de l'exclure techniquement suffit à déclencher l'obligation de notification. Les fiduciaires traitant des données fiscales de clients personnes physiques, et les cabinets médicaux, se trouvent systématiquement dans ce cas de figure.

Procédure de notification au PFPDT

  1. J+0 (détection) — Isolement du ou des comptes compromis, préservation des logs (accès, authentification, boîte mail). Le DSI ou RSSI documente l'heure exacte de détection.
  2. J+0 à J+1 — Analyse préliminaire : quels systèmes, quelles données, quelle fenêtre temporelle d'accès non autorisé ? Un inventaire même partiel est nécessaire avant notification.
  3. J+1 à J+3 — Rédaction de la notification sur le portail du PFPDT. Éléments requis : nature de la violation, catégories et volume de données concernées, conséquences probables, mesures prises et envisagées, coordonnées du responsable (ou DPO si désigné).
  4. J+3 max (sauf cas exceptionnels) — Envoi de la notification. Si l'analyse est incomplète, notifier avec les informations disponibles et compléter ultérieurement.
  5. J+3 à J+10 — Information des personnes concernées si le risque pour leurs droits est élevé (art. 24 al. 4 nLPD). Pour une fiduciaire, cela signifie contacter les clients dont les données ont potentiellement été exposées.
  6. Acteurs : DSI (technique), juriste ou DPO (qualification légale), direction (décision de notifier), RSSI si distinct du DSI.

Autres obligations réglementaires selon le secteur

Les établissements soumis à la FINMA (banques, assurances, gérants de fortune) ont des obligations de reporting complémentaires selon la Circulaire FINMA 2023/1 sur les risques opérationnels. Un incident smishing affectant un gérant de fortune indépendant doit être reporté à la FINMA si les seuils de matérialité sont atteints (impact financier, accès à des données clients). Les hôpitaux cantonaux et cliniques doivent en outre respecter les directives cantonales de protection des données sanitaires, qui peuvent imposer des délais plus courts.

Mesures de mitigation techniques et organisationnelles

Côté utilisateur et endpoints

La première ligne de défense reste le Mobile Device Management (MDM). Sur un parc de 50 smartphones gérés, la configuration minimale recommandée par les CIS Benchmarks pour iOS et Android inclut : blocage de l'installation d'applications hors stores officiels, application d'un PIN minimum 6 chiffres ou biométrie, et activation du filtre DNS anti-phishing au niveau du profil MDM. Sur iOS 17+, le mode de navigation privée Safari intègre désormais un avertissement pour les sites frauduleux connus, mais cela ne couvre pas les domaines créés dans les dernières 48 heures.

L'authentification multifacteur (MFA) résiste partiellement au smishing : un attaquant qui capture identifiants et code OTP via une page de phishing en temps réel (attaque MITM de type EvilProxy) peut tout de même s'authentifier. Les tokens matériels FIDO2/passkeys résistent à ce vecteur car le challenge est lié cryptographiquement au domaine légitime. Pour une PME de 50 employés, le passage complet aux passkeys Microsoft Entra ID ou Apple représente un chantier de 2 à 4 semaines selon la maturité de l'annuaire existant.

Côté réseau et messagerie

Le filtrage DNS (résolveurs sécurisés avec catégorisation de menaces) réduit significativement le taux de connexion aux domaines de phishing, y compris depuis les appareils mobiles connectés au Wi-Fi d'entreprise. En dehors du réseau d'entreprise — soit la majorité du temps pour les smartphones — le filtrage DNS doit être appliqué via le profil MDM (configuration de résolveur DoH ou DoT forcé). Les VPN split-tunnel peuvent servir à router le trafic DNS via le résolveur d'entreprise même hors réseau.

Sur les postes fixes, l'activation de Microsoft Defender SmartScreen (Windows 11) ou de la protection Safari contre le phishing (macOS 14 Sonoma) offre une couche supplémentaire, mais uniquement pour la navigation web, pas pour les clics depuis l'application SMS native.

Formation et procédures

Les exercices de simulation de smishing sont moins répandus que le phishing e-mail, alors que l'efficacité du vecteur SMS est supérieure (taux de clic moyen estimé entre 20 et 35 % vs 3 à 10 % pour l'e-mail selon plusieurs études sectorielles). Une simulation trimestrielle réaliste, basée sur les leurres actuellement actifs en Suisse romande (notifications PostCH, AFC), couplée à un debriefing immédiat, réduit significativement la réponse impulsive au message urgent.

La procédure interne de signalement doit être connue de tous : un employé qui reçoit un SMS suspect doit savoir à qui l'envoyer (DSI, RSSI, helpdesk) et dans quel délai. Un canal dédié (messagerie interne, adresse mail abuse@entreprise.ch) simplifie la remontée et permet une réaction sous 30 minutes.

Cas pratique : bureau d'études à Lausanne, 68 endpoints

Contexte

Un bureau d'études en génie civil basé à Lausanne, 68 collaborateurs dont 22 régulièrement en déplacement sur chantier avec smartphones professionnels (iOS 17, gérés via MDM). En janvier 2025, 4 collaborateurs reçoivent un SMS prétendant provenir de « SBB-CFF » les informant d'un remboursement de 18,50 CHF pour un billet annulé, avec un lien vers un domaine du type « remboursement-cff-ch[.]net ». Deux collaborateurs cliquent et saisissent leurs identifiants Microsoft 365.

Chronologie et procédure de réponse

  1. J+0, 14h22 — Le helpdesk reçoit un signalement d'un collaborateur qui a cliqué puis s'est ravisé. Le DSI est notifié. Vérification immédiate dans Microsoft Entra ID : sign-in logs des 4 utilisateurs concernés sur les 24 dernières heures. Deux connexions anormales depuis des IP géolocalisées en Roumanie et au Vietnam sont identifiées.
  2. J+0, 14h45 — Révocation forcée des sessions actives via PowerShell (Revoke-AzureADUserAllRefreshToken) pour les deux comptes compromis. Réinitialisation des mots de passe. Activation temporaire de l'accès conditionnel restreignant les connexions aux seuls pays Suisse/France/Allemagne.
  3. J+0, 15h30 — Extraction des logs de messagerie Exchange Online : vérification des règles de transfert créées, des e-mails envoyés depuis les comptes pendant la fenêtre de compromission (14h00-14h45). Aucune règle de transfert détectée ; 3 e-mails internes envoyés depuis un compte compromis, sans données sensibles apparentes.
  4. J+0, 16h00 — Analyse du contenu des boîtes mail concernées : les deux ingénieurs disposent d'accès à des plans de chantier et à des contrats clients (personnes morales). L'un d'eux traite également la facturation et dispose d'e-mails contenant des coordonnées bancaires de fournisseurs (personnes physiques indépendants).
  5. J+1, 09h00 — Réunion DSI + direction + juriste externe. Qualification : violation de données personnelles (coordonnées bancaires de 7 indépendants dans les e-mails accessibles pendant 45 minutes). Décision de notifier le PFPDT.
  6. J+2, 11h00 — Envoi de la notification au PFPDT via le formulaire en ligne. Parallèlement, contact individuel des 7 personnes concernées par courrier électronique signé par la direction, expliquant l'incident, la durée d'exposition et les mesures prises.
  7. J+5 — Déploiement d'une politique MFA renforcée : activation des passkeys pour tous les comptes M365 disposant d'accès à des données sensibles (22 comptes). Coût estimé : 0 CHF supplémentaire (fonctionnalité incluse dans Microsoft Entra ID P1, déjà licencié). Durée de déploiement : 3 jours ouvrés.
  8. J+10 — Formation de rappel smishing, 45 minutes, basée sur la simulation du leurre CFF utilisé dans l'attaque réelle. Taux de participation : 100 % (session obligatoire, 3 créneaux proposés).

Bilan financier de l'incident

Coût direct : 0 CHF de perte financière (aucun virement frauduleux). Coût indirect estimé : 14 heures de travail DSI/helpdesk (soit environ 2 100 CHF à 150 CHF/h), 3 heures de consultation juridique externe (750 CHF), et 6 heures de direction mobilisée (600 CHF). Total : environ 3 450 CHF pour un incident contenu rapidement grâce aux logs centralisés. Sans MDM ni journalisation des sign-ins, la fenêtre de détection aurait pu s'étendre à plusieurs jours, avec un coût potentiel bien supérieur.

Récapitulatif opérationnel

  • Activer la journalisation des connexions (Entra ID sign-in logs, Jamf, ou équivalent) sur tous les comptes avec rétention minimum 90 jours — condition sine qua non pour toute analyse post-incident.
  • Déployer le MFA résistant au phishing (FIDO2/passkeys) en priorité sur les comptes à accès sensibles (comptabilité, RH, direction, administrateurs IT). Les OTP SMS ou TOTP restent vulnérables au smishing en temps réel.
  • Configurer le filtrage DNS anti-phishing via le profil MDM pour les smartphones professionnels, actif hors réseau d'entreprise (DoH/DoT forcé).
  • Définir et diffuser une procédure de signalement interne connue de tous les collaborateurs : canal, délai (sous 30 minutes), destinataire. Tester cette procédure annuellement.
  • Planifier des simulations smishing réalistes trimestriellement, basées sur les leurres actifs en Suisse (PostCH, AFC, banques). Débriefing immédiat obligatoire.
  • Qualifier rapidement tout incident suspect au regard de la nLPD : dès qu'une exfiltration de données personnelles ne peut être exclue, notifier le PFPDT sans attendre la certitude — mieux vaut une notification préventive qu'une notification tardive sanctionnable.
  • Tenir un registre des incidents (date, vecteur, systèmes affectés, données en jeu, mesures prises) : obligation implicite de la nLPD et prérequis pour tout audit ou certification ISO 27001.
  • Vérifier les règles de transfert e-mail immédiatement lors de toute compromission de compte Microsoft 365 ou Google Workspace — c'est le premier réflexe des attaquants pour maintenir un accès discret.
  • Sensibiliser spécifiquement aux SMS professionnels : rappeler que ni La Poste, ni les banques, ni l'AFC ne demandent de coordonnées bancaires ou de validation de compte par SMS avec lien externe.
  • Documenter le processus de réponse à incident avant qu'un incident survienne : qui décide quoi, dans quel délai, avec quels outils d'analyse. Un runbook smishing de 2 pages vaut mieux qu'une improvisation sous stress.

Pour les PME romandes qui souhaitent auditer leur posture actuelle sur ces vecteurs, SynGuard propose des évaluations de parc endpoints adaptées aux organisations de 20 à 150 collaborateurs.

Sources

Noter cet article

Pas encore de note