En l'espace d'un mois Microsoft publie deux mises à jour défaillantes pour son navigateur Edge. Sous Windows une application s'installe...
Cet article Windows, Microsoft avoue avoir installé discrètement une application inoffensive a été publié en premier par GinjFo.
Dans cet article, nous allons nous intéresser à Sysmon, un outil qui permet une meilleure journalisation des évènements de sécurité système sous Windows. Il s'agit d'un élément indispensable pour une surveillance efficace des évènements de sécurité.
Nous allons notamment voir que les évènements Windows par défaut ne permettent pas d'avoir une détection très précise des activités systèmes et des attaques telles qu'elles sont opérées aujourd'hui, et comment Sysmon permet d'améliorer cette détection.
Nous verrons également comment l'installer et le configurer à l'aide de modèles de configuration proposés par la communauté, et analyserons ensuite concrètement les journaux produits par Sysmon.
Sysmon (pour System monitor) est à la fois un service et un driver fournit dans le package SysInternals de Microsoft. Il vise à améliorer la journalisation des évènements Windows avec un focus sur la journalisation des évènements de sécurité système. Il s'agit plus d'un outil de détection que de prévention, dans le sens où il permet une meilleure journalisation des évènements, mais ne permet pas à lui seul de bloquer des activités malveillantes.
Depuis Sysmon 14, Microsoft a revu sa stratégie concernant Sysmon. Celui-ci peut maintenant bloquer des exécutables malveillants ("FileBlockExecutable") ainsi que la suppression de fichiers via certains outils ("FileBlockShredding"). Cette protection n'est cependant pas parfaite et ne remplace par une solution dédiée (EPP/EDR).
Pour être plus clair, voici une partie de la liste des évènements que Sysmon peut surveiller et journaliser :
Tous ces évènements peuvent paraitre très (trop) précis pour être intéressants. Mais, tous correspondent à des attaques et modes opératoires bien identifiés et connus des attaquants. Sysmon permet alors de retracer bien plus précisément que les logs par défaut une activité malveillante sur un système.
En plus de journaliser ces évènements clés pour surveiller l'activité d'un système, il inclut plusieurs éléments importants du point de vue des équipes de sécurité et relatifs au contexte de l'évènement :
Ces différents éléments facilitent également l'investigation numérique ainsi que la recherche et corrélation d'évènements, par exemple, grâce aux IOC (Indicators of compromise) publiés par la communauté ou une équipe interne de Threat Intelligence (adresse IP, nom DNS, hash d'un binaire, etc). Rien de mieux qu'un exemple pour illustrer cela. Comparons la journalisation de l'évènement "Création d'un processus" entre les logs par défaut Windows et les journaux créés par Sysmon (cliquez sur l'image pour zoomer) :
L'eventID 1 (à droite de l'image) créé par Sysmon est beaucoup plus verbeux en contenu technique. Il fournit plus d'informations de contexte autour de l'exécution du processus. Ces informations vont notamment grandement faciliter la recherche et la détection d'activité malveillante qui ont lieu sur le système.
Il faut savoir que l'intérêt de Sysmon est aussi la journalisation d'évènements qui ne sont pas du tout journalisés par Windows (au contraire de la création d'un processus, qui est le cas le plus simple pour exposer les capacités de Sysmon). Nous verrons ensuite que, grâce à la configuration que nous allons utiliser, les TTP (Tactics, Techniques and Procedures ) relatifs à tel ou tel évènement journalisé sont aussi indiqués. Nous comprenons donc bien ici que l'intérêt de Sysmon est d'avoir des logs plus précis, orientés autour d'évènements de sécurité très importants sur un système d'exploitation et facilitant la détection et l'investigation numérique.
Enfin, comme tout élément capable de générer des journaux d'évènement, la puissance Sysmon est décuplée si ces évènements sont centralisés et analysés par une plateforme de type SIEM (ELK, Splunk, etc.) et traités par un SOC (Security Operation Center).
Le code source de Sysmon est public et peut être consulté librement. Ainsi, vous pouvez découvrir précisément comment il fonctionne : Github - Sysinternals/SysmonCommon
Les journaux d'évènements Windows peuvent paraitre complexes au premier abord. D'apparence, ils sont assez verbeux et consultables à travers un outil de visualisation/recherche peu efficace ("Observateur d'évènements"). Il est difficile de trouver exactement ce que l'on cherche si l'on n'y est pas familier.
Également, la politique d'audit par défaut de Windows passe sous silence des évènements importants de l'activité sur le système. Pour illustrer ce constat, intéressons-nous aux journaux produits durant trois étapes d'attaque d'un système. Pour faciliter cette analyse, j'ai créé un filtre de journalisation dans l'Observateur d'évènements qui centralise tous les Event ID, peu importe leur source :
Admettons qu'en tant qu'attaquant, j'exécute le binaire "mimikatz64.exe" :
Connexion.\mimikatz64.exePar défaut, cette activité n'est pas journalisée comme nous le montre "auditpol.exe" :
Tel que recommandé dans le guide "Recommandations de sécurité pour la journalisation des systèmes Microsoft Windows en environnement Active Directory" de l'ANSSI, nous pouvons positionner la stratégie d'audit "Suivi Détaillé" > "Création du processus" à "Réussite". Alors, si l'on réitère la même opération, un évènement avec l'Event ID "4688 - A new process has been created" sera créé :
La moindre des choses que l'on puisse dire est que cet évènement est peu verbeux. Les seuls éléments concrets dont nous disposons sont : le nom de compte ayant exécuté la commande, le nom du processus créateur et le nom du processus. Par exemple, le simple fait de renommer "mimikatz64.exe" en "itconnect.exe" suffit à contourner l'un des principaux éléments sur lequel une détection serait possible (le nom du processus) :
Dans un second temps, je décide d'ajouter un moyen de persistance en modifiant le contenu de la clé de registre "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run". Cette clé de registre est utilisée pour lancer des binaires au démarrage (voir Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder). Il s'agit d'un moyen de persistance très connu et souvent utilisé par les attaquants, qui leur permet d'avoir une connexion vers leur serveur C2 (Command & Control) dès le démarrage du système compromis :
reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v mabackdoor /t REG_SZ /d "Z:\backdoor.exe"J'utilise ensuite la CmdLet PowerShell "Get-EventLog" pour récupérer les évènements 4657 – A Registry Value Was Modified relatifs à la modification d'une clé de registre :
À nouveau, aucun évènement n'est journalisé par défaut sous Windows lors de la modification des clés de registre. Enfin, je vais initialiser une connexion réseau vers un serveur malveillant afin de récupérer un ransomware :
À nouveau, aucun évènement journalisé.
Comment nous le voyons à travers cet exemple, les journaux d'évènements produits par Windows par défaut ne sont pas suffisants pour tracer exactement le déroulement de mon attaque et de mon activité sur le système. Par défaut, ils ne sont pas tous activés et lorsqu'ils le sont, leur contenu n'est pas assez détaillé pour une investigation numérique efficace.
Autrement dit, si vous subissez une cyberattaque et que, par chance, vos journaux d'évènements sont préservés (externalisation, centralisation, voire sauvegarde), ceux-ci ne seront pas suffisants pour que l'équipe d'investigation numérique ou de remédiation puisse vous dire précisément ce qu'il s'est passé, par où est passé l'attaquant, quelles ont été ses actions, etc.
Nous allons à présent voir comment installer Sysmon sur un système Windows (serveur ou client, la procédure est la même). Pour acquérir la dernière version de Sysmon, il faut le télécharger depuis le site de Microsoft : SysInternals - Sysmon.
Attention à bien télécharger le binaire depuis le site de Microsoft, et nulle part ailleurs.
Une fois que ce binaire est téléchargé, décompressé et présent sur notre système cible, nous allons ouvrir une Invite de commande en tant qu'administrateur, puis exécuter le binaire avec l'option "-i" :
.\Sysmon64.exe -i -accepteulaVoici la sortie attendue :
L'installation de Sysmon64 entraine notamment la création d'un service "Sysmon64" et l'installation d'un driver "SysmonDrv", dont le rôle est de capturer les évènements de sécurité côté kernel. Le driver échange notamment avec les API Windows et exploite l'Event Tracing for Windows (ETW) pour capturer les informations sur les actions qu'il souhaite surveiller.
Il est important de noter que l'installation de Sysmon est permanente, son service et son driver seront toujours présents et actifs après un redémarrage. Il peut toutefois être désinstallé simplement.
Le driver permet notamment à Sysmon d'utiliser des callbacks, aussi appellés hooks (crochet), sur des fonctions clés du système d'exploitation. Lorsqu'une fonction surveillée est invoquée, le callback associé au driver Sysmon est déclenché. À ce moment-là, Sysmon peut collecter des informations pertinentes sur l'événement en cours, telles que les détails du processus impliqué, les arguments de la fonction, les fichiers accédés, etc. Ces informations sont ensuite journalisées. On retrouve cette mécanique sur la plupart des services type EPP/EDR aujourd'hui.
Aucun redémarrage n'est nécessaire, en vous rendant dans le "Gestionnaire de tâches" puis dans "Services", vous devriez voir le service "Sysmon64" en cours d'exécution :
Vous noterez également qu'il est impossible d'arrêter ce service en tant qu'administrateur :
Cela est dû à une protection mise en place par Windows sur ce service : le Protected Process Light. Cette protection est notamment chargée de vérifier l'intégrité du code pour s'assurer que seul le code "vérifié" et "de confiance" est chargé dans le processus protégé. Ainsi, il ne peut être pris pour cible d'une injection de code ou de DLL et personne ne peut toucher à ce processus :
Grâce à cette protection, il sera plus difficile pour l'attaquant d'altérer le fonctionnement de ce processus en vue de mettre fin à la journalisation de ses actions.
Sysmon s'installe par défaut avec une configuration qui permet de journaliser certains évènements. Cette configuration par défaut peut être consultée via l'option "-s" :
.\Sysmon64.exe -sVoici le résultat attendu :
Comme vous pouvez le voir, il s'agit d'une configuration au format XML. Celle-ci permet de définir les évènements à journaliser, leur Event ID et leur contenu. Exemple avec la journalisation de la création d'un processus :
Ici, nous voyons dans un premier temps la définition de l'event ID avec son nom et son ID ("1"). Les sections précédentes de cet article contiennent déjà un exemple d'évènement créé via cette règle, vous pourrez donc voir les champs déclarés par la configuration dans cet évènement. Par défaut, la journalisation de cet évènement est activée ("ruledefaut=include"). Ce qui n'est pas le cas de tous les évènements, exemple avec l'évènement "11 - Process Create" :
Ainsi, avec la configuration par défaut, vous ne constaterez aucun évènement avec l'ID 11 dans vos logs. Nous voyons ici qu'il faut savoir lire et comprendre cette configuration, au risque de ne pas être assez précis dans notre journalisation.
Pour visualiser les logs, ouvrez l'Observateur d'évènements, puis rendez-vous dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon".
En fonction de la configuration en place (pour l'instant, celle par défaut), vous verrez dès à présent différents évènements journalisés.
Les attaquants les plus avancés vont toujours commencer par regarder quels sont les composants de sécurité en place sur un système avant de tenter d'aller plus loin dans leur compromission. Il s'agit d'une phase de prise d'information très classique, par exemple :
La réponse à ces questions permet à l'attaquant d'avoir une idée du niveau de discrétion dont il doit faire preuve pour ses prochaines opérations sur le système ou le réseau.
Cependant, Sysmon donne la possibilité aux administrateurs de dissimuler sa présence, notamment en modifiant le nom du driver et du service lorsqu'il s'exécute. Par défaut, comme nous l'avons vu, nous pouvons voir un service "Sysmon64" actif dans la liste des services en cours d'exécution :
Lors de la phase d'installation, Sysmon propose l'option "-d" pour permettre de donner un nom arbitraire au driver Sysmon (limité à 8 caractères). Quant au nom du service, il est déterminé par le nom du binaire exécuté lors de l'installation. Il nous suffit donc de le modifier avant installation :
Une fois cette opération effectuée, il sera plus difficile pour l'attaquant de détecter la présence de Sysmon sur le système :
Sur l'image ci-dessus, le processus Sysmon apparait bien comme "ITCProc". Dès lors, pour gérer le service Sysmon et par exemple, récupérer sa configuration actuelle, il faudra utiliser le binaire nommé "ITCProc.exe", l'utilisation de "Sysmon64.exe" ne fonctionnera plus.
Attention, cette méthode est une dissimulation et il existe d'autres moyens de détecter la présence du driver Sysmon (notamment via son altitude identifier).
À présent, nous allons configurer Sysmon pour qu'il journalise les évènements qui nous intéressent. La configuration par défaut est un bon départ, mais vous allez voir qu'il est possible d'aller beaucoup plus loin assez simplement.
Nous allons notamment nous baser sur des configurations connues et éprouvées créées par la communauté de la cybersécurité. La configuration la plus connue est celle proposée par SwiftOnSecurity, consultable et téléchargeable ici : Github - SwiftOnSecurity :
Cette configuration comporte plusieurs intérêts :
Bref, utiliser cette configuration apporte une réelle plus-value par rapport à celle par défaut et un gain de temps qui évite d'avoir à concevoir sa propre configuration XML, avec les difficultés que le format et la complexité des uses-case apportent. Avant de l'appliquer, je vous recommande tout de même de finir la lecture de cet article, puis de lire en détail le contenu de la configuration XML, afin que vous sachiez exactement ce qui sera journalisé et ce qui sera exclu de la journalisation.
Il nous suffit donc de télécharger cette configuration XML puis de l'appliquer à Sysmon, nous pouvons utiliser l'option "-c" :
.\Sysmon64.exe -c .\sysmonconfig-export.xmlVoici la sortie attendue :
Pour vérifier que notre configuration est en place, nous pouvons utiliser l'option "-c" de "Sysmon" :
Les éléments de configuration affichés sont à présent très différents et bien plus verbeux que la configuration par défaut de Sysmon.
Nous pouvons à tout moment revenir à la configuration par défaut avec l'option "-c --".
Maintenant que nous avons appliqué notre configuration à Sysmon, il est très important de ne pas laisser le fichier de configuration persister sur le système sous la forme d'un fichier XML. Si l'attaquant accède à ce fichier, il aura la possibilité de comprendre en détail les règles de détection en place, incluant ses potentielles exclusions et exceptions. Ainsi, il pourra construire une attaque qui exploite ou contourne les règles configurées.
En cela, il est mieux de laisser l'attaquant dans le noir et de supprimer cette configuration du système. Attention à ne pas non plus la laisser accessible sur un partage réseau trop ouvert auquel l'attaquant pourrait avoir accès.
Même si le fichier de configuration initial a été supprimé, Sysmon aura toujours cette configuration à disposition. Lors de l'import d'une configuration avec l'option "-c", Sysmon transforme cette configuration XML en blob de données et le stocke dans une clé de registre :
Ce blob de donnée n'est pas facile à parser et l'attaquant aura du mal à récupérer en clair les règles et exclusions de la configuration à partir de celui-ci.
Comme nous l'avons vu, les journaux d'évènements Sysmon sont stockés dans "Journaux des applications et des services" > "Microsoft" > "Windows" > "Sysmon". Si je réitère mon activité malveillante initiale (celle qui n'avait pas été ou peu journalisée par les logs par défaut de Windows) : voici ce que je peux voir dans les logs Sysmon (cliquez sur l'image pour zoomer) :
Nous voyons clairement dans les logs : un event ID 1 - Process Create, un event ID 13 - Registry value set et and event ID 3 : Network Connecion detected. Ce qui correspond et retrace exactement les activités malveillantes réalisées sur le système. Dans la capture ci-dessus, nous avons les détails de l'exécution de "mimikatz64.exe", déjà exposé précédemment dans cet article. On peut noter la présence de nombreuses informations, dont le hash MD5 du binaire, qui ne changera pas en fonction du nom qui lui est donné (bien que des méthodes simples permettent de modifier ce hash pour qu'il ne colle plus aux signatures classiques).
Nous pouvons également regarder le contenu de l'évènement relatif à l'ajout d'une valeur dans une clé de registre :
À nouveau, nous avons un grand nombre d'informations à propos de l'évènement, le processus parent, le nom de la clé de registre modifiée, sa valeur, on y retrouve clairement l'exécutable malveillant, etc. Vous remarquerez également la présence du "T1060" dans l'attribut "RuleName", il s'agit de l'identifiant du TTP relatif à cette action malveillante. Cet ajout provient de la configuration SwitfOnSecurity et vise à aider l'analyste à comprendre la nature et l'impact d'un évènement de sécurité.
Pour mieux comprendre l'intérêt et les bénéfices de cette information, regardons par exemple le contenu du TTP T1060 sur le site du framework MITRE ATT&CK (le framework ayant été mis à jour récemment, l'action au TTP 1060 rédige vers son nouvel identifiant : T1547.001 - Boot or Logon Autostart Execution: Registry Run Keys / Startup Folder ):
Il ne s'agit là que d'un extrait, mais l'on comprend ici bien plus en détail les enjeux de cet évènement : l'attaquant a cherché à établir une persistance sur le système en modifiant une clé de registre contenant des binaires exécutés au démarrage.
Enfin, voici l'évènement relatif au téléchargement d'un binaire malveillant depuis un serveur appartenant à l'attaquant, action qui n'était pas du tout journalisée par les logs par défaut de Windows :
Là aussi, nous obtenons des informations claires et précises sur l'évènement, notamment l'IP, nom et port de destination, qui sont des informations importantes en termes de détection (grâce aux IOC) et d'investigation.
Pour mieux comprendre chaque évènement produit par Sysmon, nous pouvons utiliser la documentation Microsoft, qui référence précisément les eventID et leur définition : Sysmon - Events
J'espère que cet article vous a aidé à mieux comprendre ce qu'est Sysmon, son utilisation standard ainsi que sa plus-value pour la sécurité d'un système Windows et plus globalement du système d'information. Nous n'avons pas fait un tour complet de l'outil, notamment en ce qui concerne les évènements plus techniques (CreateRemoteThread, RawAccessRead, Process Tampering, etc.), ni la construction complète d'un fichier de configuration avec ses exclusions, exceptions, etc. Mais, le contenu de l'article devrait être suffisant pour mettre en place et utiliser Sysmon au sein de votre système d'information.
Ce qu'il est important de retenir au-delà de Sysmon est l'importance d'avoir une journalisation la plus complète et précise possible concernant les évènements de sécurité, puis d'être capable de la centraliser (SIEM) et de surveiller activement et comprendre ces différents évènements. Dans cette démarche macro, Sysmon n'est finalement qu'un point de départ.
N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord !
The post Windows : utilisation de Sysmon pour tracer les activités malveillantes first appeared on IT-Connect.
Intel publie de nouveaux pilotes Wi-Fi et Bluetooth pour Windows 11 et 10. Ils corrigent un problème de BSOD et améliorent les performances.
Cet article Intel essaie de corriger les plantages de Windows 11 et 10 causés par ses pilotes a été publié en premier par GinjFo.
Certains ordinateurs propulsés par des processeurs Intel de 11ème génération étaient incapables de se mettre à jour vers Windows 11. C'est désormais possible grâce à une correction de bug de la part de Microsoft.
L’article Après plus de deux ans, la mise à niveau vers Windows 11 est enfin possible pour ces PC est apparu en premier sur Tom’s Hardware.
Bien qu’abandonné, Windows 7 fait toujours partie du paysage informatique et à la surprise générale une nouvelle build a été publiée.
Cet article Une nouvelle build de Windows 7 est publiée a été publié en premier par GinjFo.
Un des problèmes que les utilisateurs rencontrent régulièrement est que le PC s’allume, c’est à dire que vous entendez les ventilateurs et l’écran s’allume mais Windows 10 ne démarre pas.
Les sources de ce problème de démarrage sont multiples, comme une corruption du système par une mise à jour, une défaillance de disque, un pilote qui plante le démarrage, etc.
Dans ce guide complet, je vous donne plusieurs solutions lorsque votre PC s’allume mais que Windows 10 ne démarre pas.
Une réinitialisation de l’alimentation ou un redémarrage matériel ou encore en anglais Power Reset ou Hard Reset efface toutes les informations de la mémoire de l’ordinateur sans effacer les données personnelles.
Cela peut résoudre des corruptions de sources d’alimentation qui engendre des comportements aléatoires de votre PC. Voici la procédure générique à réaliser.
Pour les PC portables :
Pour un PC de bureau :
Plus de détails avec tous les conseils et autres méthodes sur cette page :
Une fois que cela est fait, relancez normalement votre PC et vérifier si Windows 10 se charge normalement.
Sinon passez à l’étape suivante.
Si Windows 10 est corrompu ou quelque chose empêche son démarrage, vous pouvez tester d’accéder au mode sans échec.
Pour cela, il faut parvenir à démarrer sur les options de démarrage avancées.
Voici les méthodes pour y parvenir :
Au besoin, consultez ce guide : Démarrer sur les options de dépannage de Windows 10, 11
Ensuite pour accéder au mode sans échec :
Si vous parvenez à accéder au mode sans échec, c’est une bonne nouvelle car cela signifie que quelque chose bloque le mode normal.
Tentez alors :
Les options de récupérations fournissent aussi un utilitaire pour corriger les problèmes qui empêchent le chargement de Windows.
Voici comment l’utiliser :
Ce problème d’accès au bureau de Windows 10 peut se produire après une mise à jour du système.
Notamment, cela se produit souvent après une mise à jour de fonctionnalités.
Notez que si vous rencontrez un écran noir après la saisie du mot de passe ou code PIN, il faut parfois patienter car la mise à jour continue de s’installer.
Sinon une solution est de désinstaller la dernière mise à jour.
Voici comment faire :
Une autre source des problèmes de chargement de Windows 10 est que les fichiers de configuration de démarrage sont corrompus.
En général, une erreur BCD vous le notifie mais si cela empêche le démarrage, vous pouvez tenter de réparer le démarrage de Windows 10 en invite de commandes.
bcdboot C:\WindowsVoici comment restaurer Windows à une date antérieure :
Plus de détails dans ces tutoriels :
En plus des problèmes logiciels, un problème matériel peut aussi empêcher le chargement de Windows.
Le plus courant étant une défaillance du support de stockage ; notamment celui qui stocke la partition C et la partition EFI.
Vous devez vérifier la santé de votre disque dur à partir d’un Live USB :
Les deux derniers Live USB embarquent le logiciel CrystalDiskInfo pour vérifier l’état des disques à travers la technologie S.M.A.R.T.
Pour Ubuntu, suivez le tutoriel fourni ci-dessus.
Vous pouvez réinitialiser le PC depuis les options de récupération. Vous avez la possibilité de conserver les données personnelles mais il faudra réinstaller vos applications.
Pour ce faire, choisissez l’option “Réinitialiser ce PC” depuis les options de récupération.
Si la réinitialisation de Windows 10, est impossible (blocage, plantage, etc), la seule solution est de réinstaller Windows 10 avec une clé USB.
Aidez-vous de ces tutoriels :
L’article Mon PC s’allume mais ne démarre pas en Windows 10 est apparu en premier sur malekal.com.
Windows Memory Cleaner libère de l’espace RAM afin de récupérer de précieux Go et d’éviter les ralentissements
Cet article Windows Memory Cleaner optimise la mémoire pour booster les performances a été publié en premier par GinjFo.
En environnement Active Directory, les stratégies de groupe jouent un rôle dans l'administration et la sécurisation des postes de travail et des serveurs. Néanmoins, au fil des années, elles sont susceptibles de s'accumuler et l'équipe IT peut finir par perdre le contrôle sur leurs GPO et ne plus avoir une bonne visibilité sur le rôle de chacune d'elle... Au point, de se retrouver avec des GPO en double, des GPO vides, des GPO avec des permissions incorrectes, ou tout simplement des GPO mal configurées. D'ailleurs, tôt ou tard, ceci pourrait être à l'origine d'un problème avec l'une de vos stratégies de groupe...
Nous pouvons dire que l'administration des GPO est un véritable défi, surtout quand elles sont nombreuses et gérées par plusieurs personnes. Dans ce tutoriel, nous allons découvrir l'outil GPOZaurr, qui pourra vous venir en aide puisque ce module PowerShell va analyser l'intégralité de vos GPO et vous générer un joli rapport que vous pourrez ensuite analyser.
Il sera d'une aide précieuse à celles et ceux qui ont la volonté de faire du tri dans leurs GPO, mais également si vous cherchez à investiguer sur un problème de stratégies de groupe. Nous pourrions même dire que GPOZaurr permet de faire un audit des GPO. En complément, vous pouvez lire cet article :
Lorsque nous allons exécuter un audit avec GPOZaurr, l'outil va vérifier près d'une vingtaine de points de configuration et anomalies potentielles. Par exemple :
Il fournira aussi un rapport complet sur l'ensemble de vos GPOs permettant d'identifier les GPO vides, non liées, appliquées, désactivées, sans filtrage de sécurité, etc...
Vous pouvez retrouver le projet GPOZaurr sur GitHub :
Tout d'abord, ouvrez une console PowerShell sur votre machine et installez le module GPOZaurr :
Install-Module -Name GPOZaurrVous devez savoir que GPOZaurr va également installer les modules PSWriteHTML, ADEssentials, PSSharedGoods, PSWriteColor, car ce sont des prérequis à son fonctionnement. D'ailleurs, c'est le même développeur principal derrière ces différents modules, et vous connaissez peut-être déjà l'excellent module PSWriteHTML.
Si l'installation ne passe pas avec la commande ci-dessus, réessayez avec celle-ci :
Install-Module -Name GPOZaurr -AllowClobber -ForcePar ailleurs, GPOZaurr nécessite l'installation des outils RSAT pour l'Active Directory et la console de "Gestion des stratégies de groupe" pour être en mesure d'effectuer l'analyse de votre environnement. Ces consoles sont présentes sur les serveurs contrôleurs de domaine Active Directory et peuvent être installées sur un serveur ou poste de travail d'administration.
Une fois que GPOZaurr est installé, vous pouvez l'exécuter via le cmdlet "Invoke-GPOZaurr" pour qu'il effectue une analyse de vos GPO.
Remarque : vous devez l'exécuter avec un compte Administrateur pour que l'ensemble des points puissent être vérifiés. A partir d'un compte utilisateur standard, certaines informations pourront être récupérées, mais l'analyse sera partielle.
Invoke-GPOZaurrSans aucun paramètre, GPOZaurr va effectuer une analyse complète des stratégies de groupe de votre domaine Active Directory. Ainsi, sur un domaine avec plusieurs milliers de GPO, l'analyse peut durer plusieurs heures. Sur mon Lab, où il y a un peu moins de 100 GPO, l'analyse est relativement rapide puisqu'elle nécessite environ 2 minutes.
Si vous souhaitez effectuer une analyse uniquement sur certaines catégories ou certaines anomalies, sachez que ce cmdlet intègre un paramètre nommé "-Type" qui vous permettra de spécifier le périmètre de l'analyse.
Invoke-GPOZaurr -Type <Nom du rapport>
# Exemple n°1 :
Invoke-GPOZaurr -Type GPOBroken
# Exemple n°2 :
Invoke-GPOZaurr -Type GPOBroken,GPOPermissionsVoici la liste des valeurs disponibles :
Par ailleurs, le paramètre "-FilePath" vous offre la possibilité de nommer le rapport comme vous le souhaitez et de le stocker dans le répertoire de votre choix. Sinon, par défaut, ce sera dans le répertoire temporaire de l'utilisateur utilisé pour lancer l'analyse. L'exemple ci-dessous vous permettra d'intégrer la date et l'heure dans le nom du rapport.
Invoke-GPOZaurr -FilePath "C:\TEMP\GPOZaurr_$(Get-Date -Format yyyyMMdd-hhmm).html"Le rapport s'ouvrir sur votre machine dès lors que l'analyse est terminée. La partie supérieure du rapport contient un ensemble d'onglets, ce qui permet de naviguer dans les différentes catégories. Chaque onglet contient une zone qui décrit ce qui a été analysé, un graphique, ainsi qu'un tableau récapitulatif avec le statut de vos GPO.
Chaque sous-rapport peut être exporté au format Excel, CSV ou PDF. De plus, vous pouvez effectuer des recherches sur chaque colonne d'un tableau afin de filtrer les résultats rapidement.
Pour avoir une vue d'ensemble de vos GPO, cliquez sur l'onglet "Group Policy Summary". Il offre un aperçu global sur l'ensemble de vos GPO avec quelques indicateurs clés (oui/non) : GPO vide, GPO activée, GPO optimisée, GPO avec un problème, GPO liée, etc.
En complément, si vous basculez sur l'onglet "Group Policy Content", vous pourrez constater que GPOZaurr a organisé vos GPO par catégorie. Par exemple, la catégorie "Audit" permet de voir toutes les GPO qui permettent de configurer des paramètres de stratégies d'audit.
Chaque onglet contient des informations intéressantes et qui pourront s'avérer plus ou moins utiles et pertinentes selon le contexte dans lequel vous utilisez GPOZaurr. Si vous passez sur l'onglet "SYSVOL (NetLogon) Files List", vous pourrez visualiser l'ensemble des fichiers détectés dans le partage SYSVOL. Ce sera aussi l'occasion de voir si ces fichiers sont liés à une GPO, ou pas.
GPOZaurr est également capable de corriger les problèmes à votre place, grâce à un processus étape par étape où l'outil vous fournit les commandes PowerShell à exécuter pour faire le nécessaire. À chaque fois que vous changez d'onglet, les étapes de remédiation sont adaptées en fonction du contexte. Néanmoins, je vous recommande de corriger les problèmes vous-même et d'utiliser GPOZaurr uniquement pour vous faciliter le travail d'analyse. Même rien ne vous empêche de vous inspirer de la solution proposée, mais l'objectif étant de limiter les effets indésirables...
J'ai découvert GPOZaurr récemment, et c'est bien dommage.... Il aurait pu me rendre bien des services pour investiguer sur des problèmes de GPO, générer un rapport complet sur les GPO pour un audit ou encore pour effectuer du tri dans les GPO. J'espère que cet article vous donnera envie de l'utiliser et de l'ajouter à votre boite à outils !
En complément de cet article, vous pouvez lire celui rédigé par l'auteur de ce module (en anglais) :
The post GPOZaurr, l’outil ultime pour analyser vos stratégies de groupe first appeared on IT-Connect.
Jusqu'à maintenant, il était impossible de gérer vos autres appareils connectés depuis un seul ordinateur, à l'image de MacOS avec les iPhone et iPad. La firme de Redmond va bientôt y remédier grâce à l'ajout de cette fonctionnalité dans la dernière version bêta de Windows 11.
L’article Windows 11 : vous pourrez bientôt gérer vos PC et Xbox depuis votre ordinateur est apparu en premier sur Tom’s Hardware.
Oyez, oyez, amis Windowsiens ! Réjouissez-vous, car Microsoft, dans son immense mansuétude, a enfin daigné lever le blocage qui empêchait certains d’entre vous de goûter aux joies de Windows 11. Eh oui, après deux longues années d’attente, les possesseurs de processeurs Intel Rocket Lake peuvent désormais franchir le Rubicon et passer du côté obscur de la Force.
Enfin, seulement s’ils mettent à jour leurs pilotes Intel Smart Sound Technology !
Mais qu’est-ce que c’est que cette histoire de pilotes ? Eh bien figurez-vous que certaines versions des pilotes audio Intel SST provoquaient des écrans bleus de la mort sur Windows 11, rien que ça. Les pilotes fautifs, en version 10.29.0.5152 et 10.30.0.5152, étaient plus vicieux qu’un Gremlins mouillé après minuit.
Mais tel un chevalier blanc sur son fier destrier, Intel est venu à la rescousse en sortant des versions corrigées des pilotes, estampillées 10.30.00.5714 et 10.29.00.5714 (et au-delà). Microsoft a évidemment mis un certain temps à lever son blocus, mais mieux vaut tard que jamais, n’est-ce pas ?
Car oui, Microsoft est en pleine phase « open bar » en ce moment : tout le monde est invité à rejoindre la grande famille Windows 11. Même si parfois, ça implique de bloquer certaines apps tierces un peu trop curieuses ou de laisser tomber le support de fonctionnalités exotiques comme Windows Mixed Reality. Mais c’est le prix à payer pour profiter d’un OS moderne et innovant (ou pas) comme Windows 11 ^^.
Pour mettre à jour vos pilotes et enfin accéder au Saint Graal qu’est Windows 11, rien de plus simple : passez par Windows Update ou allez directement sur le site d’Intel. Une fois vos pilotes à jour, attendez 48h (le temps que Microsoft réalise que vous existez) et voilà, vous pourrez enfin voir à quoi ressemble le menu Démarrer de Windows 11. Spoiler : c’est pareil que Windows 10.
Mais attention, cette mise à jour ne concerne que les versions Desktop de Windows, à savoir :
Les versions Serveur ne sont pas impactées par ce problème. Pour les administrateurs IT qui gèrent des parcs informatiques, vous pouvez déployer les pilotes mis à jour en utilisant des outils tels que Windows Update for Business, Intune ou Autopatch.
Et si jamais après deux jours, Windows refuse toujours obstinément de vous laisser passer à la caisse pour acheter votre billet pour Windows 11, contactez le support ! A l’ancienne 🙂
Sur ce, je vous laisse, j’ai un pilote à mettre à jour.
Andy Young est un ancien développeur de Microsoft qui a participé à l'élaboration de Windows 11. Le 9 avril dernier, il s'est plaint sur X de gros problèmes de performance sur le menu Démarrer, signe que le système d'exploitation manque encore d'optimisation.
L’article Un ancien développeur de Microsoft se plaint du menu démarrer de Windows 11 est apparu en premier sur Tom’s Hardware.
Les processeurs Intel ont été victimes de 2 failles de sécurité importantes en 2017, Spectre et Meldown. Spectre (variante 2) refait surface.
Cet article Faille Spectre et CPU Intel en 2024, Microsoft publie une solution sous Windows ! a été publié en premier par GinjFo.
Le Patch Tuesday du mois d’avril 2024 a été l’occasion pour Microsoft de corriger des soucis de sécurité autour de l’authentification PAC Kerberos.
Cet article Windows, Microsoft colmate les failles affectant le protocole de validation PAC Kerberos a été publié en premier par GinjFo.
Dans ce tutoriel, nous allons exploiter PowerShell pour créer un journal personnalisé et des événements personnalisés dans l'Observateur d'événements de Windows ou Windows Server, à l'aide de deux cmdlets : New-EventLog et Write-EventLog. En complément, nous verrons comment utiliser la classe .NET "EventLog" pour créer des entrées avancées.
Sur Windows, le système d'exploitation, les composants et les applications peuvent générer des événements qui sont inscrits dans les différents journaux centralisés dans l'Observateur d'événements. Ces journaux sont une mine d'informations pour les administrateurs systèmes, mais aussi pour les équipes en charge de la sécurité : une action suspecte peut être consignée dans un événement, qui représentera alors une trace intéressante.
L'intérêt ensuite est de collecter ces événements dans un puits de logs ou un SIEM afin de les analyser et de détecter les comportements suspects ou les anomalies sur une infrastructure.
Grâce à la commande Write-EventLog ou à l'utilisation de la classe EventLog, nous pouvons alimenter les journaux de Windows avec des événements personnalisés qui, eux aussi, pourront être exploités par une solution telle qu'un SIEM. Autrement dit, votre script PowerShell pourra créer des événements contenant les informations de votre choix.
Remarque : avant de pouvoir utiliser Write-EventLog, cette action était possible sous Windows grâce à l'utilisation de l'utilitaire en ligne de commande EVENTCREATE.exe.
Au sein de l'Observateur d'événements, vous pouvez créer un journal personnalisé, associé au nom de votre choix, à condition que celui-ci ne soit pas déjà utilisé. Cette étape est facultative, car nous pouvons créer des enregistrements dans certains journaux natifs, notamment dans le journal "Applications" de Windows.
Néanmoins, le fait de créer un journal personnalisé et d'y inscrire par la suite nos propres événements, permet "d'isoler" nos événements personnalisés. Ceci peut vouloir dire également qu'il faudra adapter la configuration de votre outil de collecte de log pour qu'il prenne en charge ce nouveau journal.
La commande suivante permet de créer un journal nommé "PowerShell-Demo", qui accepte deux sources : "Script-1" et "Script-2". Vous pouvez en ajouter autant que vous le souhaitez, et, vous pouvez ajouter des sources supplémentaires à un journal existant. Ceci est indispensable, car chaque événement de journal doit être associé à une source.
New-EventLog -LogName "PowerShell-Demo" -Source "Script-1","Script-2"Ce journal sera immédiatement visible dans l'Observateur d'événements sous "Journaux des applications et des services".
D'ailleurs, pour ajouter une source supplémentaire, il suffit d'exécuter une nouvelle fois New-EventLog en indiquant le nom du journal et le nom de la source supplémentaire à ajouter. Voici un exemple pour ajouter la source "Script-3" :
New-EventLog -LogName "PowerShell-Demo" -Source "Script-3"Si vous effectuez une erreur, par exemple, dans le nom de votre journal, sachez que vous pouvez le supprimer avec cette commande :
Remove-EventLog -LogName "PowerShell-Demo"Pour approfondir l'utilisation de ce cmdlet, vous pouvez consulter cette page :
Désormais, nous allons voir comment écrire un nouvel événement dans le journal d'événements que nous venons de créer. Nous pourrions aussi l'ajouter dans un autre journal (attention, certains sont protégés), tout se joue au niveau du paramètre "-LogName" de la commande Write-EventLog puisqu'il permet de préciser le journal cible.
Comme pour les autres cmdlets PowerShell, vous pouvez spécifier le nom du cmdlet suivi de chaque paramètre et de sa valeur, mais dans le cas présent, l'écriture proposée ci-dessous permet d'avoir une meilleure lisibilité.
$Event = @{
LogName = "PowerShell-Demo"
Source = "Script-1"
EntryType = "Error"
EventId = 10000
Message = "Cette alerte a été généré depuis PowerShell"
}
Write-EventLog @EventCe bout de code va créer un événement de type "Erreur" dans notre journal, associé à la source "Script-1" et l'ID "10000". Il contiendra le message "Cette alerte a été généré depuis PowerShell", comme vous pouvez le voir sur l'image ci-dessous. Essayez d'utiliser des ID différents pour vos types d'événements, et évitez aussi d'utiliser des ID déjà utilisé par Windows.
À la place du type "Error" permettant de générer une erreur, vous pouvez utiliser les valeurs suivantes : Warning, Informational, SuccessAudit, et FailureAudit. Sachez que cette commande prend en charge le paramètre "-ComputerName", ce qui permet de créer un événement dans le journal d'un ordinateur distant.
Pour consulter ce journal personnalisé, ou un autre journal, vous pouvez utiliser le cmdlet PowerShell "Get-EventLog". Bien que ce cmdlet soit très pratique, il ne permet pas d'accéder à tous les journaux, donc sachez qu'il existe aussi un second cmdlet prévu pour consulter les journaux : "Get-WinEvent".
Voici la commande à utiliser pour récupérer les logs de notre journal :
Get-EventLog -LogName "PowerShell-Demo"Pour approfondir l'utilisation de ces cmdlets, vous pouvez consulter ces pages :
Pour aller plus loin dans l'écriture d'événements dans un journal Windows, il convient d'exploiter la classe EventLog directement depuis PowerShell. Celle-ci va nous permettre d'ajouter des données mieux structurées dans notre événement, notamment dans la section "EventData" visible à partir de la vue XML. C'est utile pour stocker plusieurs informations tout en permettant de récupérer de façon indépendante chaque information.
Voici un exemple :
Nous avons mis en pratique cette méthode dans ce tutoriel :
Ceci complexifie l'inscription d'un nouvel événement, car nous devons créer nos propres objets et nous passer de l'utilisation de Write-EventLog. Un premier objet "System.Diagnostics.EventInstance" permettra d'indiquer le numéro d'ID et le type d'événements, tandis qu'un second objet "System.Diagnostics.EventLog" permettra de préciser les données de l'événement.
Néanmoins, pour que l'utilisation reste simple, nous vous proposons d'utiliser cette fonction :
function Write-EventLogV2 {
<#
.SYNOPSIS
Crée un évènement dans l'observateur d'évènement
.DESCRIPTION
La fonction utilise la CmdLet WriteEvent pour créer un évènement à partir des paramètres d'entrée.
.PARAMETER dataUser
Nom utilisateur qui sera inscrit dans le contenu de l'évènement à créer
.PARAMETER dataDescription
Contenu de la description qui sera inscrite dans le contenu de l'évènement à créer
.PARAMETER ID
Event ID de l'évènement à créer
.PARAMETER evtLog
Journal de l'évènement à créer
.PARAMETER evtSource
Source de l'évènement à créer
.EXAMPLE
New-EventLog -dataUser "John" -dataDescription "new description"
.OUTPUTS
None
#>
param(
[Parameter(Mandatory=$true)]$dataUser,
$dataDescription="",
$ID=10000,
$evtLog="PowerShell-Demo",
$evtSource="Script-2"
)
# Charge la source d'événement dans le journal si elle n'est pas déjà chargée.
# Cette opération échouera si la source d'événement est déjà affectée à un autre journal.
if ([System.Diagnostics.EventLog]::SourceExists($evtSource) -eq $false) {
[System.Diagnostics.EventLog]::CreateEventSource($evtSource, $evtLog)
}
# Construire l'événement et l'enregistrer
$evtID = New-Object System.Diagnostics.EventInstance($ID,1)
$evtObject = New-Object System.Diagnostics.EventLog
$evtObject.Log = $evtLog
$evtObject.Source = $evtSource
$evtObject.WriteEvent($evtID, @($dataUser,"Description : $dataDescription"))
}En entrée, cette fonction accepte deux messages ($dataUser et $dataDescription - vous pouvez renommer ces paramètres dont le nom a été choisi vis-à-vis du script d'origine), un numéro d'ID (par défaut, ce sera 10000), le nom d'un journal d'événement (par défaut, ce sera "PowerShell-Demo") ainsi qu'une source (par défaut, ce sera "Script-2").
De plus, par défaut, cette fonction génère des événements de type "Information". Si vous souhaitez changer le type d'événement, vous devez ajuster la valeur présente sur cette ligne :
$evtID = New-Object System.Diagnostics.EventInstance($ID,1)En effet, la première valeur correspond à l'ID souhaité, ici associé à la variable $ID, tandis que la seconde valeur correspond au type d'événement. Le 1 correspond au type "Information".
Ce qui permettra de générer des événements similaires à celui-ci :
Si besoin, vous pouvez ajouter d'autres valeurs dans la seconde partie de "$evtObject.WriteEvent" pour avoir des lignes "<Data>" supplémentaires.
En suivant ce tutoriel, vous devriez être en mesure de créer vos propres événements personnalisés dans les journaux Windows, que ce soit dans un journal existant ou dans votre propre journal à l'aide de PowerShell ! Libre à vous d'utiliser ces cmdlets ou cette fonction dans vos scripts, et de les adapter à vos besoins ! En tout cas, ceci ouvre des possibilités très intéressantes !
The post Comment utiliser PowerShell pour créer un événement dans un journal Windows ? first appeared on IT-Connect.
Voici une histoire qui va vous donner des sueurs froides dans le dos juste avant d’aller faire dodo ! Figurez-vous que Raspberry Robin, ce satané malware plus fourbe qu’un présentateur de C8, est de retour pour une nouvelle tournée de piratage en 2024 façon Taylor Swift. Les chercheurs en cybersécurité de chez HP Wolf Security ont repéré ses traces et croyez-moi, il a plus d’un tour dans son sac pour passer entre les mailles du filet !
Ce petit malin utilise des fichiers WSF (Windows Script Files) bien planqués sur différents domaines et sous-domaines pour se faufiler incognito. Et le pire, c’est qu’il arrive à berner ses victimes pour qu’elles aillent d’elles-mêmes sur ces pages web piégées. Une fois que le fichier WSF est exécuté, bim ! Il télécharge son payload principal, un DLL bien vicieux qui peut être n’importe quoi : du SocGholish, du Cobalt Strike, de l’IcedID, du BumbleBee, du TrueBot ou même du ransomware.
Mais avant de télécharger son précieux DLL, il va mener une série de reconnaissances pour vérifier s’il n’est pas en train de se faire piéger dans un environnement d’analyse ou une machine virtuelle. Et si jamais il détecte la présence d’un antivirus comme Avast, Avira, Bitdefender, Check Point, ESET ou Kaspersky, il se met direct en mode furtif et reste planqué.
Et comme si ça suffisait pas, il est même capable de bidouiller les règles d’exclusion de Microsoft Defender pour être sûr de passer entre les gouttes. C’est vraiment le Solid Snake des malwares ! Les scripts qu’il utilise ne sont même pas reconnus comme malveillants par les scanneurs sur VirusTotal, c’est dire à quel point il est balèze en infiltration.
Alors c’est sûr, avec Raspberry Robin dans la nature, faut être sur ses gardes. Ce malware est une vraie plaie depuis qu’il a été découvert en 2021. Au début, il se planquait sur des clés USB avec un fichier LNK qui pointait vers son payload hébergée sur un appareil QNAP compromis. Mais maintenant, il a évolué et il est devenu encore plus sournois.
Bref, gaffe à vous… Assurez-vous d’avoir un bon antivirus à jour, ne cliquez pas n’importe où et méfiez-vous comme de la peste des clés USB inconnues qui traînent.
Aujourd’hui, j’aimerai vous parler d’un truc qui va en faire rêver plus d’un parmi vous : Faire tourner des applis .NET modernes sur ce bon vieux Windows 95 ! Impossible vous dites ? Et bah non, figurez-vous qu’un développeur un peu barré a réussi cet exploit !
Ce génie du code s’appelle Matt et il a même partagé son projet dingue sur GitHub. Son objectif était simple : Backporter .NET 2.0 à 3.5 sur Windows 95. À la base, même le support de Windows XP n’était pas prévu pour ces versions de .NET, alors Windows 95, n’en parlons pas !
Mais ça n’a pas découragé notre bidouilleur qui s’est retroussé les manches. Déjà, il a fallu installer Internet Explorer 5.01 et le Microsoft USB Supplement sur une version de Windows 95 OSR 2. Pas le choix, c’est nécessaire pour que .NET puisse fonctionner.
Ensuite, le plus gros du boulot a consisté à implémenter toutes les APIs Windows manquantes que .NET utilise sur les versions plus récentes de l’OS. Un vrai travail de titan et Matt a dû recoder des trucs dans tous les sens, intercepter des appels système, bref, il a mis les mains dans le cambouis et vous savez quoi ?
Ça marche !
Bon, c’est sûr que tout n’est pas parfait, il y a encore quelques bugs et incompatibilités par ci par là, mais on peut déjà faire tourner pas mal d’applications .NET sur Windows 95 grâce à son projet. La classe non ?
Franchement, chapeau bas. C’est ce genre de projets fous qui font qu’on kiffe toujours autant l’informatique. Bon par contre, je ne suis pas sûr que ce soit très utile dans la vraie vie, mais qu’importe, l’idée c’est de repousser les limites !
Je vous laisse avec ses explications. C’est un vrai film, vous allez voir !
En tout cas, si vous voulez vous amuser à installer des applis .NET sur votre Windows 95 (ou dans une VM hein, on n’est pas des sauvages), n’hésitez pas à tester son projet. Vous pourrez ensuite mettre ça sur votre profil Tinder et frimer en montrant à votre futures conquêtes une capture écran de Paint.NET qui tourne comme par magie sur votre vieux coucou ! (Je plaisante, NE FAITES PAS ÇA !!)
Si vous êtes développeur, vous connaissez certainement Notepad++. Il s’agit d’un éditeur de texte et de code source surpuissant sous Windows. Cependant, pour les utilisateurs de macOS et Linux, la quête d’un outil similaire (à la fois puissant et polyvalent) peut s’avérer être un défi. Aujourd’hui, je vous propose de découvrir Notepad Next. Il s’agit d’un outil simple, efficace, multi-plateforme et gratuit ! Notepad Next Notepad Next est une logiciel open source et gratuite qui fonctionne sous Windows, Linux et macOS. Les développeurs derrière cet outil ne cachent pas leur grande inspiration tirée du célèbre Notepad++. Ils ont créé un […]Windows 11 est peu apprécié des utilisateurs qui lui préfèrent largement la version 10 de l’OS. Malheureusement, celui-ci ne sera bientôt plus mis à jour par Microsoft et à cette occasion, l’entreprise en profite pour faire de la pub à son OS le plus récent.
L’article La fin de Windows 10 est proche, des publicités pour Win 11 envahissent le système est apparu en premier sur Tom’s Hardware.
On pensait tous que Windows 11 allait révolutionner notre expérience sur PC, et dommage car malgré les promesses de Microsoft, celui-ci semble trainer des pieds, même sur des machines survitaminées. C’est en tout cas le constat amer que dresse Andy Young, un ancien ingénieur de la firme de Redmond, dans une publication sur Twitter.
The Windows 11 Start Menu is comically bad.
— Andy Young (@anerdguynow) April 9, 2024
This machine has a $1600 Core i9 CPU and 128 GB of RAM and this is the performance I often get.
What is going on in Redmond? pic.twitter.com/hDvALHRB5q
Le mec a un PC doté d’un processeur Intel Core i9 à 1600 dollars et de pas moins de 128 Go de RAM. Une bête de course taillée pour avaler les tâches les plus gourmandes sans sourciller. Et pourtant, lorsqu’il lance le menu Démarrer de Windows 11, c’est la douche froide. Les icônes peinent à s’afficher, les clics se perdent dans les limbes, bref, c’est le grand n’importe quoi.
« Les performances sont comiquement mauvaises, mais que se passe-t-il à Redmond ?«
Car oui, Andy Young n’est pas n’importe qui. Pendant 13 ans, il a travaillé chez Microsoft en tant qu’ingénieur logiciel senior. Il a participé au développement de Windows et connait les subtilités du système comme sa poche. Alors quand il voit son bébé patauger de la sorte, ça lui fait mal au cœur.
« J’aime Windows, mais là, si les données suggèrent que le logiciel que vous avez construit frustre un pourcentage significatif d’utilisateurs, c’est qu’il y a encore du pain sur la planche.«
Les réactions à son tweet ne se sont pas fait attendre. De nombreux utilisateurs ont partagé leur déception et leur agacement face aux performances en demi-teinte de Windows 11, y compris sur des configurations musclées. Lenteurs au démarrage, latence dans l’affichage des fenêtres, bugs en tout genre… Les plaintes sont légion.
Alors, Windows 11 serait-il tout simplement un bide intersidéral ?
Peut-être pas, mais force est de constater que l’expérience utilisateur est loin d’être optimale, et ce malgré les mises à jour régulières déployées par Microsoft. La prochaine version du système, au nom de code Sun Valley 3, arrivera-t-elle à redresser la barre ?
On verra bien, mais en attendant, les utilisateurs les plus exigeants lorgnent de plus en plus du côté d’Apple et surtout de Linux et de ses distributions légères et rapide.
En tout cas, si Windows 11 semble un peu pataud, sachez qu’il existe de nombreuses astuces pour lui redonner du peps. Par exemple, désactivez les effets visuels inutiles, faire le ménage dans vos programmes lancés au démarrage, optimiser la base de registres… Bref, un peu de tuning bien senti peut faire des miracles. Et si vraiment rien n’y fait, vous pourrez toujours revenir à ce bon vieux Windows 10 en attendant des jours meilleurs.
