Microsoft a publié une nouvelle mise à jour pour Windows Server afin de corriger des problèmes de performance et de connexion via le Bureau à distance.
Si vous avez un serveur sous Windows Server et que vous rencontrez des problèmes sur l'accès Bureau à distance alors ce correctif devrait vous intéresser fortement. Cette mise à jour résout les problèmes suivants : écran noir, connexion / ouverture de session très lente, et des lenteurs de façon générale. Dans certains cas, le Bureau à distance devient même totalement inaccessible, comme si le serveur refusait de répondre et que le service était planté.
C'est suite à l'installation de la mise à jour KB5008218 que le Bureau à distance commencerait à dysfonctionnait selon les symptômes évoqués ci-dessus.
D'après le site de Microsoft, ce correctif s'applique aux versions suivantes : Windows Server 2022, Windows Server 2019, Windows Server 2016 et Windows Server 2012 R2.
Il est à noter que cette mise à jour n'est pas distribuée via Windows Update donc elle ne sera pas installée automatiquement sur les serveurs. Elle est disponible en téléchargement via le site Microsoft Catalog et ensuite vous pouvez l'importer au sein de votre serveur de gestion de mises à jour, dans WSUS par exemple.
En fonction de votre version de Windows Server, la KB à installer ne sera pas la même :
Comme vous pouvez le constater, toutes les mises à jour ne sont pas encore en ligne sur le site de Microsoft, mais cela ne devrait pas tarder. Il manque la KB pour Windows Server 2022 et Windows Server 2016.
Depuis le 5 octobre 2021, Windows 11 est disponible en version stable et les utilisateurs peuvent l'installer sur leur ordinateur en quelques clics, à condition d'avoir du matériel compatible. En comparaison de Windows 10, peut-on dire que Windows 11 est vraiment une petite révolution ? Voici mon avis sur la question.
Cela fait trois mois que Windows 11 est sorti, et cela fait aussi trois mois que je l'utilise sur mon ordinateur au quotidien. Le 5 octobre 2021, mon côté geek a pris le dessus alors j'ai fait la mise à niveau de Windows 10 vers Windows 11, en laissant mes quelques doutes de côté (vous savez l'appréhension de faire partie de ceux qui vont essuyer les plâtres comme on dit).
Finalement, l'opération s'est déroulée correctement : mes applications et mes données sont là. Si cela s'est bien passé, c'est probablement parce que Windows 10 et Windows 11 sont assez proches d'un point de vue des composants système, du fonctionnement, et si l'on fait abstraction des nouveaux éléments graphiques.
À moi Windows 11, le système d'exploitation Windows de nouvelle génération qui marque le début d'une nouvelle ère. Ce n'est pas moi qui le dis, c'est Satya Nadella, le PDG de Microsoft sur Twitter le 4 octobre 2021 : "Windows 11 marque le début d'une nouvelle génération de Windows, permettant à chacun de rêver en grand et de transformer ses idées en réalité. Nous sommes impatients de voir ce que vous allez créer.". Un système que Microsoft continue de peaufiner puisque des infos sur Windows 11 sont publiées régulièrement (notamment sur IT-Connect).
Windows 11, quels sont les changements majeurs ?
Avec Windows 11, plusieurs changements majeurs sont apportés par Microsoft, à commencer par les prérequis du système d'exploitation. La firme de Redmond se montre beaucoup plus exigeante afin d'améliorer la sécurité du système d'exploitation et des ordinateurs, notamment en imposant l'utilisation d'un processeur relativement récent et surtout l'utilisation d'une puce TPM 2.0. Alors même si l'on peut outrepasser cet obstacle afin d'installer Windows 11 sur un ordinateur dit "non compatible", ces nouveaux prérequis ont beaucoup fait parler ces derniers mois, mais bon je ne vais pas vous refaire le film.
Si je devais retenir trois changements majeurs au sein du système Windows 11 en lui-même, ce serait les suivants :
- L'interface graphique
En comparaison de Windows 10, l'interface graphique de Windows 11 n'est plus tout à fait la même. Tout d'abord, le menu Démarrer change une nouvelle fois pour être un peu plus épuré, et le bouton vient se placer au centre de la barre des tâches (même si l'on peut le repositionner à gauche). Ensuite, ce sont les fenêtres qui ont évoluées puisqu'elles bénéficient d'angles arrondis et d'une réorganisation des boutons d'actions. Personnellement, j'aime bien les angles arrondis et il paraît que c'est la mode en terme de design.
En complément, Microsoft a réintroduit les fameux widgets dans Windows 11. Personnalisable, la page des widgets permet d'obtenir des informations diverses et variées en fonction des widgets actifs : météo, photos, actualités, calendrier Outlook, tâches Microsoft To Do, etc. Étant donné que les tuiles dynamiques ne sont plus disponibles dans le menu Démarrer, je pense que les widgets sont une façon de les remplacer. Pour le moment, je n'ai pas trouvé un grand intérêt aux widgets, il faudrait que j'essaie à l'occasion, mais je suis habitué à fonctionner sans eux.
Le panneau des paramètres a évolué également, et je le trouve mieux organisé que sous Windows 10. Microsoft continue de lui ajouter des paramètres petit à petit, et à terme le menu "Panneau de configuration" historique devrait surement disparaitre.
Le nouveau panneau des paramètres de Windows 11
Avec ces changements au niveau du design et l'intégration de divers thèmes, on peut dire que Microsoft a su rajeunir l'interface graphique de Windows et lui donner un nouveau point de départ.
- Microsoft Store
Selon moi, un autre changement majeur, c'est le Microsoft Store. Même si le nom reste le même qu'avant, son contenu est réellement différent. Il est désormais plus ouvert aux éditeurs tiers et permet l'installation d'application de bureau classique. Autrement dit, il ne se limite plus aux applications modernes.
Ainsi, au moment d'installer un logiciel, ce n'est plus nécessaire de rechercher sur Internet un lien de téléchargement. Il suffit de le rechercher dans le Microsoft Store et de l'installer. Petit à petit les applications sont ajoutées, et je trouve que cette nouveauté est particulièrement intéressante pour le grand public, notamment pour les personnes qui ne sont pas forcément à l'aise avec l'informatique et qui ont tendance à télécharger les logiciels un peu n'importe où. Au final, ça termine un jour ou l'autre avec un malware sur la machine et un coup de fil à l'informaticien de la famille. En complément, on retrouve la possibilité de louer des films et d'acheter des jeux vidéos.
Derrière le Microsoft Store, se cache aussi le gestionnaire de paquets "WinGet" qui permet de gérer les logiciels en ligne de commande. C'est un outil à suivre et qui devrait venir concurrencer Chocolatey par la suite.
- Le support des applications Android
Même si ce n'est pas encore disponible en version stable et que cela se rapproche du Microsoft Store, je trouve que le support des applications Android en mode natif dans Windows 11 est une amélioration majeure. Même s'il y a déjà l'application "Votre Téléphone" que l'on connaît depuis Windows 10 et qui permet d'interagir avec son smartphone depuis Windows, là on va plus loin.
Windows 11 devrait permettre d'installer et d'exécuter les applications Android, sans avoir besoin de s'appuyer sur un émulateur tiers ou d'un smartphone (déport d'affichage).
Alors, Windows 11, une révolution ou pas ?
Sous le capot, Windows 11 est surement très très proche de Windows 10. Dans la pratique aussi d'ailleurs, car on s'habitue assez rapidement aux changements, mais il faut avouer que Windows 11 apporte de véritables changements vis-à-vis de Windows 10, notamment ceux évoqués ci-dessus. En fait, on en attendait peut-être encore plus !
Pour marquer le coup véritablement, peut-être que Microsoft aurait dû attendre un peu avant de le sortir afin de proposer un système encore plus aboutit au moment de sa sortie. Par exemple, avec les applications Android déjà opérationnelles, des applications historiques complètement révisées (le Bloc-notes par exemple), le nouveau lecteur multimédia, etc... Pour vraiment créer un écart important avec Windows 10 et tourner la page avec ce que l'on a pu connaître jusqu'ici.
Actuellement, on pourrait presque le comparer à une mise à jour majeure de Windows 10, même si ce serait un peu réducteur compte tenu des changements effectués. On peut dire que Windows 11 est une petite révolution et une évolution logique de Windows 10, mais j'insiste sur le fait que c'est une petite révolution. Avec Windows 11, Microsoft veut entrer dans un nouveau cycle, dans une nouvelle ère, alors maintenant on en veut plus !
Et vous, quel est votre avis à ce sujet ? J'attends vos commentaires !
L'utilisation de Windows PowerShell par les attaquants et les malwares est désormais chose commune, la puissance de ce moteur et ce langage est utilisée depuis plusieurs années (nous vous en parlions déjà sur IT-Connect en 2014). Il faut savoir que par défaut, PowerShell ne laisse pas beaucoup de traces de son exécution dans la plupart des environnements Windows.
Cette tendance doit mener à une vigilance accrue des équipes de sécurité qui doivent impérativement se mettre à surveiller l'exécution de commandes PowerShell sur les systèmes protégés. Dans cet article, nous allons voir comment activer la journalisation des commandes et scripts PowerShell exécutés sur un système Windows. Il existe trois moyens différents d'activer la journalisation des commandes PowerShell.
II. PowerShell et Transcript
Le transcript (littéralement transcription) est une méthode historique utilisée pour journaliser l'exécution de commandes PowerShell. Cette méthode comporte des manquements, mais c'est toujours mieux que de ne rien journaliser :).
La transcription crée un enregistrement unique de chaque session PowerShell comprenant toutes les entrées et sorties, exactement telles qu'elles apparaissent dans le terminal PowerShell. Les transcriptions sont écrites dans des fichiers texte, un fichier par utilisateur et par session, comme ceci :
Deux fichiers Transcript enregistrés correspondant à deux sessions PowerShell d'un utilisateur
Les transcriptions contiennent également des horodatages et des métadonnées pour chaque commande afin de faciliter l'analyse. Voici un exemple du contenu d'un fichier de transcription PowerShell :
Exemple de commandes et sorties enregistrées par les transcriptions
Cependant, la transcription n'enregistre que ce qui apparaît dans le terminal PowerShell, ce qui n'inclura pas le contenu des scripts exécutés ou la sortie écrite vers d'autres destinations tel que le système de fichiers. Pour l'activer localement et pour une session donnée, nous pouvons utiliser la commande start-transcript :
PS C:\Users\admin> Start-Transcript Transcription démarrée, le fichier de sortie est C:\Users\admin\Documents\PowerShell_transcript.DESKTOP-DBSUD32.g32CqxMk.20211227184120.txt PS C:\Users\admin> write-host "Hello" Hello PS C:\Users\admin> Stop-Transcript Transcription arrêtée, le fichier de sortie est C:\Users\admin\Documents\PowerShell_transcript.DESKTOP-DBSUD32.g32CqxMk.20211227184120.txt PS C:\Users\admin>
Bien sûr, cela n'a aucun intérêt de tenter de surveiller l'activité d'un attaquant sur un système si il doit lui-même activer la journalisation. C'est pourquoi nous pouvons passer par les GPO pour l'activation de la transcription.
Pour activer la transcription au niveau GPO, il faut se rendre dans Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Windows PowerShell. Il faut ensuite passer le paramètre Activer la transcription PowerShell à Activé :
Activation des Transcripts PowerShell
Par défaut, les transcriptions sont écrites dans le dossier Documents de l'utilisateur, mais cette configuration peut être modifiée vers n'importe quel emplacement accessible sur le système local ou sur le réseau. Il faut être conscient qu'un système de journalisation a peu de valeur s'il peut être supprimé ou désactivé par l'utilisateur lui-même et peut même s'avérer dangereux si des données sensibles peuvent y être consultées (par exemple : mots de passe saisis dans le terminal).
Dans l'idéal, la meilleure pratique consiste à externaliser les transcriptions du système et les envoyer sur un serveur de fichier. Ce répertoire distant doit être un partage réseau restreint en écriture seule (seule l'équipe de sécurité pourra y accéder en lecture par exemple). Attention tout de même, dans l'éventualité où un répertoire distant non accessible serait indiqué, les transcriptions ne seront plus enregistrées.
Pour modifier le répertoire d'écriture, il faut utiliser l'option correspondante dans le paramètre précédemment modifié :
Indication d'un répertoire distant pour l'écriture des transcriptions PowerShell
Il est également conseillé de cocher l'option Inclure les en-têtes de l'appel. Cela permet simplement l'horodatage de chaque commande :
Effet de l'activation de l'horodatage individuel des commandes
Pour activer ce même paramétrage au niveau de la base de registre, il faut modifier les registres suivants :
Grâce aux transcriptions, je peux affirmer que l'utilisateur admin a téléchargé un fichier à 11h36 le 29/12/2021. À présent j'exécute un script PowerShell qui fait la même opération, sans aucune sortie dans le terminal. Voici la trace laissée dans la transcription :
Transcription de l'exécution d'un Script PowerShell
Comme indiqué précédemment, la faiblesse de cette solution est qu'elle ne journalise que les entrées/sorties du terminal, l'utilisation d'un script est donc un moyen de contourner la journalisation par la transcription. Dans le cadre d'une activité malveillante, on peut facilement imaginer que le script utilisé ait été supprimé à la suite de son utilisation, nous n'avons alors aucune trace de ce qu'il s'est passé. Heureusement, d'autres solutions existent :).
III. PowerShell et Script Block Logging
Le script block loggingenregistre les blocs de code au fur et à mesure qu'ils sont exécutés par le moteur PowerShell, capturant ainsi l'intégralité du contenu du code exécuté par un attaquant, y compris les scripts et les commandes.
Il enregistre notamment le code "désobfusqué" au fur et à mesure de son exécution. Par exemple, en plus d'enregistrer le code obfusqué d'origine, le script block loggingenregistre les commandes décodées passées avec l'argument -EncodedCommand de PowerShell, ainsi que celles obfusquées avec XOR, Base64, ROT13, etc, en plus du code obfusqué d'origine. Le script block logging n'enregistrera cependant pas la sortie du code exécuté. Ces évènements seront journalisés dans la console de journalisation classique Windows et porteront l'ID d'évènement 4104. Les blocs de code dépassant la longueur maximale d'un message de journal d'évènements sont fragmentés en plusieurs entrées.
Il faut cependant savoir qu'à partir de PowerShell 5.0, le système enregistre automatiquement les blocs de code si leur contenu correspond à une liste de commandes ou de techniques de script suspectes, même si le script block logging n'est pas activé. Ces blocs suspects sont enregistrés au niveau avertissement dans l'ID d'évènement 4104, à moins que le script block logging ne soit explicitement désactivé. Cette fonctionnalité garantit que certaines informations nécessaires aux investigations (forensic) sont enregistrées pour une activité suspecte connue, même si la journalisation n'est pas activée.
L'activation du script block logging capturera toutes les activités, pas seulement les commandes considérées comme suspectes par le processus PowerShell. Cela permet d'identifier toute l'étendue de l'activité de l'attaquant. Les blocs qui ne sont pas considérés comme suspects seront également enregistrés dans l'ID d'évènement 4104, mais avec des niveaux verbose ou information.
Pour activer le script block logging au niveau GPO, il faut se rendre dans Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Windows PowerShell. Il faut ensuite passer le paramètre Activer la journalisation de blocs de scripts PowerShell à Activé :
Activation de la fonctionnalité Script Block Logging
Pour activer ce même paramétrage au niveau de la base de registre, il faut modifier le registre suivant :
Les évènements journalisés peuvent être trouvés localement dans l'Observateur d'évènements -> Journaux des applications et des services -> Microsoft -> Windows -> PowerShell -> Operationnal :
Journalisation d'une commande PowerShell sous l'ID d'évènement 4104
Cette commande est journalisée dans l'ID d'évènement 4104. Si j'exécute un script contenant cette commande, voilà ce que l'on pourra voir dans l'observateur d'évènements :
Journalisation des commandes exécutées par un script PowerShell
Nous avons bien ici notre commande de lancement du script, puis dans l'évènement suivant, la ligne de commande exécutée par le script, dont on retrouve par ailleurs le nom dans "Chemin d'accès :".
Nous allons maintenant passer à un cas un peu plus complexe qui est le cas d'un script contenant une commande encodée. L'encodage en base64 est la manière la plus basique de "dissimuler" une commande en PowerShell, cela permettra par exemple de ne pas faire apparaitre en clair la directive Invoke-WebRequest, qui permet de faire une requête HTTP, dans un script ou un terminal.
Pour ce faire, j'encode une première fois ma commande PowerShell en base64 :
J'exécute enfin ma commande en spécifiant -encodedcommand (ou -e), ce qui indique à PowerShell qu'il va devoir décoder la commande avant de l'exécuter, la commande qu'il obtiendra contiendra encore une fois un -encodedcommand, et la troisième commande qu'il obtiendra exécutera enfin une requête pour télécharger un fichier via HTTP.
Lors de son exécution, voici les différentes entrées portant l'ID d'évènement 4104 que l'on peut trouver dans l'observateur d'évènements :
Journalisation des différentes étapes de décodage de la commande PowerShell
On voit ici que les différentes étapes de l'exécution de ma commande apparaissent, on voit notamment les deux résultats du décodage base64, ce qui nous permet de voir la commande finale exécutée (contenant le Invoke-WebRequest) dans l'évènement journalisé.
Cas plus complexe où l'on peut vraiment parler d'obfuscation. Voici la même commande Invoke-WebRequest obfusquée grâce à l'outil Invoke-Obfuscation :
Ça fait mal aux yeux n'est-ce pas ? :p Sachez que c'est sur ce format de commande que travaillent la plupart des analystes en investigation numérique. Ce résultat est très difficilement compréhensible par l'homme et pose également problème aux systèmes de détection automatique. La commande est pourtant générée par un script trouvé sur internet en quelques secondes et elle fonctionne à merveille. Pour information, voici quelques-unes des techniques d'obfuscation utilisées ici :
Reordering : l'opérateur de formatage -f est utilisé afin de reconstituer une chaine de caractère ayant été divisée en plusieurs parties, ordonnée dans un sens qui rend complexe sa compréhension.
"{1}{0}"-f 'x','IE'
Replacing: Consiste à écrire une commande incorrecte ou mal formatée, puis à remplacer certains caractères au dernier moment pour qu'elle retrouve une structure correcte pour son exécution.
Escaping character: Consiste à positionner des caractères ` au milieu d'une chaine de caractères afin de complexifier la compréhension de la commande par l'analyste.
Dans notre cas, les ` ([char]39) apparaissent après la phase de remplacement et sont positionnés à la place des dbT ([char]100+[char]98+[char]84)
Up/Lower case : Écriture de commande ou mot-clé détectable en alternance de minuscule/majuscule afin de tromper des expressions régulières qui ne prendraient pas la casse en compte.
InvOKE-EXprESSIOn
Si vous êtes toujours là, voici la journalisation obtenue lors de l'exécution de cette commande :
Journalisation des étapes de reconstruction d'une commande obfusquée
Voilà qui est intéressant, trois évènements journalisés reconstituent la commande à chaque étape de sa reconstruction, et nous voyons à nouveau la commande exécutée en clair.
IV. PowerShell et le module Logging
Le module loggingenregistre les détails de l'exécution au fur et à mesure de l'exécution, y compris l'initialisation des variables et les appels de commande. Le module logging enregistrera des portions de script, du code désobfusqué et des données de sortie. Cette journalisation capturera certains détails manqués par d'autres sources de journalisation PowerShell, bien qu'elle puisse ne pas capturer de manière fiable l'intégralité des commandes exécutées. Les événements de journalisation du module sont écrits dans l'ID d'événement (EID) 4103 et s'orientent sur l'utilisation de modules plutôt que le suivi de l'exécution d'une commande ou d'un script de A à Z.
Voici par exemple la journalisation générée par l'exécution de notre commande obfusquée :
Journalisation de l'exécution d'une commande obfusquée
On voit ici que trois évènements (EID 4013) ont été journalisés, chacun faisant apparaitre une étape de notre commande, correspondant à l'utilisation d'un module précis : Invoke-Expression, Invoke-WebRequest,Out-Default (la sortie). Le module ciblé par l'évènement est spécifié en première ligne (CommandInvocation) alors que les données utiles à un analyste sont dans la partie Contexte.
Pour activer le module logging au niveau GPO, il faut se rendre dans Configuration ordinateur -> Modèles d'administration -> Composants Windows -> Windows Powershell. Il faut ensuite passer le paramètre Activer l'enregistrement des modules à Activé :
Activation du module Logging PowerShell
Il ne faut pas oublier ici d'activer le module logging pour tous les modules (en fonction de ce que l'on souhaite) en positionnant un wildcard (*) dans Noms des modules. On peut se servir de cette option pour journaliser uniquement l'utilisation de certains modules, mais cela n'est pas recommandé, car il est presque impossible d'anticiper toutes les possibilités qu'utilisera un attaquant.
Pour activer ce même paramétrage au niveau de la base de registre, il faut modifier le registre suivant :
IV. Pour aller plus loin : centralisation et corrélation
Nous voyons donc que ces trois méthodes de journalisation sont complémentaires, la transcription présente des manquements qui peuvent être problématiques pour mener à bien une investigation numérique ou pour de la surveillance des évènements de sécurité. Le script block logging et le module logging apparaissent comme des sources d'information pertinentes aussi bien pour de l'analyse forensic que pour l'envoi des journaux à un SIEM qui tentera ensuite d'y détecter des activités suspectes ou malveillantes.
Dans tous les cas, l'externalisation des journaux hors du système qui les produit et leur centralisation pour mener à bien des opérations de corrélation d'évènements et de détection des activités suspectes est clairement recommandée une fois que la journalisation des commandes PowerShell est activée. Je vous oriente vers cet article pour aller plus loin sur ce sujet : Centralisation des logs, un outil pour la sécurité.
Directive 36 : Activer et configurer les journaux des composants Si toutes les actions précédentes ont été mises en œuvre, une centralisation des journaux sur un dispositif dédié pourra être envisagée. Cela permet de faciliter la recherche automatisée d’évènements suspects, d’archiver les journaux sur une longue durée et d’empêcher un attaquant d’effacer d’éventuelles traces de son passage sur les équipements qu’il a compromis.
N'hésitez pas à partager vos expériences et vos avis dans les commentaires de cet article
Le système Apple iOS qui équipe les iPhone contient une faille de sécurité de type "déni de service" au sein de la fonctionnalité HomeKit. Le nom "doorLock" est associé à cette vulnérabilité.
La vulnérabilité doorLock affecte toutes les versions du système iOS entre les versions 14.7 et 15.2, tout en sachant que la version 15.2 est la plus récente à ce jour. Comme je le disais en introduction, cette faille est située dans HomeKit, la fonctionnalité d'iOS qui permet de gérer des objets connectés (ampoule, interrupteur, prise, etc.) depuis son iPhone (ou son iPad).
À ce jour, la vulnérabilité n'est toujours pas corrigée par Apple et la firme à la pomme semble repousser sans cesse l'intégration de ce correctif à une mise à jour. D'après le chercheur en sécurité Trevor Spiniolas, Apple serait informé de cette vulnérabilité depuis le 10 août 2021, ce qui aurait dû être suffisant pour la corriger.
Pour exploiter la faille de sécurité doorLock, un attaquant doit réussir à modifier le nom d'un appareil HomeKit en précisant une chaîne de caractères de plus de 500 000 caractères. Par exemple, si un malware est installé sur un iPhone, il peut accéder à HomeKit pour modifier les informations d'un appareil, ou forcer la création d'un appareil dans le cas où HomeKit n'est pas utilisé par le propriétaire de l'iPhone. Sinon, une invitation HomeKit malveillante pourrait être utilisée.
La faille doorLock est de type déni de service : dès lors que la chaîne de 500 000 caractères sera validée, l'appareil va complètement planter à tel point qu'il faudra le réinitialiser (hard reset) pour qu'il redémarre. Cela signifie que les données seront effacées alors mieux vaut avec une sauvegarde de son appareil.
Le plus grave avec la faille doorLock, c'est qu'une fois que l'appareil redémarre et que l'utilisateur se reconnecte au compte iCloud, et donc qu'il récupère les informations HomeKit, le bug se déclenche à nouveau ! En fait, il faut restaurer l'appareil sans se connecter à son compte iCloud dans un premier temps et désactiver la partie "Home" d'iOS avant de se connecter.
Puisque pour le moment il n'y a pas de correctif officiel de la part d'Apple, il vaut mieux rester prudent. Si vous recevez une invitation HomeKit pour ajouter un appareil, n'acceptez pas sans réfléchir, car cela peut avoir des conséquences ! À bon entendeur !
L'auteur de Have I Been Pwned a ajouté à la base du site les informations de plus de 441 000 comptes dérobés par le malware RedLine dans le cadre de ses campagnes d'attaques.
Le malware RedLine est très actif depuis plusieurs mois et il est diffusé au travers de campagnes de phishing, mais aussi de certains sites, notamment des sites liés aux téléchargements illégaux. Dès lors qu'il est en place sur votre machine, il va entrer en action afin de dérober un maximum d'informations : identifiants, numéro de cartes bancaires, identifiants VPN, identifiants FTP, cookies, etc... En fonction de ce qui est mémorisé à droite à gauche dans votre navigateur et les logiciels présents sur votre poste. Il peut également télécharger des exécutables afin de réaliser d'autres actions malveillantes.
Les données collectées sont stockées au sein d'une archive nommée "Logs" et qui est ensuite envoyée vers un serveur distant. Chaque archive est revendue 5$ sur le dark web ou utilisée pour compromettre les comptes de l'utilisateur. Il s'avère que le chercheur en sécurité Bob Diachenko a découvert un serveur qui exposait 6 millions d'enregistrements collectés entre août et septembre 2021. D'ailleurs, il a pu faire le rapprochement entre certains comptes présents dans cette liste et les alertes reçues par certains utilisateurs de LastPass la semaine dernière. Néanmoins, ce serveur ne semble plus être utilisé par les pirates, car le nombre d'enregistrements n'augmente pas.
Bob Diachenko a pris contact avec Troy Hunt, l'auteur du site Have I Been Pwned, afin qu'il puisse ajouter les informations récoltées sur ce serveur au sein de la base du site. Sur les 6 millions d'enregistrements, on retrouve 441 657 adresses e-mails uniques.
Si votre adresse e-mail apparaît dans cette liste associée au malware RedLine, c'est une très mauvaise nouvelle. Puisque le malware est capable de récupérer des informations diverses et variées comme évoquées ci-dessus, il va falloir modifier une multitude de mots de passe pour être sûr de sécuriser les différents accès. Cela peut représenter un travail conséquent... Et surtout, c'est à faire dès que possible pour éviter que la situation se dégrade... En complément, il faudra penser à réaliser une analyse de son système pour retirer la souche RedLine.
Cette liste contient les enregistrements collectés entre août et septembre 2021 donc elle n'est pas exhaustive, mais cela permet de faire une vérification sur cet échantillon intéressant.
En accédant au site Have I Been Pwned et en précisant votre adresse e-mail, vous pouvez voir si vous avez été victime du malware RedLine (ou d'une autre fuite de données). Ce que je vous recommande de faire, on ne sait jamais !
