ClickFix — Audit de sécurité et investigation post-incident
Détection d'une attaque ClickFix sur un site culturel tiers, investigation complète et audit de sécurité post-incident
Contexte de réalisation
Une réalisation sans mandat
Cette réalisation n'a pas été commandée. Personne ne m'a rien demandé. Je suis tombée sur l'incident en visitant le site en tant qu'abonnée, un matin de mai 2026, et j'ai choisi d'agir.
C'est ce qui la distingue de la quasi-totalité des autres réalisations de ce portfolio, qui s'inscrivent dans une commande — un stage, un CDC (Cahier Des Charges), une demande formalisée. Ici, le déclencheur vient de moi. Le cadre d'intervention, je l'ai construit moi-même. Les livrables, je les ai produits sans filet et sans interlocuteur technique.
Cette posture a un nom dans le monde de la cybersécurité : la responsible disclosure (divulgation responsable), aussi appelée coordinated vulnerability disclosure (divulgation coordonnée de vulnérabilité). Elle consiste à trouver une faille ou une compromission, à contacter l'organisation concernée en privé avec tous les éléments pour agir, et à ne pas rendre l'information publique avant qu'elle soit corrigée. C'est exactement ce que j'ai fait : rapport détaillé envoyé à l'équipe éditoriale du site concerné, enseignants en copie, aucune publication.
Cette pratique s'inscrit dans l'esprit de l'OWASP (Open Web Application Security Project — Projet Ouvert sur la Sécurité des Applications Web), une organisation mondiale à but non lucratif dont la mission est d'améliorer la sécurité du web par la contribution collective et ouverte — sans mandat, sans rémunération obligatoire. L'injection de script détectée sur le site concerné correspond précisément à la catégorie A03 — Injection du référentiel OWASP Top 10, et plus spécifiquement à une forme de XSS (Cross-Site Scripting — Script Inter-Sites) : du code malveillant injecté dans une page pour s'exécuter dans le navigateur des visiteurs.
Cette posture extérieure explique aussi pourquoi certaines compétences du référentiel E5 ne sont pas cochées. Des sous-entrées comme mettre en place les niveaux d'habilitation, gérer des sauvegardes ou vérifier le respect des règles d'utilisation internes supposent d'être prestataire ou technicien au sein d'une organisation — d'avoir un périmètre confié. Je n'avais pas ce périmètre. Ce que j'avais, c'est une observation, une méthode, et le choix d'agir.
Compétences E5 mobilisées
1.1 ✅ Recenser et identifier les ressources numériques
Inventorier les composants du système d'information (matériels, logiciels, données, services) et les documenter pour en assurer la traçabilité et la gestion.
J'ai recensé l'ensemble des ressources numériques potentiellement exposées par l'incident : le navigateur et ses 8 extensions, les connexions réseau actives, les processus en mémoire, les logiciels installés, les fichiers récents et l'historique PowerShell (l'interface de ligne de commande de Windows). Ce recensement structuré en 7 points est la base de l'audit documenté dans l'annexe.
1.2 ✅ Exploiter des référentiels, normes et standards
S'appuyer sur des documentations officielles, des normes de qualité ou des standards techniques pour guider ses choix et garantir la conformité des solutions produites.
Pour identifier la technique et évaluer les risques réels, je me suis appuyée sur des publications de référence : Microsoft Security Blog, Fortinet, Stormshield, CIS (Center for Internet Security — Centre pour la Sécurité Internet). Ce sont les mêmes sources qu'un CERT (Computer Emergency Response Team — Équipe de Réponse aux Incidents de Sécurité Informatique) professionnel consulterait après un incident. C'est ce qui m'a permis de distinguer ce que le JS (JavaScript) pouvait faire seul de ce qui nécessitait l'exécution du script, et de structurer mes 7 vérifications en conséquence.
1.3 ❌ Mettre en place et vérifier les niveaux d'habilitation
Définir et contrôler qui a accès à quoi : droits, rôles, comptes utilisateurs — de façon à protéger les ressources tout en permettant le travail des personnes autorisées.
Non mobilisée dans cette réalisation. L'incident n'impliquait pas de gestion de comptes, de rôles ou de permissions.
1.4 ✅ Vérifier les conditions de la continuité d'un service
S'assurer qu'un service peut rester disponible ou être rapidement rétabli en cas d'incident, de panne ou d'intervention technique.
Après l'incident, j'ai vérifié que ma propre machine restait opérationnelle — c'est la continuité de mon outil de travail. Et j'ai transmis à l'équipe du site concerné les actions nécessaires pour rétablir un service sain : retrait du script injecté, rotation des mots de passe d'administration du CMS (Content Management System — Système de Gestion de Contenu) Ghost, activation du 2FA (Two-Factor Authentication — Authentification à Deux Facteurs), audit des logs serveur.
1.5 ❌ Gérer des sauvegardes
Mettre en place une stratégie de sauvegarde des données et des configurations, avec une procédure permettant de les restaurer en cas de perte ou de corruption.
Non mobilisée dans cette réalisation.
1.6 ⚠️ Vérifier le respect des règles d'utilisation
Contrôler que l'usage des outils et des systèmes est conforme aux règles définies : chartes, politiques de sécurité, obligations légales (RGPD, licences, etc.).
Non cochée au sens strict — je n'étais pas prestataire de l'organisation et je n'avais pas de politique interne à faire respecter. Mais j'ai bien vérifié une conformité : en m'appuyant sur les normes de sécurité web générales (un CAPTCHA — Completely Automated Public Turing test to tell Computers and Humans Apart — ne demande pas d'ouvrir un terminal ; un script externe ne s'injecte pas dans le code d'un CMS — Content Management System — tiers ; l'API — Application Programming Interface — navigator.clipboard.writeText() n'a rien à faire sur une page de biographie), j'ai identifié que le comportement du site constituait une violation de ces règles. Le référentiel était implicite mais réel : les normes communes du web.
2.1 ✅ Collecter, suivre et orienter des demandes
Recueillir les demandes des utilisateurs, les qualifier, les prioriser et les orienter vers la bonne ressource ou procédure de traitement.
J'ai reçu un signal d'alerte — le comportement suspect du site — et je l'ai traité de bout en bout : qualification de l'incident (ClickFix / pastejacking), investigation complète, documentation, puis orientation vers les personnes concernées (équipe du site par mail, enseignants en copie). L'incident a été collecté, instruit et transmis.
2.2 ❌ Traiter des demandes concernant les services réseau et système
Diagnostiquer et résoudre des incidents ou des demandes liés à l'infrastructure : réseau, système d'exploitation, serveurs, équipements physiques.
Non mobilisée dans cette réalisation. L'incident ne portait pas sur l'infrastructure réseau ou système.
2.3 ✅ Traiter des demandes concernant les applications
Diagnostiquer et résoudre des incidents ou des demandes liés aux applications : dysfonctionnement, anomalie, évolution fonctionnelle.
J'ai analysé une anomalie applicative — un script injecté dans une page web — en lisant le code source HTML, en décodant le JS (JavaScript) obfusqué par URL (Uniform Resource Locator) inversée, et en identifiant le fichier externe malveillant css.js chargé dynamiquement. C'est un diagnostic applicatif complet, mené sur pièces.
3.1 ❌ Participer à la valorisation de l'image
Contribuer à construire ou améliorer l'image de l'organisation sur le web, en tenant compte de son identité, de sa charte graphique et du cadre juridique applicable.
Non mobilisée dans cette réalisation.
3.2 ❌ Référencer les services en ligne
Mettre en œuvre des techniques de référencement (SEO, sitemap, structuration des URL) pour améliorer la visibilité des services en ligne dans les moteurs de recherche.
Non mobilisée dans cette réalisation.
3.3 ❌ Participer à l'évolution d'un site Web
Concevoir, modifier ou enrichir un site web en intégrant les données propres à l'organisation, dans le respect de ses besoins et contraintes techniques.
Non mobilisée dans cette réalisation. J'ai analysé le site compromis, pas modifié ni maintenu.
4.1 ✅ Analyser les objectifs et les modalités d'organisation d'un projet
Lire et comprendre un cahier des charges, identifier les contraintes, les acteurs et les ressources nécessaires avant de démarrer une réalisation.
Avant de lancer l'investigation, j'ai posé les bonnes questions dans l'ordre : le site est-il malveillant ou piraté ? À quel moment le script arrive dans le presse-papier ? Où est-il dans le code source ? Cette démarche structurée — observer, questionner, vérifier, conclure — est explicitement documentée section par section dans le rapport d'investigation.
4.2 ✅ Planifier les activités
Découper un projet en tâches, les séquencer dans le temps et organiser leur enchaînement pour atteindre les objectifs dans les délais impartis.
J'ai découpé le travail en étapes successives et dépendantes : identification de la technique, lecture du code source, décodage de l'obfuscation (camouflage du code malveillant), 7 vérifications d'audit sur ma machine, rédaction du rapport d'investigation, rédaction de l'annexe d'audit, envoi du mail à l'équipe du site. Chaque étape conditionne la suivante.
4.3 ✅ Évaluer les indicateurs de suivi d'un projet et analyser les écarts
Mesurer l'avancement réel d'un projet par rapport à ce qui était prévu, identifier les écarts et les causes de blocage, et ajuster si nécessaire.
J'ai défini des critères de résultat explicites pour chacune des 7 vérifications : soit un résultat ✅ clair (aucune trace suspecte), soit un ❌ qui aurait déclenché une action corrective. Le bilan final — "machine saine, 0 indicateur de compromission détecté" — est une évaluation explicite et documentée des indicateurs.
5.1 ❌ Réaliser les tests d'intégration et d'acceptation d'un service
Vérifier que les composants d'un service fonctionnent correctement ensemble et que le résultat correspond aux attentes exprimées avant mise en production.
Non mobilisée dans cette réalisation.
5.2 ❌ Déployer un service
Installer, configurer et mettre en production un service dans son environnement réel, de façon opérationnelle et sans interruption du service existant.
Non mobilisée dans cette réalisation.
5.3 ✅ Accompagner les utilisateurs dans la mise en place d'un service
Former, documenter ou guider les utilisateurs pour qu'ils puissent s'approprier un service et l'utiliser en autonomie.
J'ai rédigé deux documents destinés à une équipe non technique : un rapport d'investigation qui explique la chaîne d'attaque de façon accessible, et une annexe d'audit qui détaille chaque vérification avec le risque couvert et le résultat obtenu. J'ai aussi formulé 5 recommandations concrètes et actionnables pour que l'équipe puisse rétablir un service sain.
6.1 ✅ Mettre en place son environnement d'apprentissage personnel
Structurer les outils, méthodes et ressources qui permettent d'apprendre en faisant, de progresser de façon autonome et de capitaliser ses connaissances.
J'ai utilisé Claude.ai comme outil de réflexion structuré — pas pour écrire à ma place, mais pour formuler mes hypothèses, identifier la technique et décoder le script. Les deux conversations exportées (investigation ClickFix + Tout sur ClickFix) sont des traces concrètes de cette démarche d'apprentissage en situation réelle, un matin de mai 2026.
6.2 ✅ Mettre en œuvre des outils et stratégies de veille informationnelle
Identifier des sources fiables, les consulter régulièrement et exploiter les informations recueillies pour rester à jour sur les évolutions technologiques et professionnelles.
Pour conduire l'investigation, j'ai mobilisé des sources de veille en cybersécurité : Microsoft Security Blog, Fortinet, Stormshield, CIS (Center for Internet Security). Ce sont les mêmes sources qu'un professionnel consulterait après un incident — je les avais déjà en tête parce que je les suis dans le cadre de ma préparation à l'épreuve E7 (Cybersécurité).
6.3 ✅ Gérer son identité professionnelle
Construire et entretenir une présence numérique cohérente avec son parcours et ses compétences : portfolio, profil LinkedIn, livrables publics.
Cette réalisation est documentée sur mon portfolio praxis-debug.net. Elle illustre une posture professionnelle réelle : détection d'une menace en situation, investigation autonome, production de livrables soignés, alertage de l'organisation concernée. C'est de la cybersécurité appliquée, pas un exercice de cours.
6.4 ✅ Développer son projet professionnel
Analyser ses expériences pour identifier ses points forts, ses axes de progression et les compétences à acquérir en vue d'un objectif professionnel.
Cette situation m'a confrontée à une technique d'attaque que je ne connaissais pas — ClickFix / pastejacking. Je l'ai apprise en situation, pas en cours. Ça a confirmé mon intérêt pour la cybersécurité et m'a donné envie d'approfondir l'analyse de code malveillant et la réponse à incident — des domaines que je veux intégrer à mon projet professionnel.