Hameçonnage en tant que service

Introduction

Dans cet article, je vais traiter de l’hameçonnage en tant que service, communément appelé Phishing-as-a-Service (PhaaS) en anglais.

Souvenez-vous, fin des années 1990, début 2000, une petite révolution technologique, l’arrivée du SaaS (Software as a Service). Adopté progressivement il est maintenant incontournable surtout depuis l’arrivée des connexions Internet haut débit.

Aujourd’hui, selon certaines études, les applications SaaS représentent 90 % des applications utilisées par les entreprises. Les entreprises ont donc largement migré vers ce type d’application car ce modèle propose quelques avantages tels que :

• Coûts prévisibles

• Accessible de partout.

• Mises à jour automatiques

• Évolutif

• Collaboration simplifiée

Qu’est-ce que le PhaaS ?

Le PhaaS (Phishing-as-a-Service) utilise la même approche que le SaaS, il a donc plus ou moins les mêmes avantages avec un petit quelque chose de plus comme la limonade 🥃 de Kevin Parent.

Ce petit quelque chose est son fonctionnement malicieux puisqu’il s’agit finalement d’une plateforme utilisée pour lancer des campagnes de phishing.

Un cybercriminel avec peu ou pas de compétences techniques achète ou s’abonne à ce service via le Dark Web pour mener ces activités criminelles.

Exemple concret / Cas réel

LabHost PhaaS [1] actif depuis 2021 ;

EvilProxy [2] actif depuis 2022 ;

Caffeine [3] actif depuis 2022 ;

Greatness [4] actif depuis 2022 ;

Whisper 2FA [5] très actif depuis juillet 2025 ;

Toutes ces plateformes offrent des fonctionnalités similaires qui permettent d’hijacker une session (réutilisation des cookies de session), d’intercepter ou de faire de la redirection pour contourner le MFA, d’automatiser la génération et la rotation de domaines/subdomaines avec certificats TLS valides (Let’s Encrypt ou similaire), d’offusquer son IP d’origine derrière des proxy/cloud, etc.

Comment s’en protéger / Bonnes pratiques

Les PhaaS modernes s’appuient sur le recours à un proxy en direct. En pratique, cela signifie que les méthodes MFA classiques qui se basent sur l’emploi d’un TOTP et OTP unique, ou d’un code transmis par SMS, sont exposées à des vulnérabilités. Habituellement, la vulnérabilité exploitée est une redirection ouverte (Open Redirect).

À l’heure actuelle, une contre-mesure efficace consiste à recourir à FIDO2 / passkeys / clés matérielles telles qu’une Yubikey ou un dispositif similaire associée à un développement Security by Design, incluant un processus SDLC (Software Development Life Cycle) sur la coche.

Une attaque ciblée vers une entreprise qui n’offre que du MFA classique sans aucun durcissement du code applicatif aura probablement un taux de réussite élevé. ⚠️

Conclusion

À la lumière de cet état de fait, quel serait le niveau de risque résiduel concernant l’accès à une solution SaaS à l’aide d’une identité selon le contrôle MFA déployé ?

SMS MFA seul : ✅ protège contre les attaques simples de mot de passe

SMS MFA seul : ❌ inefficace contre le phishing proxifié / PhaaS en temps réel

Le risque résiduel est donc évalué entre élevé et très élevé, selon la criticité de l’actif, le profil lié à l’identité ciblée. (Bureautique, Bureautique avec profil privilégié, etc.), la robustese du code.

Il est donc nécessaire de s’assurer de déployer des mesures supplémentaires comme FIDO2 par exemple.

Alors oui, la mise en place du durcissement (hardening) comme nonce + horodatage [6] est efficace mais uniquement lors d’une tentative de replay.

Ce type de durcissement n’offre pas de protection fiable contre un proxy en temps réel (PhaaS), malheureusement.

Partagez-vous mon analyse ?