Mois : juillet 2026

Depuis le début du mois de juillet 2026, une campagne de phishing d’envergure cible les clients du service Easy Hebergement. Les emails, envoyés depuis des infrastructures légitimes compromises (Amazon SES) et signés DKIM, imitent nos communications.
L’objet du message — « Au sujet de [votre-domaine] » — joue sur l’urgence : le domaine du destinataire serait sur le point d’être réservé par un tiers. Une technique classique d’ingénierie sociale qui exploite la peur de perdre un nom de domaine.

Anatomie de l’email piégé

L’email est structuré en deux parties : une version texte brut et une version HTML riche. La version HTML immite les codes visuels d’Easy Hebergement — barre sombre en en-tête, bouton d’appel à l’action arrondi, tableau de synthèse — pour inspirer confiance. L’URL de phishing est dissimulée derrière le texte du bouton « Consulter ». Voici le lien vers lequel pointe ce bouton :

L’URL utilise la plateforme Vercel (vercel.app), un service légitime d’hébergement serverless, ce qui lui permet de passer inaperçue aux yeux des filtres anti-spam basiques. Le jeton token contient un identifiant unique de victime, prouvant qu’il s’agit d’une campagne ciblée et non d’un envoi de masse aveugle. Les paramètres dn (domain name), pid (product ID) et sp (support language) suggèrent que l’attaquant a préparé une page de destination dynamique adaptée à chaque victime.

Des infrastructures légitimes détournées

Plusieurs éléments techniques rendent cette campagne particulièrement dangereuse. L’email transite par Amazon SES (Simple Email Service), un service d’envoi massif réputé, et les en-têtes DKIM sont correctement signés, ce qui fait que le message passe les contrôles SPF, DKIM et DMARC sans encombre. L’adresse d’expéditeur est noreply@chibakei-crm.com, un domaine qui n’a aucun lien avec Easy Hebergement. Les serveurs SMTP utilisés sont localisés en ap-northeast-1 (Tokyo), ce qui éloigne les traces des enquêteurs européens.

Comment protéger vos clients et votre marque

Face à une campagne aussi sophistiquée, la sensibilisation est primordiale. Voici quelques réflexes à adopter :

• Vérifier l’expéditeur. Easy Hebergement n’envoie jamais d’emails depuis un domaine tiers comme chibakei-crm.com. Les communications officielles proviennent toujours de @easy-hebergement.fr.
• Ne jamais cliquer sur un lien par urgence. Saisissez manuellement l’URL de votre interface de gestion dans votre navigateur.
• Survolez les liens (sur desktop) avant de cliquer pour vérifier la destination réelle.
• Signalez tout email suspect à Easy Hebergement via leur canal officiel.

Les URLs malveillantes identifiées dans cette campagne (présentées à titre informatif, ne pas cliquer) :

Easy Hebergement vous confirme qu’aucune de ces URLs ne fait partie de son infrastructure légitime.Nous recommandons à tous ses clients de changer leur mot de passe immédiatement s’ils ont cliqué sur l’un de ces liens.

Conclusion : la cybersécurité est l’affaire de tous

Cette campagne de phishing illustre une tendance de fond : les attaquants n’ont plus besoin de logiciels malveillants complexes quand un email bien conçu suffit à tromper un utilisateur pressé. L’utilisation de services légitimes (Amazon SES, Vercel) et de signatures DKIM valides rend la détection technique difficile. La meilleure défense reste la formation des collaborateurs et des clients : savoir reconnaître les signes d’un email frauduleux, résister à l’urgence artificielle, et toujours privilégier une connexion directe au site officiel. Easy Hebergement a mis en ligne une page d’information dédiée et renforcé ses dispositifs de surveillance. Restez vigilants.

Article rédigé à titre préventif. Les URLs présentées sont des exemples réels issus de la campagne en cours. Ne pas cliquer. Ne pas partager.

Date de l’incident : 23 juillet 2026 Durée
: 3h19 (16:49 → 20:08 CEST) Impact : Perte de
connectivité sur le VLAN 1234 pour les usages concernés Gravité
: Moyenne

TL;DR

Un switch de coeur de réseau (QFX) est tombé en panne de manière
silencieuse : ses ports restaient actifs physiquement,
mais l’équipement ne répondait plus et ne transitait plus le trafic. Les
routeurs voisins, n’ayant aucun mécanisme de détection de cette panne,
ont continué à envoyer du trafic vers une destination qui n’existait
plus. Résultat : du blackholing — le trafic partait
vers le néant.

La timeline

      16:49  ── Alerte détection incident
  │
  ├── 16:55 ─── 1er ingénieur prend en main
  ├── 17:10 ─── Diagnostic : switch ne répond plus
  │              (ni console RS232, ni SSH/IP)
  ├── 17:30 ─── 2ème ingénieur mobilisé
  ├── 18:00 ─── 3ème ingénieur mobilisé
  ├── 18:15 ─── Ingénieur sur site au datacentre
  │              (vérification physique)
  ├── 18:45 ─── Identification du blackholing
  │              sur core02.pa2.par
  ├── 19:15 ─── Création de routes statiques
  │              more-specific sur core02
  ├── 19:45 ─── Trafic rétabli sur VLAN 1234
  └── 20:08 ─── Incident résolu

L’architecture (simplifiée)

Avant l’incident

                    INTERNET
                       │
                       │ BGP
                       │
          ┌────────────┴────────────┐
          │                         │
    ┌─────┴─────┐            ┌──────┴─────┐
    │ core01    │   OSPF/    │ core02     │
    │   EX      │◄──BGP────► │   EX       │
    │           │  (inactif) │            │
    └─────┬─────┘            └──────┬─────┘
          │                         │
          │                         │
    ┌─────┴─────────────────────────┴─────┐
    │              qfx32.pa2.par          │
    │                 (QFX)               │
    │              ✅ Actif               │
    └─────────────────┬───────────────────┘
                      │
              VLAN 1234 / 2345 / 3456
                      │
                ┌─────┴─────┐
                │  Serveurs │
                └───────────┘

Pendant l’incident

                    INTERNET
                       │
                       │ BGP
                       │
          ┌────────────┴────────────┐
          │                         │
    ┌─────┴─────┐            ┌──────┴─────┐
    │ core01    │            │ core02     │
    │ ✅ OK     │            │ ⚠️ Reçoit   │
    │           │            │ du trafic  │
    └─────┬─────┘            └──────┬─────┘
          │                         │
          │                         │
    ┌─────┴─────────────────────────┴─────┐
    │          ❌ qfx32.pa2.par           │
    │         (PANNE SILENCIEUSE)         │
    │      Ports UP mais ne répond plus   │
    └─────────────────┬───────────────────┘
                      │
              💀 BLACKHOLING
              (trafic jeté dans le vide)
                      │
                ┌─────┴──────┐
                │  Serveurs  │
                │INJOIGNABLES│
                └────────────┘

Pourquoi c’est arrivé ?

1. La panne silencieuse

Le switch

qfx32.pa2.par

présentait un défaut rare mais critique :

Point clé : Les équipements voisins voyaient
toujours des ports actifs. Aucun mécanisme n’a signalé la
défaillance.

2. Le split-brain VRRP

       core01                          core02
    ┌───────────┐                 ┌───────────┐
    │  VRRP     │                 │  VRRP     │
    │  MASTER   │ ◄── Conflit ──► │  MASTER   │
    │  (croit)  │                 │  (croit)  │
    └───────────┘                 └───────────┘
         │                              │
         └──────────┬───────────────────┘
                    │
            Les DEUX routeurs
            sont "master"
            en même temps

Normalement, le VRRP fait qu’un seul routeur est master. Ici, comme
aucune interface physique n’est tombée (les ports du
QFX étaient restés UP), le mécanisme de bascule ne s’est jamais
déclenché.

3. Le blackholing

   core02 reçoit du trafic
           │
           ▼
   core02 cherche une route
           │
           ▼
   Route trouvée via qfx32
           │
           ▼
   qfx32 ne transite plus
           │
           ▼
   💀 Trafic jeté dans le vide

La résolution

Étape 1 : Isoler core02

On a voulu tout rediriger vers core01. Mais problème
:

              core02
    ┌──────────────────────────┐
    │                          │
    │   VLAN 1234 ──► qfx32    │  ← On peut couper
    │                          │
    │   VLAN 2345 ──► machines │  ← On NE PEUT PAS couper
    │   VLAN 3456 ──► machines │  ← (machines directes)
    └──────────────────────────┘

Étape 2 : Routes statiques more-specific

# Sur core02.pa2.par
# Créer des routes /32 plus précises que la route générale
# pour rediriger le trafic vers core01

routing-options static route 192.168.1.10/32 next-hop core01.ip
...

Principe : Une route plus précise (/32) est toujours
prioritaire sur une route générale (/24). Cela permet de rediriger le
trafic des machines impactées vers core01 sans toucher
aux machines connectées directement à core02.

Les enseignements

Ce qui a bien fonctionné

• ⏱️ Temps de réaction : 6 minutes entre l’alerte et la prise en
  main
• 👥 Mobilisation de 4 ingénieurs rapidement
• 🏢 Ingénieur sur site en 1h26 (région parisienne)
• 🔧 Résolution par routes statiques (solution temporaire mais
  élégante)

Ce qui a mal fonctionné

• ❌ Pas de détection de panne silencieuse
• ❌ Lien OSPF/BGP entre core01 et core02 inactif depuis le
  11/03/2026
• ❌ VRRP en split-brain (les deux routeurs master)
• ❌ Architecture non réellement redondante

Actions correctives

Le mot de la fin

« Il n’existe pas de correctif simple en l’état. Rendre l’ensemble
réellement résistant à la panne d’un équipement passerait par une
révision de l’architecture, pour la simplifier et la rendre plus
cohérente. »

La leçon principale : la redondance ne sert à rien si les
mécanismes de bascule ne fonctionnent pas. Un équipement en
panne silencieuse est plus dangereux qu’un équipement franchement
éteint, car il est invisible aux systèmes censés le compenser.

Merci à Mediactive networks pour leur soutien pour la résolution de
l’incident et pour le travail à venir. Notre objectif reste d’offrir à
tous nos clients (mutualisé, infogéré, cloud) un service de qualité,
stable et résilient.