La fin de la sécurité périmétrique statique
Pendant des années, la défense périmétrique reposait sur un postulat simple : le trafic malveillant provient d’IPs réputées « sales » (Tor, Datacenters exotiques, VPNs gratuits). Cette époque est révolue. L’alerte émise par GreyNoise concernant l’activité entre le 28 janvier et le 2 février 2026 marque un tournant industriel dans la reconnaissance offensive.
Nous ne parlons pas ici d’un « script kiddie » scannant depuis son VPS DigitalOcean. Nous faisons face à une infrastructure de 63 000+ adresses IP résidentielles (RESIP) mobilisées pour cartographier les instances Citrix ADC / NetScaler mondiales. Pour un ingénieur infrastructure, cela signifie que le bruit de fond de l’internet est devenu l’arme principale des attaquants.
1. Anatomie Technique de la Campagne
L’attaque se distingue par une dichotomie intéressante entre l’infrastructure réseau utilisée et la payload applicative.
A. L’Infrastructure : Le paradoxe de l’OS
L’analyse des paquets TCP révèle une sophistication dans l’obfuscation.
- La source apparente : Des IPs résidentielles (FAI grand public : Orange, Comcast, Verizon, etc.). Impossible de les bloquer massivement sans impacter des utilisateurs légitimes (télétravail, partenaires).
- La signature TCP : C’est ici que l’analyse devient fascinante. Bien que les IPs appartiennent à des machines infectées (probablement des botnets Windows grand public), le fingerprinting de la stack TCP indique que le trafic de scan est initié ou relayé par des machines Linux.
- Interprétation : Les attaquants utilisent les machines Windows compromises comme de simples tunnels (proxies), tandis que la logique de scan est exécutée depuis des serveurs de commande Linux centralisés. Cela permet de masquer la véritable origine tout en bénéficiant de la « blancheur » des IPs résidentielles.
B. La Méthodologie de Ciblage (Le « Two-Step »)
La campagne ne tire pas à l’aveugle. Elle suit une logique économique stricte pour économiser les ressources du botnet :
- Phase 1 : Identification du Service (Broad Scan) Les bots cherchent d’abord les panneaux de connexion Citrix (les portails Gateway). C’est un scan volumétrique (plus de 111 000 sessions détectées).
- Phase 2 : Fingerprinting de Version (Targeted Probe) Une fois la cible validée, une seconde requête, souvent issue d’une IP différente (parfois Cloud/Datacenter pour la vitesse), interroge une URL spécifique :
/epa/scripts/win/nsepa_setup.exe
C. Pourquoi ce fichier .EXE ?
Pourquoi télécharger un exécutable de 20 Mo ? Pour lire ses métadonnées. Ce fichier, utilisé pour l’Endpoint Analysis (EPA), est souvent accessible publiquement même sans authentification. En analysant les propriétés du binaire (Date de compilation, Version interne), l’attaquant peut déduire avec une certitude de 100% la version du firmware du NetScaler (ex: 13.1 Build 49.13). Résultat : Ils ne cherchent pas à entrer maintenant. Ils construisent une base de données qualifiée (« Hit List ») associant IP : Version. Le jour où une CVE sortira sur la version 13.1, ils sauront exactement qui frapper dans les 15 minutes.
2. Impacts sur l’Infrastructure et la Sécurité
Cette campagne met en échec plusieurs couches de défense standards.
L’effondrement de la Réputation IP
Vos feeds de Threat Intelligence (Cisco Talos, Crowdsource, etc.) ont généralement un temps de latence de 24 à 48h. Ici, les IPs résidentielles tournent trop vite. Le temps que l’IP soit « blacklistée », l’attaquant est déjà passé à la suivante. Votre pare-feu, s’il est configuré uniquement sur la réputation Layer 3/4, est aveugle.
Le risque de « False Negative » dans le SOC
Pour un analyste SOC, ce trafic ressemble à du trafic utilisateur légitime.
- User-Agent :
Mozilla/5.0 ... Chrome/50... - Source : IP FAI résidentiel.
- Comportement : Accès à une page de login ou téléchargement d’un plugin client. Sans corrélation avancée, cette activité passe sous les radars comme du « bruit » ou des erreurs de connexion.
Le Talon d’Achille : Chrome 50
L’erreur opérationnelle (OpSec) des attaquants est l’utilisation d’un User-Agent datant de 2016 (Chrome/50). C’est une anomalie statistique énorme en 2026. Aucun utilisateur réel, même avec un vieux PC, ne navigue avec cette version. C’est votre principal IOC (Indicator of Compromise).
3. Recommandations et Durcissement (Hardening)
Il ne s’agit plus de « patcher », mais de durcir la configuration pour réduire la surface d’information.
🛡️ Niveau 1 : Filtrage au niveau du NetScaler (WAF/Responder)
L’objectif est de tuer la connexion avant qu’elle ne consomme des ressources CPU/RAM.
Action : Bloquer les User-Agents anachroniques. Insérez cette politique en haut de votre liste de bind :
# Détection des UA Chrome 50 (ou versions trop anciennes)
add responder policy POL_DROP_ANCIENT_UA "HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"Chrome/50\") || HTTP.REQ.HEADER(\"User-Agent\").CONTAINS(\"Chrome/4\")" DROP
# Application globale (ou sur vos vServer Gateway)
bind lb vserver <Votre_Vserver> -policyName POL_DROP_ANCIENT_UA -priority 10🛡️ Niveau 2 : Obfuscation de la Version (Security by Obscurity)
Bien que controversée, masquer la version exacte complique la tâche des bots automatisés. Action : Si vous n’utilisez pas les fonctionnalités EPA (Endpoint Analysis), désactivez les chemins d’accès ou restreignez-les via des règles de réécriture (Rewrite Policies) pour renvoyer une 403 Forbidden sur /epa/* pour les IPs non authentifiées.
🛡️ Niveau 3 : Surveillance Logique (SIEM)
Configurez vos outils (Splunk, ELK, Datadog) pour lever une alerte si :
- Une même IP accède à
/epa/scripts/win/nsepa_setup.exe. - ET que cette IP n’a pas généré de log d’authentification (réussie ou échouée) dans les 60 secondes précédentes. Cela isole le comportement de « Scan » du comportement d’un utilisateur réel qui téléchargerait le plugin après s’être logué.
Conclusion
Cette campagne de février 2026 nous rappelle une leçon cruelle : votre infrastructure publique est scannée en permanence. L’utilisation massive de proxies résidentiels par les attaquants nivelle par le bas l’efficacité des pare-feux traditionnels. La réponse n’est pas technologique, elle est architecturale : minimiser l’exposition des métadonnées (versioning), adopter une posture « Zero Trust » même pour les accès publics, et baser la détection sur le comportement (User-Agent, chemin d’accès) plutôt que sur l’origine IP.
Source des données brutes : GreyNoise Intelligence