De six signaux au blocage automatique

Contexte

Il s'agit d'une application web WordPress dans un environnement d'hébergement mutualisé protégé par Aegis. Le client et le domaine exact sont anonymisés — chaque chiffre, technique et chronologie de cette étude provient directement de l'enregistrement de l'incident (registre WORM), sans embellissement.

L'attaque n'était pas un seul événement « bruyant » mais une série de signaux apparemment sans lien, éparpillés entre le WAF, le SIEM et la couche réseau. Isolément, chacun se perd facilement dans le bruit. La valeur d'un SOC est justement de les relier en une seule histoire — et d'y réagir pendant que l'attaque est encore en cours.

Ce qui s'est passé

En un peu moins de dix minutes, la même source (31.45.239.xxx) a traversé cinq phases successives :

• 1 · Scan de l'application web T1595 · Active Scanning

  Un scanner automatisé cartographie la structure du site, cherchant des chemins connus et des fichiers exposés. Le premier signal, discret — pas une attaque en soi, mais le prélude.

• 2 · Sondage de l'interface admin T1190 · Exploit Public-Facing App

  Requêtes ciblées vers /wp-admin et les chemins de connexion — l'attaquant vérifie si l'interface est ouverte.

• 3 · Tentative d'exploit WordPress (WAF) T1190

  Le WAF intercepte une tentative d'exploitation d'une vulnérabilité WordPress connue — la charge utile est bloquée au niveau applicatif, mais l'attaquant n'abandonne pas.

• 4 · Déluge de connexions (credential stuffing) T1110.003 · Password Spraying

  Une série de requêtes POST vers la connexion — une tentative de forcer le mot de passe avec un grand nombre de combinaisons en peu de temps.

• 5 · Épuisement L7 (slowloris) T1499 · Endpoint DoS

  Lorsque la percée directe échoue, l'attaquant passe à l'épuisement des ressources — maintenir lentement les connexions ouvertes pour étouffer le serveur.

Comment Aegis a réagi

Chacune de ces phases a déclenché sa propre alerte — six au total, issues de trois couches de défense différentes (WAF, SIEM d'authentification, détection réseau). Le moment décisif n'a été aucune détection isolée, mais la corrélation :

• Le moteur de corrélation Aegis a reconnu que les six alertes partagent la même IP source et s'enchaînent dans une séquence d'attaque — de la reconnaissance vers une intrusion active.
• La combinaison des techniques a franchi le seuil de confiance : ce n'est plus « un scanner errant sur Internet », mais une attaque ciblée et multi-étapes sur une cible précise.
• Aegis a automatiquement émis l'ordre de bloquer la source au périmètre — sans attendre un analyste.

Piste de preuves

La réponse automatique n'est pas la fin de l'histoire — chaque décision laisse une piste auditable :

• Les six alertes d'origine et leur corrélation sont consignées dans l'enregistrement d'incident immuable (WORM).
• Chacune des 188 requêtes malveillantes est liée à une technique et un horodatage.
• Le blocage lui-même — qui l'a émis (l'automatisation), sur quelle base et quand — fait partie du même dossier de preuves.

C'est la différence entre « le système a bloqué quelque chose » et « nous pouvons montrer exactement ce qui s'est passé, pourquoi et dans quel ordre » — que ce soit pour un audit interne ou les registres NIS2.