Voici mon compte rendu des conférences auxquelles j’ai pu assister lors du Coriin de cette année, une conférence orientée réponse à incident et forensic qui a lieu chaque année au FIC (Forum International de la Cybersécurité).
Vous pouvez retrouver l’ensemble des informations de cette conférence à cette adresse
Adversary-in-The-Middle#
Investiguer et détecter la menace du phishing Adversary-in-The-Middle par Grégoire Clermont et Quentin Bourgue
- Détection d’une augmentation significative des offres “phishing as a service” via des kits clés en main.
- Utilisation de Cloudflare (CAPTCHA) pour minimiser l’exposition d’IOC et donc ne pas favoriser la détection des activités.
- Ciblage de services spécifiques, en particulier Microsoft, de façon moins représentative d’autres services tels que Gmail, Dropbox, etc.
Investigation#
- Pour leur investigation, ils ont utilisé VirusTotal et URLscan.
- Ils ont utilisé le hash des images présentes sur les pages pour pivoter.
- Ils ont essayé de trouver les packs de phishings (archive zip ou rar) stockés directement sur les hébergements web via le nom des fichiers en constituant des wordlists.
- Enfin, ils ont tenté d’identifier l’infrastructure utilisée par les attaquants via Censys ou Shodan.
Pour plus d’informations, consultez l’article sur le blog de Sekoia : Kit phishing.
Remediation#
Différentes stratégies de détection ont été proposées :
- Détection de l’absence d’UserAgent dans les requêtes de connexions (usurpées par le site de l’attaquant).
- Utilisation de proxy résidentiels.
- Possibilité de mettre en place des canaries.
En pivotant sur les ID de session (uniquement depuis le centre d’administration O365), il est possible de retracer les actions effectuées après l’infection.
Pour plus d’informations, consultez les slides à cette adresse : CoRIIN2024-BOURGUE-CLERMONT.pdf
VIGINUM - Portal Konbat investigation#
Investigations réalisées par VIGINUM sur un réseau de « portails d’information » numériques diffusant des contenus de propagande
Rapport sur Portal Konbat#
- Plus de 193 portails d’informations différents découverts.
- Pas de production de contenu, seulement de la distribution.
L’élément déclencheur a été une vidéo réalisée par des Français lors d’une “manifestation” officieuse en soutien à l’armée russe.
Pour identifier l’ensemble des sites internet, plusieurs pivots ont été utilisés :
- Via la balise
<meta name="description" content="...">. - Via l’adresse IP.
- Via la WebArchive.
L’objectif final est de prévenir les futures vagues de fake news en identifiant des “patterns”.
Exemple de méthode utilisée pour tracer une IP :
- Lors d’une tentative de typosquatting d’un article provenant d’un journal officiel, la page de celui-ci est copiée.
- Sur cette page figure un tracker (qui a pour but initial de compter le nombre de vues, faire différentes statistiques, etc.).
- Le tracker a donc récupéré à un moment donné l’IP utilisé par celui qui a copié l’article.
- En demandant l’accès aux informations, l’équipe de la SGDSN peut donc récupérer cette adresse.
Plus d’informations dans le rapport officiel de la SGDSN
VolWeb#
VolWeb, une plateforme open-source d’analyse forensique de la mémoire
Présentation de VolWeb#
- VolWeb est un front web pour l’outil Volatility.
- Il permet également l’analyse de dump mémoire stockés sur un serveur distant.
- Il ajoute la possibilité d’intégrer une base de CTI avec un connecteur pour faire ressortir d’éventuels marqueurs dans les analyses.
- Simplification de la gestion des analyses : une analyse sera associée à un bucket S3.
- Enfin, l’outil est multithreadé.
Pour plus d’informations, consultez les slides de la présentation.
Advanced Forensic#
Récupération avancée en systèmes de fichiers exFAT et NTFS
- Utilisation du principe de Carvin.
Pour plus d’informations, consultez les slides de la présentation.
CHU de Brest - DFIR Invest#
Code Bleu DFIR : Chirurgie exploratrice de la cyberattaque du CHU de Brest
Détection initiale#
- 20h49 : Signalement par l’ANSSI de traffic suspect (communication entre un C2 et un beacon Cobalt Strike).
- 22h09 : L’ensemble des communications sont suspendues préventivement pour éviter une escalade rapide de l’infection.
- Après une rapide analyse, les données ne sont pas chiffrées sur les serveurs.
- L’Active Directory n’est pas directement impacté, aucun compte suspect n’a été créé, pas de compromission globale du SI.
- Identification du patient 0 : malheureusement pas sur site lors de cette détection, il a donc fallu faire sans dans un premier temps.
Patient 0#
- En accord avec le budget en place à l’époque de l’incident, les médecins venaient avec leurs ordinateurs perso sur site (BYOD), et se connectaient aux applications métiers via une ferme RDS.
- C’est un de ces PC qui a été compromis via un stealer.
- Aucune trace de revente sur les forums des identifiants concernés n’a été identifiée.
Réponse à l’incident#
- Le prestataire de Réponse à Incident Lexfo est dépêché sur place.
- Mise en place d’une stack Elastic (Elasticsearch, Kibana, Winlogbeat, …) pour l’ingestion et le traitement des différentes logs récupérées.
- Chacune des connexions a été espacée de quelques jours à chaque fois.
Première connexion des attaquants#
- Reconnaissance et tentative d’élévation de privilèges via PrintNightmare (patché), via Zerologon, puis finalement Rubeus, sans succès apparent.
- Après test par Lexfo, les serveurs étaient vulnérables, mais les attaquants n’ont pas su l’exploiter. L’outil utilisé attendait un argument et aucun n’a été renseigné par l’attaquant.
- Plusieurs scripts et fichiers textes utilisés lors de ces tentatives ont pu être rattachés au groupe Blackcat.
Seconde connexion des attaquants#
- Pivot sur un second serveur.
- Tentative d’élévation de privilège similaire à la première, toujours sans succès.
Troisième connexion des attaquants#
- Utilisation cette fois-ci de Cobalt Strike (installation d’un beacon), utilisation de Bloodhound pour faire une cartographie de l’AD, et nouvel essai d’élévation de privilège avec Zerologon.
- De même que pour Rubeus, la tentative d’exploitation de Zerologon a échoué.
- Le beacon Cobalt Strike sera détecté par l’EDR du CHU et les communications avec le C2 sont celles qui ont alerté l’ANSSI, ce qui a mené au déclenchement de l’alerte initiale.
- Les attaquants ont tenté de brute-forcer des comptes locaux sur les serveurs RDP, sans succès.
Des IOC liés à cette attaque peuvent être trouvés dans le rapport FIN12 de l’ANSSI.
Apple sysdiagnose#
Apple sysdiagnose pour l’analyse inforensique iOS, Amel Khamoum, Jérôme Rouaix et Davy Douhine
Plusieurs pistes de recherche d’IOC :
- L’analyse de flux réseau (via les backups iTunes).
- L’analyse des données stockées sous forme de fichier SQLite.
Plusieurs projets existent en parallèle :
- Tinycheck (Kaspersky).
- MVT (Amnesty International).
Les logs extraites à l’aide de sysdiagnose ne sont pertinentes que si elles sont exploitées à l’aide de bons outils :
Pour plus d’informations, consultez les slides de la présentation.
GW Forensic#
GW Forensic : Investigation numérique sur Google Workspace, Arnaud L’Hutereau
Google Workspace est présent dans le framework MITRE.
Il existe plusieurs règles SIGMA (Github).
Présentation d’un use case “Password Reset”#
Utilisation de l’outil GW Forensic pour la collecte et l’exploitation des logs :
- Compte avec le rôle “reporting”.
- Vérification des adresses IP de connexions.
- Vérification de la présence de scripts dans Google Apps Scripts (Code as a Service by Google).
- Récupération et analyse du script.
Il est possible d’indexer les events dans un OpenSearch/Elasticsearch.
Pour plus d’informations, consultez les slides de la présentation.
The (Virtual) Office#
The (Virtual) Office
Qu’est-ce qu’un virtual office ?#
Un virtual office est :
- Un espace de travail flexible.
- La mise à disposition d’adresse mail et de numéro de téléphone.
- La mise à disposition de mobilier.
- Peu cher.
Pourquoi utiliser un virtual office ?#
Les virtual offices sont pratiques pour impressionner ses clients et montrer son sérieux. Cependant, ils peuvent également être utilisés pour créer des arnaques :
- “Money laundering” : embellir l’apparence d’un business pas très clean à la base.
- Créer des entreprises fantômes, fictives ou qui ne servent qu’à couvrir des activités illicites.
- Spam / Phishing.
- Marketplace fraud / dropshipping.
Comment détecter ces arnaques ?#
Pour détecter ces arnaques, il est possible de :
- Vérifier la cohérence des informations présentes sur le site, les statuts de l’entreprise ainsi que l’adresse renseignée.
- “Vérifier les patrons de transaction étranges” : domiciliation des comptes dans des juridictions où il est peu probable de revoir son argent en cas d’escroquerie, des transactions importantes et fréquentes.
- Vérifier les antécédents : essayer de relier à de possibles fraudes passées.
- Vérifier les avis en ligne.
- Une description d’entreprise volontairement vague.
Il est important de noter que beaucoup d’entreprises légitimes utilisent ces “virtual offices” pour de bonnes raisons.
Comment les attaquants mènent-ils leurs activités frauduleuses ?#
Pour mener leurs activités frauduleuses, les attaquants utilisent des hébergeurs “bulletproof” tels que :
- Alex Host.
- DmzHost.
Ces hébergeurs ont la réputation d’ignorer les DMCA et de fermer les yeux sur les activités illicites de leurs clients.
Des virtual offices proposent des services clé en main de “création d’entreprise” comme par exemple companyhouse[.]co[.]uk.
Pour la création anonyme de site web, des services tels que njal[.]la répondent également présent. Il est à noter que ce provider est utilisé par des APT, des groupes de ransomware, des scammers, pour l’hébergement d’infrastructure liées à des stealers ou des botnets.
Retex Forensic#
Retour d’expérience - Scénario forensic peu commun, Néstor Hernandez De La Torre et Valère Champion
- Retour sur une réponse à incident après une escroquerie de type “FoVi” (Faux virement)
- Les analystes ont dû comprendre comment les attaquants ont contourné le MFA physique (Yubi key) nécessaire à la réalisation des virements, dont le seul possesseur est le PDG de l’entreprise.
Problèmes rencontrés#
- Impossibilité pour les analystes de travailler à distance selon leurs procédures habituelles (pas de possibilité de mettre en place une machine de rebond chez le client)
- L’hébergeur du client s’est montré peu collaboratif et n’a pas souhaité partager d’informations avec les analystes
- Aucune trace flagrante de compromission, ni du patient 0
- L’équipe d’analyste en charge de l’investigation a donc utilisé un logiciel de prise en main à distance pour interagir avec le réseau du client
- L’attaquant a dissimulé ses traces avec des scripts de suppression de logs
Détection et investigation#
- La détection s’est faite par des traces présentes sur le réseau
- Il s’est avéré que la clé de validation du MFA physique était branchée en permanence au PC du PDG
- L’attaquant se connectait en RDP avec les comptes des utilisateurs, ce qui les déconnectait de leurs sessions
- Utilisation de la caméra pour savoir quand est-ce que les PC étaient inutilisés (et donc en prendre le contrôle à distance)
- L’utilisation d’un RAT (Remote Access Trojan) plutôt que d’un logiciel de prise en main à distance signé et non détecté par les outils de détection a permis aux attaquants d’obtenir un score sur la productivité de chaque employé, d’obtenir la liste des mails, de voir l’écran en temps réel, etc.
- Le logiciel comptable utilisé par l’entreprise n’est pas facile à prendre en main, les attaquants avaient donc des connaissances dans le milieu ou se sont formés sur le logiciel en question
Récapitulatif de l’attaque#
- À chaque fois qu’ils pivotaient sur une nouvelle machine, ils utilisaient un script effaçant l’eventviewer
- La reconnaissance s’est faite via l’envoi de packets ICMP pour trouver les IP des machines connectées
- L’authentification s’est faite via du bruteforce SMB
- La faille Bluekeep a été utilisée pour élever ses privilèges
- Les attaquants ont pivoté sur le contrôleur de domaine via une RCE
- Ils ont ensuite installé un logiciel de contrôle à distance sur le PC du CEO et ont effectué 2 virements de quelques dizaines d’euros, sans doute pour tester (ce sont ces virements qui ont déclenché la réponse à incident)
- Ils ont profité de leur accès pour lire l’intégralité des mails du CEO, ce qui leur a permis d’être informé de l’avancée de l’enquête les concernant en temps réel
- Peu avant que les analystes ne découvrent l’entièreté des preuves, ils ont cette fois effectué un virement de plusieurs dizaines de milliers d’euros
Latest DFIR Invest - Linux rootkit & ADCS exploit#
From using Linux rootkits to exploiting ADCS, how far is a threat actor willing to go for free shipping?, Jean Marsault et Léo Fernand
- Réponse à incident débutée après la détection de services BTOBTO sur plusieurs serveurs, dont des domaines contrôleurs.
- Le ransomware n’était pas encore déployé.
- L’équipe DFIR a déployé du vélociraptor sur l’ensemble des serveurs concernés.
Reconstitution de l’attaque#
- Accès initial via un serveur Ivanti.
- Vulnérabilité exploitée pour élever les privilèges sur le serveur et récupérer des identifiants.
- Authentification sur les ESXI via la réutilisation de ces identifiants.
- Élévation de privilèges via le serveur d’impression.
- Utilisation d’un rootkit Linux userland “opensource” pour la persistance (non obfusqué) (Github).
- Utilisation d’une vulnérabilité dans Adobe Reader pour Side Loader une DLL sur les postes utilisateurs.
- Utilisation d’un tenant Azure malveillant pour interagir avec les endpoints infectés.
- Les commandes étaient rédigées dans les brouillons de boîtes mails Outlook créées depuis le tenant malveillant (dead drop de commande).
- OneDrive était utilisé pour l’upload de fichiers.
- Le retour d’Internet n’a été possible qu’après le blocage de ce tenant malveillant.
Plus d’un an après, le client n’est pas complètement remis de cette réponse à incident, alors que le ransomware n’a pas été déployé.
Source de l’image de fond & de l’icone : Sherc88