I. Présentation

Dans ce tutoriel, nous allons apprendre à bloquer / désactiver PowerShell sur les machines Windows afin qu'il soit inaccessible pour les utilisateurs standards. Cette configuration est fortement recommandée pour renforcer la sécurité de ses postes de travail et serveur.

PowerShell est un très bon outil d'administration, très puissant et qui permet de réaliser énormément de choses. Le problème, c'est qu'il est aussi beaucoup utilisé par les pirates informatiques par l'intermédiaire des logiciels malveillants (malwares). Je pourrais même être plus précis en affirmant que, depuis plusieurs années, certains ransomwares s'appuient sur PowerShell. Puisque Windows PowerShell est intégré à Windows, c'est une opportunité intéressante. Même si la politique d'exécution de scripts PowerShell est un premier rempart, cela n'est pas suffisant.

L'utilisation de la console PowerShell, de PowerShell ISE et l'exécution de scripts doit être limitée à certains comptes, notamment ceux associés aux membres du service informatique. Par exemple, lorsqu'un technicien intervient sur un poste de travail, il y a des chances qu'il ait besoin d'accéder à PowerShell. À l'inverse, l'utilisateur standard, usager de la machine au quotidien, il y a peu de chances qu'il utilise PowerShell, et si c'est le cas on peut considérer que c'est anormal.

A. Avertissement au sujet des scripts PowerShell exécutés par GPO

Dans certaines entreprises, on s'appuie sur les stratégies de groupe pour exécuter des scripts PowerShell à l'ouverture de session (ou à la fermeture de session) dans le contexte de l'utilisateur. Si vous appliquez la méthode détaillée dans cet article, ces scripts ne pourront plus s'exécuter, car l'utilisateur ne peut plus accéder à l'exécutable de PowerShell. Par contre, les scripts PowerShell exécutés dans le contexte de la machine (paramètre de configuration ordinateur) continueront de fonctionner.

B. Ce que nous allons faire...

Dans un premier temps, nous allons créer une GPO nommée "Restreindre-Acces-PowerShell" qui va s'appliquer sur l'OU "Personnel" de mon Active Directory. Cette OU contient tous les salariés de l'entreprise, à part les membres du service informatique. Tous les membres de cette OU ne pourront plus utiliser PowerShell. Cette GPO s'appuie sur les stratégies de restriction logicielle.

Dans un second temps, nous verrons comment créer une exception afin d'autoriser certains utilisateurs à exécuter PowerShell grâce à un groupe de sécurité AD. Par exemple, vous pouvez cibler tous les comptes de votre annuaire Active Directory et ajouter les membres du service informatique à ce groupe afin de les autoriser à exécuter PowerShell.

II. Bloquer PowerShell pour les utilisateurs standards

À partir de la console de Gestion des stratégies de groupe, je vais créer une GPO nommée "Restreindre-Acces-PowerShell" et la lier à l'OU "Personnel". Ensuite, il faut modifier cette GPO et parcourir les paramètres comme ceci :

Configuration utilisateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de restriction logicielle

Effectuez un clic droit sur "Stratégies de restriction logicielle" et cliquez sur "Nouvelles stratégies de restriction logicielle".

Afin de créer de nouvelles règles, effectuez un clic droit sur "Règles supplémentaires" puis cliquez sur "Nouvelle règle de chemin d'accès".

Par défaut, Windows PowerShell est installé à l'emplacement suivant sur Windows : "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe". Le chemin d'accès sera donc ce chemin. Ensuite, pour le paramètre "Niveau de sécurité", choisissez "Non autorisé".

Sur une machine Windows, il y a Windows PowerShell à deux emplacements pour les versions 32 et 64 bits, ainsi que l'éditeur de scripts PowerShell ISE, en version 32 et 64 bits également. En complément, on peut aussi trouver PowerShell 7 (PowerShell Core) qu'il faudra installer soi-même. Afin d'assurer une protection efficace, il faut bloquer l'ensemble de ces exécutables, sinon la configuration sera incomplète.

Répétez l'opération afin de créer une règle pour l'ensemble des chemins suivants :

# PowerShell 7 - 64 bits
C:\Program Files\PowerShell\7\pwsh.exe
# Windows PowerShell - 64 bits
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
# Windows PowerShell - 32 bits
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe
# Windows PowerShell ISE - 64 bits
C:\Windows\System32\WindowsPowerShell\v1.0\powershell_ise.exe
# Windows PowerShell ISE - 32 bits
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe

Vous allez obtenir ceci :

Notre configuration est prête ! Vous pouvez fermer la GPO, et tester sur un poste client en vous connectant avec un utilisateur sur lequel s'applique la GPO. Si vous essayez d'exécuter PowerShell de différentes façons, vous verrez que le message "Cette application a été bloquée par votre administrateur système" s'affiche.

Bien joué ! PowerShell est bloqué, y compris si on l'exécute via une autre application comme Windows Terminal.

Note : sachez que si vous souhaitez complètement désactiver PowerShell sur la machine, peu importe l'utilisateur, c'est possible en utilisant la même méthode via un paramètre de configuration ordinateur plutôt qu'utilisateur. La GPO devra alors cibler des objets ordinateurs.

III. Autoriser PowerShell pour certains utilisateurs

Maintenant, nous allons voir comment gérer une exception afin que tous les membres d'un groupe de sécurité Active Directory soient en mesure de passer outre la restriction. Au sein de l'annuaire Active Directory, créez un groupe de sécurité. Pour ma part, il se nomme "GG-Autoriser-PowerShell" et contient deux utilisateurs. L'utilisateur "Guy Mauve" est normalement un utilisateur lambda, mais pour les besoins de cette démo il aura le droit d'utiliser PowerShell.

Dès lors que le groupe de sécurité est prêt, nous devons retourner dans la console de gestion des GPO. Sélectionnez la GPO dans la liste, cliquez sur l'onglet "Délégation" en haut à droite puis sur le bouton "Ajouter" en bas.

Sélectionnez le groupe "GG-Autoriser-PowerShell" et validez. Ensuite, cliquez sur "OK" en veillant à ce que l'autorisation soit positionnée sur "Lecture".

Toujours dans l'onglet "Délégation", nous devons affiner les droits pour refuser l'application de la GPO sur ce groupe. En bas à droite, cliquez sur "Avancé...".

Dans la liste, sélectionnez le groupe "GG-Autoriser-PowerShell" et vérifiez que la permission "Lecture" soit bien autorisée et cochez la colonne "Refuser" pour la permission "Appliquer la stratégie de groupe".

Voilà, l'exclusion est en place : Guy Mauve va pouvoir profiter de PowerShell sur sa session. Je vous encourage à mettre en place cette mesure de sécurité sur votre infrastructure !

En complément, je vous recommande de bloquer l'accès à l'Invite de commande via le paramètre de GPO prévu à cet effet. Voici quelques liens utiles :

• Tutoriel - Bloquer CMD par GPO
• Tutoriel - Stratégie de restrictions logicielles
• Tutoriel - AppLocker

The post Comment bloquer PowerShell pour les utilisateurs ? first appeared on IT-Connect.

Microsoft est sur le point d'activer par défaut l'option "Attack Surface Reduction" de sa solution Microsoft Defender. L'objectif est d'empêcher les hackers de voler les identifiants via un dump du processus LSASS.

Lorsque l'on cherche à voler des identifiants sur une machine Windows, notamment pour s'authentifier sur une autre machine du réseau par la suite et progresser sur l'infrastructure cible, il y a une méthode bien connue qui consiste à faire un dump mémoire du processus LSASS (Local Security Authority Server Service) de Windows, après avoir obtenu un accès admin sur la machine. Grâce à ce dump que l'on peut effectuer avec Mimikatz, l'attaquant peut récupérer les hash NTLM correspondants aux utilisateurs connectés à la machine. Ensuite, cela ouvre d'autres possibilités comme le brute force sur les hash pour récupérer les mots de passe en clair, ou l'utilisation de la technique Pass-the-Hash pour s'authentifier sur un autre ordinateur en réutilisant les informations obtenues via le dump.

Microsoft Defender ASR : la réponse au problème ?

Pour contrer ces attaques et éviter qu'un dump mémoire du processus LSASS puisse être effectué, Microsoft propose plusieurs solutions pour empêcher l'accès à ce processus, y compris avec les droits administrateur. Il y a la fonctionnalité Credential Guard qui permet d'isoler le processus LSASS dans un container virtualisé pour empêcher les autres processus d'y accéder. Le problème, c'est que Credential Guard a tendance à rentrer en conflit avec certaines applications et certains pilotes. Résultat, certaines entreprises ne peuvent pas activer cette fonction.

L'alternative proposée par Microsoft consiste à utiliser la fonctionnalité "Attack Surface Reduction" (ASR) de Microsoft Defender, et cette option va être activée par défaut. Avant cela, l'option n'était pas configurée par défaut. Désormais, si l'on essaie de réaliser un dump mémoire du processus LSASS, on obtient un accès refusé même avec les droits administrateur. On peut se demander pourquoi Microsoft n'avait pas activé cette option plus tôt ? En fait, c'est parce qu'elle pourrait générer de faux positifs et beaucoup d'entrées dans l'observateur d'événements.

Désormais, Microsoft semble bien décidé à réduire la surface d'attaque de ses systèmes, en renforçant la configuration par défaut. Dernièrement, plusieurs actions vont dans ce sens : la désactivation de certaines macros dans Office ou encore la suppression à venir de WMIC sont de très bons exemples.

ASR : un premier pas, mais pas suffisant

La fonction ASR de Microsoft Defender for Endpoint est un premier pas, mais d'après les premiers retours, ce n'est pas suffisant. Voici pourquoi. Tout d'abord, il y a une limitation au niveau du système, ou plutôt un prérequis : il faut utiliser Windows en version Entreprise et Microsoft Defender doit être l'antivirus principal de la machine. Même si le site Bleeping Computer confirme que cela fonctionne sur Windows 10 Pro et Windows 11 Pro, ce n'est pas ce que dit Microsoft. Si vous installez un autre antivirus sur la machine, la fonction ASR est immédiatement désactivée. Pour le coup, c'est bien dommage.

Plus gênant encore, des chercheurs en sécurité sont parvenus à contourner la protection d'ASR en exploitant la liste des répertoires et fichiers exclus du périmètre de Microsoft Defender. Résultat, ils ont pu effectuer un dump mémoire du processus LSASS malgré que l'ASR soit actif sur la machine.

ASR rule to harden LSASS is being turned on by default, but remember that this isn't a silver bullet, plenty of ways around this... this has to be one of my favourites pic.twitter.com/fuQYJ3ZcAn

— Adam Chester (@_xpn_) February 9, 2022

<script async src="https://platform.twitter.com/widgets.js" charset="utf-8">

D'après Benjamin Delpy, le développeur de Mimikatz, Microsoft a probablement ajouté cette exclusion pour une autre règle, mais visiblement cela s'applique à toutes les règles. Néanmoins, cette protection devrait tout de même compliquer la tâche lors des attaques, surtout si Microsoft corrige le tir sur cette histoire d'exclusion. Disons que les choses vont dans le bon sens !

Source

The post Vol d’identifiants : Microsoft Defender veut protéger le processus LSASS first appeared on IT-Connect.

Microsoft continue de faire évoluer son outil de synchronisation Azure AD Connect afin de prendre en charge des scénarios synchronisation supplémentaire. Désormais, il va être possible de synchroniser un seul annuaire Active Directory vers plusieurs tenants Office 365.

Actuellement disponible en version preview, ce nouveau scénario va permettre de synchroniser des objets d'un annuaire Active Directory vers plusieurs tenants Office 365 à l'aide d'Azure AD Connect. Par exemple, des utilisateurs et des groupes peuvent être synchronisés vers plusieurs tenants Azure AD. Ainsi, un utilisateur peut avoir plusieurs comptes sur plusieurs environnements Office 365, en prenant le même compte AD comme source.

Par contre, il faudra mettre en place plusieurs serveurs Azure AD Connect : un par tenant, car une instance Azure AD Connect peut gérer seulement un tenant.

Quant à la gestion du mot de passe, Microsoft précise que la synchronisation du mot de passe (via le hash) est possible vers plusieurs tenants. Dans ce cas, il faut activer également la réécriture du mot de passe au sein d'Azure AD Connect. De cette façon, si le mot de passe est modifié auprès d'un tenant, il sera réécrit au niveau de l'AD local puis synchronisé sur les autres tenants. Grâce à ce mécanisme, le mot de passe reste unique sur les différents comptes associés à un même utilisateur.

Vous pouvez retrouver tous les détails au sein de la documentation Microsoft.

Attendiez-vous avec impatience que ce scénario soit pris en charge ?

The post Azure AD Connect : la synchro multi-tenants disponible en preview first appeared on IT-Connect.

La CISA a mis à jour son catalogue des vulnérabilités étant exploitées dans le cadre de cyberattaques. Avec ces 15 vulnérabilités supplémentaires, le total est porté à 367 failles de sécurité.

La CISA est une agence fédérale américaine qui traite des questions de la cybersécurité et elle rattachée directement au département de la sécurité intérieure. Dans le même esprit que l'ANSSI en France, elle publie régulièrement des informations intéressantes.

Elle maintient à jour un catalogue qui référence les vulnérabilités connues utilisées dans le cadre d'attaques informatiques. Quinze vulnérabilités supplémentaires viennent de faire leur entrée dans ce listing. On peut considérer que les entreprises doivent prioriser l'installation des mises à jour de sécurité qui permettent de se protéger contre ces failles de sécurité. Cela est d'autant plus vrai que les CVE listées sont patchées depuis plusieurs mois ou années, ce qui permet de voir où l'on se situe.

Par exemple, dans la liste des 15 vulnérabilités, on retrouve la CVE-2021-36934 baptisée SeriousSAM. Il s'agit d'une faille de sécurité Windows au sein du gestionnaire de la base de comptes locaux (SAM) qui permet à n'importe quel utilisateur d'accéder à la base de données du Registre sous Windows 10. Conséquence : il est possible d'extraire le hash des mots de passe et d'obtenir les privilèges administrateur en exploitant ces informations. La bonne nouvelle, c'est qu'elle a déjà était patchée en juillet 2021 par Microsoft à l'occasion d'un Patch Tuesday.

Voici la liste des 15 vulnérabilités avec des vulnérabilités découvertes entre 2014 et 2021 :

Référence CVE	Nom de la CVE
CVE-2021-36934	Windows SAM - Élévation de privilèges
CVE-2020-0796	Microsoft SMB v3 - Exécution de code à distance
CVE-2018-1000861	Jenkins : Stapler Web Framework - Désérialisation des données non fiable
CVE-2017-9791	Apache Struts - Mauvaise validation des données
CVE-2017-8464	Microsoft Windows Shell (.lnk) - Exécution de code à distance
CVE-2017-10271	Oracle Corporation WebLogic Server - Exécution de code à distance
CVE-2017-0263	Microsoft Win32k - Élévation de privilèges
CVE-2017-0262	Microsoft Office - Exécution de code à distance
CVE-2017-0145	Microsoft SMBv1 - Exécution de code à distance
CVE-2017-0144	Microsoft SMBv1 - Exécution de code à distance
CVE-2016-3088	Apache ActiveMQ - Mauvaise validation des données
CVE-2015-2051	D-Link DIR-645 Router - Exécution de code à distance
CVE-2015-1635	Microsoft HTTP.sys - Exécution de code à distance
CVE-2015-1130	Apple OS X - Bypass de l'authentification
CVE-2014-4404	Apple OS X - Buffer-overflow

Le catalogue complet, où l'on retrouve de nombreuses vulnérabilités, comme la faille Log4Shell (Log4j), est accessible à cette adresse : CISA - Catalogue des vulnérabilités

Pour qu'une vulnérabilité soit ajoutée au catalogue, elle doit respecter 3 critères :

• Il y a une référence CVE associée
• Il y a des preuves que la vulnérabilité est activement exploitée par les pirates dans le cadre d'attaques
• Il y a une mise à jour disponible ou des mesures d'atténuation précises

En étant protégé contre ces différentes failles de sécurité, vous réduisez directement votre surface d'attaque.

Source

The post D’après la CISA, ces 15 vulnérabilités sont exploitées dans des attaques first appeared on IT-Connect.

Au sein de la dernière version de Windows 11 publiée dans le canal Dev, l'outil en ligne de commande "wmic.exe" n'est plus présent sur le système d'exploitation ! Une page se tourne (mais partiellement).

Pour rappel, l'outil en ligne de commande "wmic.exe" correspondant à "Windows Management Instrumentation Command-line" permet d'utiliser WMI sur une machine Windows. Grâce à lui, il est possible d'exécuter des requêtes sur le système, que ce soit pour exécuter des actions ou obtenir de nombreuses informations sur le système. Un outil fort utile pour les administrateurs système !

Je tiens à vous rassurer d'entrée : l'outil wmic.exe va disparaître de Windows, mais le WMI quant à lui sera toujours présent ! C'est seulement qu'au lieu d'utiliser wmic.exe, il va falloir utiliser les commandes PowerShell correspondantes, puisque PowerShell fonctionne très bien avec WMI.

Comme l'a constaté le chercheur en sécurité Grzegorz Tworek, Microsoft a appliqué ce qui était prévu : "wmic.exe" est bien déprécié depuis Windows 10 21H1, et il n'est plus présent sur la dernière build en cours de développement de Windows 11. Si l'on essaie d'exécuter cette commande, le système indique qu'elle n'est pas reconnue.

Comment expliquer cette décision de la part de Microsoft ? Et bien, l'objectif est de mettre des bâtons dans les roues des pirates puisque cet outil est couramment utilisé par les logiciels malveillants. Il fait partie de la catégorie des "LoLBins", c'est-à-dire des outils capables de tromper la vigilance des antivirus car ils ont une bonne réputation. En effet, "wmic.exe" est signé par Microsoft.

Par exemple, il est fréquent que "wmic.exe" soit utilisé par les ransomwares afin de supprimer les clichés instantanés d'une machine via la commande suivante :

wmic.exe shadowcopy delete /nointeractive

Cet outil peut-être utilisé également pour ajouter des exclusions à Microsoft Defender afin d'autoriser le logiciel malveillant. Autre exemple : lister les antivirus installés sur la machine et les supprimer. Même si cela part d'une bonne intention de la part de Microsoft, cette joie devrait être de courte durée. Les pirates vont bien trouver des alternatives pour exécuter leurs commandes, mais si cela peut réduire les attaques ou les rendre plus difficiles, on ne va pas s'en plaindre.

Si vous utilisez "wmic.exe" dans vos scripts, vous n'avez plus qu'à entamer la migration vers les commandes PowerShell. Enfin, vous avez encore le temps de voir venir, mais il faut y penser.

Source

The post C’est officiel, Microsoft commence à supprimer WMIC de Windows first appeared on IT-Connect.