I. Présentation

Dans ce tutoriel, nous allons apprendre à synchroniser manuellement un appareil Windows inscrit dans Microsoft Intune. Cette manipulation peut s'avérer utile si vous venez de créer une nouvelle stratégie sur Intune et que vous souhaitez vérifier son bon fonctionnement, sans avoir à attendre. Ceci peut être pratique également en phase de dépannage sur un appareil Windows (stratégie non redescendue, stratégie en erreur, etc.).

• Cliquez ici pour regarder la vidéo sur YouTube

Si vous avez l'habitude de travailler avec un Active Directory et les stratégies de groupe, vous recherchez surement un équivalent à la célèbre commande "gpupdate". À l'heure actuelle, cette commande n'existe pas pour Intune, à moins d'utiliser PowerShell mais cela implique de s'appuyer sur le module Microsoft Graph.

Dans cet article, nous allons étudier différentes possibilités, que ce soit depuis l'appareil à synchroniser en lui-même ou à partir du Centre d'administration Intune. Ceci nous donnera aussi l'occasion d'évoquer les cycles de synchronisation par défaut d'Intune, pour Windows et les autres OS pris en charge.

II. Les cycles de synchronisation Intune

Le cycle d'actualisation ou fréquence d'actualisation par défaut pour les appareils inscrits sur Intune, et peu importe le système d'exploitation, est de 8 heures. Cela signifie que lorsqu'une nouvelle stratégie est créée, elle peut mettre jusqu'à 8 heures à "redescendre" sur les appareils.

Voici un tableau récapitulatif :

Plateforme	Fréquence d'actualisation
Android, AOSP	Environ toutes les 8 heures
iOS/iPadOS	Environ toutes les 8 heures
macOS	Environ toutes les 8 heures
Windows 10/11	Environ toutes les 8 heures
Windows 8.1	Environ toutes les 8 heures

Néanmoins, lorsqu'un appareil vient de s'inscrire dans Intune, la fréquence d'actualisation est un peu différente. Il y aura des synchronisations rapprochées au départ, comme le montre le tableau ci-dessous.

Plateforme	Fréquence d'actualisation
Android, AOSP	Toutes les 3 minutes pendant 15 minutes, ensuite toutes les 15 minutes pendant 2 heures, et ensuite environ toutes les 8 heures.
iOS/iPadOS	Toutes les 15 minutes pendant 1 heure, et ensuite environ toutes les 8 heures.
macOS	Toutes les 15 minutes pendant 1 heure, et ensuite environ toutes les 8 heures.
Windows 10/11	Toutes les 3 minutes pendant 15 minutes, ensuite toutes les 15 minutes pendant 2 heures, et ensuite environ toutes les 8 heures.
Windows 8.1	Toutes les 3 minutes pendant 15 minutes, ensuite toutes les 15 minutes pendant 2 heures, et ensuite environ toutes les 8 heures.

Les informations présentées dans les tableaux ci-dessus sont issues de la documentation Microsoft :

• Microsoft Learn - Policy refresh intervals

Certaines actions impliquent une synchronisation "dès que possible", où Intune notifie l'appareil qu'il doit se synchroniser maintenant. Voici ce que l'on peut lire sur cette page de la documentation Microsoft : "Les appareils se connectent à Intune lorsqu'ils reçoivent une notification de connexion ou lors de la connexion programmée. Lorsque vous ciblez un appareil ou un utilisateur avec une action, Intune notifie immédiatement l'appareil pour qu'il s'enregistre et reçoive ces mises à jour. Par exemple, une notification est envoyée lorsqu'une action de verrouillage, de réinitialisation du code d'accès, d'application ou d'attribution de stratégie est exécutée."

De plus, il y a un cycle différent pour l'Intune Management Extension, utilisée notamment pour l'exécution des scripts PowerShell avec Intune et le déploiement des applications avec Intune, où le cycle de synchronisation est de 1 heure.

Par ailleurs, il n'est pas à exclure qu'il y ait quelques exceptions et des cycles d'actualisation différents sur certaines fonctionnalités spécifiques d'Intune. C'est le cas avec les stratégies d'App Protection comme l'explique cette page.

III. Synchroniser un appareil Windows

Nous allons nous intéresser à différentes façons de synchroniser un appareil Windows, que ce soit depuis l'appareil en lui-même, depuis le Centre d'administration Microsoft Intune ou à l'aide de PowerShell.

A. Synchroniser à partir des paramètres de Windows

La première méthode à connaître, et que nous avons déjà évoqué dans de précédents articles, consiste à utiliser l'interface de gestion des paramètres de Windows.

Ouvrez les "Paramètres" Windows, cliquez sur "Comptes" à gauche, puis sur "Accès Professionnel ou Scolaire". Cliquez sur la flèche (mise en évidence sur l'image ci-dessous), puis sur le bouton "Info".

Une nouvelle page apparaît. Sur celle-ci, vous devez cliquer sur le bouton "Synchroniser". Ceci va permettre de déclencher une synchronisation, et il ne vous reste plus qu'à patienter le temps qu'elle soit effectuée.

B. Synchroniser à partir du Portail d'entreprise

Parmi les fonctionnalités de l'application "Portail d'entreprise" appelée également "Company Portal", il y a la possibilité de lancer une synchronisation sans passer par les paramètres du système Windows. Au sein de cette application, qui doit être au préalable installée sur l'appareil, cliquez sur le bouton des paramètres en bas à gauche (1) afin d'accéder au bouton nommé "Synchroniser" (2). Ceci est facilement accessible par un utilisateur lambda.

Une autre possibilité, c'est d'effectuer un clic droit sur "Portail d'entreprise" dans le menu Démarrer afin de cliquer sur le bouton "Synchroniser cet appareil". Le problème, c'est que cette entrée est visible seulement lorsque l'on effectue un clic droit à partir de la liste de toutes les applications (si l'application est épinglée au menu Démarrer et que l'on passe par ce raccourci, cela n'est pas proposé).

C. Synchroniser un appareil depuis le portail Intune

Désormais, nous allons basculer sur le Centre d'administration Intune puisqu'il intègre deux fonctionnalités permettant de lancer une synchronisation sur un ou plusieurs appareils.

Tout d'abord, quand vous accédez à la liste des "Appareils" et qu'ensuite, vous cliquez sur un appareil dans la liste, vous verrez apparaître un bouton nommé "Synchroniser" dans la "Vue d'ensemble". Il vous suffit de cliquer sur ce bouton.

Une fenêtre de confirmation apparaît, cliquez sur "Oui" et cela va envoyer un signal à la machine pour qu'elle se synchronise.

D. Synchroniser en masse des appareils depuis le portail Intune

Le Centre d'administration Intune vous offre aussi la possibilité d'effectuer des actions en masse sur une sélection d'appareils. La synchronisation fait partie des actions envisageables. Voici la marche à suivre :

1 - Cliquez sur "Appareils" dans le menu de gauche du portail Intune

2 - Cliquez sur "Tous les appareils".

3 - Cliquez sur le bouton "Actions d'appareil en bloc".

Un assistant va s'exécuter. Plusieurs options sont à configurer :

1 - Vous devez commencer par choisir le système d'exploitation, donc prenez "Windows".

2 - Sélectionnez le type d'appareil "Appareils physiques".

3 - Comme type d'action à exécuter, sélectionnez "Synchroniser".

Passez à l'étape suivante. Vous devrez alors cliquer sur "Sélectionner les appareils à inclure" afin de sélectionner un ou plusieurs appareils, dans la limite de 100 appareils (limite actuelle).

Ensuite, poursuivez jusqu'à la fin de la création de la tâche. Une notification au sein d'Intune vous indiquera si la tâche a été lancée, ou non.

E. Synchroniser un appareil avec PowerShell

Avec PowerShell, nous pouvons interagir avec les services Cloud de Microsoft tels qu'Azure et Intune par l'intermédiaire de Microsoft Graph. Il y a un ensemble de modules PowerShell disponibles et à utiliser en fonction des usages. Nous allons voir comment utiliser Microsoft Graph avec PowerShell pour synchroniser un appareil (puis plusieurs appareils).

• PowerShell : comment se connecter à Microsoft Graph API ?
• Microsoft Graph V2 - PowerShell : Nouveautés, migration V1/V2 et avenir des modules AzureAD/MSOnline

Commencez par ouvrir une console PowerShell en tant qu'administrateur afin d'installer les modules Microsoft Graph. Vous pouvez tout installer, ou uniquement installer ceux dont vous avez besoin. Peut-être que vous avez déjà ces modules sur votre machine si vous avez l'habitude d'interagir avec les services Microsoft avec PowerShell.

Puis, exécutez la commande suivante pour basculer dans une console PowerShell avec la stratégie d'exécution "RemoteSigned", sinon vous allez obtenir des erreurs par la suite (si vous êtes en "Restricted", par exemple).

powershell.exe -ExecutionPolicy RemoteSigned

Installez tous les modules Microsoft Graph (alternative ci-dessous) :

Install-Module Microsoft.Graph

Si vous préférez limiter l'installation au strict minimum, installez ceci :

Install-Module -Name Microsoft.Graph.DeviceManagement
Install-Module -Name Microsoft.Graph.DeviceManagement.Actions

Vous devez savoir que :

• Le module "Microsoft.Graph.DeviceManagement" contient le cmdlet "Get-MgDeviceManagementManagedDevice" que nous allons utiliser par la suite pour récupérer des informations sur les appareils.
• Le module "Microsoft.Graph.DeviceManagement.Actions" contient le cmdlet "Sync-MgDeviceManagementManagedDevice" que nous allons utiliser pour déclencher une synchronisation sur un appareil.

Ensuite, connectez-vous à Microsoft Graph avec PowerShell. Nous pourrions établir une connexion globale, mais nous allons plutôt limiter notre connexion à certains scopes correspondants à nos besoins. Ceci pour des raisons de sécurité et pour limiter les droits de la session que nous allons initier.

Connect-MgGraph -Scope DeviceManagementManagedDevices.PrivilegedOperations.All, DeviceManagementManagedDevices.ReadWrite.All,DeviceManagementManagedDevices.Read.All

Suite à l'exécution de cette commande, vous êtes invités à vous authentifier auprès de votre tenant Microsoft 365. Puis, vous devez valider la demande d'autorisations émise par l'application Microsoft Graph.

Quand c'est fait, un message doit s'afficher dans la console : "Welcome to Microsoft Graph!". Il signifie en quelque sorte que vous pouvez commencer à interroger Intune à partir de PowerShell, car la connexion est établie.

Commençons par l'exécution d'une première commande qui va retourner la liste de tous vos appareils, aussi bien Windows que les autres plateformes, en retournant les propriétés "DeviceName" et "LastSyncDateTime" qui correspondent respectivement au nom de l'appareil et à sa date de dernière synchronisation. Le paramètre "-All" est important, car si vous avez beaucoup d'appareils, la liste sera incomplète s'il n'est pas précisé.

Get-MgDeviceManagementManagedDevice -All | Format-Table DeviceName, LastSyncDateTime

Voici un exemple :

Si vous souhaitez obtenir ces informations uniquement pour les appareils Windows, vous devez ajouter un filtre sur la propriété "OperatingSystem". Il y a deux façons d'effectuer ce filtre :

Get-MgDeviceManagementManagedDevice -Filter "Startswith(OperatingSystem,'Windows')" -All | Format-Table DeviceName, LastSyncDateTime
# ou
Get-MgDeviceManagementManagedDevice -All | Where{ $_.OperatingSystem -eq "Windows" } | Format-Table DeviceName, LastSyncDateTime

Vous devez stocker le résultat du cmdlet "Get-MgDeviceManagementManagedDevice" dans une variable afin de récupérer l'ID de l'appareil à cibler. Dans l'exemple ci-dessous, nous allons ajouter un filtre basé sur l'opérateur "Contains" pour rechercher la machine "PC-ITC-02". C'est sur cette machine que nous souhaitons forcer une synchronisation.

$Target = Get-MgDeviceManagementManagedDevice -Filter "contains(deviceName,'PC-ITC-02')"

Le résultat est stocké dans la variable "$Target". Elle contient un ensemble de propriétés au sujet de cet appareil, dont la propriété "Id" qui est requise par le cmdlet "Sync-MgDeviceManagementManagedDevice".

Ainsi, voici comment nous allons forcer la synchronisation sur cet appareil :

Sync-MgDeviceManagementManagedDevice -ManagedDeviceId $Target.Id

Cette commande ne retourne pas de résultat dans la console, mais l'ordre de synchronisation sera bien envoyé à l'appareil.

F. Synchroniser plusieurs appareils avec PowerShell

Grâce à l'utilisation de PowerShell, nous allons pouvoir cibler plusieurs appareils et créer des filtres sur-mesure.

Voici un premier exemple pour obtenir la liste de tous les appareils dont le nom commence par "PC-ITC", ce qui permettra de cibler les appareils nommés "PC-ITC-01", "PC-ITC-02", etc.

Get-MgDeviceManagementManagedDevice -Filter "Startswith(deviceName,'PC-ITC')"

Voici un second exemple pour obtenir la liste de tous les appareils dont le nom contient la chaine de caractères "ITC" (peu importe si cela est au début, à la fin, au milieu, etc.).

Get-MgDeviceManagementManagedDevice -Filter "Contains(deviceName,'ITC')"

Ensuite, nous pouvons stocker le résultat dans une variable et parcourir la liste d'appareils avec une boucle ForEach dans le but de déclencher une synchronisation sur chaque appareil.

$Targets = Get-MgDeviceManagementManagedDevice -Filter "Startswith(deviceName,'PC-ITC')"

ForEach ($Device in $Targets) {
        try {
            Sync-MgDeviceManagementManagedDevice -ManagedDeviceId $Device.id -ErrorAction Stop
            Write-Host "$($device.DeviceName) - Synchronisation exécutée" -ForegroundColor Green
        }
        catch {
            Write-Host "$($device.DeviceName) - Echec de l'opération avec l'erreur : $($_.Exception.Message)" -ForegroundColor Red
        }
}

Pour chaque appareil, il y aura un retour dans la console pour indiquer si la commande "Sync-MgDeviceManagementManagedDevice" s'est exécutée correctement ou non. Attention, ceci n'indique pas réellement le résultat de la synchronisation.

PC-ITC-02 - Synchronisation exécutée

IV. Conclusion

Suite à la lecture de cet article, vous êtes capable de forcer la synchronisation d'un appareil Windows inscrit dans Intune pour qu'il récupère les dernières stratégies qui lui sont affectées !

Il y a deux autres méthodes que j'aurais pu indiquer et qui fonctionnent assez bien. La première, c'est le fait de redémarrer l'appareil Windows, mais ceci est un peu contraignant si un utilisateur travaille sur son ordinateur. La seconde, c'est le fait de redémarrer le service "IntuneManagementExtension" pour une actualisation liée aux applications et aux scripts.

The post Intune – Comment forcer la synchronisation d’un ordinateur Windows ? first appeared on IT-Connect.

I. Présentation

Dans cet article, nous allons introduire le Portail d'entreprise ou Company portal pour que vous puissiez avoir une idée plus précise de l'intérêt de cette fonctionnalité d'Intune, qui peut vous rendre bien des services.

Nous allons évoquer les fonctionnalités clés, le déploiement de l'application sur Windows, et nous découvrirons l'interface de cette même application.

• Comment débuter avec Microsoft Intune ?

II. Les fonctionnalités du Company Portal d'Intune

A. À quoi sert le Portail d'entreprise ?

Le Portail d'entreprise met à disposition des utilisateurs des informations utiles sur leur organisation et il leur donne accès à des actions pratiques en mode "self-service", comme la possibilité d'installer des applications, de déclencher la synchronisation d'un appareil ou encore de vérifier l'état de la conformité d'un appareil. Par ailleurs, l'enrollment d'un appareil peut être effectué via cette application, plutôt que par les paramètres du système.

Vous pourrez en savoir plus sur cette page :

• Microsoft Learn - Le portail web du Portail d'entreprise

Le Portail d'entreprise joue un rôle important dans le déploiement des applications via Intune. En effet, vous avez la possibilité de définir une des "applications en vedette", c'est-à-dire des applications disponibles et mises en avant dans le Portail d'entreprise. Ceci peut être utile pour mettre à disposition une application pour vos utilisateurs, sans que l'installation soit automatique : c'est l'utilisateur qui a la main.

Ceci s'applique aux applications dont l'option "Afficher ceci en tant qu'application à la une dans Portail d'entreprise" est définie sur "Oui". Vous pouvez tout à fait changer cette option sur vos applications existantes.

B. Les applications Portail d'entreprise

Le Portail d'entreprise Intune est accessible de plusieurs façons puisqu'il y a un portail Web et des applications, notamment une application Windows et une application mobile sur Android et iOS. N'importe quel utilisateur, à partir de son appareil inscrit et de son compte, peut accéder au Portail d'entreprise avec un navigateur via cette adresse :

• portal.manage.microsoft.com

Par ailleurs, l'application est accessible dans le Microsoft Store :

Désormais, nous allons voir comment déployer cette application via Intune.

III. Déployer l'application Company Portal sur Windows

Nous allons apprendre à déployer l'application Company Portal sur Windows à partir d'une stratégie d'applications Intune. Cette application étant publiée dans le Microsoft Store accessible depuis Windows, nous pouvons effectuer cette opération facilement.

Si vous n'êtes pas familier avec le déploiement d'applications du Microsoft Store via Intune, je vous recommande la lecture de cet article :

• Intune : déployer une application du Microsoft Store

Intune – Comment déployer une application du Microsoft Store ?

À partir du Centre d'administration Intune, vous devez créer une nouvelle application :

• Cliquez sur "Applications", puis "Windows" et cliquez sur le bouton "Ajouter".
• Dans le panneau latéral, choisissez le type d'application "Application Microsoft Store (nouvelle)" et suivez l'assistant.

À l'étape "Informations sur l'application", cliquez sur "Rechercher l’application Microsoft Store (nouvelle)" afin de rechercher "company portal". Sélectionnez l'application "Company portal" de type "UWP" visible dans la liste et cliquez sur "Sélectionner".

Ensuite, vous devez configurer cette application. Vous pouvez commencer par indiquer son nom en français, à savoir "Portail d'entreprise". Vous avez le choix entre une installation par utilisateur ou par machine (système). Indiquez également un logo, que vous pouvez récupérer sur Google via une recherche d'image.

Passez à l'étape "Affectations" et sélectionnez les groupes qui doivent bénéficier de cette application.

Poursuivez jusqu'à la fin pour finaliser la création de l'application.

IV. Aperçu du Company Portal sur Windows

Une fois que l'appareil aura effectué une synchronisation, l'application "Company Portal" sera visible sur Windows et vous pourrez commencer à l'explorer. L'image ci-dessous montre la section "Appareils" où l'utilisateur peut avoir un aperçu de l'ensemble des appareils dont il est déclaré comme propriétaire.

Par ailleurs, à partir du moment où une application ou plusieurs applications sont mises en avant dans le Portail d'entreprise, elles sont visibles directement dans l'interface de celui-ci. Si l'application n'est pas installée et qu'elle est disponible pour un utilisateur, il peut décider de l'installer.

Pour forcer la synchronisation d'un appareil à partir du Portail d'entreprise, Au sein de cette application, qui doit être au préalable installée sur l'appareil, cliquez sur le bouton des paramètres en bas à gauche (1) afin d'accéder au bouton nommé "Synchroniser" (2). Ceci est facilement accessible par un utilisateur lambda.

Sachez que vous avez aussi la possibilité de modifier l'apparence du Portail d'entreprise, en jouant sur les paramètres de branding de votre organisation, directement à partir du Centre d'administration Intune. En cliquant sur ce lien, vous serez redirigé directement vers la page de configuration. Au-delà de l'apparence, vous pourrez aussi activer/désactiver certaines fonctionnalités, notamment celle-ci qui peut être gênante :

Pour en savoir plus, consultez cette documentation de Microsoft :

• Microsoft Learn - Apparence du Portail d'entreprise

V. Conclusion

Suite à la lecture de cet article, vous en savez plus sur le Portail d'entreprise de Microsoft Intune et vous êtes désormais en mesure de procéder à son déploiement et à sa personnalisation. Son atout principal, c'est le fait de permettre la publication d'applications auprès des utilisateurs. L'étape de branding est simple à effectuer, mais elle est importante, car elle permet d'ajouter le logo de votre entreprise, les coordonnées, etc.

The post Intune – Découverte du Portail d’entreprise sur Windows first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons aborder la notion de "Stratégies de conformité" dans Microsoft Intune. Qu'est-ce qu'une stratégie de conformité ? Quel est l'intérêt d'une stratégie de conformité ? Comment configurer une stratégie de conformité Windows dans Intune ? Cet article répondra à ces différentes questions.

• Cliquez ici pour regarder la vidéo sur YouTube

Pour ceux qui débutent avec Intune, nous vous encourageons à lire cet article d'introduction :

• Comment débuter avec Microsoft Intune ?

Pour uniformiser la sécurité de vos appareils, vous devriez aussi vous intéresser à ces articles :

• Stratégie Intune - Chiffrer Windows avec BitLocker
• Stratégie Intune - Configurer Windows LAPS
• Stratégie Intune - Configurer le pare-feu Windows

II. Qu'est-ce qu'une stratégie de conformité Intune ?

Une stratégie de conformité Intune va permettre à une entreprise de s'assurer que tous les appareils utilisés par les employés respectent les règles de base en matière de sécurité.

Par exemple, nous allons pouvoir nous assurer que le pare-feu est actif sur Windows et qu'il y a bien une protection antivirus opérationnelle. Si ce n'est pas le cas, nous allons recevoir une alerte et il sera possible de limiter les tentatives d’accès effectués à partir de cet appareil non conforme.

La stratégie de conformité est d'autant plus intéressante lorsqu'elle est couplée avec les stratégies d'accès conditionnel puisque nous pourrons accorder une autorisation d'accès uniquement si l'appareil respecte sa stratégie de conformité. Ce qui permet de bloquer les connexions à partir d'un appareil non conforme.

Dans la suite de cet article, nous allons apprendre à configurer les paramètres généraux de cette fonctionnalité, avant de configurer les paramètres de notifications et de créer une stratégie de conformité Intune.

Cette stratégie de conformité Windows aura pour objectif de vérifier les points suivants :

• Pare-feu Windows Defender actif
• Module TPM actif
• Antivirus actif
• Logiciel anti-espion et logiciel anti-malware actifs
• Protection en temps réel active

Nous pourrions ajouter d'autres conditions comme la vérification du Secure Boot, l'état de BitLocker, etc.

III. Stratégies de conformité : paramètres généraux

Nous allons commencer par configurer les paramètres de stratégie de conformité au niveau du tenant Microsoft 365. Autrement dit, il s'agit de paramètres communs à l'ensemble des appareils, des utilisateurs et des stratégies.

Connectez-vous au centre d'administration Microsoft Intune. Voici un lien direct si besoin :

• intune.microsoft.com

Ensuite, cliquez sur "Appareils" puis sur "Conformité" afin de pouvoir cliquer sur le bouton "Paramètres de conformité". Vous pouvez aussi passer par "Sécurité du point de terminaison", "Conformité de l'appareil" puis "Paramètres de conformité".

Ici, nous allons retrouver deux paramètres importants :

Nous allons configurer ces deux options :

• Marquer les appareils sans stratégie de conformité comme étant, et nous allons passer l'option sur "Non conforme". Ainsi, nous partons du principe qu'un appareil n'est pas conforme : nous ne faisons pas confiance à l'appareil avant qu'il soit analysé.
• Période de validité de l'état de conformité (jours), et nous allons indiquer "30" ce qui signifie qu'un appareil identifié comme conforme bénéficiera de ce statut pendant 30 jours.

Il est à noter que la période de compliance peut être comprise entre 1 et 120 jours.

Une fois les paramètres définis, cliquez sur "Enregistrer".

IV. Stratégies de conformité : notifications

La seconde étape consiste à configurer le système de notifications, ce qui permettra notamment de recevoir un e-mail lorsqu'un appareil non conforme sera détecté. Toujours sous "Conformité", basculez sur l'onglet "Notifications" puis cliquez sur "Créer une notification".

Donnez un nom à ce modèle de notification, par exemple "Notification de base - Compliance". Ensuite, nous avons plusieurs options de base pour personnaliser l'e-mail, notamment dans le but d'intégrer des éléments permettant d'identifier votre entreprise (un logo, par exemple). Cette interface ne permettra pas de choisir un logo ou de configurer les valeurs des autres options.

Pour visualiser les valeurs attribuées à ces options, vous devez accéder aux paramètres de personnalisation du tenant. Suivez la procédure suivante :

1 - Cliquez sur "Administration de locataire".

2 - Cliquez sur "Personnalisation".

3 - Cliquez sur "Modifier".

Ensuite, il ne vous reste plus qu'à configurer les différentes options telles que le nom de l'organisation, le logo, etc...

Quand ce sera fait, retournez dans l'assistant de création d'une notification afin de passer à la seconde étape. Vous devez choisir la langue, et définir l'objet de l'e-mail ("Appareil non conforme", par exemple) ainsi que le corps du message (certaines balises HTML sont prises en charge). Puisqu'il s'agit du premier modèle de notifications, nous allons le définir par défaut.

Pour personnaliser le message avec des valeurs dynamiques (le nom de l'utilisateur ou de l'appareil, par exemple), vous pouvez utiliser "des variables", comme décrit dans cette page de la documentation Microsoft.

Ce qui donne :

Passez à l'étape "Vérifier + créer" afin de passer en revue votre paramétrage et cliquez sur "Créer".

Voilà, votre modèle de notification est créé !

V. Créer une stratégie de conformité Intune

Nous allons créer une stratégie de conformité pour définir les critères que doit respecter un appareil afin d'être considéré comme conforme. Cette fois-ci, basculez sur l'onglet "Stratégies" et cliquez sur "Créer une stratégie". À cet emplacement, vous avez également accès à l'onglet "Scripts" qui permet de créer des scripts PowerShell pour de la "mise en conformité sur-mesure" puisque c'est votre script qui va faire l'évaluation (nous pouvons imaginer un script PowerShell pour vérifier l'espace disque restant sur le volume système).

Un panneau latéral apparait sur la droite. Choisissez la plateforme "Windows 10 et ultérieur" et poursuivez. Ceci vous donne l'occasion de constater que cette fonctionnalité n'est pas limitée à Windows.

Bienvenue dans l'assistant de création d'une stratégie de conformité Intune !

Commencez par donner un nom à cette stratégie et indiquez une description. La description s'avère utile pour donner quelques indications sur le contenu de cette stratégie.

La section "Conformité personnalisée" sert à créer vos propres règles contenues dans un fichier JSON généré à partir d'un script PowerShell. Cette méthode est décrite dans la documentation Microsoft, sur cette page.

Descendez dans la page... Nous allons pouvoir exiger la vérification de certains éléments en jouant sur les options présentes dans chaque section : Intégrité de l'appareil, Propriétés de l'appareil, etc...

Commencez par la section "Intégrité de l'appareil" qui présente l'avantage de permettre de vérifier la configuration de BitLocker, du démarrage sécurisé et l'intégrité du code sur la machine Windows. Avant d'activer la vérification BitLocker, il convient de créer une stratégie de configuration de BitLocker.

La section "Propriétés de l'appareil" sert à vérifier la version du système d'exploitation Windows. Ainsi, vous pourriez considérer qu'un appareil qui exécute une version de Windows 10 qui n'est plus sous support, n'est pas conforme. Pour obtenir les numéros de version, vous pouvez vous référer à la documentation Microsoft, notamment ce lien :

• Numéros de version Windows 11

Par ailleurs, vous pouvez aussi utiliser la commande "winver" sur un appareil puisqu'elle retourne un numéro de build. Toutefois, méfiez-vous avec les numéros de version, vous devez utiliser ce format : 10.0.X.X. Ainsi, pour la build "22631.2715", nous devons préciser la valeur suivante : 10.0.22631.2715.

Ce numéro de version correspond à Windows 11 23H2 avec les mises à jour de novembre 2023, ce qui signifie que l'on peut cibler une version majeure et un niveau de mise à jour des machines. Pour Windows 11 23H2 avec les mises à jour d'avril 2024, la valeur à utiliser est légèrement différente dû à la différence de niveau de mise à jour : 10.0.22631.3447.

Voici un exemple :

La section "Conformité de Configuration Manager" s'adresse aux personnes en co-gestion avec (System Center) Configuration Manager.

Le volet "Sécurité système" s'adresse aux administrateurs qui souhaitent effectuer des vérifications sur la configuration et l'utilisation des mots de passe sur un appareil. À la fin de la section, il y a tout de même des paramètres que nous allons activer pour vérifier l'état du pare-feu, du module TPM, de l'antivirus, et du logiciel anti-espion.

Puis, un peu plus bas, nous allons pouvoir activer certains contrôles liés à Defender :

Vous avez aussi un paramètre spécifique à "Microsoft Defender for Endpoint" pour vérifier le niveau de risque d'un appareil. C'est très intéressant pour les entreprises équipées avec cette solution sur leur appareil Windows.

Passez à l'étape "Actions en cas de non conformité". Ici, nous allons créer plusieurs règles :

• Marquer l'appareil comme non conforme immédiatement.
• Envoyer un e-mail à l'utilisateur final (grâce à notre modèle de notifications précédemment créé !) - L'administrateur aura aussi l'e-mail.
• Ajouter un appareil à la liste des mises hors service 20 jours après la non-conformité. Ceci est facultatif, mais permet d'ajouter l'appareil à la liste "Mettre hors service les appareils non conformes". Lorsqu'un administrateur retire un appareil de cette liste, ceci enclenche la suppression de toutes les données de l'entreprise de l'appareil et le retire de la gestion Intune. A utiliser avec précaution.

Remarque : pour certains appareils, notamment sous Android, macOS, iOS et iPadOS, il est possible de verrouiller l'appareil à distance s'il n'est pas conforme. Ceci correspond à la fonction Remote Lock.

Pour finir, l'étape "Affectations" que l'on a l'habitude de croiser dans les assistants Intune se présente à l'écran. L'objectif étant d'affecter cette stratégie de conformité à un groupe d'appareils, comme ici le groupe "PC_Corporate".

Attention : n'oubliez pas que nous avons activé une option au niveau du tenant pour déclarer non conformes tous les appareils sans stratégie de conformité. S'il s'agit de votre stratégie de conformité de base, vous pouvez l'appliquer directement à tous les appareils.

Révisez votre configuration et cliquez sur le bouton "Créer" pour finaliser la création de la stratégie de conformité.

Voilà, la stratégie de conformité va être déployée sur les appareils qui rentrent dans le périmètre de l'affectation.

VI. Suivre l'état des appareils

Suite au déploiement de cette stratégie, les appareils sont analysés via la stratégie de conformité et un état s'affiche directement dans la colonne "Compatibilité" de la liste des appareils inscrits dans Intune. Ici, nous pouvons voir que l'appareil "PC-ITC-01" n'est pas conforme.

Si nous cliquons sur cet appareil, nous pouvons obtenir des précisions. Nous voyons bien qu'il ne respecte pas notre politique.

En fait, le détail de l'analyse nous montre que le pare-feu de la machine est dans un état "non conforme". En effet, sur cet appareil, le pare-feu Windows est désactivé.

Dans le même temps, une notification par e-mail a été envoyée ! Cette notification reprend bien les éléments configurés dans notre modèle de notifications et dans les paramètres de personnalisation (textes, logo, etc.).

Désormais, il va falloir faire le nécessaire pour qu'il soit de nouveau conforme...!

VII. Conclusion

Suite à la lecture de ce tutoriel, vous êtes en mesure de créer votre première stratégie de conformité Intune pour vos appareils Windows. Avant de modifier les paramètres au niveau du tenant, effectuez une première stratégie de conformité afin de la tester sur quelques appareils de votre parc informatique.

• Microsoft Learn - Intune - Stratégies de conformité

The post Intune – Comment (et pourquoi) configurer une stratégie de conformité Windows ? first appeared on IT-Connect.

Le malware Raspberry Robin est en circulation depuis plusieurs années et il continue de se propager pour infecter les appareils Windows. Désormais, il est capable de contourner Microsoft Defender et d'être très furtif sur la machine infectée. Faisons le point !

À la base, le logiciel malveillant Raspberry Robin se propage principalement par l'intermédiaire de clés USB, comme nous l'avions évoqué dans un précédent article publié en juillet 2022. Mais, depuis mars 2024, les pirates semblent bien décidés à le distribuer plus largement, alors qu'initialement, il ciblait plutôt les industries et les grandes entreprises.

Campagnes de phishing et fausses publicités

Un nouveau rapport publié par l'équipe de chercheurs en sécurité HP Wolf Security met en avant les nouvelles capacités et techniques employées par Raspberry Robin. Désormais, la clé USB est remplacée par de fausses publicités et des campagnes de phishing par e-mails. L'objectif étant de rediriger les utilisateurs vers des sites malveillants contrôlés par les pirates sur lesquels sont hébergés des fichiers WSF (Windows Script Files) obscurci.

"Le format de fichier WSF prend en charge les langages de script, tels que JScript et VBScript, qui sont interprétés par le composant Windows Script Host intégré au système d'exploitation Windows.", peut-on lire. De plus, les chercheurs en sécurité précisent que le code des scripts WSF distribués par les pirates est long et difficile à analyser. En effet, il y a beaucoup de lignes de code inutiles, uniquement là pour brouiller les pistes.

Une analyse minutieuse de la machine infectée

La dernière version de Raspberry Robin se démarque également par sa capacité à contourner les solutions de sécurité et à passer entre les mailles du filet. Avant de passer à l'action, le malware effectue une analyse complète de la machine pour déterminer l'environnement sur lequel il se trouve, avant de passer à la phase d'infection.

Parmi les éléments vérifiés, il y a la version de Windows, le type d'appareils (machine virtuelle, serveur, poste de travail), le type de processeur, la détection de la solution de virtualisation via l'adresse MAC, et enfin, il vérifie la présence éventuelle de certains antivirus (Kaspersky, ESET, Avast, Avira, Check Point et Bitdefender). Si l'un de ces antivirus est identifié, le script s'arrête. L'objectif principal de cette série de vérifications est de s'assurer que le malware est exécuté sur l'appareil d'un utilisateur final.

Par contre, les chercheurs en sécurité précisent que Raspberry Robin est capable de contourner Microsoft Defender : "Il est donc plus probable que le script s'exécute sur un terminal protégé par Microsoft Defender. Pour échapper à la détection, le script ajoute une exception à Microsoft Defender qui exclut l'ensemble du disque principal de l'analyse antivirus."

La phase finale : le déploiement de Raspberry Robin

Si tous les voyants sont au vert et qu'il s'agit de l'appareil d'un utilisateur final, le script va télécharger la DLL Raspberry Robin depuis un serveur situé sur Internet. Pour cela, il va s'appuyer sur la commande "curl" prise en charge nativement sur Windows, et il va stocker la DLL malveillante dans le dossier "AppData" local. Ainsi, Raspberry Robin est déployé sur la machine et il peut agir sans déclencher d'alerte sur Microsoft Defender.

Raspberry Robin est capable de télécharger et d'exécuter des charges utiles supplémentaires. Les cybercriminels ont l'habitude de l'utiliser pour déployer un ransomware ou d'autres malwares comme IcedID, BumbleBee et Truebot.

The post Toujours plus furtif, le malware Raspberry Robin contourne Microsoft Defender pour infecter Windows first appeared on IT-Connect.

I. Présentation

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.

II. Sysmon : qu'est ce que c'est ?

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 :

• Création de processus
• Modification de l'heure de création d'un fichier
• Connexion réseau
• Modification de l'état du service Sysmon
• Fin d'un processus
• Chargement de pilote
• Chargement d'image (injection de DLL)
• Evènement CreateRemoteThread (création d'un thread par un processus)
• Evènement RawAccessRead
• Requête DNS
• ProcessTampering
• etc.

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 :

• les condensats (ou hash) des images des processus lancés
• les GUID des processus (facilite la corrélation des évènements)
• des informations précises sur les connexions réseau (processus source, adresse IP, numéro de port, etc.)
• Integrity Level du processus
• des informations relatives aux métadonnées des processus (signature, auteur, description)
• etc.

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

III. Logs Windows : quelques trous dans la raquette

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" :

.\mimikatz64.exe

Par 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.

IV. Déploiement de Sysmon

A. Installer Sysmon de façon classique

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 -accepteula

Voici 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 -s

Voici 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.

B. Installation discrète de Sysmon

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 :

• Est-ce qu'un EPP (Endpoint Protection) est en place ? Ils peuvent pour cela regarder la liste des processus en cours d'exécution à la recherche de nom d'agents EPP connus (Trellix, Symantec, Sophos, etc.)
• Est-ce que Microsoft Defender est actif ? Si oui, quelle est sa configuration ? Contient-elle des exclusions intéressantes ? Sa base antivirale est-elle à jour ?
• Les journaux d'évènements sont-ils envoyés sur un autre système ? Ce qui serait le signal qu'un SIEM, voire un SOC peut enregistrer et voir son activité malveillante. L'attaquant peut pour cela regarder les processus et services actifs à la recherche d'agent de transmission de log connus, ou encore les connexions établies visant des ports connus, etc.
• Est-ce que Sysmon est installé ? Quelle est sa configuration ? Contient-elle des exclusions intéressantes ?

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).

V. Configuration de Sysmon

A. Récupération et étude d'une configuration XML Sysmon

À 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 :

• Elle est éprouvée par la communauté et sa pertinence est reconnue. Vous pouvez notamment jeter un œil à son historique de modification Github.
• Elle est documentée, même si la lecture de son contenu peut être difficile à cause du format XML, elle contient différents commentaires permettant de comprendre ses principales sections, exclusions
• Elle est bien structurée, ce qui permet une compréhension et une modification aisée. Elle peut ainsi servir de base à une configuration propre à vos besoins et environnements
• Elle contient des cas d'exclusions permettant d'éliminer les faux positifs "classiques" sur les OS Windows, facilitant ainsi l'exploitation des journaux créés par Sysmon.
• Elle apporte des éléments de contexte supplémentaires sur chaque Event ID tels que les TTP du MITRE relatif à une action malveillante journalisée.

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.

B. Application d'une nouvelle configuration Sysmon

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.xml

Voici 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 --".

C. Suppression du fichier de configuration

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.

VI. Exemple de journaux Sysmon

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).

• Pour en savoir plus sur ce qu'est un hash MD5, je vous oriente vers notre article : Gestion d’empreinte numérique sur Linux

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

VII. Conclusion

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.

I. Présentation

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 :

• Cliquez ici pour regarder la vidéo sur YouTube

• Tutoriel - Ma GPO ne fonctionne pas : 14 pistes et conseils pour s'en sortir !

II. Les vérifications effectuées par GPOZaurr

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 :

• Détection des GPO "cassées", c'est-à-dire des GPO qui sont présentes dans l'Active Directory mais qui ne sont plus dans SYSVOL, ou inversement. Ceci crée des GPO orphelines qui ne fonctionneront pas.
• Détection des liens de GPO "cassés, c'est-à-dire que la GPO a été supprimée, mais qu'une ou plusieurs liaisons n'ont pas été correctement supprimés.
• Détection des problèmes et des incohérences sur les permissions de GPO.
• Détection des GPO dupliquées.
• Détection des GPO vides.
• Détection des GPO avec une section désactivée alors qu'il y a des paramètres configurés
• Détection des mots de passe dans les GPO.
• Inventorier tous les fichiers présents dans le SYSVOL, ce qui permettra de faciliter la détection de fichiers inutiles et/ou malveillants.
• Inventorier toutes les unités d'organisation dont l'héritage est bloqué et vérifier le nombre d'utilisateurs ou d'ordinateurs concernés.
• Catégorisation des GPO, en fonction des paramètres configurés.
• Vérification des autorisations sur le partage NetLogon.
• Détection de fichiers ADM (legacy) dans le SYSVOL.

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 :

• GitHub - GPOZaurr

III. Installer GPOZaurr

Tout d'abord, ouvrez une console PowerShell sur votre machine et installez le module GPOZaurr :

Install-Module -Name GPOZaurr

Vous 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 -Force

Par 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.

IV. Générer un rapport avec GPOZaurr

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-GPOZaurr

Sans 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,GPOPermissions

Voici 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"

V. Découverte du rapport de GPOZaurr

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...

VI. Conclusion

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) :

• Evotec.xyz - GPOZaurr

The post GPOZaurr, l’outil ultime pour analyser vos stratégies de groupe first appeared on IT-Connect.

I. Présentation

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.

II. Utiliser le cmdlet New-EventLog

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 :

• Microsoft Learn - New-EventLog

III. Utiliser le cmdlet Write-EventLog

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 @Event

Ce 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 :

• Microsoft Learn - Write-EventLog
• Microsoft Learn - Get-EventLog
• Microsoft Learn - Get-WinEvent

IV. Utiliser la classe EventLog avec PowerShell

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 :

• Sécurité de l’Active Directory : les mots de passe dans la description des objets utilisateur

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.

V. Conclusion

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.

BatBadBut, c'est le nom d'une nouvelle faille de sécurité critique découverte dans la bibliothèque Rust ! Elle pourrait être exploitée par un attaquant pour exécuter des commandes sur les machines sous Windows ! Faisons le point.

Cette vulnérabilité associée à la référence CVE-2024-24576 est considérée comme critique : son score CVSS est de 10 sur 10, ce qui représente le niveau de sévérité maximal.

Pour autant, cette faille de sécurité peut être exploitée uniquement dans des scénarios spécifiques : "La bibliothèque standard Rust n'échappait pas correctement les arguments lors de l'invocation de fichiers batch (avec les extensions bat et cmd) sous Windows à l'aide de l'API Command", peut-on lire dans le bulletin de sécurité publié sur le site de Rust, le 9 avril 2024. Ceci explique que la vulnérabilité soit exploitable uniquement sur Windows.

Pour exploiter cette vulnérabilité, l'attaquant doit contrôler les arguments transmis au processus créé au moment de l'invocation du fichier batch pour exécuter les commandes shell arbitraires, en contournant le mécanisme d'échappement (escaping).

Le chercheur en sécurité RyotaK de chez Flatt Security a fait la découverte de cette vulnérabilité présente dans toutes les versions de Rust avant la version 1.77.2. Si vous utilisez Rust, vous devez donc effectuer la mise à jour vers 1.77.2 car cette version corrige cette faille de sécurité (voir cette page).

Rust ne serait pas le seul langage affecté par BatBadBut

RyotaK a surnommé cette vulnérabilité BatBadBut, et d'après lui, Rust n'est pas le seul langage de programmation affecté : tout dépend de comment est géré la fonction CreateProcess de Windows.

"CreateProcess() crée implicitement cmd.exe lors de l'exécution de fichiers batch (.bat, .cmd, etc.), même si l'application ne les a pas spécifiés dans la ligne de commande. Le problème est que cmd.exe a des règles de parsing compliquées pour les arguments de la commande, et que les exécutions des langages de programmation ne parviennent pas à échapper correctement les arguments de la commande.", précise-t-il dans un rapport publié sur le site de Flatt Security.

Pour le moment, tous les langages de programmation affectés n'ont pas résolu le problème, et il y a un travail à réaliser également du côté développement pour mieux gérer l'échappement.

• Voici un tableau récapitulatif publié par RyotaK :

Si vous êtes développeur, le rapport de RyotaK pourra vous apporter des détails techniques intéressants, notamment pour améliorer votre code afin de gérer ce problème de sécurité.

Source

The post BatBadBut : une faille critique de Rust expose les machines Windows à des attaques ! first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à activer et configurer le chiffrement BitLocker sur des machines Windows 10 et Windows 11 à l'aide d'une stratégie de chiffrement de disque Intune. Suite à la mise en place de ce tutoriel, vous serez en mesure d'automatiser le chiffrement des disques de vos ordinateurs Windows, grâce au composant BitLocker pris en charge nativement par les systèmes d'exploitation de Microsoft.

• Cliquez ici pour regarder la vidéo sur YouTube

Cette procédure est identique pour les appareils Windows Joined et Hybrid Joined à Microsoft Entra ID. Que la machine soit jointe à Entra ID ou à l'Active Directory, elle sera capable de stocker les informations associées au chiffrement BitLocker, notamment la clé de récupération, directement dans le service de gestion des identités auquel elle appartient.

Notre objectif va être de mettre en place BitLocker en automatisant sa configuration de façon silencieuse, ce qui signifie qu'aucune interaction n'est attendue de la part de l'utilisateur. Ceci implique de faire l'impasse sur certaines fonctionnalités (la saisie d'un code PIN pour déverrouiller le lecteur "BitLocké", par exemple). Cette configuration convient aux machines équipées d'une puce TPM et elle permet de chiffrer les appareils Windows sans pour autant alourdir la charge de travail de l'équipe IT. Une alternative serait de "prompter" l'utilisateur pour qu'il configure BitLocker mais ceci implique une interaction de sa part.

En complément de ce tutoriel, vous pouvez vous référer à ces liens :

• Tutoriel - Active Directory - Configurer BitLocker par GPO
• Tutoriel - Windows 11 - Utiliser BitLocker To Go
• Microsoft Learn - BitLocker

II. Prérequis et méthodes de déploiement

A. Prérequis de BitLocker

Afin de pouvoir activer et configurer BitLocker de façon automatique et silencieuse, nous devons respecter un ensemble de prérequis.

• Si les utilisateurs finaux se connectent aux appareils en tant qu’administrateurs, l’appareil doit utiliser Windows 10 version 1803 ou ultérieure, ou Windows 11.
• Si les utilisateurs finaux se connectent aux appareils en tant qu’utilisateurs standard, l’appareil doit utiliser Windows 10 version 1809 ou ultérieure, ou Windows 11.
• L’appareil doit être intégré à Entra ID, en tant qu'appareil Microsoft Entra Joined ou Microsoft Entra Hybrid Join.
• L’appareil doit disposer d'un module TPM 1.2, ou supérieur.
• Le mode BIOS doit être défini sur UEFI natif uniquement.

Nous pouvons ajouter que le disque ne doit pas être chiffré avec une solution tierce, sinon il y aura un conflit.

• Windows : mon PC est-il équipé d'une puce TPM 2.0 ?

B. Méthodes disponibles avec Intune

Pour configurer BitLocker sur des appareils Windows à l'aide d'Intune, il y a deux possibilités :

• Créer une stratégie sous la forme d'un profil de configuration Windows et sélectionner le modèle "Endpoint Protection". Il regroupe des paramètres pour le Pare-feu Windows, Microsoft Defender SmartScreen, etc... Ainsi qu'une section "Chiffrement Windows" pour BitLocker.
• Créer une stratégie de type "Chiffrement de disque" dans la section "Sécurité du point de terminaison" d'Intune.

Nous allons utiliser cette seconde possibilité, car elle est recommandée par Microsoft et de par son positionnement dans Intune, elle me semble plus adaptée.

III. Intune : créer une stratégie BitLocker

A. Créer une stratégie de chiffrement de disque

Tout d'abord, connectez-vous sur le portail d'administration de Microsoft Intune :

• intune.microsoft.com

Quand vous êtes sur le portail, effectuez les actions suivantes :

1 - Cliquez sur "Sécurité du point de terminaison" sur la gauche

2 - Cliquez sur "Chiffrement de disque"

3 - Cliquez sur "Créer une stratégie".

Un panneau latéral va s'ouvrir sur la droite. Sélectionnez "Windows 10 et ultérieur" comme "Plateforme", puis prenez le profil "BitLocker" puisque c'est, de toute façon, le seul choix disponible actuellement.

Commencez par nommer ce profil, par exemple : "Windows - Chiffrer disques avec BitLocker".

Désormais, à l'étape "Paramètres de configuration", vous avez devant les yeux deux sections : "Modèles d'administration" et "BitLocker".

Nous allons configurer les différents paramètres présents à ces deux emplacements.

B. Activer et exiger BitLocker

Nous allons commencer par la section "BitLocker" car c'est la plus rapide à configurer. Elle est très importante, car elle va nous permettre d'exiger le chiffrement des disques sur les appareils.

• Exiger le chiffrement des appareils : sélectionnez "Activé" pour que BitLocker chiffre les données de l'appareil.
• Autoriser l'avertissement pour un autre chiffrement de disque : sélectionnez "Désactivé" pour masquer les éventuelles notifications liées au chiffrement du disque, ceci est nécessaire pour accéder à la prochaine option et activer BitLocker de façon silencieuse.
• Autoriser le chiffrement utilisateur standard : sélectionnez "Activé" pour que le chiffrement BitLocker soit activé et configuré automatiquement, même si l'utilisateur connecté à la machine n'est pas Administrateur local.
• Configurer la rotation du mot de passe de récupération : conserver "Non configuré", ce qui revient à activer cette fonctionnalité et celle-ci implique que l'appareil soit joint à Entra ID (direct ou hybride).

Passez à la suite, où nous allons passer en revue les paramètres présents dans "Modèles d'administration".

C. BitLocker sur les lecteurs de données amovibles

La section "Modèles d'administration" est découpée en plusieurs groupes de paramètres afin de pouvoir ajuster le comportement de BitLocker pour les différents types de lecteurs : amovible, système, etc. Nous allons les parcourir dans l'ordre. La première partie concerne les lecteurs de données amovibles.

1 - Control use of BitLocker on removable drives : sélectionnez "Enabled" pour autoriser le chiffrement des lecteurs amovibles (non automatique)

2 - Allow users to apply BitLocker protection on removable data drives (Device) : sélectionnez "True" pour qu'un utilisateur puisse activer BitLocker sur un périphérique de stockage amovible.

3 - Enforce drive encryption type on removable data drives : forcer la méthode de chiffrement lorsqu'un lecteur amovible est chiffré avec BitLocker.

4 - Select the encryption type : sélectionnez le type de chiffrement souhaité, si vous choisissez "Used Space Only encryption", BitLocker va chiffrer uniquement l'espace de stockage consommé actuellement pour les données. Ce mode sera plus rapide s'il y a déjà des données sur le périphérique de stockage.

5 - Allow user to suspend and decrypt BitLocker protection on removable data drives : sélectionnez "False" pour que l'utilisateur ne soit pas en mesure de désactiver BitLocker, ou de le suspendre, sur un lecteur de données amovible.

6 - Deny write access to removable drives not protected by BitLocker : ce paramètre permet de forcer l'accès en lecture seule uniquement sur tous les périphériques amovibles non protégés par BitLocker. Dans le cas présent, ce paramètre ne sera pas configuré.

Voilà pour la première partie.

D. BitLocker sur les lecteurs de données fixes

Désormais, nous allons configurer la seconde partie dédiée aux lecteurs de données fixes, et il nous restera à configurer BitLocker pour le lecteur système.

- Enforce drive encryption type on fixed data drives : sélectionnez "Enabled" pour activer le chiffrement BitLocker sur les disques fixes (hors système d'exploitation).

- Select the encryption type : sélectionnez le type de chiffrement souhaité, si vous choisissez "Used Space Only encryption", BitLocker va chiffrer uniquement l'espace de stockage consommé actuellement pour les données. Ce mode sera plus rapide s'il y a déjà des données sur le périphérique de stockage.

- Choose how BitLocker-protected fixed drives can be recovered : activez ce paramètre pour accéder à des options complémentaires importantes.

- Do not enable BitLocker until recovery information is stored to AD DS for fixed data drives : ce paramètre doit être activé pour que BitLocker chiffre les disques fixes uniquement à partir du moment où les informations de récupération (clé de récupération) sont stockées dans l'Active Directory ou Entra ID (selon le type de jonction).

- Configure storage of BitLocker recovery information to AD DS : sélectionnez "Backup recovery passwords and key packages" pour sauvegarder la clé de récupération et la clé de déchiffrement (key packages), ce qui pourra être utile pour restaurer les données sur un lecteur BitLocker corrompu (voir cette page).

- Save BitLocker recovery information to AD DS for fixed data drives : activez ce paramètre pour stocker les informations dans Active Directory / Entra ID (c'est important de l'activer vis-à-vis du choix effectué précédemment).

- Omit recovery options from the BitLocker setup wizard : activez ce paramètre pour ne pas afficher les options de récupération lors de la mise en route initiale de BitLocker.

- Configure user storage of BitLocker recovery information : autoriser la génération d'un mot de passe de récupération de 48 chiffres (format de la future clé de récupération).

- Deny write access to fixed drives not protected by BitLocker : ce paramètre permet de forcer l'accès en lecture seule uniquement sur tous les lecteurs fixes non protégés par BitLocker. Dans le cas présent, ce paramètre ne sera pas configuré.

Voilà pour la seconde partie.

E. BitLocker sur les lecteurs de système d'exploitation

Maintenant, nous allons configurer la troisième partie dédiée au lecteur du système d'exploitation Windows. Nous retrouvons des mêmes paramètres communs vis-à-vis de la partie précédente, ainsi que des paramètres supplémentaires.

- Enforce drive encryption type on operating system drives : sélectionnez "Enabled" pour activer le chiffrement BitLocker sur le disque du système d'exploitation, c'est-à-dire le lecteur "C" de l'appareil.

- Select the encryption type : sélectionnez le type de chiffrement souhaité, si vous choisissez "Used Space Only encryption", BitLocker va chiffrer uniquement l'espace de stockage consommé actuellement pour les données. Ce mode sera plus rapide s'il y a déjà des données sur le périphérique de stockage.

- Require additional authentication at startup : activez ce paramètre pour pouvoir imposer l'utilisation du TPM à l'étape suivante (ceci permet la lecture des informations via la puce TPM). Sinon, il faut configurer un code PIN, ce qui implique une interaction de la part de l'utilisateur.

- Configure TPM startup key and PIN : conserver uniquement l'utilisation du TPM via l'option "Do not allow startup key and PIN with TPM".

- Configure TPM startup : sélectionnez "Require TPM" pour que BitLocker s'appuie sur TPM et que ce soit un "prérequis".

- Configure TPM startup PIN : sélectionnez "Do not allow startup PIN with TPM" pour ne pas permettre l'utilisation d'un code PIN à partir du moment où la puce TPM est déjà utilisée.

- Configure TPM startup key : sélectionnez "Do not allow startup key with TPM" pour ne pas permettre l'utilisation d'une clé de démarrage à partir du moment où la puce TPM est déjà utilisée. Il s'agit d'une clé USB avec les informations permettant de déverrouiller le lecteur BitLocker (alternative quand la machine est dépourvue de puce TPM).

Les autres options visibles sur l'image sont ignorées, car elles concernent les paramètres pour le code PIN.

Puis, nous devons nous intéresser à d'autres options toujours dans la même partie :

- Choose how BitLocker-protected operating system drives can be recovered : activez ce paramètre pour accéder à des options complémentaires importantes.

- Omit recovery options from the BitLocker setup wizard : activez ce paramètre pour ne pas afficher les options de récupération lors de la mise en route initiale de BitLocker.

- Configure storage of BitLocker recovery information to AD DS : sélectionnez "Backup recovery passwords and key packages" pour sauvegarder la clé de récupération et la clé de déchiffrement (key packages), ce qui pourra être utile pour restaurer les données sur un lecteur BitLocker corrompu (voir cette page).

- Do not enable BitLocker until recovery information is stored to AD DS for operating system drives : ce paramètre doit être activé pour que BitLocker chiffre le disque système uniquement à partir du moment où les informations de récupération (clé de récupération) sont stockées dans l'Active Directory ou Entra ID (selon le type de jonction).

- Save BitLocker recovery information to AD DS for operating system drives : activez ce paramètre pour stocker les informations dans Active Directory / Entra ID (c'est important de l'activer vis-à-vis du choix effectué précédemment).

- Configure user storage of BitLocker recovery information : autoriser la génération d'un mot de passe de récupération de 48 chiffres.

Voilà, vous pouvez passer à la suite : ce sera la dernière partie !

F. Personnaliser les méthodes de chiffrement

Cette dernière partie sert à préciser les méthodes de chiffrement, c'est-à-dire les algorithmes de chiffrement à utiliser pour les différents types de lecteur. Ceci permettra d'avoir une configuration homogène sur toutes les machines.

À ce sujet, Microsoft recommande d'utiliser l'algorithme XTS-AES pour les lecteurs fixes et les lecteurs de systèmes d'exploitation. Pour les disques amovibles, Microsoft recommande d'utiliser l'algorithme AES-CBC 128 bits ou AES-CBC 256 bits, si le disque est utilisé sur d'autres appareils qui ne fonctionnent pas sous Windows 10 (version 1511).

Voilà, vous venez de passer en revue la configuration de BitLocker pour les différents types de lecteur.

G. Finaliser la création de la stratégie

Vous pouvez poursuivre la configuration de la stratégie, avec notamment l'étape "Affectations" où vous devez affecter la stratégie à un ou plusieurs groupes d'appareils. Dans le cas présent, la stratégie est affectée au groupe "PC_Windows_BitLocker". Je vous encourage à tester cette stratégie sur un petit groupe d'appareils, pour commencer.

Poursuivez afin de terminer la création de la stratégie.

La stratégie de chiffrement de disque est prête, désormais, nous allons tester sur un appareil Windows.

IV. Tester la stratégie BitLocker

Sur un appareil Windows 11 membre du groupe "PC_Windows_BitLocker", la stratégie BitLocker s'applique correctement. Tout d'abord, nous pouvons constater que l'icône BitLocker est présent sur le disque local correspond au système. Si nous allons faire un tour dans les paramètres BitLocker, nous pouvons constater que BitLocker est activé et que les paramètres de sécurité sont définis par l'administrateur système, c'est-à-dire par notre stratégie.

V. Monitoring du déploiement BitLocker

Du côté du Centre d'administration Microsoft Intune, vous pouvez également suivre le déploiement de cette stratégie. Voici l'emplacement sous lequel vous pourrez trouver des informations :

1 - Cliquez sur "Appareils".

2 - Cliquez sur "Moniteur".

3 - Cliquez sur "État du chiffrement de l'appareil" pour accéder à ce rapport prêt à l'emploi.

Ici, vous pouvez obtenir une liste de tous les appareils et, à chaque fois, vous avez des informations intéressantes sur chacun d'entre eux : le système d'exploitation, la version de la puce TPM, ainsi que l'état du chiffrement. De plus, la colonne "Préparation du chiffrement" indique si l'appareil répond aux exigences pour l'activation de BitLocker.

À partir du moment où la stratégie BitLocker est déployée et qu'elle s'est appliquée, la colonne "État du chiffrement" passe de "Non chiffré" à "Chiffré". Voici un exemple :

VI. Récupérer la clé de récupération BitLocker

Pour finir, nous allons voir comment récupérer la clé de récupération BitLocker d'un appareil à partir de Microsoft Entra ID. En effet, ici, il s'agit d'un appareil joint directement à Entra ID. Sachez que cette information est également accessible via le portail Intune et l'utilisateur propriétaire de l'appareil peut également accéder à cette clé de récupération.

Avant toute chose, sachez que sur l'appareil en local, vous pouvez consulter le journal "BitLocker-API" présent dans l'Observateur d'événements pour voir l'activité de BitLocker. Ci-dessous, l'événement avec l'ID 845 nous indique que les informations de récupération pour le lecteur C ont été sauvegardées avec succès dans Azure AD (Entra ID) ! D'ailleurs, ceci était une condition à respecter avant que le disque soit chiffré.

A. Récupérer la clé de récupération BitLocker depuis Entra ID

À partir du Centre d'administration Microsoft Entra, nous pouvons récupérer la clé de récupération BitLocker de cet appareil.

• entra.microsoft.com

Dans la section "Appareils", puis "Tous les appareils", nous pouvons cliquer sur l'appareil "PC-ITC-02" utilisé pour cette démo et accéder à "Clés BitLocker (préversion)" afin d'avoir accès aux informations BitLocker. Ici, il n'y a qu'une seule clé de récupération, car cet appareil n'a qu'un seul disque.

Si nous cliquons sur le bouton "Afficher la clé de récupération", ceci permet d'avoir la clé de récupération en clair. Ainsi, dans un scénario de recovery où l'on aurait besoin de déverrouiller ce lecteur, nous pourrions utiliser cette clé de récupération pour accéder aux données du disque.

B. Récupérer la clé de récupération BitLocker depuis Intune

La clé de récupération est également accessible via le portail Intune, via la section "Clés de récupération" d'un appareil. En fait, nous retrouvons les mêmes informations qu'avec le portail Entra ID.

C. Récupérer la clé de récupération en tant que propriétaire de l'appareil

L'utilisateur qui est propriétaire de l'appareil peut également visualiser la clé de récupération BitLocker. Par exemple, l'utilisateur Guy Mauve est propriétaire de l'appareil "PC-ITC-02". Si, à partir de son compte, j'accède à la section "Périphériques", je peux voir cet appareil et cliquer sur le bouton "Afficher les clés BitLocker" pour accéder à cette information.

• Raccourci vers "Mon compte > Périphériques"

VII. Conclusion

En suivant ce tutoriel, vous devriez être en mesure de déployer BitLocker sur vos appareils pour gérer le chiffrement du disque Windows, mais aussi des autres disques potentiellement connectés à l'appareil. Vous pouvez aussi alléger la configuration en définissant uniquement les options pour le disque système, mais c'est tout de même préférable d'avoir un déploiement homogène et complet de BitLocker. De plus, vous êtes capable de récupérer la clé de récupération d'un appareil, en cas de besoin.

Si vous avez un doute sur un paramètre de configuration, référez-vous à la documentation Microsoft puisque tout est expliqué.

• Microsoft Learn - BitLocker

The post Intune – Comment activer et configurer BitLocker sur Windows ? first appeared on IT-Connect.

I. Présentation

Dans ce tutoriel, nous allons apprendre à gérer les services Windows à l'aide d'une stratégie de groupe (GPO). Que ce soit pour réduire la surface d'attaque des postes de travail et serveurs, ou pour les besoins d'une fonctionnalité de Windows ou d'une application, il peut s'avérer nécessaire de gérer les services Windows avec une GPO.

Dans cet exemple, nous allons voir comment arrêter et désactiver le service "Spouleur d'impression" sur les contrôleurs de domaine Active Directory, à l'aide d'une GPO. Pour des raisons de sécurité, il est recommandé de désactiver et d'arrêter ce service sur les DC, à moins que le rôle "Serveur d'impression" soit également installé. Libre à vous d'adapter cet exemple à vos besoins : la logique reste la même.

Pour gérer les services Windows par GPO, nous avons deux possibilités :

• Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Services système
• Configuration ordinateur > Préférences > Paramètres du Panneau de configuration > Services

Cette seconde méthode offre plus de contrôle grâce à des options supplémentaires et nous allons l'exploiter dans ce tutoriel. De plus, cette seconde méthode nous permet d'indiquer le nom que l'on souhaite pour le service.

II. Désactiver un service par GPO

Ouvrez la console "Gestion des stratégies de groupe" et créez une nouvelle GPO, à moins que vous préfériez utiliser une GPO existante. Pour ma part, ce sera la GPO "Sécurité - DC - Désactiver Spouleur d'impression".

Modifiez la GPO et naviguez jusqu'à l'emplacement suivant :

• Configuration ordinateur > Préférences > Paramètres du Panneau de configuration > Services

Effectuez un clic droit puis sous "Nouveau", choisissez "Service".

Vous avez besoin de connaître le "nom technique" du service afin de pouvoir le gérer par GPO. Vous pouvez obtenir cette information à partir de la console "Services" en regardant dans les propriétés du service que vous souhaitez cibler. Sinon, avec PowerShell vous pouvez rechercher votre service et repérer son nom. Par exemple, le service "Spouleur d'impression" est représenté par le nom "Spooler".

Ensuite, vous devez compléter le formulaire. Nous avons 3 options à modifier.

1 - Démarrage : le type de démarrage du service, ici, nous allons le désactiver

2 - Nom du service : vous pouvez saisir le nom vous-même (attention à l'orthographe) ou rechercher à partir de la liste de la machine locale en cliquant sur "..."

3 - Action du service : pour agir sur l'état du service, ici, nous allons l'arrêter. Ainsi, il sera désactivé et arrêter.

D'autres options sont également à votre disposition, notamment le choix d'un compte spécifique pour exécuter un service, ce qui peut être utile pour durcir la configuration de certains services. Vous avez également accès à l'onglet "Récupération" comme avec la console "Services" habituelle.

Cliquez sur "OK". Voilà, le service Spooler va être configuré par GPO. Il est possible de configurer d'autres services si besoin : répétez l'ajout d'un service via un clic droit.

III. Tester la GPO

Pour finir, testez votre GPO. Connectez-vous sur une machine concernée par la GPO et effectuez un "gpupdate /force". L'exemple ci-dessous montre bien que le service a été arrêté et désactivé, sans avoir besoin de redémarrer la machine.

Nous pouvons faire le même constat avec la console "Services" de Windows :

Si, par mégarde, un administrateur venait à changer la configuration de ce service et à le démarrer, notre GPO l'arrêtera de nouveau (et le désactivera) à la prochaine application.

IV. Conclusion

En quelques minutes et quelques clics, vous pouvez gérer les services Windows d'un ensemble de machines à l'aide d'une GPO, que ce soit pour activer ou désactiver un service, ou simplement ajuster la configuration. Si vous souhaitez forcer l'état d'un service, c'est une bonne façon de procéder. N'oubliez pas que vous pouvez gérer n'importe quel service, à condition de connaitre son nom et qu'il soit présent sur les machines cibles.

The post Configurer les services Windows par GPO : activer, désactiver, démarrer, changer le compte, etc. first appeared on IT-Connect.

Dans le cadre de ses activités malveillantes, le célèbre groupe Lazarus a exploité une faille de sécurité présente dans le pilote AppLocker de Windows. Grâce à cette vulnérabilité, les hackers ont pu obtenir un accès au niveau du noyau et désactiver les outils de sécurité présents sur la machine. Faisons le point.

CVE-2024-21338, c'est la référence CVE associée à la faille de sécurité exploitée par le groupe de hackers nord-coréen Lazarus. Microsoft l'a patché le 13 février dernier, à l'occasion de son Patch Tuesday de février 2024.

Les experts d'Avast ont mis en ligne un nouveau rapport pour évoquer ces cyberattaques. Il permet d'apprendre que le groupe Lazarus a exploité cette vulnérabilité par l'intermédiaire d'une nouvelle version de son rootkit FudModule. Ce dernier est désormais plus furtif et plus difficile à détecter, en plus d'être capable de désactiver les solutions de sécurité présentes sur la machine Windows, notamment Microsoft Defender et CrowdStrike Falcon.

Avast explique également que le groupe Lazarus a exploité cette faille de sécurité en tant que zero-day, ce qui signifie qu'il n'existait pas encore de patch de sécurité. Avast a détecté cette vulnérabilité et l'a signalée à Microsoft. "L'exploitation de la vulnérabilité zero-day constitue une autre étape importante, alors que Lazarus utilisait auparavant des techniques BYOVD (Bring Your Own Vulnerable Driver) beaucoup plus bruyantes pour franchir la frontière entre l'administrateur et le noyau.", peut-on lire.

Quelles sont les versions de Windows affectées ? Quels sont les risques ?

Si l'on se réfère au site de Microsoft, nous pouvons voir que cette vulnérabilité affecte Windows 10 version 1809 et supérieur, Windows 11, ainsi que Windows Server 2019 et Windows Server 2022. "Un attaquant qui parviendrait à exploiter cette vulnérabilité pourrait obtenir les privilèges SYSTEM.", précise Microsoft.

Dans le cas présent, c'est le logiciel malveillant déployé sur la machine qui va directement exploiter cette vulnérabilité présente dans le pilote "appid.sys" utilisé par AppLocker afin d'obtenir une liste blanche d'applications. Ainsi, ils ont accès au noyau de l'OS et peuvent en prendre le contrôle.

Pour vous protéger, vous n'avez qu'une seule option : installer les dernières mises à jour sur vos machines Windows et Windows Server.

Source

The post Windows : le groupe Lazarus a exploité cette faille de sécurité zero-day dans AppLocker ! first appeared on IT-Connect.