Tu vas tomber, en cherchant « MSIX App Attach », sur des dizaines de tutos qui te font croire que c’est trois clics dans un assistant. Tu lances MSIX Packaging Tool, tu cliques Next cinq fois, et hop, ton .msix est prêt.

Sauf que c’est faux. Enfin, à moitié.

L’assistant existe vraiment, et il fait bien le boulot. Le souci, c’est tout ce qu’il y a autour : le certificat de signature qui doit correspondre au pixel près au nom de l’éditeur, le 0x8bad0001 que crache msixmgr quand la chaîne de confiance n’est pas en place, le runtime Windows App SDK qui manque au moment de tester le package, et la source Microsoft Store de winget qui te claque un 0x8a15005e à la figure sur une VM Azure. Aucun de ces pièges n’est documenté côté à côté en français.

Je viens de me les manger tous, dans l’ordre, sur une VM de packaging Azure. Alors je te déroule le process complet : créer un package MSIX de A à Z avec Notepad++ comme cobaye, jusqu’au CIM prêt à attacher. Avec les pièges annoncés avant qu’ils ne tombent.

Une précision tout de suite : cet article s’arrête au package. L’attachement réel sur un host pool AVD (le storage Azure Files, les permissions SMB, la registration App Attach) mérite son propre guide, je le traiterai séparément. Ici, on fabrique l’artefact. C’est déjà bien assez pour un article.

Pourquoi Notepad++ et pas 7-Zip ou un truc plus lourd

Petit aparté de méthode, parce que le choix de l’app cobaye n’est pas anodin.

App Attach a une raison d’être précise : livrer une application sans la coller dans le golden image. Typiquement une app volumineuse, licenciée par département, ou mise à jour souvent. Sur le papier, n’importe quelle app fait l’affaire pour un lab. En pratique, certaines sont de mauvais cobayes.

7-Zip, par exemple, c’est tentant parce que c’est léger. Mais c’est un mauvais exemple pédagogique : gratuit, 5 Mo, utile à tout le monde. Personne ne mettrait jamais ça en App Attach dans la vraie vie, tu l’installes direct dans l’image en trente secondes.

Notepad++ est un bien meilleur choix, pour trois raisons :

• Il se capture proprement. Installeur MSI simple, pas de services Windows, pas de drivers exotiques.
• Il représente le cas réel « outil bureautique livré par groupe d’utilisateurs ».
• Depuis la v8.8.8, Notepad++ fournit un MSI x64 officiel pour le déploiement entreprise. Et un MSI se capture toujours plus proprement qu’un .exe à assistant graphique.

Au moment où j’écris, la version stable est la 8.9.6.4. C’est celle qu’on va packager.

Le matériel : ce qu’il te faut avant de commencer

On part d’une VM de packaging propre. Le mot « propre » est important : pas de Notepad++ déjà installé dessus, idéalement un snapshot pris avant de commencer pour pouvoir revenir en arrière. MSIX Packaging Tool capture les changements du système pendant l’installation. Si l’app est déjà là, la capture est faussée.

Voici les prérequis, et où je me suis fait avoir sur chacun :

On y va dans l’ordre.

I. Installer MSIX Packaging Tool (et le piège msstore)

L’outil s’installe via winget. Première commande, premier mur :

[CODE : install_msixtool.ps1]

powershell

winget install Microsoft.MSIXPackagingTool

winget install Microsoft.MSIXPackagingTool

Et là, sur ma VM Azure, je me prends ça :

Failed when searching source: msstore
0x8a15005e : The server certificate did not match any of the expected values.

Failed when searching source: msstore
0x8a15005e : The server certificate did not match any of the expected values.

Le souci, c’est que winget interroge deux sources : winget et msstore. Sur une VM Azure, l’accès au Microsoft Store est souvent restreint ou cassé côté certificat, et c’est msstore qui fait planter la commande. Or le package est dispo sur la source winget, qui elle fonctionne.

La parade, c’est de forcer la source :

[CODE : install_msixtool_fix.ps1]

powershell

winget install Microsoft.MSIXPackagingTool --source winget

winget install Microsoft.MSIXPackagingTool --source winget

Et là ça passe, propre.

Note le message en fin d’install : l’outil te prévient que le MSIX Packaging Tool Driver doit être activé séparément dans les fonctionnalités Windows. Bonne nouvelle, l’outil sait l’activer tout seul à son premier lancement. Mauvaise nouvelle, il peut s’y reprendre à deux fois. On verra ça à l’étape III, pas la peine de s’en occuper maintenant.

II. Le certificat de signature : là où tout le monde se plante

Un package MSIX doit être signé. En production tu utilises ta PKI interne ou un certificat public. En lab, un certificat auto-signé suffit, à condition de respecter une règle d’or que je te donne tout de suite, parce que c’est elle qui m’a coûté le plus de temps.

Le subject du certificat doit correspondre exactement au Publisher name du package. Au caractère près. Si ton cert dit CN=Tazmen Lab, O=Tazmen, C=World, ton Publisher dans MSIX Packaging Tool doit dire exactement la même chose. La moindre virgule de travers, et la signature échoue.

On génère le certificat en PowerShell, en admin :

[CODE : new_cert.ps1]

powershell

# Crée le dossier de travail
New-Item -ItemType Directory -Path "C:\Tools" -Force

# Génère le certificat auto-signé
$cert = New-SelfSignedCertificate `
  -Type CodeSigningCert `
  -Subject "CN=Tazmen Lab, O=Tazmen, C=World" `
  -KeyUsage DigitalSignature `
  -FriendlyName "MSIX Lab Signing" `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

# Exporte le .pfx (pour signer) et le .cer (pour la confiance)
$pwd = ConvertTo-SecureString -String "TonMotDePasse123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.pfx" -Password $pwd
Export-Certificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.cer"

# Crée le dossier de travail
New-Item -ItemType Directory -Path "C:\Tools" -Force

# Génère le certificat auto-signé
$cert = New-SelfSignedCertificate `
  -Type CodeSigningCert `
  -Subject "CN=Tazmen Lab, O=Tazmen, C=World" `
  -KeyUsage DigitalSignature `
  -FriendlyName "MSIX Lab Signing" `
  -CertStoreLocation "Cert:\CurrentUser\My" `
  -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.3", "2.5.29.19={text}")

# Exporte le .pfx (pour signer) et le .cer (pour la confiance)
$pwd = ConvertTo-SecureString -String "TonMotDePasse123!" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.pfx" -Password $pwd
Export-Certificate -Cert $cert -FilePath "C:\Tools\MSIXLabCert.cer"

Le .pfx contient la clé privée, il sert à signer. Le .cer ne contient que la partie publique, il sert à faire confiance au package sur les machines cibles.

Je te préviens sur deux pièges vécus :

Piège 1 : la variable $cert meurt avec la session. Si tu fermes PowerShell entre la création du cert et l’export, $cert est vide et l’export plante avec Cannot bind argument to parameter 'Cert' because it is null. Garde la même fenêtre PowerShell ouverte du début à la fin, ou regénère le cert dans la nouvelle session.

Piège 2 : le dossier de destination doit exister. Si C:\Tools n’existe pas, l’export te sort un Le chemin d'accès spécifié est introuvable. (0x80070003). D’où le New-Item en première ligne. Ça paraît évident écrit comme ça, mais sur le moment on cherche midi à quatorze heures.

III. La capture MSIX, écran par écran

Lance MSIX Packaging Tool depuis le menu Démarrer. Choisis Create package, puis Create your package on this computer.

Prepare computer

L’outil vérifie l’environnement. C’est ici qu’il installe le MSIX Packaging Tool Driver si besoin. Le « Checking… » peut traîner une minute ou deux, laisse-le faire.

Deux lignes à regarder sur cet écran. Windows Update is active : l’outil va le désactiver temporairement pendant la capture, c’est normal et voulu. Pending reboot : si ta VM a un redémarrage en attente, l’outil peut le réclamer. Le cas échéant, redémarre et relance.

Select installer

Trois champs à remplir :

• Installer : pointe vers ton MSI Notepad++. Tu le télécharges d’abord avec Invoke-WebRequest depuis la release GitHub officielle.
• Installer arguments : mets /quiet /norestart pour une install silencieuse.
• Signing preference : choisis Sign with a certificate (.pfx) et sélectionne ton MSIXLabCert.pfx avec son mot de passe.

[CODE : download_npp.ps1]

powershell

$url = "https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.6.4/npp.8.9.6.4.Installer.x64.msi"
Invoke-WebRequest -Uri $url -OutFile "C:\Temp\npp8964.msi"

$url = "https://github.com/notepad-plus-plus/notepad-plus-plus/releases/download/v8.9.6.4/npp.8.9.6.4.Installer.x64.msi"
Invoke-WebRequest -Uri $url -OutFile "C:\Temp\npp8964.msi"

Package information

C’est l’écran sensible. Souviens-toi de la règle d’or : le Publisher name doit matcher le subject du certificat.

Quelques remarques sur les champs :

• Package name : pas de caractères spéciaux. Notepad++(x64) est refusé (les + et les parenthèses ne passent pas). Mets NotepadPlusPlus.
• Package display name : là tu peux mettre Notepad++ (x64), c’est juste l’affichage.
• Publisher name : exactement le subject du cert. L’outil affiche d’ailleurs « Subject of the certificate provided » à côté, pour te rappeler la contrainte.
• Version : attention, l’outil pré-remplit souvent une version tronquée du genre 8.9.6.0. La vraie version Notepad++ est 8.9.6.4. Corrige le dernier champ. Petit aveu : je ne l’ai pas fait sur le coup, mon package est sorti en 8.9.6.0. Ce n’est pas bloquant pour un lab, mais en prod tu veux que la version du package colle à la version réelle de l’app.

Accelerator

Cet écran sert aux templates de conversion pré-configurés. Tu n’en as pas besoin pour Notepad++. Next, sans rien renseigner.

Installation

L’installeur MSI tourne en arrière-plan, en mode capture. Tu ne verras pas forcément l’assistant graphique de Notepad++, c’est normal, le /quiet fait son office. L’écran te propose un Restart machine : ne clique pas dessus, Notepad++ n’a pas besoin de redémarrage. Next.

First launch tasks

L’outil a détecté notepad++.exe automatiquement, avec le bon chemin et l’icône. Clique sur Run pour lancer Notepad++. C’est l’étape de validation : l’app doit s’ouvrir normalement. Vérifie qu’elle démarre, puis ferme-la.

Une popup « Are you done? » apparaît. Tu as lancé l’app, c’est tout ce qu’il fallait capturer. Clique Yes, move on.

Package report

No services were detected : parfait pour Notepad++. Aucun service Windows à embarquer, le package reste propre. C’est exactement pour ça que Notepad++ est un bon cobaye. Next.

Create package

Dernière ligne droite. Change le Save location pour quelque chose de propre, par exemple C:\Temp\, plutôt que le Desktop par défaut. Puis Create.

Et voilà :

Package successfully created
C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix

Package successfully created
C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix

Le .msix signé est sur le disque. Première moitié du boulot faite.

IV. Du MSIX au CIM avec msixmgr (et le fameux 0x8bad0001)

Pour App Attach, le .msix ne suffit pas. Il faut le « dépaqueter » dans une image disque que les session hosts monteront dynamiquement. Deux formats existent : VHDX et CIM. Microsoft recommande CIM : montage plus rapide, moins de CPU et de RAM consommés, surtout sur Windows 11. On part là-dessus.

L’outil pour ça, c’est msixmgr, qu’on télécharge sur le lien court Microsoft :

[CODE : get_msixmgr.ps1]

powershell

Invoke-WebRequest -Uri "https://aka.ms/msixmgr" -OutFile "C:\Tools\msixmgr.zip"
Expand-Archive "C:\Tools\msixmgr.zip" -DestinationPath "C:\Tools\msixmgr" -Force

Invoke-WebRequest -Uri "https://aka.ms/msixmgr" -OutFile "C:\Tools\msixmgr.zip"
Expand-Archive "C:\Tools\msixmgr.zip" -DestinationPath "C:\Tools\msixmgr" -Force

Puis on génère le CIM. Le dossier de destination doit exister, et il faut un sous-dossier dédié parce qu’un CIM est composé de plusieurs fichiers, pas d’un seul :

[CODE : create_cim.ps1]

powershell

New-Item -ItemType Directory -Path "C:\Temp\CIM\NotepadPlusPlus" -Force

C:\Tools\msixmgr\x64\msixmgr.exe `
  -Unpack `
  -packagePath "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix" `
  -destination "C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim" `
  -applyACLs `
  -create `
  -fileType CIM `
  -rootDirectory Apps

New-Item -ItemType Directory -Path "C:\Temp\CIM\NotepadPlusPlus" -Force

C:\Tools\msixmgr\x64\msixmgr.exe `
  -Unpack `
  -packagePath "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix" `
  -destination "C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim" `
  -applyACLs `
  -create `
  -fileType CIM `
  -rootDirectory Apps

Et c’est là que j’ai buté un bon moment. Premier essai :

Successfully created the CIM file: ...notepadplusplus.cim
[WARNING] ... failed to get unpacked. Please try again:
Failed with HRESULT 0x8bad0001 when trying to unpack ...

Successfully created the CIM file: ...notepadplusplus.cim
[WARNING] ... failed to get unpacked. Please try again:
Failed with HRESULT 0x8bad0001 when trying to unpack ...

Le truc vicieux, c’est que le CIM est créé mais vide. Le message « Successfully created » te fait croire que c’est bon, alors que le contenu du package n’a pas été extrait. Si tu ne lis pas le warning juste en dessous, tu pars avec une coquille vide.

Le 0x8bad0001 veut dire que msixmgr ne fait pas confiance au certificat qui a signé le package. Logique : c’est un cert auto-signé, Windows ne le connaît pas. Il faut l’installer dans les bons magasins de certificats de la machine locale.

Première tentative, le magasin Trusted People :

[CODE : trust_cert_people.ps1]

powershell

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\TrustedPeople"

J’ai relancé msixmgr. Toujours 0x8bad0001. Le hic, c’est qu’un certificat auto-signé est sa propre autorité racine : pour que la chaîne de confiance soit complète, il doit aussi être dans le magasin Trusted Root Certification Authorities.

[CODE : trust_cert_root.ps1]

powershell

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\Root"

Import-Certificate `
  -FilePath "C:\Tools\MSIXLabCert.cer" `
  -CertStoreLocation "Cert:\LocalMachine\Root"

Windows t’affiche un avertissement de sécurité à l’import dans Root, confirme avec Oui. C’est normal, tu déclares faire confiance à une autorité que tu viens de créer toi-même.

Pour mettre toutes les chances de ton côté, active aussi le mode développeur qui lève les restrictions de signature MSIX en local :

[CODE : enable_devmode.ps1]

powershell

$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null }
Set-ItemProperty -Path $regPath -Name "AllowDevelopmentWithoutDevLicense" -Value 1
Set-ItemProperty -Path $regPath -Name "AllowAllTrustedApps" -Value 1

$regPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModelUnlock"
if (-not (Test-Path $regPath)) { New-Item -Path $regPath -Force | Out-Null }
Set-ItemProperty -Path $regPath -Name "AllowDevelopmentWithoutDevLicense" -Value 1
Set-ItemProperty -Path $regPath -Name "AllowAllTrustedApps" -Value 1

Je nettoie le CIM raté, je le regénère, et cette fois :

[Warning] The app ... depends on the following packages to run correctly:
Microsoft.WindowsAppRuntime.1.4
Successfully created the CIM file: C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim

[Warning] The app ... depends on the following packages to run correctly:
Microsoft.WindowsAppRuntime.1.4
Successfully created the CIM file: C:\Temp\CIM\NotepadPlusPlus\notepadplusplus.cim

Plus de 0x8bad0001. Le CIM est rempli pour de bon. Le nouveau warning sur Microsoft.WindowsAppRuntime.1.4 est juste informatif, on va le traiter à l’étape suivante.

En clair, pour qu’un CIM se génère vraiment : le cert doit être dans TrustedPeople ET Root sur la machine de packaging. Les deux. Note-le bien.

V. Tester le package en local (sans host pool)

Pas besoin d’un host pool AVD pour valider que ton package fonctionne. Tu peux l’installer directement sur la VM de packaging avec Add-AppxPackage. C’est même recommandé avant de partir sur le déploiement.

[CODE : install_local.ps1]

powershell

Add-AppxPackage -Path "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix"

Add-AppxPackage -Path "C:\Temp\NotepadPlusPlus_8.9.6.0_x64__74sz6hfr72mwy.msix"

Et là, dernier piège de la série :

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF3
... this package depends on a framework that could not be found.
Provide the framework "Microsoft.WindowsAppRuntime.1.4" ...

Add-AppxPackage : Deployment failed with HRESULT: 0x80073CF3
... this package depends on a framework that could not be found.
Provide the framework "Microsoft.WindowsAppRuntime.1.4" ...

C’est exactement le warning qu’on avait eu en générant le CIM. Notepad++ packagé en MSIX a besoin du Windows App Runtime 1.4, qui n’est pas présent sur la VM. Il faut l’installer à part.

Le réflexe Invoke-WebRequest sur aka.ms m’a donné un fichier corrompu (« The file or directory is corrupted and unreadable »), et le lien GitHub direct s’est fait couper par le réseau de la VM. Ce qui a marché du premier coup, c’est encore winget :

[CODE : install_runtime.ps1]

powershell

winget install Microsoft.WindowsAppRuntime.1.4 --source winget

winget install Microsoft.WindowsAppRuntime.1.4 --source winget

60,6 Mo téléchargés, installé. Je relance l’install du package, et cette fois Notepad++ apparaît dans le menu Démarrer et se lance comme une app native.

Pour le désinstaller après ton test :

[CODE : uninstall_local.ps1]

powershell

Get-AppxPackage -Name "NotepadPlusPlus" | Remove-AppxPackage

Get-AppxPackage -Name "NotepadPlusPlus" | Remove-AppxPackage

À retenir pour la suite : sur tes session hosts AVD, ce runtime devra aussi être présent, soit dans le golden image, soit poussé par Intune ou GPO avant l’attachement. Une dépendance manquante côté host, et ton app refusera de démarrer même parfaitement packagée.

Ce que je retiens

Le packaging MSIX en lui-même n’est pas compliqué. L’assistant fait le job. Ce qui coince, c’est la chaîne de confiance et les dépendances, et aucun de ces points n’est mis en avant dans les tutos « trois clics ».

Si tu ne devais retenir que quatre choses :

1. Force --source winget sur les VMs Azure, la source msstore est cassée.
2. Le Publisher name = le subject du cert, au caractère près, sinon la signature saute.
3. Le cert auto-signé va dans TrustedPeople ET Root, sinon msixmgr sort un 0x8bad0001 et te génère un CIM vide en te faisant croire que tout va bien.
4. Le Windows App Runtime est une dépendance à installer séparément, sur la VM de test comme sur les session hosts.

À ce stade tu as un .msix signé, testé et validé, et un CIM prêt à être attaché. C’est tout ce dont tu as besoin pour la suite.

Et la suite, justement, c’est l’attachement réel : monter le CIM sur un Azure Files, gérer les permissions SMB quand tes session hosts sont hors domaine AD classique, et faire la registration App Attach côté host pool. Ça, ça mérite son propre guide, parce que c’est un autre niveau de pièges. Je le détaillerai dans un article séparé.

A bientôt Louis 🐇 🤜 🤛 🐰

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 :

1. 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).
2. 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

# 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 :

1. Une même IP accède à /epa/scripts/win/nsepa_setup.exe.
2. 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

L’architecture d’Azure Virtual Desktop (AVD) franchit une étape significative en matière de conformité et de performance. Microsoft vient d’annoncer la disponibilité en Public Preview des Regional Host Pools. Cette fonctionnalité répond à une problématique centrale pour les architectes DaaS (Desktop as a Service) opérant dans des environnements régulés : la localisation des métadonnées de service.

Jusqu’à présent, la conception d’AVD imposait une dichotomie entre la localisation des ressources de calcul (les machines virtuelles des hôtes de session) et celle des métadonnées de configuration du service. Cette annonce permet enfin d’aligner ces deux composantes critiques.

1. Analyse Technique

Pour comprendre l’impact de cette annonce, il faut revenir sur l’architecture fondamentale du plan de contrôle (Control Plane) d’AVD, géré par Microsoft.

Le paradigme historique : Géographie vs Région

Historiquement, lorsque vous déployiez un Host Pool AVD, vous deviez sélectionner une géographie pour le stockage des métadonnées (par exemple, « États-Unis », « Europe », « Japon »). Ces métadonnées incluent les configurations des Host Pools, des App Groups et des Workspaces, ainsi que les attributions d’utilisateurs.

Parallèlement, vos hôtes de session (les VMs où travaillent les utilisateurs) étaient déployés dans une région Azure spécifique (par exemple, « France Central », « Germany West Central »).

Cette architecture créait une dissonance : vos données utilisateurs pouvaient résider en Allemagne, mais la configuration du service indiquant qui a accès à quoi était stockée dans une base de données globale située ailleurs dans la géographie européenne.

Le nouveau modèle : Alignement Régional

Avec les Regional Host Pools en Public Preview, il est désormais possible de stocker les métadonnées du service AVD dans la même région Azure que les hôtes de session.

Le plan de contrôle AVD devient distribué. Lorsqu’un utilisateur initie une connexion, le broker AVD interroge une base de données locale à la région, plutôt qu’une base de données consolidée au niveau géographique.

Les régions initialement supportées dans cette preview incluent des zones stratégiques en termes de conformité :

• Germany West Central
• UK South
• Central India
• Canada Central
• (Liste complète incluant US, Japan, Australia, South Africa et North Europe dans l’annonce officielle).

Il est crucial de noter que cette fonctionnalité ne concerne que les métadonnées de service. Les profils utilisateurs (FSLogix) et les images disques des VMs ont toujours pu être localisés précisément ; c’est le dernier maillon de la chaîne de configuration qui est ici traité.

2. Impacts sur l’Infrastructure

L’introduction des Regional Host Pools a des conséquences directes et positives sur la conception des infrastructures VDI/DaaS dans Azure.

Souveraineté des données et Conformité (Compliance)

C’est l’impact majeur. Pour les entreprises soumises à des régulations strictes sur la résidence des données (RGPD en Europe, régulations fédérales en Allemagne, etc.), l’ancien modèle posait problème. Les auditeurs pouvaient tiquer sur le fait que des informations de configuration, même sans données personnelles directes, sortaient des frontières nationales.

En alignant métadonnées et compute dans des régions comme Germany West Central ou Central India, l’architecture DaaS devient intrinsèquement plus conforme aux exigences de souveraineté numérique locales.

Latence et Performance du Control Plane

Bien que l’impact sur la latence en session (la frappe au clavier) soit nul, l’impact sur la phase d’initialisation de la connexion peut être positif.

Le processus de brokering (authentification, identification des ressources disponibles, redirection vers un hôte) implique des requêtes vers le stockage des métadonnées. En rapprochant ce stockage du point d’entrée de l’utilisateur et des VMs cibles, on réduit potentiellement les délais de transit réseau sur le backbone Azure durant cette phase critique de « Logon ».

3. Recommandations

En tant qu’architectes d’infrastructure, comment devons-nous appréhender cette nouveauté ?

1. Posture « Public Preview » : Comme pour toute fonctionnalité en preview, elle n’est assortie d’aucun SLA (Service Level Agreement). Il est donc formellement déconseillé de l’utiliser pour des charges de travail de production critiques immédiates.
2. Stratégie de Test : C’est le moment idéal pour déployer des environnements de POC (Proof of Concept) dans les régions supportées si vous avez des exigences de compliance dans ces zones. Validez le comportement du broker et assurez-vous que tous vos outils tiers (monitoring, automation) interagissent correctement avec ces nouveaux objets régionaux.
3. Pas de Migration In-Place : Point d’attention critique, Microsoft ne propose actuellement aucun chemin de migration pour les Host Pools existants. Vous ne pouvez pas déplacer un Host Pool « géographique » vers un modèle « régional ».
   • Action : L’adoption nécessitera une stratégie de déploiement « greenfield » (nouveau déploiement) suivi d’une bascule des utilisateurs, plutôt qu’une mise à niveau transparente.
4. Infrastructure as Code (IaC) : Mettez à jour vos templates Bicep ou Terraform. Vos paramètres location pour les ressources Microsoft.DesktopVirtualization/hostPools devront désormais pointer vers des régions spécifiques (ex: germanywestcentral) et non plus des géographies, pour les déploiements ciblant cette nouvelle architecture.

Conclusion

L’arrivée des Regional Host Pools pour Azure Virtual Desktop est une évolution mature du service. Elle démontre la volonté de Microsoft d’adapter son offre DaaS aux réalités complexes de la conformité internationale et de la souveraineté des données, levant ainsi un frein important à l’adoption d’AVD dans des secteurs hautement régulés.

Source : https://techcommunity.microsoft.com/blog/azurevirtualdesktopblog/now-in-public-preview-azure-virtual-desktop-regional-host-pools/4474598