PROJET AUTOBLOG


IT-Connect

Site original : IT-Connect

⇐ retour index

Threat Intelligence : protégez-vous des adresses IP malveillantes avec CrowdSec

jeudi 25 avril 2024 à 18:00

I. Présentation

Dans cet article, nous allons découvrir les fonctionnalités gratuites de la CrowdSec Console, qui se présente comme une solution de Threat Intelligence complète et simple d'utilisation accessible avec un tableau de bord en ligne.

Cette solution va, d'une part, nous permettre d'en savoir plus sur la réputation des adresses IP grâce à la Threat Intelligence. D'autre part, elle offre une vue d'ensemble sur les activités malveillantes détectées et bloquées par vos éventuelles instances CrowdSec protégées par cet IDS/IPS. Lisez la suite de cet article pour en savoir plus et effectuer une prise en main complète de cette console !

Avant de commencer, voici nos précédents articles au sujet de CrowdSec :

II. Les fonctionnalités gratuites de la console CrowdSec

A. Créer un compte

La première étape consiste à créer un compte CrowdSec Console : vous avez seulement besoin d'une adresse e-mail valide. Pour accéder directement à la page d'inscription, suivez ce lien :

Après avoir indiqué une adresse e-mail et un mot de passe, cliquez sur "Sign up" afin de recevoir un e-mail avec un lien de validation.

Dès que c'est fait, vous avez accès à la console CrowdSec à partir de votre nouveau compte ! Lors de la première connexion, on vous posera deux questions : le type de votre organisation et le nombre de salariés. Rien de plus.

B. Les fonctionnalités principales

Avant de créer un compte sur la Console CrowdSec, vous souhaitez probablement en savoir plus sur les fonctionnalités offertes par cette console ! Nous allons évoquer les fonctionnalités gratuites et accessibles à tous. Au-delà d'avoir une vue d'ensemble sur vos serveurs où CrowdSec est déployé, ce compte vous donne accès à la Cyber Threat Intelligence de CrowdSec, ainsi qu'à diverses listes d'adresses IP malveillantes que vous pouvez pousser vers vos instances CrowdSec.

👉 Voici un récapitulatif :

Vous pouvez obtenir l'état et la version du moteur CrowdSec sur le serveur, obtenir la liste des scénarios actifs, ainsi que la liste des bouncers actifs sur ce serveur. Vous avez également accès à différentes métriques telles que le nombre d'alertes.

La Console CrowdSec indique le nombre d'alertes par instance et donne accès à un ensemble de statistiques et graphes. Il est possible de visualiser les informations pour une instance ou plusieurs instances, sur une période plus ou moins longue, grâce à un système de filtres. La version gratuite donne accès aux données sur les 7 derniers jours (et 500 alertes).

Ainsi, vous pouvez en apprendre davantage sur le profil des attaquants : adresses IP, pays d'origine, fournisseurs de service, niveau d'agressivité, type d'attaques, etc. Ceci étant lié à la Threat Intelligence évoquée ci-dessous.

La Console CrowdSec donne accès aux informations de la Cyber Threat Intelligence (CTI) de CrowdSec, appelée judicieusement CrowdSec Threat Intelligence. Ceci permet d'en savoir beaucoup plus sur les adresses IP malveillantes, grâce aux signaux collectés à partir des serveurs de CrowdSec et des milliers d'instances déployées par la communauté.

Ces informations sont précieuses et elles permettent de répondre à différentes questions. Par exemple : si une adresse IP s'attaque à votre serveur depuis plusieurs heures ou jours, s'agit-il d'une attaque ciblée à l'encontre de mon organisation ou tout simplement une adresse IP agressive à la recherche d'une opportunité ? Il pourrait s'agir d'une adresse IP qui effectue un scan constant d'Internet à la recherche de serveurs exposés et pas suffisamment sécurisés. Dans la CTI, si l'adresse IP est déjà connue, elle sera catégorie et vous pourrez en savoir plus à son sujet.

Il y a deux manières d'accéder à ces informations : effectuer une recherche sur l'adresse IP de votre choix, grâce à une zone de recherche, ou cliquer sur l'adresse IP associée à une alerte sur votre instance CrowdSec.

Quand vous installez CrowdSec, vos instances bénéficient des listes noires d'adresses IP détectées par la communauté CrowdSec. Ceci protège vos serveurs équipés de CrowdSec, mais bien que continuellement mises à jour, ces listes ne sont pas exhaustives. Aucune liste n'est exhaustive de toute façon, d'où l'intérêt de combiner plusieurs sources. C'est là que les blocklists tierces proposées par CrowdSec interviennent en complément de quelques blocklists estampillées "CrowdSec Premium" (réservées aux utilisateurs de la version Enterprise).

Avec la version gratuite, vous pouvez vous abonner à trois blocklists et les affecter à vos instances CrowdSec.

C. Quels sont les plus de la version Enterprise ?

Sans surprise, la version Enterprise fait sauter un ensemble de brides associées à la version gratuite. Nous pouvons citer quelques exemples : elle donne accès à la rétention des données sur 1 an au lieu de 7 jours, autorise la création de plusieurs utilisateurs et organisations, et permet de s'abonner à un nombre illimité de blocklists. De plus, vous avez accès à un support professionnel, en direct, et n'êtes pas limité au serveur Discord de la communauté CrowdSec.

Autre avantage de cette version payante, c'est qu'elle vous permet de gérer les décisions de vos instances à partir de la console CrowdSec. Ainsi, vous pouvez ajouter une adresse IP à la console CrowdSec pour pousser vers vos instances afin qu'elle soit bloquée. À l'inverse, vous pouvez supprimer une décision (c'est-à-dire le ban sur une adresse IP, par exemple), à partir de la console CrowdSec.

Pour comparer les différentes offres de CrowdSec et en savoir plus sur les tarifs, consultez cette page :

III. Les avantages de connecter ses instances CrowdSec à la console

Dans cette partie de l'article, nous allons déployer CrowdSec sur une machine Windows Server 2022 puis nous allons inscrire cette instance dans la Console CrowdSec pour voir quels bénéfices nous pouvons en tirer.

A. Déployer CrowdSec sur Windows Server 2022

Si vous n'avez jamais déployé CrowdSec, la Console est un bon point de départ, car elle vous guide dans ce déploiement qui s'effectue en trois étapes :

1 - Installer CrowdSec "Security Engine" sur le serveur (composant principal).

2 - Installer le "Bouncer" pour permettre le blocage des adresses IP.

3 - Enregistrer l'instance CrowdSec dans la console.

La console CrowdSec contient différents liens pour vous orienter dans la documentation.

Sur le serveur Windows Server 2022, nous allons installer CrowdSec après l'avoir téléchargé à partir du GitHub officiel. L'installation s'effectue en quelques clics.

Suite à l'installation, la configuration de CrowdSec sera accessible dans le répertoire suivant :

C:\ProgramData\CrowdSec

Ensuite, nous devons installer le bouncer "Windows Firewall", ce qui va permettre de bloquer les adresses IP malveillantes grâce à des règles de refus créées dans le pare-feu Windows Defender. Il a besoin du Runtime .NET en version 6 pour fonctionner.

Nous allons télécharger le fichier "cs_windows_firewall_installer_bundle.exe" dans sa dernière version, pour ensuite effectuer l'installation. Ce fichier, qui contient le mot "bundle", englobe à la fois le bouncer et le Runtime .NET. L'installation s'effectue en quelques clics.

Deux nouveaux services sont désormais présents sur la machine Windows :

B. Inscrire l'hôte à la console CrowdSec

Pour enregistrer la nouvelle instance dans la console CrowdSec, nous devons exécuter la commande fournie sur l'interface de la console :

cscli console enroll clv3tfwqb001fjv083qftmaxd

Sachez que vous pouvez compléter cette commande, notamment en précisant le nom sous lequel vous souhaitez effectuer cet enregistrement. Sinon, elle va remonter avec un nom aléatoire, ce qui peut être gênant si vous envisagez d'inscrire plusieurs instances. Néanmoins, sachez que le nom peut être changé à tout moment, comme nous le verrons par la suite.

cscli console enroll clv3tfwqb001fjv083qftmaxd --name "WS-2022-IIS"

Une fois que c'est fait, relancez le service CrowdSec :

Restart-Service CrowdSec

Voici un exemple :

Du côté de la console CrowdSec, nous devons approuver cette demande d'inscription via le bouton "Accept enroll".

Désormais, l'instance CrowdSec déployée sur le serveur Windows Server est inscrite dans la console. Nous pourrions en ajouter d'autres sur le même principe.

Le nom de l'instance n'étant pas très évocateur, nous allons le modifier en choisissant "Edit name or tags" après avoir cliqué sur le widget de l'instance.

Ici, nous allons choisir le nom "WS-2022-IIS" car c'est le nom d'hôte du serveur. Puis, nous pouvons ajouter des tags. Cette fonctionnalité est pratique pour catégoriser vos instances selon différents critères : système d'exploitation, rôle, etc.... Vous pouvez nommer ces tags comme vous le souhaitez. Dans l'exemple ci-dessous, je crée 2 tags : "OS" et "Type".

Il ne reste plus qu'à cliquer sur "Update" pour valider. C'est plus propre, désormais :

C. S'abonner à une blocklist d'adresses IP malveillantes

La prochaine étape va consister à nous abonner à une blocklist supplémentaire afin de bloquer des adresses IP malveillantes connues, avant même qu'elles aient une chance de s'en prendre à notre serveur. Après avoir cliqué sur l'instance, nous cliquer sur "Browse available blocklists" pour accéder à la liste des blocklists.

Ici, nous retrouvons une liste de blocklists, avec une description associée à chacune d'elles. Il y a également des statistiques intéressantes : le nombre total d'adresses IP dans cette blocklist et le nombre actuel d'abonnés, ce qui indique la popularité de cette blocklist.

Nous allons cliquer sur le bouton "Subscribe" au niveau de la blocklist nommée "Firehol cybercrime tracker list". Elle contient des adresses IP malveillantes associées à des serveurs de Command and Control (C2) utilisés par des attaquants.

Le fait de cliquer sur "Subscribe" nous donne accès à différents insights très intéressants au sujet de cette blocklist !

Ces indicateurs permettent d'évaluer la pertinence d'une blocklist vis-à-vis d'une autre et ajoutent de la transparence à la Console CrowdSec.

Tout en bas de la page, nous allons cliquer sur le bouton "Add Security Engine(s)" puis sélectionner notre instance. Nous devons également choisir un type d'action à appliquer à ces adresses IP : "Ban" permet de bannir les adresses IP de cette blocklist. Une fois que c'est fait, il ne reste plus qu'à valider.

Voilà, notre serveur "WS-2022-IIS" est désormais abonné à cette blocklist ! Au passage, l'image ci-dessous nous permet de voir quels sont les pays les plus ciblés par les adresses IP contenues dans cette liste.

IV. Analyser une adresse IP avec CrowdSec Threat Intelligence

Au quotidien, la Console CrowdSec vous permettra d'avoir un œil sur les attaques et les scans identifiés et bloqués par vos serveurs. La liste des décisions et des alertes est accessible en mode console (via le jeu de commandes "cscli") mais aussi via l'interface de la console.

Dans l'exemple ci-dessous, nous pouvons constater que l'adresse IP "52.186.17.219" a été bannie par CrowdSec, car elle a effectué des actions suspectes sur le service Web de mon serveur, en plus d'un brute force sur le service RDP.

Pour en savoir plus sur cette adresse IP et notamment savoir "A quoi elle correspond" et si elle est connue pour effectuer de nombreuses attaques, il suffit de cliquer dessus. Autrement dit, nous allons pouvoir en apprendre plus sur la réputation de cette adresse IP.

Nous sommes directement redirigés vers la Threat Intelligence de CrowdSec où nous pouvons visualiser un ensemble d'insights associés à cette adresse IP. Ici, l'adresse IP apparaît comme inconnue et nous n'apprenons pas grand-chose à son sujet : c'est normal, j'ai effectué ce scan du service web à partir d'un serveur que je contrôle et cette adresse IP n'est pas utilisée à des fins malveillantes, sauf pour cette démonstration.

Néanmoins, dans un cas réel, cela ne veut pas dire que ce n'est pas une adresse IP dangereuse : si l'adresse IP en question remonte souvent dans les alertes et qu'elle semble cibler votre serveur en particulier, il pourrait s'agir d'une attaque ciblée. Méfiance, donc.

Les choses ont évoluées au bout de plusieurs heures. Après avoir effectué plusieurs tests de scans de port et tentatives de brute force, depuis cette adresse IP et à destination de mon serveur "WS-2022-IIS". Comme le montre l'image ci-dessous, nous pouvons voir que la Threat Intelligence de CrowdSec commence à dresser le profil de cette adresse IP. Par exemple, l'adresse IP est désormais connue pour effectuer des attaques par brute force.

Sans parler des alertes et décisions de notre instance, nous pouvons solliciter la Threat Intelligence de CrowdSec pour obtenir des informations sur une adresse IP. Prenons l'exemple de l'adresse IP suivante : "193.142.146[.]226".

Nous allons cliquer sur "CrowdSec Threat Intelligence" dans le menu, saisir cette adresse IP et cliquer sur le bouton "Search" pour lancer une recherche à son sujet. Dans ce nouvel exemple, nous utilisons l'interface Web de la console CrowdSec, mais il y a également une API et des intégrations avec d'autres solutions (OpenCTI, Splunk SIEM, TheHive, etc.).

Sur le même principe que pour l'exemple précédent, nous obtenons un ensemble d'indicateurs. Sauf qu'ici, il s'agit d'une adresse IP malveillante avec une très mauvaise réputation. Nous avons des informations plus précises et un historique très complet sur les activités malveillantes initiées depuis cette adresse IP.

Nous pouvons constater que cette adresse IP est très active et agressive depuis plusieurs mois. De plus, nous pouvons constater qu'elle est déjà référencée dans la blocklist "Firehol cybercrime tracker list" à laquelle notre serveur est abonné ! C'est une bonne nouvelle, puisque cela veut dire que cette adresse IP est déjà bloquée sur notre serveur grâce au fait qu'il soit abonné à cette liste.

Sachez que même si vous ne déployez pas CrowdSec sur vos serveurs, vous pouvez tout de même créer un compte CrowdSec Console pour solliciter la "CrowdSec Threat Intelligence" afin d'obtenir des renseignements sur une adresse IP. Vous pouvez effectuer 10 requêtes par cycle de 2 heures.

V. Conclusion

Suite à la lecture de cet article, vous avez une vue d'ensemble des principales fonctionnalités offertes par la CrowdSec Console ! Grâce à la Threat Intelligence, elle a une réelle valeur ajoutée dans le suivi des menaces et sur l'activité associée à chaque adresse IP publique. Que vous soyez ou non utilisateur de la solution CrowdSec Security Engine, elle peut vous être utile !

Cet article contient une communication commerciale.

The post Threat Intelligence : protégez-vous des adresses IP malveillantes avec CrowdSec first appeared on IT-Connect.

Apple pourrait développer sa propre puce pour les serveurs et l’IA

jeudi 25 avril 2024 à 13:33

Apple travaillerait sur le développement de nouveaux processeurs destinés à équiper des serveurs et conçus pour répondre aux besoins du domaine de l'Intelligence Artificielle. Voici ce que l'on sait !

Apple pourrait être un futur concurrent de poids pour NVIDIA sur le marché des serveurs et de l'IA, même s'il y a encore beaucoup de chemins à parcourir. Sur le réseau social chinois Weibo, un leaker surnommé "Phone Chip Expert" a révélé qu'Apple travaille en interne sur le développement de puces destinées à ce marché en pleine expansion et particulièrement juteux pour les entreprises.

Cette première puce d'Apple serait basée sur une gravure en 3 nm de TSMC. Basé à Taïwan, le géant TSMC est la plus importante fonderie de semi-conducteurs et la gravure en 3 nm correspond au procédé le plus avancé à l'heure actuelle. D'ailleurs, Apple profite déjà de ce type de gravure pour ses puces A17 Pro et M3. La gravure en 2 nm est attendue pour 2025, tandis que TSMC envisage de passer à la gravure en 1,6 nm en 2026.

Pour le moment, et pour des raisons de confidentialité et sécurité, Apple effectue les calculs liés à l'IA en local sur ses appareils. La puissance est plus limitée qu'avec l'usage du Cloud, ce qui pourrait freiner Apple à un moment donné. En produisant ses propres puces pour serveurs, Apple pourrait avoir une meilleure maitrise du matériel, et surtout, optimiser le matériel vis-à-vis des besoins de ses logiciels et services.

Ainsi, Apple pourrait s'appuyer sur le Cloud pour ses services liés à l'Intelligence Artificielle, tout en tirant profit de ses propres puces. Toujours d'après "Phone Chip Expert", un début de production en masse est prévu pour le second semestre 2025. D'ici à un ou deux ans, Apple pourrait commencer à déployer ses propres serveurs.

Les informations du leaker "Phone Chip Expert", bien que généralement fiables, sont à prendre avec précautions, car Apple ne s'est pas exprimé officiellement sur le sujet.

Source

The post Apple pourrait développer sa propre puce pour les serveurs et l’IA first appeared on IT-Connect.

Les pirates d’ArcaneDoor ont compromis les firewalls Cisco pour accéder à des réseaux gouvernementaux !

jeudi 25 avril 2024 à 10:50

Depuis novembre 2023, un groupe de pirates exploite 2 failles de sécurité zero-day présentes dans les firewalls Cisco pour compromettre des infrastructures gouvernementales dans le monde entier. Faisons le point sur cette menace.

Si vous utilisez un firewall Cisco ASA (Adaptive Security Appliance ou Cisco FTD (Firepower Threat Defense), vous devriez lire cette alerte de sécurité avec une attention particulière. Un groupe de pirates, traqués sous le nom UAT4356 par Cisco Talos, et STORM-1849 par Microsoft, a compromis des firewalls vulnérables au début du mois de novembre 2023, dans le cadre d'une campagne de cyberespionnage baptisée "ArcaneDoor".

Dans le cadre de ces attaques, le groupe de pirates a exploité deux vulnérabilités en tant que failles de sécurité zero-day :

Ce n'est qu'en janvier 2024 que Cisco a pris connaissance de la campagne ArcaneDoor. Mais, d'après les chercheurs en sécurité de chez Cisco, les attaquants ont développé et testé des exploits pour ces deux failles zero-day en juillet 2023. Le vecteur d'attaque initial reste inconnu à ce jour.

Sur les appareils Cisco compromis et sur lesquels ils avaient la main, les pirates ont déployé des logiciels malveillants inconnus jusqu'ici. Le premier implant se nomme "Line Dancer" et il permet d'exécuter du code en mémoire pour désactiver la journalisation, activer l'accès distant ou encore exfiltrer les paquets capturés.

Le second implant se nomme "Line Runner" et il s'agit d'une porte dérobée persistante permettant l'exécution de code Lua sur les équipements, tout en étant discret et difficilement détectable.

Dans le rapport de Cisco Talos, nous pouvons lire : "UAT4356 a déployé deux portes dérobées dans le cadre de cette campagne, "Line Runner" et "Line Dancer", qui ont été utilisées collectivement pour mener des actions malveillantes sur la cible, notamment la modification de la configuration, la reconnaissance, la capture/exfiltration du trafic réseau et, éventuellement, le déplacement latéral."

Cisco a publié des correctifs de sécurité

Cisco a mis en ligne des correctifs de sécurité pour permettre aux entreprises de se protéger de ces failles de sécurité importantes, déjà exploitées dans le cadre de la campagne de cyberespionnage menée par le groupe UAT4356.

"Cisco recommande vivement à tous ses clients d'effectuer une mise à niveau vers les versions logicielles patchées.", peut-on lire sur le site de Cisco.

En complément de l'installation du correctif de sécurité, Cisco vous recommande de surveiller les journaux de système à la recherche d'une activité suspecte. Il peut s'agir d'un redémarrage non programmé de l'appareil, d'un changement de configuration ou encore de connexions suspectes.

Source

The post Les pirates d’ArcaneDoor ont compromis les firewalls Cisco pour accéder à des réseaux gouvernementaux ! first appeared on IT-Connect.

Pendant 5 ans, la Chine a espionné le groupe Volkswagen : 19 000 documents ont été volés !

mercredi 24 avril 2024 à 17:20

Pendant 5 ans, des hackers sponsorisés par l'État chinois ont espionné le groupe automobile Volkswagen ! Pendant cette période, ils ont dérobé des milliers de documents confidentiels au sujet des futurs véhicules électriques de la marque, mais pas seulement...

19 000, c'est le nombre de documents qu'est parvenu à dérober un groupe de hackers, entre 2010 et 2015. Cette information a été révélée il y a quelques jours grâce à des journalistes allemands parvenus à obtenir des documents internes évoquant cet espionnage important. Pour être plus précis, le 20 avril 2024, les médias allemands ZDF et Der Spiegel ont publié des articles à ce sujet.

Un groupe de hackers lié à la Chine ?

Même si la Chine n'est pas directement accusée de cet acte de cyberespionnage, tout porte à croire qu'elle en est à l'origine. En effet, il y a plusieurs indices qui vont dans ce sens, notamment la méthodologie employée par les hackers et le fait que les adresses IP utilisées par les pirates soient associées à la Chine. Bien qu'il n'y ait pas de preuve réelle, voici ce que l'on peut lire dans l'article du média ZDF : "Nous avons pu remonter l'adresse IP jusqu'à Pékin, et même jusqu'à l'Armée populaire de libération (APL)."

Par ailleurs, les hackers ont utilisé deux logiciels espions habituellement utilisés par les acteurs étatiques chinois : "China Chopper" et "PlugX". Par exemple, China Chopper est un web shell découvert pour la première fois en 2012 et utilisé pour obtenir la persistance sur un système compromis.

À quoi correspondent les documents volés ?

Au total, les pirates auraient volé environ 19 000 documents. Mais, alors, à quoi correspondent-ils ? Au-delà des informations au sujet des véhicules électriques de Volkswagen, les pirates ont mis la main sur d'autres documents, car ce n'était pas leur cible initiale. Parmi les objectifs identifiés des hackers, il y avait :

Par ailleurs, des documents relatifs aux boites de vitesses automatiques, aux travaux effectués sur les piles à combustibles ou encore l'e-Mobilité, ont été dérobés par les hackers.

Cette affaire est clairement de l'espionnage industriel et les documents volés ont pu participer à donner un avantage concurrentiel à la Chine, si elle est bien à l'origine de cette attaque. Ceci est d'autant plus vrai que le groupe Volkswagen comprend également d'autres marques comme Audi, Lamborghini, MAN, Porsche, Skoda et Bentley.

Source

The post Pendant 5 ans, la Chine a espionné le groupe Volkswagen : 19 000 documents ont été volés ! first appeared on IT-Connect.

Hack the box – Sherlocks (forensic) : découverte et solution de Litter

mercredi 24 avril 2024 à 10:00

I. Présentation

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

Lien du challenge : Hack The Box - Sherlocks - Litter

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éesWindows, DNS, protocol tunneling
Outils utilisésWireshark, python

Retrouvez tous nos articles Hack The Box via ce lien :

II. Découverte de l'archive

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é

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.

Exemple : T1567.002 - Exfiltration Over Web Service: Exfiltration to Cloud Storage

Il ne nous reste donc plus que le protocole DNS comme candidat !

B. Tâche n°2 : Identifier l'IP suspecte

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 ?

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

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 :

python3 dnscat2text.py -f suspicious_traffic.pcap -d microsofto365.com

J'obtiens le résultat suivant :

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

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

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-ci et 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

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

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 :

TTP (MITRE ATT&CK)Détails
T1583.001 - Acquire Infrastructure: DomainsAcquisition du nom de domaine microsofto365.com
T1583.002 - Acquire Infrastructure: DNS ServerMise en place d'un serveur DNS via un dnscat2 exposé sur Internet en vue de recevoir et de répondre aux requêtes du système compromis (client)
TA0002 - ExecutionCompromission de l'utilisateur test sur le système desktop-umncbe7 par un vecteur non connu
T1608.002 - Stage Capabilities: Upload ToolDépôt du binaire dnscat2
T1071.004 - Application Layer Protocol: DNSExécution du binaire dnscat2 et établissement d'un canal de communication encapsulé dans le protocole DNS
T1036.005 - Masquerading: Match Legitimate Name or LocationRenommage du binaire dnscat2 en win_installer.exe
T1083 - File and Directory DiscoveryRecherche dans le système de fichier du système compromis
T1048.003 - Exfiltration Over Alternative Protocol: Exfiltration Over Unencrypted Non-C2 ProtocolAffichage 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 :

C. Côté attaquant

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

The post Hack the box – Sherlocks (forensic) : découverte et solution de Litter first appeared on IT-Connect.