Password spray Azure CLI : construire un flux IOC (plages IPv6/ASN) et détecter les rafales

Entre le 12 et le 26 juin, une campagne de password spray a généré plus de 81 millions de tentatives d'authentification contre des comptes Microsoft Entra ID, documentée par Huntress. Le vecteur : le client Azure CLI, dont l'user-agent et l'appId sont détournés pour émettre des requêtes d'authentification en masse. La quasi-totalité du trafic provient d'un seul opérateur réseau, AS32167 (LSHIY LLC), depuis des plages IPv6. Bilan rapporté : 78 comptes compromis chez les organisations touchées.

Ce n'est pas un énième credential stuffing générique. C'est un signal exploitable dès maintenant : une plage ASN identifiée, un pattern de client précis, une fenêtre temporelle atypique. La question pour un RSSI ou un administrateur M365 n'est pas « dois-je m'inquiéter du password spray en général » mais « mes comptes sont-ils actuellement visés par cette campagne précise, et quelle blocklist activer aujourd'hui ».

Pourquoi AS32167 et l'IPv6 changent la donne

Le choix de l'IPv6 n'est pas anodin. L'espace d'adressage IPv6 est si vaste qu'un blocage IP par IP est inutile : l'attaquant fait tourner ses sources à chaque tentative. Bloquer par ASN (le numéro de système autonome, c'est-à-dire l'opérateur ou l'hébergeur qui annonce ces plages) est la seule approche qui tienne, parce que l'infrastructure derrière un ASN loué à des fins offensives ne change pas aussi vite que les adresses individuelles.

AS32167 (LSHIY LLC) est le numéro observé dans cette campagne. Le retenir seul serait fragile : les opérateurs de ce type d'infrastructure tournent régulièrement d'un ASN à l'autre pour échapper aux blocklists statiques. D'où la nécessité de construire un flux, pas une liste figée une fois pour toutes.

Construire le flux IOC : plages IPv6/ASN

La méthode reproductible :

1. Partir du fait documenté. L'advisory public identifie l'ASN, la fenêtre temporelle, le volume. C'est la matière première, pas une preuve de concept à copier telle quelle.
2. Résoudre les plages IPv6 annoncées par l'ASN. Un ASN annonce des blocs (préfixes) via BGP ; on les récupère via les registres régionaux (RIPE, ARIN) ou des outils comme bgp.he.net / whois -h whois.radb.net.
3. Vérifier la corroboration. Un ASN ne doit entrer dans un flux revendu ou partagé que s'il est corroboré par plusieurs sources indépendantes (l'advisory Huntress, vos propres logs de sign-in, éventuellement un second rapport public), jamais sur la seule base d'un signalement isolé.
4. Appliquer l'hygiène « ne jamais bloquer ». Vérifier qu'aucun préfixe légitime (CDN partagé, cloud public à usage mixte) n'est inclus par erreur avant intégration en blocklist conditionnelle.

Exemple de structure de flux consommable par une politique d'accès conditionnel :

# extrait de flux IOC - blocklist conditionnelle ASN/IPv6
indicators:
  - type: asn
    value: 32167
    name: "LSHIY LLC"
    first_seen: "2026-06-12"
    last_seen: "2026-06-26"
    corroboration: 2
    context: "password_spray_azure_cli"
  - type: ipv6_range
    value: "2a0e:aa07::/32"
    asn: 32167
    confidence: high
    action: conditional_block

Le point clé : le flux ne dit pas « bloquer cette IP », il dit « ce contexte (ASN + comportement) mérite un accès conditionnel renforcé ». C'est cette nuance qui évite de transformer un signal de threat intelligence en incident de production.

Règle Entra ID : rafales sur le client Azure CLI

Le vecteur observé exploite spécifiquement le client Azure CLI (appId 04b07795-8ddb-461a-bbee-02f9e1bf7b46, bien connu, et son user-agent caractéristique python/... azure-cli/...). Une campagne de spray via ce client se repère par la combinaison de trois signaux dans les SigninLogs Entra ID :

• appDisplayName = "Azure CLI" ou appId correspondant, en volume anormal
• Rafale de tentatives sur une fenêtre courte (minutes) depuis peu de sources réseau distinctes mais un même ASN
• Hors plage horaire normale de l'organisation (nuit, week-end pour un usage qui devrait être diurne et ouvré)

Exemple de règle Sigma appliquée aux SigninLogs :

title: Azure CLI Authentication Burst Outside Business Hours
id: 8e2f4a1c-azure-cli-spray
status: experimental
logsource:
  product: azure
  service: signinlogs
detection:
  selection:
    AppDisplayName: "Azure CLI"
    ResultType:
      - '50126'  # invalid username or password
      - '50053'  # account locked
  timeframe: 10m
  condition: selection | count() by SourceASN > 20
falsepositives:
  - Legitimate CI/CD pipelines using Azure CLI service principals
  - Administrators scripting bulk operations
level: high

Le seuil de 20 échecs en 10 minutes n'est pas universel : il doit être calibré sur le volume normal d'authentifications CLI de l'organisation. C'est l'objet du point suivant.

Seuils adaptés PME : combien de tentatives avant blocage

Une PME n'a pas le volume d'authentification d'un grand compte, ce qui est en réalité un avantage : les rafales anormales ressortent plus nettement. Ordres de grandeur raisonnables comme point de départ :

Ces seuils se resserrent avec l'historique : après deux à trois semaines d'observation, on ajuste à la baseline réelle de l'organisation plutôt qu'à des valeurs génériques.

Anti faux positifs : ne pas bloquer IPv6 à l'aveugle

C'est le piège le plus coûteux. Le client Azure CLI est utilisé quotidiennement par des usages parfaitement légitimes :

• Pipelines CI/CD (GitHub Actions, GitLab CI, Azure DevOps) qui s'authentifient via principal de service avec le même appId Azure CLI
• Administrateurs qui scriptent des opérations en masse depuis des postes ou des VM de rebond
• Automatisations internes (scripts de provisioning, exports planifiés)

Avant/après sur la même alerte :

Avant (règle naïve) : bloquer toute IPv6 associée à un échec d'authentification Azure CLI. Résultat : un pipeline CI légitime qui échoue une fois sur un secret expiré déclenche un blocage, la build casse, l'équipe ouvre un ticket, la confiance dans les alertes s'érode.

Après (règle ciblée) : ne cibler que la combinaison ASN suspect + volume de rafale + hors plage horaire, avec une liste blanche explicite des ASN et plages IPv6 connus pour l'organisation (fournisseur CI/CD, VPN d'entreprise, postes admin identifiés). Le pipeline légitime, qui échoue depuis une plage whitelistée à une heure ouvrée, ne déclenche jamais l'accès conditionnel renforcé.

La règle à retenir : on cible l'ASN et le pattern de spray, jamais le protocole IPv6 en tant que tel.

Où ça se branche : feed IOC + règle Sigma, deux couches complémentaires

Le flux IOC (IP/ASN) alimente la politique d'accès conditionnel côté Entra ID : c'est la couche statique, rapide à activer, qui bloque ou renforce l'authentification en fonction de la provenance réseau. La règle Sigma sur les SigninLogs (appDisplayName Azure CLI, échecs en masse) est la couche comportementale : elle détecte le pattern même si l'attaquant change d'ASN demain.

Les deux sont complémentaires et non substituables. Le flux IOC seul rate toute nouvelle infrastructure louée après la publication de l'advisory. La règle comportementale seule rate l'opportunité de bloquer en amont, avant même la première tentative réussie, un ASN déjà connu comme hostile.

Maintenance : une infrastructure qui tourne, un flux qui doit suivre

Le point le plus souvent négligé : l'infrastructure d'attaque n'est pas statique. Un ASN utilisé aujourd'hui pour du password spray peut être abandonné dans deux semaines au profit d'un autre bloc loué ailleurs. Un flux IOC figé au 26 juin devient obsolète en quelques semaines.

Cadence recommandée :

• Mise à jour du flux ASN/IPv6 : hebdomadaire au minimum, idéalement corrélée à la publication de nouveaux rapports (Huntress, CISA, fournisseurs de threat intelligence)
• Ré-évaluation des seuils Entra ID : mensuelle, ou immédiatement après un changement de volume normal (nouvel outil CI, croissance des effectifs)
• Combinaison IOC statique + détection comportementale : ne jamais reposer uniquement sur l'un ou l'autre. Le statique bloque vite ce qui est déjà connu ; le comportemental attrape ce qui ne l'est pas encore.

En résumé

Cette campagne AS32167/LSHIY illustre un cas concret de password spray via client Azure CLI, avec un vecteur d'accès initial directement exploitable pour les organisations hébergées Azure/M365. La réponse tient en deux couches : un flux IOC ASN/IPv6 corroboré et maintenu, consommé par l'accès conditionnel, et une règle comportementale sur les SigninLogs qui détecte le pattern de rafale même quand l'infrastructure change. L'anti-faux-positif n'est pas une option : whitelister les usages CLI légitimes avant activation est ce qui distingue une détection utile d'un cran de sécurité qui casse les pipelines.

C'est exactement cette discipline (fait documenté, plages ASN corroborées, seuils calibrés, anti-FP vérifié) que porte le feed IOC de ThreatClaw : les indicateurs sont mis à jour au rythme où l'infrastructure d'attaque tourne, pas figés à la date d'un advisory.