Ce qui se passe dans les 24 premières heures après le lancement d’un nouvel actif

Ce qui se passe dans les 24 premières heures après le lancement d'un nouvel actif

Les attaquants repèrent les nouveaux équipements connectés à Internet en quelques minutes seulement après leur mise en ligne. Des outils automatisés balaient en permanence l’ensemble des adresses IP publiques pour identifier les failles potentielles.

Chronologie technique des premières 24 heures

Mise en service de l’équipement

Un développeur déploie une instance cloud fraîche. Une règle de pare-feu mal ajustée libère un port. Un portail fournisseur apparaît sur un sous-domaine non surveillé. Résultat : un point d’accès routable sur Internet émerge sans alerte sécurité.

De 5 à 60 minutes : découverte par les scanners

Des infrastructures de numérisation automatisées explorent sans relâche le web public. Shodan, Censys et ShadowServer recensent les hôtes fraîchement indexés, avec Censys qui scrute des dizaines de milliers de ports.

En moins d’une heure, les ports ouverts sont listés, les bannières de services récupérées (versions de serveurs web, certificats TLS, empreintes SSH), et les signatures de réponses croisées avec des bases de vulnérabilités connues.

De 1 à 6 heures : phase de reconnaissance

L’équipement apparaît dans les requêtes Shodan et Censys. Les outils d’attaque lancent leur propre analyse : versions de services, ports de gestion ouverts (RDP sur 3389, SSH sur 22, panneaux admin sur 8080/8443), certificats TLS menant à d’autres domaines.

Un certificat révèle souvent des détails sur l’infrastructure entière sans contacter les éléments surveillés.

De 6 à 12 heures : sondages actifs

La détection passive passe à l’offensive. Les données GreyNoise indiquent un pic d’activité des scanners. Des tentatives de credential stuffing visent SSH et RDP. Les services web subissent des attaques par force brute sur les répertoires. Elasticsearch et Redis sont testés sans authentification. Les frameworks sont évalués face à des CVE identifiés.

Les botnets gèrent ces opérations à grande échelle, sans intervention humaine.

De 12 à 24 heures : prise de contrôle

Des chercheurs de Unit 42 ont déployé 320 honeypots sur divers fournisseurs cloud (RDP, SSH, SMB, Postgres). 80 % ont été compromis en moins de 24 heures.

Les vulnérabilités exploitables, erreurs de configuration ou identifiants par défaut suffisent pour une compromission rapide.

Exemple concret : une API secrète découverte

Des analyses ont révélé une application web de logistique accessible publiquement. L’examen du bundle JavaScript compilé servi aux navigateurs a mis en évidence une référence à une API backend inconnue des inventaires.

Cette interface fonctionnait en open access, sans jeton ni identifiants.

New asset
En variant les identifiants d’endpoints, les tests ont extrait :

  • noms de clients, adresses email et notes de comptes
  • identifiants en clair pour comptes clients
  • noms d’utilisateurs et mots de passe par défaut des appareils
  • informations sur réseaux internes des dispositifs déployés
  • noms et adresses email d’employés

Évolution rapide de la surface d’attaque

Selon une étude de Unit 42 sur la surface d’attaque externe, elle gagne plus de 300 services par mois en moyenne. Plus de 20 % des services cloud accessibles de l’extérieur se renouvellent mensuellement.

Les équipes sécurité peinent à suivre. La plupart des enquêtes de violations reviennent à une méconnaissance d’un élément exposé sur Internet.

Un équipement inconnu échappe aux correctifs, à la surveillance ou à la mise hors ligne en cas de crise. Souvent, il s’agit d’un service backend cité dans un fichier JavaScript négligé.