winsight

WinSight est une suite de petits outils de sécurité Windows, à usage unique et auditables, décrits par leurs auteurs comme s'inscrivant dans l'esprit des outils macOS d'Objective-See. Elle est gratuite, open source (GPL-3.0-or-later), ne nécessite aucun compte et ne rapporte aucune télémétrie. Ce qu'elle couvre, d'après le tableau du README : - Analyseur de persistance (comparable à KnockKnock) : 27 surfaces de démarrage automatique, verdicts Authenticode tenant compte du catalogue, tri par ligne de commande pour les interpréteurs signés exécutant la charge utile d'un tiers, enrichissement VirusTotal en option. - Pare-feu sortant (comparable à LuLu) : blocage/autorisation par application appliqué via la Windows Filtering Platform ; en audit seul tant qu'un opérateur élevé ne l'a pas armé. - Guardian (comparable à BlockBlock) : une fenêtre de décision lorsqu'un nouvel élément de démarrage apparaît - Autoriser, Bloquer (mis en quarantaine, restaurable) ou décider plus tard - plus la réconciliation des changements effectués pendant que WinSight ne tournait pas. - Détection de rançongiciels (comparable à RansomWhere?) : fichiers leurres visibles et variables selon la machine, rafales de renommage/suppression, entropie à l'écriture et contrôles d'intégrité bornés des signatures de conteneurs. - Moniteur de caméra et de microphone (comparable à OverSight) : historique d'activation et transitions du ConsentStore avec couverture de lecture par store et correspondance de processus au mieux. - Connexions et DNS (comparable à Netiquette, DNSMonitor) : instantanés de la table des connexions TCP/UDP plus requêtes DNS en direct, attribués aux processus lorsque Windows expose un propriétaire. - Vérification de signature (comparable à What's Your Sign?) : verdicts Authenticode, catalogue et packages MSIX vérifiés, utilisés par chaque outil, plus une entrée « Check signature with WinSight » dans l'Explorateur de fichiers et un verbe `winsight sign`. - Analyse de détournement (comparable à DHS) : chemins de service non entre guillemets, répertoires de service et entrées PATH inscriptibles, et imports DLL fantômes, chacun évalué selon son exploitabilité sur la machine actuelle. Au-delà des originaux macOS, le README mentionne l'attribution d'écriture (nommer le programme derrière une alerte de persistance ou de rançongiciel lors d'une exécution élevée), l'exploration par processus (`winsight process <pid>`) et les preuves d'accès physique (`winsight presence`). Il indique aussi que la vue d'ensemble rapporte en lecture seule la posture opérationnelle configurée et observée, y compris l'indisponibilité explicite lorsque Defender ne peut être interrogé, et que WinSight ne modifie jamais ce réglage lui-même. Trois interfaces sont proposées : un tableau de bord WPF de bureau et de zone de notification en anglais, français et espagnol ; une ligne de commande avec 28 verbes prenant en charge `--flagged` et `--json` (une enveloppe versionnée avec schemaVersion, generatedAt et reports), sortant avec un code non nul quand quelque chose est notable ; et un serveur MCP (`winsight mcp`) uniquement stdio local, en lecture seule, avec six outils, trois ressources et deux invites guidées et aucun écouteur réseau. Les trois partagent une seule couche d'orchestration. Installation : par utilisateur par défaut, sans droits administrateur ni runtime .NET requis, avec des ZIP portables pour x64 et Arm64. Le README énonce clairement deux conséquences : le pare-feu sortant est indisponible dans une installation par utilisateur car le service refuse de s'enregistrer depuis un chemin qu'un principal non privilégié peut modifier, et les binaires de WinSight sont remplaçables par un adversaire s'exécutant en tant que cet utilisateur. Les binaires publiés ne sont pas signés Authenticode ; le projet publie à la place des sommes de contrôle SHA-256, un SBOM et des attestations de provenance de build GitHub, et conseille de les vérifier avant exécution. Le service de pare-feu sortant n'est délibérément pas installé par le programme d'installation, puisqu'il enregistre un service LocalSystem et modifie WFP. Les points de posture de sécurité listés incluent : aucune télémétrie ni analytique, la seule connexion sortante étant une recherche de hachage VirusTotal explicitement initiée par l'utilisateur (un hachage, jamais le contenu des fichiers), activée par une variable d'environnement `WINSIGHT_VT_KEY` et refusable avec `--no-network` ; une frontière privilégiée mise en œuvre comme un canal nommé authentifié plutôt que l'interface ; une application opt-in, démarrant en audit seul, sans chemin en ligne de commande pour l'armer ; un rapport séparé de l'intention souhaitée et de l'état effectif, rapportant `Degraded` plutôt que `Active` lorsque l'application ne peut être vérifiée exactement ; une fenêtre bornée de 128 applications les moins récemment utilisées pour les applications sortantes inconnues, avec journalisation de la pression de capacité par échantillonnage exponentiel ; une application qui survit aux redémarrages via la persistance de démarrage du service, l'état étant revérifié à chaque lecture de statut ; un refus d'installer le service depuis un chemin inscriptible avec une revérification d'identité NTFS sur 128 bits ; et aucun pilote noyau, l'interception reposant sur un pilote étant différée. Les actions de réponse (suspendre, reprendre, terminer, restaurer, révoquer) exigent `--confirm`, sont enregistrées dans un journal en ajout seul lisible avec `winsight actions`, et revalident leurs cibles. Les leurres de rançongiciels sont des fichiers visibles ordinaires dans Documents, Bureau, Images, Téléchargements, Vidéos et Musique, désactivés jusqu'à activation, et le nettoyage ne supprime que les fichiers dont l'identité enregistrée et le contenu d'origine correspondent encore. L'aptitude à la production est explicitement déclarée comme non établie pour x64 et Arm64, citant un audit de sécurité de septembre ayant trouvé des défauts hors des scénarios de qualification historiques et un candidat corrigé qui nécessite encore une CI fraîche et une qualification en VM isolée. Le README note aussi que CodeQL s'exécute via la configuration par défaut de GitHub plutôt qu'un workflow de dépôt, de sorte qu'il ne peut être audité depuis un clone et ne s'exécute pas sur les forks. Les enregistrements de qualification historiques pour le comportement privilégié sont liés sous docs/validation, chacun lié à un commit et une exécution CI, le README précisant qu'aucun ne couvre les défauts de l'audit de septembre. La compilation depuis les sources nécessite le SDK .NET 10 sous Windows ; le script de publication restaure un outil SBOM Microsoft épinglé et installe un compilateur Inno Setup épinglé après vérification de son SHA-256 et de sa signature Authenticode. La CI impose le formatage, un audit des vulnérabilités des dépendances, la suite de tests complète sur trois images Windows dont Arm64 natif, un plancher de couverture de lignes de 80 % sur les bibliothèques du moteur de détection et la moitié écrite à la main du service privilégié, ainsi qu'un cycle de vie d'installation/désinstallation packagé sur x64 et Arm64 natifs. Les problèmes de sécurité sont orientés vers un signalement privé plutôt que vers des issues publiques.