Cyberattaque ou panne informatique ? Comment faire la différence avant qu’il ne soit trop tard

Introduction

Face à un service qui rame, des partages de fichiers inaccessibles ou des utilisateurs qui ne parviennent plus à s’authentifier, beaucoup d’entreprises hésitent : panne ou attaque ? Cette confusion coûte cher. Une panne se règle avec des gestes techniques classiques. Une attaque, elle, exige une réaction immédiate, documentée et coordonnée — isoler, préserver les preuves, activer la chaîne d’escalade. Dans cet article, on vous donne des critères simples, un arbre de décision et un protocole des 10 premières minutes pour réduire le risque.

1) Pourquoi on confond encore en 2025

1. Les symptômes se ressemblent (indisponibilités, lenteurs, erreurs d’authentification).
2. Les environnements sont hybrides (on-prem + cloud) : une défaillance côté SaaS peut imiter une attaque locale.
3. Les campagnes d’attaque sont industrialisées et silencieuses (mouvements latéraux, exfiltration low-and-slow).
4. Les équipes IT ne sont pas toujours formées à la gestion d’incident sécurité (IR) et mélangent correctifs classiques et actions forensiques.

À retenir : si vous appliquez des correctifs « panne » à une attaque active, vous risquez d’effacer des preuves, d’alerter l’attaquant… et d’aggraver l’impact.

2) 10 signaux qui orientent vers une cyberattaque

1. Fichiers chiffrés / extensions anormales / notes de rançon.
2. Appels réseau sortants inhabituels (pics de trafic vers l’étranger, ports atypiques).
3. Comptes avec élévation de privilèges récents, non justifiés.
4. Multiples échecs d’authentification (ou MFA « fatigue », rafales de prompts).
5. Outils de sécurité désactivés (EDR, antivirus, journaux coupés).
6. Tâches planifiées ou scripts inconnus apparus récemment.
7. Création/usage de comptes « backdoor ».
8. Hashes/processus correspondant à des familles connues de malwares.
9. Alertes corrélées (EDR, pare-feu, portail mail) sur une même période.
10. Tentatives de suppression de sauvegardes ou d’instantanés.

3) 10 signaux qui orientent vers une panne

1. Changement programmé (maintenance, mise à jour réseau).
2. Logs de service indiquant un crash applicatif reproductible.
3. Saturation matérielle (CPU/mémoire/disque) corrélée à une charge légitime.
4. Équipement réseau défaillant (alimentation, ventilateurs, ports).
5. Certificat expiré ou DNS mal propagé.
6. Quota atteint (boîtes mail, stockage).
7. Incident côté fournisseur cloud/SaaS public.
8. Erreur humaine documentée (mauvaise règle ACL, route).
9. Aucune élévation de privilège ni tentative d’accès suspecte.
10. État « propre » des agents de sécurité (EDR, SIEM, journaux complets).

4) L’arbre de décision en 3 étapes (ultra-pratique)

Étape A — Isoler & observer (5 minutes)

1. Segmenter/vlaner le poste/serveur suspect sans couper l’alimentation.
2. Geler les actions utilisateurs, ne pas redémarrer.
3. Photographier l’écran, noter l’heure exacte, préserver la RAM si outillage présent.

Étape B — Qualifier (5 à 15 minutes)

1. Vérifier logs d’authentification et EDR : pics d’échecs, nouveaux privilèges, services stoppés.
2. Relever connexions sortantes anormales (pays, ports, volume).
3. Rechercher indicateurs de compromission (hash, noms de tâches, clés de registre, artefacts connus).

Étape C — Décider

1. ≥1 IOC fort + activité anormale ? Traiter comme attaque.
2. Aucun IOC, cause technique claire et reproductible ? Orientation panne.
3. Doute ? Traiter comme attaque et escalader vers le SOC.

5) MTTD & MTTR : les métriques qui sauvent votre ROI

1. MTTD (Mean Time To Detect) : temps de détection.
2. MTTR (Mean Time To Respond/Recover) : temps de réponse/retour à la normale.
3. Objectif PME : réduire MTTD avec un SOC managé (surveillance 24/7, corrélation) et standardiser la réponse pour comprimer le MTTR (procédures, automatisation, playbooks).

6) Le protocole des 10 premières minutes (à coller au mur)

1. Isoler le périmètre affecté (réseau/port/sous-réseau).
2. Interdire les redémarrages sauvages.
3. Photographier/filmer l’écran si messages d’erreur/rançon.
4. Capturer l’heure, l’utilisateur, l’hôte, l’IP.
5. Préserver les journaux (SIEM, pare-feu, EDR).
6. Appeler la cellule de crise (IT + direction + correspondant légal).
7. Noter tous les gestes réalisés (pour le rapport).
8. Vérifier l’intégrité des sauvegardes déconnectées.
9. Prévenir le SOC / prestataire sécurité.
10. Préparer la communication interne (éviter la panique et les fuites d’info).

7) Gouvernance & preuves

1. Un registre d’incident (IRIS/équivalent) centralise faits, horodatage, décisions.
2. Preuves : copies de journaux, artefacts, captures d’écran, hachages.
3. Conformité : RGPD (violation potentielle de données ?), délais de notification (CNIL, clients) si impact confirmé.

Conclusion

1. La règle d’or : en cas de doute, traitez comme une attaque. Une panne supporte l’investigation, une attaque n’attend pas. Standardisez vos gestes, mesurez MTTD/MTTR, entraînez-vous.