I. Présentation

Dans ce tutoriel, nous allons apprendre à configurer l'audit des contrôleurs de domaine de façon à générer un événement lorsque le mot de passe d'un utilisateur est réinitialisé, ou qu'il y a une tentative de réinitialisation d'un mot de passe. Grâce à cet événement, il sera possible de savoir quel utilisateur a effectué le changement de mot de passe, mais aussi quel est le compte concerné par cette réinitialisation.

Pour auditer cet événement, nous devons modifier la stratégie d'audit des contrôleurs de domaine afin que l'événement avec l'ID 4724 soit généré lorsque le mot de passe est réinitialisé avec succès ou qu'il y a une tentative en échec.

• Microsoft Docs - Event ID 4724

Note : Lorsqu'un utilisateur tente de modifier son propre mot de passe, l'ID de l'événement sera différent puisque ce sera 4723.

II. Événement ID 4724 : créer la GPO

Commencez par ouvrir la console "Gestion de stratégie de groupe" et créez une nouvelle GPO nommée "Réinitialisation mots de passe - Audit". Bien sûr, vous pouvez utiliser une GPO existante notamment si vous avez déjà une GPO pour configurer l'audit. Cette GPO doit-être liée à l'OU "Domain Controllers", il n'est pas nécessaire qu'elle soit associée au domaine.

Modifiez la GPO et parcourez les paramètres de cette façon :

Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité

Ici, vous devez activer le paramètre "Audit : forcer les paramètres des sous-catégories..." pour que les paramètres d'audit avancés soient pris en compte. Comme ceci :

Une fois que c'est fait, parcourez l'arborescence de cette façon pour trouver un autre paramètre :

Stratégies > Paramètres Windows > Paramètres de sécurité > Configuration avancée de la stratégie d'audit > Stratégies d'audit > Gestion du compte

Le paramètre que l'on activer ici, se nomme "Auditer la gestion des comptes d'utilisateurs". Double-cliquez dessus et cochez les trois cases pour générer des événements aussi bien en cas de succès qu'en cas d'échec.

Validez et fermez l'éditeur de la GPO puisqu'elle est déjà prête ! Il n'y a pas d'autres paramètres à activer. Désormais, il faut actualiser les GPO afin de tester.

III. Visualiser l'événement 4724 sur le contrôleur de domaine

À partir de la console "Utilisateurs et ordinateurs Active Directory", ou d'un autre moyen tel que PowerShell, il faut réinitialiser le mot de passe d'un utilisateur pour vérifier si cela fonctionne... Dans la console AD, il suffit de faire un clic droit sur un utilisateur puis cliquer sur "Réinitialiser le mot de passe". En PowerShell, on peut utiliser cette commande :

Set-ADAccountPassword "nom-utilisateur" -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "NouveauMotDePasse" -Force)

Une fois que c'est fait, rendez-vous dans l'Observateur d'événements sur le contrôleur de domaine ! Sous "Journaux Windows", effectuez un clic droit sur "Sécurité" et cliquez sur "Filtrer le journal actuel". Il suffit d'indiquer l'ID 4724 puis de valider.

Là, on peut voir différents événements donc la stratégie de groupe fonctionne bien ! Chaque événement contient deux sections :

• Sujet : l'utilisateur qui est à l'origine de la réinitialisation du mot de passe
• Compte cible : l'utilisateur qui est "victime" du changement de mot de passe

Si l'on prend l'exemple ci-dessous, on peut affirmer que l'utilisateur "florian" a réinitialisé le mot de passe du compte "vincent.timmes" le 24 mars 2022 à 11h23. Une information intéressante !

Sur la copie d'écran ci-dessus, nous constatons également la ligne "Ordinateur : SRV-ADDS-01.it-connect.local" mais cela ne correspond pas à l'ordinateur source (malheureusement). En fait, cet événement ne permet pas de connaître le nom de la machine utilisée par "florian" pour réinitialiser le mot de passe du compte "vincent.timmes". Par contre, l'événement est généré sur le contrôleur de domaine interrogé au moment de réinitialiser le mot de passe.

Note : Lorsqu'un événement en échec est généré, c'est potentiellement à cause d'un mot de passe qui ne respecte pas la politique de mots de passe, car Microsoft précise qu'en cas d'accès refusé, cela ne génère pas un événement en échec. Un petit détail à connaître.

Voilà, vous êtes désormais en mesure de savoir qui a réinitialisé un mot de passe dans votre Active Directory ! Dans le même esprit, si l'audit Active Directory vous intéresse, je vous invite à lire mon tutoriel sur le verrouillage des comptes Active Directory.

The post Active Directory : comment savoir qui a réinitialisé le mot de passe d’un utilisateur ? first appeared on IT-Connect.

Microsoft a corrigé un bug sur Windows Server 2019 qui affecte les serveurs DNS et plus particulièrement le chargement des zones de stub. Résultat, vous pouvez constater des problèmes de résolution DNS.

Pour rappel, un serveur DNS sous Windows Server permet de créer différents types de zones, notamment les zones de stub qui sont des copies de zones dans lesquelles on retrouve des enregistrements de type ressources pour identifier les serveurs DNS faisant autorité sur la zone en question. Autrement dit, c'est une sorte de redirecteur dynamique.

D'après Microsoft, les utilisateurs ont pu rencontrer ce bug connu s'ils ont installé la mise à jour KB5009616 sortie le 25 janvier 2022, ou une version plus récente, c'est-à-dire la KB5010427 (sortie le 15 février 2022) ou la KB5011551 (sortie le 22 mars 2022).

En lisant le message publié sur le site de Microsoft, on apprend que ce bug a été corrigé par l'intermédiaire de la fonctionnalité Known Issue Rollback (KIR) mais que le correctif ne sera pas diffusé automatiquement sur les machines affectées. Pourtant, il me semble que c'est le but de la fonctionnalité KIR justement.

Les administrateurs système doivent mettre en place de stratégies de groupe pour que KIR soit opérationnel, tel qu’expliqué dans cette documentation officielle. Voici les liens vers les packages MSI à télécharger :

• Téléchargement 1 for Windows Server 2019
• Téléchargement 2 for Windows Server 2019

Avez-vous rencontré ce bug qui affecte uniquement Windows Server 2019 ?

Source

The post Windows Server 2019 : Microsoft corrige un bug lié au DNS first appeared on IT-Connect.

Début mars, Microsoft a annoncé l'arrivée prochaine de Windows 11 22H2 et visiblement les choses avancent bien, car la firme de Redmond vient d'approuver Windows 11 22H2 ! Cela signifie que la version passe dans le canal "Release" accessible aux membres du programme Windows Insider.

Depuis que Windows 11 est sorti, Microsoft travaille sur une nouvelle version majeure de son système d'exploitation dans le but d'apporter de nouvelles fonctionnalités, dont la possibilité d'exécuter des applications Android nativement sur Windows (en passant par l'Amazon AppStore). Entre nous, c'est probablement la nouveauté la plus attendue.

Pour tester les nouvelles fonctionnalités, les améliorations et corriger des bugs au fur et à mesure, la firme de Redmond publie régulièrement de nouvelles Builds avec le nom "22000.xxx" au sein du canal "Beta" de Windows 11. De quoi permettre aux membres du programme Windows Insider de tester les nouveautés en avant-première, et aussi d'effectuer de précieux retours à Microsoft.

Désormais, les versions 22000.xxx sont disponibles dans le canal "Release" de Windows 11, ce qui signifie que la sortie de la nouvelle version "Windows 11 22H2", aussi appelée "Windows 11 Sun Valley 2", est relativement proche.

Dans le même temps, Microsoft a publié la Build 22581 de Windows 11 dans les canaux habituels pour le développement et les tests, à savoir les canaux "Beta" et "Dev". Les utilisateurs qui souhaitent continuer à tester les futures fonctionnalités, doivent rester dans le canal "Dev".

Au-delà de permettre l'utilisation d'applications Android, Windows 11 22H2 va notamment apporter les changements suivants :

• Mises à jour de certaines applications telles que Bloc-notes, Paint et le Media Player
• Correction de bugs, dont le bug du "glisser-déposer" qui ne fonctionne pas via la barre des tâches (enfin !)
• Amélioration des performances du système

Si vous suivez mes articles d'actualités au sujet de Windows 11, vous avez déjà pu avoir un aperçu des nouveautés à venir au sein de cette nouvelle version majeure de Windows 11.

Windows 11 22H2 devrait sortir dans le courant du printemps 2022 !

Source

The post Windows 11 22H2 passe dans le canal Release et devrait sortir prochainement ! first appeared on IT-Connect.

Les chercheurs en sécurité de Splunk ont réalisé une expérience technique plutôt intéressante, qui consiste à tester 10 ransomwares différents dans le but de déterminer la rapidité avec laquelle ils chiffrent les fichiers sur une machine compromise. Grâce à ces résultats, il est plus facile d'évaluer la faisabilité d'une réponse rapide à leurs attaques.

Lorsqu'un ransomware entre en action sur une machine, il va chiffrer l'intégralité des données afin que celles-ci deviennent inutilisables par l'entreprise. Dans le cas où les données sont chiffrées, l'entreprise a trois options : payer la rançon, ce qui est déconseillé pour ne pas encourager les travaux des cybercriminels ; restaurer les données à partir d'une sauvegarde ; tirer un trait sur les données, ce qui n'est pas si simple !

Ransomware : quel est le plus rapide ?

Du coup, la vitesse de chiffrement est importante, car plus vite il est détecté, moins il aura le temps de chiffrer de données, et donc moins les dommages seront importants.

Pour mener à bien leur expérience technique qui consiste à faire un benchmark des ransomwares en quelque sorte, les chercheurs en sécurité de Splunk ont utilisé :

• 4 profils de machines avec des niveaux de performance différents
• 10 ransomwares distincts, avec à chaque fois 10 échantillons
• 400 tests de chiffrement pour établir leur tableau de synthèse (10 x 10 x 4 en fait !)

Plus précisément, les machines victimes sont sous Windows, deux sous Windows 10 et deux sous Windows Server 2019, avec à chaque fois deux niveaux de performances. Les configurations utilisées correspondent à ce que l'on peut retrouver en entreprise. Quant à l'échantillon de données, il fait 53 Go et il contient 98 561 fichiers.

Si l'on regarde le tableau ci-dessous, on peut voir que les différences de performances sont énormes entre certains ransomwares, à isopérimètre.

Même si certains ransomwares comme LockBit et Babuk sont bien plus rapides que d'autres, il faut tenir compte aussi de la dernière valeur : 42 minutes et 52 secondes. Cela correspond à la moyenne globale des 10 ransomwares. Quand les pirates à l'origine de LockBit affirmaient que c'était le plus rapide de tous les ransomwares, on comprend que cela n'était pas simplement une sorte "d'argument commercial" !

Même si la quantité de données chiffrées ici est relativement faible par rapport aux volumes que l'on peut rencontrer en entreprise, force est de constater que l'opération de chiffrement est rapide ! Cela veut dire qu'il faut être très réactif pour stopper l'hémorragie lorsque le chiffrement est en cours, mais cela signifie aussi qu'il faut être capable de détecter l'activité malveillante avant d'en arriver à la dernière étape : l'exécution du ransomware.

Ce schéma synthétique du CERT-NZ montre les différentes étapes d'une attaque par ransomware et les éventuelles opportunités de détecter l'activité malveillante.

L'article de Splunk est disponible à cette adresse si vous souhaitez découvrir tout le compte-rendu.

Source

The post Des chercheurs ont évalué la vitesse de chiffrement de 10 ransomwares first appeared on IT-Connect.

La série continue ! Microsoft a confirmé que le compte de l'un de ses salariés a été compromis par les cybercriminels du groupe LAPSUS$. Grâce à ces identifiants, ils ont pu accéder aux codes sources stockés sur un serveur Azure DevOps et exfiltrer des données.

La nuit dernière, le groupe LAPSUS$ a mis en ligne une archive de 37 Go correspondante à des données dérobées sur le serveur Azure DevOps de Microsoft. Cette archive contient des codes sources d'applications Microsoft associés à différents projets tels que Bing, Cortana et Bing Maps. Voici un aperçu des dossiers contenus dans l'archive mise en ligne :

De son côté, Microsoft a rapidement réagi en affirmant qu'un compte d'un salarié avait été compromis par les hackers de LAPSUS$. Même si ce compte offre un accès limité aux dépôts où sont stockés les codes sources, il a tout de même permis d'exfiltrer plusieurs giga-octets de données. La firme de Redmond précise : "Aucun code ou donnée client n'a été impacté dans les activités observées. Notre enquête a révélé qu'un seul compte avait été compromis, accordant un accès limité. Nos équipes de réponse aux incidents de cybersécurité se sont rapidement engagées à protéger le compte compromis et à empêcher toute autre activité."

Même si Microsoft n'a pas expliqué comment le compte a pu être compromis, l'entreprise américaine a publié des informations globales sur la tactique, les techniques et les procédures utilisées par le groupe LAPSUS$, identifié avec le nom "DEV-0537".

Pour obtenir des identifiants, le groupe LAPSUS$ utiliseraient les méthodes suivantes :

• Déployer le logiciel malveillant Redline pour dérober des mots de passe et des jetons de session
• Acheter des informations d'identification et de jetons de session sur des forums criminels
• Payer les employés des organisations ciblées (ou les fournisseurs/partenaires commerciaux) pour avoir accès aux informations d'identification
• Rechercher des identifiants exposés dans des dépôts de code publics

À partir du moment où ils sont en possession d'identifiants, ils sont en mesure d'essayer de connecter à l'infrastructure cible de différentes façons, par exemple via un accès VPN, ou un service de gestion des identités.

Lorsque le compte est protégé par le MFA, ils utilisent une méthode qui permet de rejouer les sessions, ou alors ils envoient des demandes d'approbation MFA en boucle jusqu'à ce que l'utilisateur s'agace de recevoir les notifications et approuve la connexion. D'après Microsoft, il y a au moins un cas d'attaque où la méthode "SIM swap" a été utilisée afin de récupérer les codes MFA envoyés par SMS.

Dès lors que les pirates ont accès au réseau, ils l'utilisent l'outil AD Explorer pour rechercher des comptes avec des privilèges élevés, pour ensuite cibler des solutions collaboratives comme SharePoint, Confluence, Jira, Slack ou encore Microsoft Teams. Ils n'hésitent pas également à exploiter des vulnérabilités connues et présentent au sein de solutions populaires comme Confluence et GitLab.

Le rapport de Microsoft est accessible à cette adresse : DEV-0537.

Une fois de plus, les différentes techniques évoquées ci-dessus montrent qu'il faut éduquer les utilisateurs et les sensibiliser aux différents risques !

Enfin, je vous rappelle que le groupe LAPSUS$ enchaine les piratages contre les grandes entreprises ces dernières semaines, avec une liste qui est loin d'être anodine : Okta qui est actuellement dans la tourmente, mais aussi NVIDIA, Samsung en publiant 190 Go de données, le site de e-commerce MercadoLibre, ainsi que le géant du jeu vidéo Ubisoft.

Source

The post Microsoft confirme avoir été piraté par le groupe LAPSUS$ ! first appeared on IT-Connect.