Post by Abdelmajid Jiyadi

Observation intéressante sur un pattern de reconnaissance automatisée que je vois revenir de plus en plus souvent. Une IP, en moins de 20 secondes, envoie des dizaines de requêtes vers un serveur web à la recherche de : clés privées (.key, .pem) credentials cloud (.aws/credentials, service-account.json) secrets applicatifs (.env.production, secrets.yml, credentials.json) fichiers d'infra (terraform.tfstate, docker-compose.yaml) Ce type de scan tourne en permanence sur quasiment toute IP publique exposée — rien de nouveau en soi. Ce qui mérite qu'on s'y attarde : chaque requête portait un User-Agent différent, empruntant l'identité de crawlers légitimes — GPTBot, ClaudeBot, PerplexityBot, Amazonbot, CCBot, Google-Extended... Aucun crawler d'indexation légitime n'a de raison d'aller chercher un fichier .aws/credentials ou une clé privée. La rotation d'UA ici sert un objectif précis : se fondre dans le bruit de fond du trafic "IA de confiance" pour — → contourner des règles de détection basées sur la signature UA → échapper à des allow-lists mal calibrées autour des crawlers IA → diluer le volume de requêtes par UA pour rester sous des seuils de rate-limiting Détail révélateur : la wordlist incluait aussi des fichiers de config d'outils IA/dev — .cursor/mcp.json, .claude/settings.json, .codex/config.toml — signe que les scanners de secrets s'adaptent déjà aux nouveaux endpoints où des tokens API traînent en clair. À retenir pour les équipes SOC : la prolifération des crawlers IA légitimes, chacun avec son propre UA, élargit la surface que des acteurs malveillants peuvent usurper pour se camoufler. La détection basée uniquement sur le User-Agent devient de moins en moins fiable — il faut corréler avec le comportement (volume, séquence de chemins ciblés, taux d'erreur, timing) plutôt qu'avec la seule identité déclarée dans le header. La reconnaissance moderne s'habille avec ce qui inspire confiance.