SmartScreen, réputation et fichiers « bloqués » : réel vs bruit

Ce que fait réellement SmartScreen (et ce qu’il ne fait pas)

SmartScreen est un service de réputation et une couche d’application qui essaie de répondre à une question désordonnée :
« Cet élément est-il susceptible de nuire à l’utilisateur ? » Il le fait avec des signaux de réputation — prévalence des téléchargements, comportement observé,
télémétrie, réputation des URL, et si le fichier ressemble à des familles de malwares connues. Ce n’est pas uniquement basé sur des signatures, et
ce n’est pas un « antivirus », bien qu’il chevauche absolument Defender et d’autres contrôles.

En pratique, SmartScreen apparaît à plusieurs endroits :

• Microsoft Edge (et parfois d’autres navigateurs via Windows) : vérifications de réputation d’URL et de téléchargement.
• Explorateur / ShellExecute : quand vous double-cliquez sur un fichier téléchargé, Windows peut consulter SmartScreen.
• Paramètres Windows Security : bascules et politiques de « protection basée sur la réputation ».

SmartScreen n’est pas déterministe. Deux utilisateurs téléchargeant le « même » fichier peuvent obtenir des résultats différents si :
le hash du fichier diffère (installateur repackagé, build différent), un utilisateur est derrière un proxy inspectant le TLS qui réécrit
le contenu, le fichier provient d’une zone différente (intranet vs internet), ou la politique diffère selon l’OU.

SmartScreen ne prouve pas non plus qu’il s’agit de malware. Il prouve plus souvent « faible réputation » ou « inconnu » que « malveillant ».
Dans les environnements d’entreprise, cette distinction importe. Les outils à faible réputation sont courants : utilitaires internes, installateurs de fournisseurs de niche,
builds récents, et EXE de « correctif rapide » poussés par des équipes allergiques à l’ingénierie des releases.

Voici la posture opérationnelle qui vous garde sain d’esprit : traitez SmartScreen comme un indice de triage.
Lorsqu’il signale quelque chose, vérifiez la provenance et l’intégrité. Si c’est connu et sûr, corrigez le chemin de distribution pour que la réputation
s’améliore et que les avertissements disparaissent. N’apprenez pas aux gens à le contourner pour toujours.

Réputation vs signature de code : liés, mais pas interchangeables

La signature de code répond à : « Qui prétend avoir construit ça ? » La réputation répond à : « À quelle fréquence avons-nous vu ceci, et comment s’est-il comporté ? »
Les deux peuvent être usurpés ou abusés, mais les modes de défaillance diffèrent.

Unsigned ne veut pas dire malveillant. Signé ne veut pas dire sûr.

Beaucoup d’outils internes ne sont pas signés. Certains fournisseurs expédient encore des utilitaires non signés. SmartScreen les sanctionnera plus souvent,
surtout lorsqu’ils sont nouveaux ou peu téléchargés.

Pendant ce temps, il existe des malwares signés. Des certificats sont volés. Des acteurs peu scrupuleux achètent des certificats.
Et parfois un fournisseur légitime livre quelque chose qui se comporte comme de l’adware parce que leur plan de monétisation implique des « offres optionnelles » et la flexibilité morale d’un vendeur de voitures d’occasion.

Ce que la signature change en pratique

• Interface de confiance utilisateur : « Éditeur inconnu » contre un éditeur nommé.
• Contrôles de politique : AppLocker / WDAC peuvent se baser sur le signataire.
• Montée en réputation : les binaires signés gagnent souvent de la réputation plus rapidement que les non signés, toutes choses égales par ailleurs.

Si vous déployez largement des EXE internes, investissez dans la signature. Pas parce que c’est à la mode, mais parce que cela transforme un ticket helpdesk récurrent
en non-événement. Cela vous donne aussi une histoire propre de révocation quand (pas si) vous devez retirer quelque chose.

Une citation qui devrait être collée sur l’écran de chaque ingénieur release :
« L’espoir n’est pas une stratégie. » — souvent attribuée aux cercles opérationnels ; considérez ceci comme une idée paraphrasée largement utilisée en ingénierie/fiabilité.

Le modèle de réputation de SmartScreen récompense la constance ennuyeuse : URL de téléchargement stable, identité de signature stable, packaging stable,
et ne pas repackager l’installateur tous les deux jours parce que quelqu’un a changé un logo.

Fichiers « bloqués » : MOTW, Zone.Identifier et Attachment Manager

Quand les utilisateurs disent « le fichier est bloqué », ils peuvent vouloir dire trois choses différentes :

1. Avertissement SmartScreen lors du lancement d’un fichier.
2. Blocage par Attachment Manager dû aux informations de zone (Mark of the Web).
3. Application d’une politique (AppLocker, WDAC, SRP, quarantaine EDR, Controlled Folder Access, etc.).

Mark of the Web (MOTW) est généralement le responsable de la case à cocher « Ce fichier provient d’un autre ordinateur et peut être bloqué »
que vous voyez dans les Propriétés d’un fichier. Sous le capot, c’est un flux de données alternatif NTFS (ADS) nommé Zone.Identifier.
Il stocke une « zone » (Internet, Intranet, Trusted, etc.) et parfois une URL référente.

MOTW n’est pas un jugement moral. C’est des métadonnées de provenance. Le fichier peut être parfaitement sûr, mais Windows le traitera comme
provenant de la zone Internet, ce qui entraîne plus de invites et une inspection accrue.

Pourquoi les archives et les fichiers extraits se comportent bizarrement

MOTW peut se propager. Si un ZIP est tagué avec MOTW, Windows peut marquer aussi les fichiers extraits. C’est bon pour la sécurité, pénible pour
l’automatisation, et absolument dévastateur pour les flux de travail « téléchargez un ZIP de scripts et exécutez-les ».

Et oui : vous pouvez supprimer MOTW. Vous devriez le faire seulement après avoir établi la provenance et l’intégrité. Si votre workflow standard
exige de supprimer MOTW pour fonctionner, c’est un signe. Corrigez le canal de distribution.

Blague n°1 : SmartScreen n’est pas paranoïaque. C’est juste le seul dans la pièce qui se souvient de ce que les utilisateurs cliquent.

Faits intéressants et brève histoire (ce que l’on oublie)

• SmartScreen n’a pas commencé dans Windows. Il a été introduit comme filtre anti-phishing dans Internet Explorer avant de devenir un système de réputation plus large.
• « Réputation » est en partie popularité. Les binaires à faible prévalence (builds récents, outils de niche) sont statistiquement plus risqués, donc ils reçoivent plus d’avertissements.
• MOTW utilise des flux de données alternatifs NTFS. Ce sont des métadonnées attachées au fichier, pas un fichier différent que vous pouvez voir dans l’Explorateur.
• Les chemins de copie peuvent supprimer MOTW. Déplacer un fichier via des systèmes de fichiers non NTFS, certains archivageurs, ou certains outils de copie peut supprimer les métadonnées ADS.
• Le comportement d’extraction des ZIP a évolué. Windows a fait évoluer la propagation de MOTW aux contenus extraits pour réduire les attaques « télécharger, dézipper, exécuter une macro ».
• SmartScreen est distinct de Defender AV. Ils peuvent tous deux bloquer l’exécution, mais utilisent des signaux et des expériences utilisateur différents.
• La réputation liée à la signature de code est réelle. Une identité de signature cohérente aide à éviter les invites « éditeur inconnu » et peut améliorer les résultats de réputation.
• Les proxies d’entreprise peuvent créer des « nouveaux fichiers ». L’inspection SSL ou la réécriture de contenu peut changer les hashes, réinitialisant effectivement la réputation et compliquant le dépannage.

Playbook de diagnostic rapide

Quand un fichier est « bloqué », ne commencez pas par vous disputer avec l’utilisateur sur ce qu’il a cliqué. Commencez par classifier le blocage.
Le goulot d’étranglement est généralement l’un des suivants : métadonnées de provenance, réputation, politique, ou détection réelle de malware.

1) Identifier précisément le symptôme

• S’agit-il d’un dialogue SmartScreen « Windows a protégé votre PC » ?
• S’agit-il d’une situation Propriétés → Débloquer (case à cocher) ?
• S’agit-il d’un message « Votre organisation a utilisé le contrôle d’application » / AppLocker ?
• EDR a-t-il mis le fichier en quarantaine silencieusement ?

2) Vérifier d’abord la présence de MOTW / Zone.Identifier

C’est le plus rapide à confirmer et le plus simple à corriger en toute sécurité une fois la source vérifiée.
Si MOTW est présent, comprenez comment il s’y est retrouvé : téléchargement navigateur, pièce jointe email, synchronisation Teams/SharePoint,
ou « quelqu’un l’a copié depuis la pièce jointe d’un ticket ».

3) Valider la signature et le hash

Si c’est censé être un logiciel fournisseur, il doit être signé. Si c’est interne, il devrait l’être aussi — éventuellement.
Hashez le fichier, comparez avec votre magasin d’artefacts connu-bon, et arrêtez de deviner.

4) Déterminer quel contrôle l’a bloqué

SmartScreen, Defender, AppLocker, WDAC et votre EDR peuvent tous « bloquer ». Leurs logs sont différents. Votre travail est de trouver
le premier point d’application, pas la dernière plainte.

5) Corriger le chemin de distribution, pas l’endpoint

Si votre « correction » consiste à dire aux utilisateurs de cliquer sur « Exécuter quand même », vous n’avez rien corrigé. Vous avez ajouté une exception fragile qui
échouera à l’échelle, lors d’une panne, ou sous audit.

Tâches pratiques : commandes, sorties et décisions

Ci-dessous se trouvent des vérifications pratiques qui séparent le « risque réel » de la « taxe de workflow ». Chaque tâche inclut : une commande, à quoi ressemble la sortie,
et la décision opérationnelle que vous prenez.

Task 1: Check MOTW (Zone.Identifier) presence on a file

cr0x@server:~$ pwsh -NoProfile -Command "Get-Item -LiteralPath 'C:\Users\alice\Downloads\tool.exe' -Stream Zone.Identifier -ErrorAction SilentlyContinue | Format-List"
Stream         : Zone.Identifier
Length         : 132

Ce que cela signifie : Le fichier a MOTW. Windows le traitera comme téléchargé depuis une zone (souvent Internet).

Décision : Ne débloquez pas encore. Vérifiez d’abord la source/la signature/le hash. Ensuite décidez de supprimer MOTW ou de corriger la distribution.

Task 2: Read the Zone.Identifier content (what zone is it?)

cr0x@server:~$ pwsh -NoProfile -Command "Get-Content -LiteralPath 'C:\Users\alice\Downloads\tool.exe' -Stream Zone.Identifier"
[ZoneTransfer]
ZoneId=3
ReferrerUrl=https://example.invalid/download
HostUrl=https://example.invalid/tool.exe

Ce que cela signifie : ZoneId=3 indique typiquement la zone Internet. Referrer/Host peut expliquer le chemin.

Décision : Si l’URL hôte est inattendue (système de ticketing, passerelle email, miroir inconnu), traitez comme suspect jusqu’à vérification.

Task 3: Unblock a file (remove MOTW) after verification

cr0x@server:~$ pwsh -NoProfile -Command "Unblock-File -LiteralPath 'C:\Users\alice\Downloads\tool.exe'; 'unblocked'"
unblocked

Ce que cela signifie : MOTW est supprimé. Les invites de l’Explorateur et SmartScreen peuvent changer.

Décision : Si vous faites cela de manière répétée pour le même artefact, arrêtez. Déplacez l’artefact vers un canal logiciel géré ou signez-le.

Task 4: Check if a whole folder is full of MOTW-tagged files

cr0x@server:~$ pwsh -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\Users\alice\Downloads\vendor-kit' -Recurse -File | ForEach-Object { Get-Item $_.FullName -Stream Zone.Identifier -ErrorAction SilentlyContinue | Select-Object PSPath,Stream,Length } | Select-Object -First 5"
PSPath                                                        Stream          Length
------                                                        ------          ------
Microsoft.PowerShell.Core\FileSystem::C:\Users\alice\Downloads\vendor-kit\a.exe Zone.Identifier 126
Microsoft.PowerShell.Core\FileSystem::C:\Users\alice\Downloads\vendor-kit\b.dll Zone.Identifier 126

Ce que cela signifie : L’extraction de l’archive a propagé MOTW largement.

Décision : Préférez distribuer via un installateur signé/MSI ou un gestionnaire de paquets interne plutôt qu’un ZIP de binaires.

Task 5: Verify Authenticode signature

cr0x@server:~$ pwsh -NoProfile -Command "Get-AuthenticodeSignature -LiteralPath 'C:\Users\alice\Downloads\tool.exe' | Format-List Status,StatusMessage,SignerCertificate"
Status         : Valid
StatusMessage  : Signature verified.
SignerCertificate : [Subject]
  CN=Vendor Corp, O=Vendor Corp, L=Seattle, S=WA, C=US

Ce que cela signifie : La signature est valide et chaînée à une racine de confiance sur cette machine.

Décision : Si SmartScreen affiche toujours un avertissement, vous avez probablement affaire à la réputation/faible prévalence ou à un binaire repackagé. Investiguer la cohérence de la distribution.

Task 6: Detect “Unknown publisher” cause (unsigned or signature failure)

cr0x@server:~$ pwsh -NoProfile -Command "Get-AuthenticodeSignature -LiteralPath 'C:\Users\alice\Downloads\tool.exe' | Format-List Status,StatusMessage"
Status         : NotSigned
StatusMessage  : No signature was present in the subject.

Ce que cela signifie : Binaire non signé. Cela augmente les invites et diminue les signaux de confiance.

Décision : Pour les outils internes : priorisez la signature. Pour les outils fournisseurs : faites pression sur le fournisseur ou empaquetez-les dans un installateur/paquet signé.

Task 7: Hash the file for integrity and dedup across sources

cr0x@server:~$ pwsh -NoProfile -Command "Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\Users\alice\Downloads\tool.exe'"
Algorithm       Hash                                                             Path
---------       ----                                                             ----
SHA256          2C2D6B0E0E5A9B7B0B0A7E0D6A1C8F1A8B8A0B1C2D3E4F5061728394A5B6C7D8 C:\Users\alice\Downloads\tool.exe

Ce que cela signifie : Vous avez une empreinte stable pour comparaison.

Décision : Si deux utilisateurs rapportent des hashes différents pour la « même » URL de téléchargement, suspectez la réécriture du proxy, des miroirs différents, ou des rebuilds.

Task 8: Check SmartScreen / Windows Defender operational events (local)

cr0x@server:~$ pwsh -NoProfile -Command "Get-WinEvent -LogName 'Microsoft-Windows-Windows Defender/Operational' -MaxEvents 5 | Select-Object TimeCreated,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
02/05/2026 10:14:22 1116 Information      The antimalware platform detected malware or other potentially unwanted software.

Ce que cela signifie : Defender a enregistré un événement de détection. C’est au-delà du territoire « application inconnue » de SmartScreen.

Décision : Traitez comme un workflow d’incident de sécurité : isoler, capturer l’échantillon en sécurité, confirmer le nom de détection, valider la source, et coordonner avec SecOps.

Task 9: Check SmartScreen-related logs (application experience / shell)

cr0x@server:~$ pwsh -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-SmartScreen/Debug'; StartTime=(Get-Date).AddDays(-1)} -ErrorAction SilentlyContinue | Select-Object -First 3 | Format-List TimeCreated,Id,Message"
TimeCreated : 02/05/2026 09:58:01
Id          : 1000
Message     : SmartScreen check performed for file: C:\Users\alice\Downloads\tool.exe

Ce que cela signifie : Un contrôle SmartScreen a eu lieu. Selon la configuration du système, les logs de debug peuvent être rares ou désactivés.

Décision : Si vous ne pouvez pas voir les logs à cause de la politique, passez à la vérification de la politique (GPO/MDM) et reproduisez sur une machine de test contrôlée.

Task 10: Confirm reputation-based protection settings (local Defender prefs)

cr0x@server:~$ pwsh -NoProfile -Command "Get-MpPreference | Select-Object EnableSmartScreen,PUAProtection,DisableIOAVProtection | Format-List"
EnableSmartScreen      : True
PUAProtection          : 1
DisableIOAVProtection  : False

Ce que cela signifie : SmartScreen est activé ; la protection PUA est activée (bloque souvent les « bundlers ») ; le scan IOAV est activé (le contenu téléchargé est scanné).

Décision : Si un problème de « blocage » corrèle avec l’activation de la protection PUA, examinez si le logiciel inclut des bundlers/offres optionnelles et remplacez-le.

Task 11: Identify AppLocker enforcement vs audit (classic “it runs for me” trap)

cr0x@server:~$ pwsh -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-AppLocker/EXE and DLL'; StartTime=(Get-Date).AddDays(-7)} -MaxEvents 3 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated           Id Message
-----------           -- -------
02/04/2026 16:20:41 8004 EXE was blocked. File path: C:\Users\alice\Downloads\tool.exe

Ce que cela signifie : AppLocker a bloqué l’exécution. Ce n’est pas la réputation SmartScreen ; c’est la politique.

Décision : Créez/ajustez des règles allow (préférez les règles par éditeur pour le code signé). Ne dites pas aux utilisateurs de « débloquer » un fichier que la politique interdit.

Task 12: Check WDAC / Code Integrity logs (Windows 10/11/Server)

cr0x@server:~$ pwsh -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-CodeIntegrity/Operational'; StartTime=(Get-Date).AddDays(-7)} -MaxEvents 3 | Select-Object TimeCreated,Id,Message | Format-Table -Wrap"
TimeCreated           Id Message
-----------           -- -------
02/04/2026 16:20:44 3077 Code Integrity determined that a process (\Device\HarddiskVolume3\Users\alice\Downloads\tool.exe) attempted to load.

Ce que cela signifie : Code Integrity est dans le chemin (souvent WDAC). Vous avez besoin de la décision de politique, pas seulement des métadonnées du fichier.

Décision : Si WDAC est en enforcement, corrigez en mettant à jour la politique WDAC pour autoriser le signataire/le chemin/le hash selon le cas — préférez l’autorisation par signataire.

Task 13: Identify if the file is coming from a browser or email path (common MOTW sources)

cr0x@server:~$ pwsh -NoProfile -Command "Get-ChildItem -LiteralPath 'C:\Users\alice\Downloads' -Filter *.exe | Sort-Object LastWriteTime -Descending | Select-Object -First 3 Name,LastWriteTime"
Name       LastWriteTime
----       -------------
tool.exe   02/05/2026 09:55:12
agent.exe  02/04/2026 11:02:48
setup.exe  02/03/2026 15:33:09

Ce que cela signifie : Établit la chronologie. Corrélez avec des changements de proxy, des campagnes email, ou de nouvelles releases.

Décision : Si cela a commencé juste après un changement réseau/sécurité, concentrez-vous sur le canal de distribution et la réécriture de contenu, pas sur l’endpoint.

Task 14: Detect if an archive is carrying MOTW and needs a safer handling process

cr0x@server:~$ pwsh -NoProfile -Command "Get-Item -LiteralPath 'C:\Users\alice\Downloads\bundle.zip' -Stream Zone.Identifier -ErrorAction SilentlyContinue | Format-List"
Stream         : Zone.Identifier
Length         : 128

Ce que cela signifie : Le ZIP lui-même est tagué. L’extraction peut propager la balise.

Décision : Préférez un installateur signé ou un dépôt d’artefacts interne + flux de packaging, plutôt que « télécharger un ZIP et exécuter ».

Blague n°2 : La seule chose plus persistante que MOTW est l’unique exécutif qui transfère des EXE par email « parce que c’est plus rapide ».

Trois mini-récits en entreprise (comment ça casse dans la vraie vie)

Mini-récit 1 : L’incident causé par une fausse hypothèse

Une entreprise de taille moyenne a déployé un nouvel outil interne de support. C’était un petit EXE développé par une équipe d’infrastructure : il collectait
des logs, les zippait, et les téléchargeait dans un ticket. Il n’était pas signé. L’équipe a supposé que parce qu’il était hébergé sur leur intranet,
Windows le traiterait comme « approuvé ».

Dès le premier jour, la moitié des utilisateurs ont eu des avertissements SmartScreen. L’autre moitié non. L’équipe de support a conclu que SmartScreen était « aléatoire »
et a dit aux utilisateurs de cliquer sur « Exécuter quand même ». Cette consigne a été recopiée dans un article de base de connaissances qui a vécu pendant des années,
comme une colonie de drosophiles.

Le vrai problème n’était pas l’aléa. C’était la provenance. Certains utilisateurs ont téléchargé via un navigateur moderne qui a apposé MOTW et déclenché
des vérifications SmartScreen. D’autres ont reçu l’outil via un partage réseau où les métadonnées ADS n’existaient pas ou ne se propageaient pas de la même manière.
Quelques utilisateurs l’ont récupéré depuis une pièce jointe email—garantie MOTW et scrutiny supplémentaire.

L’incident s’est produit plus tard, et il a été douloureux : une campagne de phishing a livré un EXE usurpateur ressemblant à l’outil de support.
Les utilisateurs avaient été formés à contourner l’avertissement. SmartScreen faisait son travail ; l’organisation avait appris aux gens à l’ignorer.
Le nettoyage n’a pas été que technique—la sécurité a dû démêler un anti-pattern culturel.

La correction a été ennuyeuse et efficace : signer l’outil interne, le publier via un portail logiciel géré, et retirer la directive « Exécuter quand même ».
Les avertissements SmartScreen ont fortement diminué. Plus important : les avertissements sont redevenus significatifs.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a estimé que les téléchargements étaient trop lents pour les utilisateurs distants. Ils ont introduit une couche d’optimisation : un proxy qui mettait en cache
les installateurs et effectuait l’inspection SSL. Le but était noble : réduire la bande passante et accélérer la distribution logicielle.

En une semaine, SmartScreen a commencé à signaler un installateur fournisseur largement utilisé comme « application non reconnue ». Il fonctionnait depuis des années.
Le support a accusé Microsoft. La sécurité a accusé le fournisseur. Le fournisseur a accusé « votre environnement ». Tout le monde avait raison, d’une pire manière.

Le proxy réécrivait les réponses. Pas malicieusement—juste assez pour changer le hash de la charge utile. Le binaire livré aux utilisateurs n’était plus
identique octet par octet à ce que le fournisseur avait expédié. Les systèmes de réputation sont sensibles au hash ; vous n’obtenez pas de crédit pour « à peu près le même EXE ».

L’optimisation cassait aussi la vérification de la signature de façon intermittente. Certains fichiers arrivaient intacts, d’autres non, selon le comportement du cache.
L’équipe a appris à la dure que « l’optimisation de contenu » est indiscernable d’une altération à moins de contrôler toute la chaîne.

La résolution : exclure l’inspection SSL pour les domaines de distribution logicielle, mettre en cache seulement au niveau du paquet (pas en réécrivant le fichier),
et distribuer le logiciel via un système de packaging interne qui produisait des artefacts stables et signés. La performance s’est améliorée et les avertissements ont cessé.
L’« optimisation » n’a fonctionné qu’après avoir arrêté d’être trop futée.

Mini-récit 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une grande entreprise avait une règle qui agaçait les développeurs : tout exécutable interne devait être signé, et chaque release devait publier
un hash SHA-256 dans un index d’artefacts interne. La politique était appliquée par CI, pas par l’espoir.

Un matin, SmartScreen a commencé à avertir sur un utilitaire lié à la paie qui n’avait jamais déclenché d’avertissement. Les utilisateurs ont paniqué parce que
le logiciel de paie attire rapidement l’attention des cadres. L’équipe endpoint n’a pas commencé par désactiver quoi que ce soit. Ils ont suivi le playbook ennuyeux.

D’abord, ils ont comparé les hashes des machines affectées à l’index d’artefacts. Mismatch. Puis ils ont validé la signature : toujours « Valide », mais signée
par un certificat différent de celui attendu. Cela a réduit le problème de « Microsoft nous bloque » à « nous n’exécutons pas l’artefact que nous croyons exécuter ».

Il s’est avéré qu’un agent de build avait été ré-imagé et avait récupéré la mauvaise clé de signature depuis un chemin d’un coffre hérité. Rien de malveillant ; juste
une erreur de gestion des clés. Mais SmartScreen a réagi parce que la réputation attachée à l’identité de signature connue ne s’appliquait pas à la nouvelle.

Parce qu’ils avaient des hashes et une discipline de signature, l’équipe est revenue en arrière en quelques heures, a republé la build correcte signée, et a restauré
la chaîne de certificats attendue. Les avertissements SmartScreen ont disparu. Le postmortem a été court et indulgent.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: « La case Débloquer apparaît sur un installateur fournisseur à chaque fois »

Cause racine : MOTW est appliqué par le chemin de téléchargement ; les utilisateurs enregistrent depuis la zone Internet, puis lancent depuis Downloads.

Correction : Vérifiez la signature + le hash, puis distribuez via un canal logiciel géré (Intune/ConfigMgr/dépôt de paquets). Ne normalisez pas le débloquage manuel.

2) Symptom: SmartScreen avertit sur des outils internes mais pas sur les mêmes outils depuis un partage de fichiers

Cause racine : Différences de métadonnées de zone ; la copie depuis un partage peut supprimer ADS/MOTW ; les téléchargements navigateur le marquent.

Correction : Cessez de compter sur la « magie du partage ». Signez les outils et distribuez de façon cohérente. Si vous avez besoin de zones de confiance, utilisez des mécanismes d’entreprise adaptés.

3) Symptom: Même URL, utilisateurs différents, résultats SmartScreen différents

Cause racine : Hashs de fichier différents dus à la réécriture par proxy, miroirs différents, ou repackaging « utile ».

Correction : Hashez le fichier sur plusieurs endpoints, comparez. Corrigez le chemin de distribution pour fournir des octets identiques de bout en bout.

4) Symptom: Les utilisateurs voient « Votre organisation a utilisé le contrôle d’application pour bloquer cette application »

Cause racine : Application de la politique WDAC ; ce n’est pas SmartScreen.

Correction : Mettez à jour la politique WDAC avec des règles basées sur le signataire, ou placez l’outil dans une pipeline signée approuvée. Ne demandez pas aux utilisateurs de débloquer les fichiers.

5) Symptom: « Éditeur inconnu » alors que le fournisseur jure que c’est signé

Cause racine : Signature manquante, cassée, ou effacée par un processus de repackaging ; ou chaîne de confiance cassée sur l’endpoint.

Correction : Utilisez Get-AuthenticodeSignature. Si invalide, retéléchargez depuis la source autoritaire ; si problème de chaîne, corrigez soigneusement le magasin de racines d’entreprise.

6) Symptom: Des scripts zippés ne s’exécutent plus après extraction ; PowerShell se plaint

Cause racine : MOTW s’est propagé aux fichiers extraits ; la stratégie d’exécution et les fonctionnalités de sécurité les traitent comme d’origine Internet.

Correction : Préférez des scripts signés et un déploiement approprié. Si vous devez, débloquez après vérification et seulement dans un environnement de staging contrôlé.

7) Symptom: Pics d’avertissements SmartScreen juste après un changement de sécurité réseau

Cause racine : L’inspection/caching SSL modifie les téléchargements ; la réputation se réinitialise ; la vérification de signature devient incohérente.

Correction : Excluez les chemins de distribution logicielle de la réécriture ; vérifiez que les octets exacts du fournisseur atteignent les endpoints.

8) Symptom: Installateurs livrés via Teams/SharePoint sont plus souvent signalés que prévu

Cause racine : La synchronisation cloud et le traitement des pièces jointes peuvent préserver MOTW ou appliquer un scan additionnel.

Correction : Utilisez une plateforme de distribution logicielle plutôt que d’utiliser des outils de collaboration comme CDN. C’est pratique jusqu’à ce que ça ne le soit plus.

Listes de contrôle / plan pas à pas

Checklist A: Quand un utilisateur signale « SmartScreen a bloqué mon application »

1. Obtenez le texte exact de l’invite et une capture d’écran si possible. Classez : SmartScreen vs MOTW vs politique vs AV.
2. Collectez le fichier depuis l’utilisateur en toute sécurité (ne lui demandez pas de l’envoyer par email). Utilisez une méthode de transfert sécurisée.
3. Calculez son hash (SHA-256). Comparez avec les artefacts connus bons.
4. Vérifiez le statut de la signature et l’identité de l’éditeur.
5. Vérifiez la présence et la zone MOTW.
6. Consultez les logs Defender/EDR pour des détections réelles.
7. Si c’est un outil légitime : corrigez le chemin de distribution (signature, hébergement stable, packaging). Ne « documentez » pas un contournement.

Checklist B: Renforcer votre distribution logicielle interne pour réduire SmartScreen

1. Signez les exécutables et scripts avec un certificat de signature de code d’entreprise cohérent.
2. Publiez via un canal géré (centre logiciel/MDM/dépôt de paquets) plutôt que des téléchargements ad hoc.
3. Assurez la consistance octet-par-octet : pas de middleboxes qui réécrivent les payloads.
4. Versionnez les artefacts de façon immuable. Ne remplacez pas des fichiers sur la même URL.
5. Fournissez des hashes dans un index interne et faites vérifier cela par la CI.
6. Préférez des formats d’installateurs avec des métadonnées adaptées à l’entreprise (MSI) quand c’est approprié.
7. Surveillez les blocages comme des signaux : les pics indiquent généralement un changement de distribution ou de politique, pas que « les utilisateurs se sont soudainement détériorés ».

Checklist C: Procédure d’unblocking sûre (pour fichiers validés et connus bons)

1. Vérifiez que la signature est valide et attendue.
2. Vérifiez que le hash correspond à un artefact approuvé.
3. Confirmez l’origine du fichier (HostUrl/Referrer du Zone.Identifier si présent).
4. Débloquez en utilisant Unblock-File dans un répertoire contrôlé.
5. Relancez avec le principe du moindre privilège ; observez le comportement.
6. Documentez pourquoi le débloquage était nécessaire et créez une tâche pour corriger la distribution afin que ce ne soit plus nécessaire la prochaine fois.

FAQ

1) SmartScreen est-il la même chose que Microsoft Defender Antivirus ?

Non. Ils collaborent, mais ce sont des contrôles différents. Defender AV est principalement détection et remédiation de malwares.
SmartScreen est une passerelle de réputation et de sécurité (incluant la réputation d’URL/application), souvent plus en amont dans le flux utilisateur.

2) Si un fichier est signé, pourquoi SmartScreen avertit-il encore ?

La signature prouve l’identité, pas la popularité ou la sécurité. SmartScreen peut toujours avertir si le fichier a une faible prévalence, est nouvellement observé,
semble suspect heuristiquement, ou si l’identité du signataire est nouvelle/inconnue par rapport aux versions précédentes.

3) Qu’est-ce exactement que la case « Débloquer » dans les Propriétés ?

Elle est généralement liée aux métadonnées MOTW/Attachment Manager. Windows stocke l’information de zone dans le flux de données alternatif Zone.Identifier.
Le débloquage supprime cette étiquette de zone.

4) Pourquoi les fichiers extraits d’un ZIP apparaissent comme bloqués ?

Parce que le ZIP portait MOTW, et Windows a propagé la balise aux fichiers extraits. C’est intentionnel : les attaquants aiment le flux « zip-and-run ».
C’est agaçant quand vous distribuez des utilitaires légitimes en fichiers individuels.

5) Devrait-on simplement désactiver SmartScreen en entreprise ?

En général : non. Le désactiver échange une nuisance opérationnelle gérable contre une augmentation mesurable du succès d’ingénierie sociale.
Si SmartScreen est bruyant, la correction est généralement la signature + une distribution stable, pas éteindre l’alarme parce qu’on a brûlé une tartine.

6) Comment savoir si le blocage vient de SmartScreen ou d’AppLocker/WDAC ?

Regardez le message et consultez les logs. AppLocker écrit dans les logs AppLocker ; WDAC dans les logs Code Integrity. Les invites SmartScreen ressemblent à
« Windows a protégé votre PC » et apparaissent souvent au lancement plutôt que comme un refus de politique strict.

7) Un proxy ou un produit de sécurité peut-il provoquer des avertissements SmartScreen ?

Oui. L’inspection SSL, le caching, ou l’« optimisation » des téléchargements peuvent changer les octets du fichier, modifiant les hashes et donc la réputation.
Certains produits reconditionnent aussi les téléchargements, suppriment des signatures, ou interfèrent avec la validation de la chaîne de confiance.

8) Supprimer MOTW est-il sûr si l’outil est interne ?

Ça peut l’être si vous avez vérifié la signature et le hash contre un artefact approuvé. Mais si votre workflow standard exige de retirer MOTW,
vous opérez un modèle de distribution cassé. Corrigez le pipeline pour que les utilisateurs n’aient pas besoin de contourner les fonctions de sécurité.

9) Pourquoi ça marche pour un utilisateur mais pas pour un autre ?

Des différences de politique (OU/MDM), de magasins de confiance, de chemin navigateur, de posture EDR, ou de provenance de fichier peuvent changer les résultats. Aussi : tout le monde
n’a pas téléchargé les mêmes octets, même s’ils le croient.

10) Quelle est la meilleure façon long terme de réduire les invites SmartScreen pour les applications internes ?

Signez votre code de façon cohérente, distribuez via un canal géré, gardez les artefacts immuables, et évitez le repackaging. Si vous avez besoin de règles d’autorisation,
préférez les politiques basées sur le signataire plutôt que des exceptions par hash qui pourrissent instantanément.

Conclusion : prochaines étapes sans dégrader la sécurité

Les avertissements SmartScreen sont un signal. Parfois le signal dit « c’est réellement dangereux ». Souvent il dit « votre livraison logicielle est désordonnée ».
Traitez-le comme de la télémétrie de production : classez, confirmez, et corrigez le système en amont qui génère le bruit.

Prochaines étapes pratiques :

• Cessez de distribuer des exécutables en téléchargements ad-hoc quand vous pouvez utiliser un déploiement logiciel géré.
• Signez les outils internes et conservez une identité de signature cohérente entre les versions.
• Rendez les artefacts immuables : fichiers versionnés, hashes stables, pas de remplacements in-place.
• Instrumentez le chemin de blocage : logs AppLocker/WDAC, événements opérationnels Defender, et vérifications MOTW.
• Éliminez la consigne « Exécuter quand même » et remplacez-la par un workflow de débloquage vérifié plus un plan pour supprimer le besoin.

Si vous faites cela, SmartScreen redevient ce qu’il devait être : un ralentisseur significatif pour les choses réellement risquées, pas une taxe quotidienne sur les personnes
qui essaient de faire leur travail.