82 314 dollars, c'est l'incroyable facture que s'est mangé un dev mexicain après 48 heures d'utilisation frauduleuse de sa clé API Gemini. Sa dépense habituelle était de 180 dollars par mois environ, j'imagine que ça lui a fait un peu mal aux fesses. Et c'est une bonne raison pour moi de vous inciter une nouvelle fois à bien sécuriser vos clés API !

Le gars bosse dans une petite startup et de ce que j'ai compris, quelqu'un a chopé ses credentials et s'est lâché sur Gemini 3 Pro pendant deux jours. La réponse de Google ? "Responsabilité partagée". En gros, eux sécurisent l'infra, et vous sécurisez vos clés. Si vous vous faites plumer, c'est votre problème !

Et c'est pas un cas isolé car les chercheurs de Truffle Security ont scanné le web et trouvé 2 863 clés Google API exposées en clair sur des sites publics. Toutes identifiables par le préfixe AIza.

Sauf que comme je vous l'expliquais dans un article précédent, ces clés, à la base, étaient conçues comme de simples identifiants de projet pour Maps et Firebase et la doc Google disait carrément qu'elles n'étaient pas secrètes ! Et quand l'API Gemini a été activée sur ces projets, hé bien ces clés sont devenues des clés d'authentification, sans que personne ne réalise ce changement de paradigme.

Mais bon, plutôt que de chialer comme des fragiles, voyons comment éviter de se retrouver dans cette situation ^^.

Scanner vos secrets existants

Avant tout, faut savoir si vous avez déjà des fuites. Deux outils open source font ça très bien.

TruffleHog scanne vos dépôts Git, vos fichiers, et même vos buckets S3 pour trouver des secrets qui traînent. L'install est simple :

brew install trufflehog
trufflehog git https://github.com/user/project --only-verified

grep -r "AIza" . --include="*.js" --include="*.py" --include="*.env"

brew install git-secrets
cd mon-projet
git secrets --install
git secrets --register-aws

git secrets --add 'AIza[0-9A-Za-z_-]{35}'
git secrets --add 'sk-proj-[0-9a-zA-Z]{48}'

gcloud services api-keys list
gcloud services api-keys create --display-name="gemini-prod-$(date +%Y%m)"
gcloud services api-keys delete ANCIENNE_CLE_ID

Si comme moi, vous payez rubis sur l’ongle Google Cloud ou Cloudflare pour héberger vos services parfaitement légaux, et bien sachez que pendant que vous respectiez scrupuleusement leurs conditions d’utilisation tordues, une opération de phishing monumentale utilisait tranquillement leurs infrastructures pour cloner des sites du Fortune 500. Ça a duré trois ans sans que personne ne soit inquiété et cela malgré 265 signalements publics…

Ce sont les chercheurs de Deep Specter Research qui ont découvert un empire du phishing qui ferait passer les arnaqueurs nigérians pour des amateurs. Je vous parle de 48 000 hosts virtuels répartis sur plus de 80 clusters, tous bien au chaud sur l’infrastructure premium de Google Cloud à Hong Kong et à Taiwan. Le tout géré évidemment comme une vraie plateforme phishing-as-a-service, avec sept évolutions techniques majeures sur la période.

Les criminels utilisaient HTTrack Website Copier , un vieiiiil outil parfaitement légal de scraping web, pour créer des clones parfait au pixel près de +200 grandes entreprises. Lockheed Martin, le géant de la défense américaine , s’est notamment retrouvé avec un jumeau malveillant hébergé sur le domaine militaryfighterjet.com. C’est un site qui parlait initialement d’avions de chasse et qui s’est transformé en casino en ligne tout en servant de façade pour du phishing ciblé.

La technique était redoutablement efficace. Les attaquants récupéraient des domaines expirés qui appartenaient à des organisations légitimes. Ces domaines gardaient ainsi leur réputation, leurs backlinks, parfois même leurs communautés sur les réseaux sociaux.

Et pour éviter la détection, le système de cloaking analysait en temps réel les headers HTTP, les user agents et la géolocalisation IP. Donc si vous étiez un bot de Google ou un chercheur en sécurité, vous voyiez un site normal. Mais si vous étiez une vraie victime potentielle, c’était bienvenue dans la matrice. Cette technique sophistiquée a permis aux sites malveillants de maintenir d’excellents rankings SEO tout en servant leur contenu frauduleux aux bonnes personnes.

L’infrastructure comptait 86 adresses IP physiques côté Google Cloud, mais le réseau virtuel était bien plus vaste avec 44 000 adresses IP virtuelles chez Google et 4 000 chez d’autres hébergeurs. En mars 2025, l’opération a d’ailleurs atteint son pic avec 33 890 observations actives selon les données de Deep Specter. Sur l’année 2025 seule, on comptait 2 791 hosts avec 56 075 observations au total.

Mais voilà le scandale dans le scandale… malgré 265 détections publiques par des chercheurs et des outils de threat intelligence, ni Google ni Cloudflare n’ont suspendu les comptes concernés. Les signalements incluaient des domaines malveillants, des adresses IP compromises et des certificats SSL frauduleux.

Mais aucune réponse des géants du cloud… Rien. Nada. Que dalle.

Cette passivité a fait passer ces entreprises, de, je cite “neutral intermediaries” en “de facto enablers of illicit activity”. Traduction, au lieu d’être des hébergeurs neutres, ils sont de par leur inaction, devenus des complices.

Les conséquences pour les entreprises clonées sont également désastreuses car au-delà des pertes de trafic organique qui se traduisent directement en manque à gagner, elles font face à des risques légaux majeurs. Violations potentielles du RGPD si des données européennes sont compromises, problèmes DMCA pour le contenu copié, scrutin de la FTC américaine, obligations de divulgation SEC… Sans compter les frais juridiques pour tenter de faire fermer ces clones.

Visiblement, il y a des problèmes de gouvernance majeurs chez les géants du cloud… Les providers ont les moyens techniques de détecter ces abus, mais apparemment, tant que les factures sont payées, la motivation pour agir reste limitée…

Les chercheurs appellent donc Google, Cloudflare et les marques affectées à renforcer leurs mécanismes de détection, fermer les boucles de monitoring et appliquer des politiques strictes de résiliation de comptes.

Je suis pas sûr que le message passe mais bon, après ça les expose à des risques juridiques, alors ils seront peut-être plus sérieux la prochaine fois…

Source

35 secondes… C’est même pas le temps qu’il vous faut pour réchauffer votre café au micro-ondes. Par contre, c’est pile poil le temps qu’il a fallu à des attaquant pour balancer 11,5 térabits par seconde sur les serveurs protégés par Cloudflare. Pour vous donner une idée, c’est comme si quelqu’un vous envoyait 10 000 films HD d’un coup, direct dans la tronche.

Cette attaque monumentale s’inscrit dans une série d’assauts qui deviennent de plus en plus violents. Par exemple, au premier trimestre de cette année, Cloudflare a bloqué 20,5 millions d’attaques DDoS. C’est quand même une augmentation de 358% par rapport à l’année dernière. Visiblement, quelqu’un s’amuse à tester les limites de l’infrastructure Internet mondiale… Mais le plus bizarre dans cette histoire, c’est l’origine de l’attaque.

Apparemment, la majorité du trafic malveillant provenait de ressources compromises sur Google Cloud Platform, donc de serveurs légitimes, payés rubis sur l’ongle par des entreprises lambda, transformés en armes de destruction massive de réseau. Le modèle pay-as-you-go du cloud est devenu une aubaine pour les attaquants qui peuvent louer une gigantesque puissance de feu quasi illimitée juste le temps de leur méfait.

L’attaque dont on parle aujourd’hui a utilisé la technique du UDP flood. Celle-ci est un peu vicieuse car contrairement au protocole TCP qui établit une connexion avant d’envoyer des données, l’UDP balance tout sans prévenir. Ainsi, chaque paquet UDP force le serveur victime à allouer des ressources pour le traiter, jusqu’à ce qu’il ne puisse plus répondre aux requêtes légitimes.

Et ce qui est impressionnant, c’est la rapidité de montée en puissance car les systèmes de Cloudflare ont détecté une progression de zéro à 11 térabits en moins de 10 secondes. C’est plus rapide qu’une Tesla qui passe de 0 à 100 et les défenses automatisées ont immédiatement appliqué des règles de limitation et du filtrage par IP pour étouffer l’attaque avant qu’elle ne fasse des dégâts.

Le rapport Q1 2025 de Cloudflare révèle que Google Cloud (AS396982) figure parmi les principaux réseaux sources d’attaques DDoS HTTP et la plupart des réseaux dans ce classement sont des fournisseurs cloud ou d’hébergement connus. D’ailleurs, pour aider ces fournisseurs à identifier et neutraliser les comptes abusifs, Cloudflare propose gratuitement un flux des botnet qui font des attaques DDoS afin que tout le monde puisse rapidement les bloquer. C’est leur façon de dire “on est tous dans le même bateau, entraidons-nous”.

En tout cas, cette attaque de 11,5 Tbps pulvérise totalement le précédent record établi en juin dernier, qui plafonnait à 7,3 Tbps. À ce rythme, on se demande où ça va s’arrêter, d’autant plus que ce n’est pas un cas isolé. Cloudflare rapporte en effet avoir bloqué des centaines d’attaques dépassant 1 Tbps ces dernières semaines, incluant une attaque UDP distincte qui a atteint 5,1 milliards de paquets par seconde. Pour contextualiser, c’est comme si chaque être humain adulte sur Terre vous envoyait un SMS.

Évidemment, l’industrie s’inquiète de cette escalade et sans protection de type Cloudflare, une attaque de cette ampleur mettrait n’importe quel site hors ligne instantanément. Même avec toute la bonne volonté du monde, votre FAI ne pourrait pas absorber 11,5 térabits de trafic malveillant… En tout cas, j’ai hâte de lire le rapport de Cloudflare qui devrait arriver bientôt…

Je me demande comment on pourrait se passer de Cloudflare maintenant… Ils sont devenus tellement incontournables… Ils sont un bouclier incroyable mais également un point de centralisation dramatique pour le net.

En attendant, une chose est sûre, les attaques DDoS ne sont plus ce qu’elles étaient. On est passé du petit script kiddie qui s’amuse à faire tomber le site de son lycée avec LOIC à des opérations massives capables de mettre à genoux des infrastructures entières… Et avec l’évolution du cloud et de l’IA, on n’a probablement encore rien vu.

Source