Auteur : swiiptel - easy-hebergement - prosygma

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)               │
    │            [ OK ] 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   │
    └─────────────────┬───────────────────┘
                      │
              [XX] 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 :

Comportement	État
Ports physiques	✅ UP (LED allumées)
Console RS232	❌ Aucune réponse
Adresses IP	❌ Aucune réponse
Transit trafic	❌ Aucun
Détection par les voisins	❌ Invisible

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
...

---

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

---

Le mot de la fin

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.

Ou pourquoi le nos erreurs se voient parfois…

Ce soir (13 octobre 2025) un peu après 21h00, les sites du cluster1 ne répondaient plus.

Nous avons remis en route nos services manuellement un peu après 23h00 et souhaitions vous parler un peu de l’envers du décor dans un court article de blog.

Le cluster 1 qui connu une panne entre entre 21h00 et 23h30 repose pour son fonctionnement sur des centaines de milliers de ligne de code dans différents langages.

Certains scripts de maintenance passent leurs temps à récupérer les connexions pas fermées, les scripts php qui durent trop longtemps, les connexions sql trop longues ou trop nombreuses et encore une foule d’autres sujets que nos robots scrutent en permanence pour maintenir le service opérationnel.

Nous travaillons également en permanence à l’amélioration de nos infrastructures et procédons. Ces jours-ci nous réalisons des tests de continuité d’activité nous mettant d’être résilients sur des coupures électriques.

Ce soir, il ne s’agit pas d’une attaque, mais bien d’un bon vieux bug sur des scripts de maintenance qui n’ont pas pu faire leur office dû aux tests d’arrêt de certains systèmes.

Ces systèmes n’étant pas disponibles, ils ne pouvaient pas délivrer le service attendu. L’anomalie de ce soir nous a permis de déterminer l’origine de la faiblesse de ce script et d’y remédier.

Veuillez nous excuser pour la gêne occasionnée et soyez assurés que nous sommes dans une logique d’amélioration continue avec objectif de renforcer la sécurité et la résilience de nos services.

Cet incident a eu lieu sur le cluster1, le cluster2 qui héberge nos services cloud, les vds, les serveurs dédiés n’ont pas été touchés par cet incident.

Si vous avez des besoins spécifiques vous pouvez dès à présent disposer de nos services pour vous aider à définir une architecture cible de SI.
Exemple sur le schéma suivant avec un firewall dédié, un ou plusieurs services opérés dans un espace réseau dédié, un accès par VPN:

Contactez-nous pour un diagnostic et une étude:
– https://www.swiiptel.net,
– Ou https://www.easy-hebergement.fr/contact

Avec l’augmentation du volume de données échangées et traitées quotidiennement, de nombreuses entreprises constatent une saturation progressive de leurs bases de données. Le besoin d’augmenter leur capacité découle souvent de la croissance du trafic web (nombre de hits par heure), du nombre croissant d’utilisateurs connectés simultanément, et de la multiplication des services digitaux.

Par exemple, un site e-commerce peut voir ses requêtes exploser lors d’une campagne promotionnelle, entraînant des ralentissements ou des erreurs si la base de données n’est pas dimensionnée en conséquence. Pour garantir la fluidité de l’expérience utilisateur et éviter les interruptions de service, il devient donc indispensable d’élargir les ressources allouées.

Nous avons étendu la capacité de vos packs titane et ultimate pour refléter ce besoin. Vous disposez maintenant de bases de 5Go sur les packs ultimate et de 99k hits/heure avec 99 connexions simultanées.

En parallèle, les boîtes mail d’entreprise sont de plus en plus sollicitées, non seulement pour l’échange de messages, mais aussi pour le stockage de pièces jointes volumineuses (PDF, présentations, rapports, etc.).

Passer d’une capacité de 25 à 50 Go pour la messagerie permet aux collaborateurs de conserver un historique de leurs échanges sans devoir constamment archiver ou supprimer d’anciens messages.

Prenons l’exemple d’un cabinet de conseil : entre les documents contractuels, les livrables clients et les échanges internes, un consultant peut rapidement atteindre la limite de stockage, ce qui entraîne des blocages ou pertes de temps.

La capacité de base de vos boîtes mail est passée de 25Go à 50Go pour les packs titane et ultimate.

Pour commander votre pack titane ou ultimate c’est par ici:

https://www.easy-hebergement.fr/hebergement-mutualise

Nous sommes ravis de vous annoncer une mise à jour majeure sur nos infrastructures qui transforme votre expérience en tant qu’utilisateur de nos services d’hébergement web. Après des mois de planification et d’efforts techniques, nous avons procédé à une migration complexe, destinée à décupler ou plus la rapidité de vos sites web. Cette amélioration représente une avancée significative dans la performance et la fiabilité de vos plateformes en ligne.

Cette migration repose sur l’intégration de toutes dernières technologies en matière de serveurs et d’optimisation réseau. Grâce à des infrastructures modernes et à des systèmes de stockage ultra-rapides, vos sites bénéficieront de temps de réponse améliorés. Les pages s’afficheront rapidement, offrant à vos visiteurs une expérience utilisateur fluide, tout en améliorant votre référencement sur les moteurs de recherche.

Nous sommes conscients que ce type de transition peut engendrer des interrogations et, dans certains cas, des interruptions. Soyez assurés que notre équipe technique travaille jour et nuit pour minimiser l’impact de cette migration sur vos activités. Nous mettons tout en oeuvre pour que le processus se déroule de la manière la plus transparente possible.

Avec cette évolution, nous affirmons notre engagement à vous fournir un service d’hébergement de pointe, adapté à vos exigences. Nous vous remercions de votre confiance et restons à votre disposition pour répondre à vos questions ou vous accompagner dans cette transition. Ensemble, nous préparons l’avenir de vos sites web, avec des performances dignes des meilleurs.

Nous remercions nos partenaires dont Mediactive Networks qui est un partenaire majeur pour son support dans cette transition.

Si vous recevez le mail suivant, c’est une opération de phishing, classez directement à la verticale !

From: Easy-hebergement Updates
Date: Tue, 25 Apr 2023 10:55:30 +0200
Subject: Urgent Security Update - Opt-in Required for Better Protection
Message-Id:
To: sholby@sholby.net
Sender: postmaster@net.1cooldns.com
Reply-To: Easy-hebergement Updates
X-Mailer: Z
X-Originating-IP: 2.1.206.126
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=-CyrBPiCm7t7WM27u8Wa4pg=="

--=-CyrBPiCm7t7WM27u8Wa4pg==
Content-Type: text/plain; charset=utf-8

Dear valued easy-hebergement user, We are writing to inform you about a crucial security update that has been applied to our system to ensure the safety of your data. As a result, we are urging all our users to confirm their participation by opting in for this update. To facilitate this process, we request that you respond to this email with a "yes" to indicate that you would like to opt-in for the security update. Please note that opting-out of this update is not recommended, as it could put your data at risk. Your safety and security are our top priorities, and we are committed to providing you with the highest level of protection possible. Therefore, we encourage you to take this opportunity to update your account and ensure that it remains secure. Should you have any questions or concerns regarding this update, please feel free to contact our customer support team at any time. We appreciate your cooperation and look forward to continuing to serve you. Best regards, Cyber s
ecurity specialist Easy-hebergement Team
Switch to html version to view full message
--=-CyrBPiCm7t7WM27u8Wa4pg==
Content-Type: text/html; charset=utf-8
Content-Id:

Dear valued easy-hebergement user,We are writing to inform you about a crucial security update that has been applied to our system to ensure the safety of your data. As a result, we are urging all our users to confirm their participation by opting in for this update.To facilitate this process, we request that you respond to this email with a "yes" to indicate that you would like to opt-in for the security update. Please note that opting-out of this update is not recommended, as it could put you
r data at risk.Your safety and security are our top priorities, and we are committed to providing you with the highest level of protection possible. Therefore, we encourage you to take this opportunity to update your account and ensure that it remains secure.Should you have any questions or concerns regarding this update, please feel free to contact our customer support team at any time. We appreciate your cooperation and look forward to continuing to serve you.Best regards,Cyber security specialist Easy-hebergement Team
--=-CyrBPiCm7t7WM27u8Wa4pg==--

Bonjour,

à partir d’aujourd’hui toutes les offres Cloud VDS bénéficient d’un doublement de la mémoire RAM incluse :

• VDS Bravo : 1 Go (au lieu de 512 Mo)
• VDS Charlie : 2 Go (au lieu de 1 Go)
• VDS Delta : 4 Go (au lieu de 2 Go)
• VDS Echo : 8 Go (au lieu de 4 Go)

Envie de tester nos offres Cloud VDS ? Bénéficiez actuellement d’une promotion sur toutes les nouvelles commandes (de -10 à 25%).

Plus d’informations sur : http://www.easy-hebergement.fr/serveurs-cloud-vds

PS : Cette mise à jour vient d’être appliquée à tous nos clients existants

Bonne continuation sur nos serveurs.

Bonjour à tous,

PHP 7.0 est à présent disponible sur l’hébergement mutualisé. Ce sont à présent 6 versions de PHP que nous proposons :

5.2, 5.3, 5.4, 5.5, 5.6 et 7.0

Les versions PHP 5.2 et 5.3 sont fortement déconseillées car elles ne sont plus maintenues par l’équipe de développement de PHP (vous avez à présent un message d’avertissement dans l’espace-client si vous utilisez cette version).

À cette occasion, nous avons augmenté certaines limites de PHP :

• Memory_limit : passage de 128 à 256 Mo maximum (et valeur par défaut à 192 Mo au lieu de 128 Mo à partir de PHP 5.5)
• Max_execution_time : passage de 90 à 120 secondes maximum
• Max_input_time : passage de 90 à 120 secondes maximum
• Upload_max_filesize : passage de 128 à 256 Mo maximum
• Post_max_size : passage de 128 à 256 Mo maximum

Bonne continuation sur nos serveurs.

Bonjour à tous,

Nous avons prévu de déployer courant de semaine prochaine une mise à jour des serveurs web (sans coupure) incluant notamment :

– Mise à jour des versions de PHP existantes
– Mise à jour des librairies SSL (notamment pour les nouvelles règles Paypal)
– Ajout de PHP 7.0

Suite à cette mise à jour, il ne sera plus possible d’activer PHP 5.2 et PHP 5.3 sur les nouveaux hébergements (ces versions ne sont plus supportées par l’équipe de développement de PHP).

Vous pourrez néanmoins continuer à les utiliser sur les hébergements existants (mais nous vous recommandons fortement de passer sur des versions plus récentes).

 

Bonne continuation sur nos serveurs 🙂

Bonjour à tous,

Nous vous l’annoncions dans un billet précédent, nous avons considérablement amélioré les performances de l’hébergement mutualisé.
Nous avons à présent lancé le deuxième étage de la fusée avec une amélioration importante de la stabilité des serveurs web de la plateforme d’hébergement. En effet, dans certaines conditions, certains serveurs web du cluster pouvaient, en raison de pics de charge, être lents ou difficilement joignables et entraîner ainsi des micro-coupures (le temps que le système les retire du cluster d’hébergement).

Nos améliorations déployées progressivement depuis une semaine ont permis d’éliminer ces micro-coupures.

Bonne continuation sur nos serveurs 🙂