GLIMPS parmi les Lauréats du Grand Défi Cyber

GLIMPS — Mon, 29 Nov 2021 13:04:00 +0000

GLIMPS parmi les Lauréats du Grand Défi Cyber.

Le Grand Cyber Challenge fait partie du plan d’un milliard d’euros visant à renforcer la cybersécurité du pays d’ici 2025. L’objectif du gouvernement est clair : rendre nos systèmes durablement résilients aux cyber-attaques.

Chez GLIMPS, nous partageons cet objectif ! Depuis de nombreuses années, nous constatons un déséquilibre entre les moyens déployés pour générer une attaque et les moyens mis en place pour se défendre. Ce déséquilibre s’accroît au profit des cybercriminels en raison de la généralisation des usages numériques, de la convergence des réseaux et de l’arrivée de nouvelles technologies connectées dans tous les domaines. Le nombre de vulnérabilités exploitables et de vecteurs d’attaque est en constante augmentation. Les attaques par ransomware en France ont plus que triplé en 2020, l’ANSSI a recueilli 192 signalements en 2020 contre 54 l’année précédente.

C’est dans ce contexte particulièrement préoccupant que nous avons souhaité agir rapidement avec les autres acteurs du Grand Cyber Challenge et les différents organismes étatiques afin de proposer des solutions innovantes et automatisées au bénéfice des entreprises. Notre ambition est plus que jamais d’actualité : » Ensemble, faire que la défense soit plus forte que l’attaque « .

Depuis le début de nos activités il y a 18 mois, nous avons placé l’intelligence artificielle au cœur de notre technologie de conceptualisation. Conscients des opportunités offertes par les nouvelles techniques d’IA, notamment l’apprentissage automatique, nous avons investi dans la recherche et le développement. Cela nous a permis d’accélérer nos travaux dans ce domaine et de réaliser des progrès significatifs tant dans l’analyse automatisée des logiciels (en amont des attaques) que dans la détection d’attaques même inconnues (en aval). Cette approche innovante basée sur le principe du » concept code « , nous permet d’augmenter les capacités de détection et de réaction en temps réel sur tout système informatique : IT, OT, IOT, smartphone, tablette, etc.

Au-delà des enjeux technologiques, l’automatisation de la cybersécurité apportera un nouveau souffle aux entreprises qui font face à une pénurie de talents qui se répète d’année en année et qui peinent à fidéliser leur personnel. Conscients des enjeux et de ce manque à combler, nous avons intégré cette problématique dans la conception de nos outils, afin de rendre les produits avancés accessibles aux utilisateurs moins expérimentés.

Nous sommes très fiers d’être lauréat du Grand Défi Cyber, pour une jeune entreprise comme la nôtre c’est une reconnaissance de notre technologie et de notre savoir-faire en matière d’innovation de rupture. Cela nous donne l’opportunité de représenter l’excellence française dans ce domaine au niveau européen et international. Les subventions permettront de soutenir la R&D de l’entreprise et d’accélérer le développement de nouveaux produits.

Publication C&esar : Automatisation de l’analyse de binaires

GLIMPS — Mon, 29 Nov 2021 10:48:03 +0000

Automatisation de l'analyse de binaires : de la collecte source ouverte à la Threat Intelligence

Par Frédéric Grelot, Sébastien Larinier et Marie Salmon

Abstract

De nombreuses sources ouvertes de binaires, et particulièrement de malware ont émergé dans le paysage ces dernières années. Et leur qualité n’a rien à envier aux sources commerciales comme le soulignait Thibaut Binetruy (HMiser, CERT Société Generale, 2020), « Integrating operational threat intel in your defense mechanisms doesn’t mean buying Threat Intel. You can start by using the [mass] of open source indicators available for free. ». Certaines sont mises à disposition par des sources officielles (Abuse.ch, alimenté entre autre par le CERT national Suisse), d’autres de manières plus obscures, voire anonymement (VirusShare, Vx-underground, etc.).

Le panorama que nous en avons dressé souligne la grande disparité qualitative et quantitative de ces sources. Il nous a fallu prendre en compte cette diversité dans le cadre de nos travaux de recherche, en concevant une plateforme dédiée nous permettant d’alimenter nos produits d’analyses de binaires, et ainsi rendre possible l’analyse quotidienne des corrélations inter- et intra-familles de malwares à grande échelle.

Ces travaux permettent une application sur des cas concrets tels que Babuk, Ryuk et Conti. Nous avons ainsi pu mettre en évidence les liens sur ces familles grâce à l’identification immédiate de corrélations, complétée par une analyse manuelle, qui a ainsi permis de confirmer précisément la généalogie des échantillon.

Si vous souhaitez en savoir plus,
téléchargez l'intégralité de la publication :

Comparaison des ransomware utilisés contre Enel et Honda

François Plumerault — Wed, 12 Aug 2020 13:03:37 +0000

Comparaison des ransomware utilisés contre Enel et Honda.

François a effectué un stage chez nous entre avril et août. Il a notamment travaillé au développement d’un outil qui extrait les symboles d’un programme écrit en Go. Voici un article qui présente une application de son travail pour l’analyse et la comparaison de ransomware.

Analyse d'EKANS

EKANS (SNAKE à l’envers) est un nouveau ransomware programmé en langage Go apparu en décembre 2019, il a notamment affecté Honda et Enel. La particularité de ce dernier, celle qui a suscité de l’intérêt, ne réside pas dans sa méthode de propagation mais plutôt dans sa volonté de « tuer » des systèmes de contrôle industriel. Cette particularité a été notamment étudiée et expliquée par Dragos.

La technologie GLIMPS permet de détecter des similarités entre binaires partageant du code source, même compilés différemment ou pour des architectures différentes. De plus, j’ai, au cours de mon stage dans l’entreprise, développé un outil permettant d’extraire les symboles du runtime d’exécutable Go.

Deux malware avec des similarités identifiées, et écrits en Go… C’est donc un bon cas d’étude pour vérifier la pertinence des résultats et pour tester l’outil de récupération des symboles en situation réelle !

Cette analyse nous a ainsi permis de vérifier l’origine commune indiscutable des virus utilisés dans les attaques Honda et Enel.

Application de la technologie de conceptualisation de code de GLIMPS

GLIMPS a mis au point une technologie de conceptualisation de code permettant de comparer très efficacement des logiciels compilés entre eux, même s’ils ont subi des transformations lors des étapes de compilation, ou qu’ils ciblent des architectures différentes.
2 applications de cette technologie ont été développées : GLIMPS-Malware compare un fichier à une base de millions d’exemplaires de malware classés, de manière à identifier si un fichier est bienveillant ou malveillant, et s’il est malveillant, à caractériser l’origine probable de l’attaque.
GLIMPS-Audit facilite l’analyse fine d’un logiciel, légitime ou malware, en identifiant et documentant le code connu (bibliothèques sur étagères…) le constituant. Il permet également la comparaison logiciel à logiciel, ce que nous avons utilisé dans le cadre de cette analyse.

En passant les exemplaires provenant des attaques Honda et Enel dans GLIMPS-Malware, ils sont immédiatement détectés comme des fichiers malveillants et caractérisés comme des variantes du ransomware SNAKE. A priori, nous avons récupéré les bons fichiers !

Grâce à GLIMPS-Audit, nous avons ensuite comparé les 2 ransomware entre eux. Nous pouvons ainsi confirmer que, malgré les méthodes d’offuscation, les ransomware ayant ciblé Enel et Honda sont quasiment identiques et issus de la même origine : sur 4369 fonctions, 4230 sont ainsi identifiés de manière certaine, et 88 matchs supplémentaires ont une bonne probabilité d’être identiques. Il reste ainsi, sur les 4369 fonctions des 2 ransomware moins de 50 fonctions pour lesquelles la corrélation est moins immédiate.

La récupération des symboles runtime

Le langage Go est un langage de haut niveau possédant un garbage collector et un runtime capturant les erreurs d’exécutions (division par 0, buffers overflow, etc.). Le runtime de Go lorsqu’il détecte une erreur provoque une « panic » et affiche le détail de l’erreur. Par exemple :

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x460c1f]
goroutine 1 [running]:
main.main()
/tmp/sandbox311401280/prog.go:18 +0x1f
exit status 2

Ce détail contient le chemin des fichiers sources (/tmp/sandbox311401280/prog.go), le nom des fonctions (main.main), les numéros de lignes (18), l’adresse des fonctions (pc=0x460c1f et +0x1f donc l’adresse de la fonction est 0x460c00), etc… Ce sont ces mêmes symboles que nous récupérons.

Une fois les symboles des EKANS appliqués au code désassemblé, d’importantes similitudes sautent aux yeux. En effet, presque toute les fonctions du paquet main (paquet contenant la fonction main en Go) ont vu leur nom ainsi que le chemin des fichiers les contenants offusqué, transformé en une chaîne aléatoire. Notons, que le nom de la fonction main du paquet main, main.main (main_main dans IDA) n’a pas pu être changée puisqu’elle est nécessaire à la compilation (c’est le point d’entrée du programme) et que leurs modifications ont lieu avant cette dernière. De plus, le numéro de ligne de plusieurs fonctions correspond, par exemple la fonction main est à la ligne 339 dans les deux ransomwares. Mais encore, l’offuscation du chemin des fichiers est partielle et montre d’importants points communs, comme nous pouvons le voir dans l’exemple ci-dessous :

« Enel » : [{
« Name »: »main.cempcamllplldijidcni »,
« File »: »C:/Users/Admin3/go/src/nmhgfmidblhkfacdajkc/pbopnijdlnfbnimbiham.go »,
« Line »:254
}]
« Honda » : [{
« Name »: »main.jfplojgoheneeggeidee »,
« File »: »C:/Users/Admin3/go/src/cgillndadlcobliljlfo/nknejkdfponfiknchiad.go »,
« Line »:254
}]

Les fonctions sont situées à la même ligne et sont dans le même paquet (main), sont situées dans des fichiers dont les chemins commencent de la même façon et sont offusqués de la même façon. Nous pouvons dès lors considérer sans prendre trop de risque que ce sont les mêmes fonctions. Ce qui était déjà confirmé par les résultats de GLIMPS-Audit et qu’on voit également par une analyse plus précise avec un logiciel de rétro-ingénierie (IDA). Ces observations permettent ainsi dans de nombreux cas de venir confirmer la pertinence des résultats obtenus avec GLIMPS-Audit.

Une autre importante similitude visible depuis les symboles concerne les noms des fonctions importés. En effet, pour les deux ransomwares, les mêmes fonctions des mêmes paquets sont importées.

La recherche des fonctions pour tuer les processus

Une fois les symboles précédemment récupérés chargés dans un logiciel de rétro-ingénierie nous avons décidé de chercher le mécanisme utilisé par les ransomwares pour tuer des processus.

Pour cela nous avons recherché les différentes fonctions Go permettant de fermer un processus. Malheureusement, sa bibliothèque standard ne fournit pas de fonction effectuant une telle tâche indépendamment de l’OS. Nous avons donc regardé du côté des bibliothèques Windows (puisque les ransomwares sont des PE permettant de tuer un processus dont l’on connaît le nom ainsi que des chaînes de caractères des noms des exécutables habituellement visés par les ransomwares. Ces exécutables sont, entre autres, les antivirus (par exemple, kavshell.exe) et les navigateurs (par exemple, firefox.exe). Seul la fonction TerminateProcess a été trouvé. En remontant l’origine de ses arguments nous avons compris que les autres fonctions, notamment celles permettant de lister les processus, étaient importées dynamiquement. Une fois la fonction permettant d’effectuer des importations dynamiques trouvées NewLazyDll nous avons réalisé que si nous ne trouvions pas de noms de fonction ou de processus c’était parce que toutes les chaînes utilisées par les deux ransomwares sont chiffrées. En fait, chacune des assignations de chaîne a été remplacé par un appel vers une fonction littérale qui utilise deux autres chaines afin d’obtenir et de retourner la chaîne d’origine. Par exemple,

print(« Hello world\n »);
//devient
print(func () string {
var string1 = « \x21\x0d\xc3\xb5\x79\x7c\x2d\x9e\x38\x92\xb2\x99 »
var string2 = « \x69\x6a\xab\xd7\xee\xa6\x4e\xc3\x3a\xc8\xa2\xa5 »
var slice1 = []byte(string1)
var slice2 = []byte(string2)
var size = len(slice1)
var sliceRes = make([]byte, size)
for i := 0; i < size; i++ {
sliceRes[i] = byte((int(slice1[i]) + i*2) ^ int(slice2[i]))
}
return string(sliceRes)/*la valeur de retour est « Hello world\n »*/
}())

Cette méthode d’offuscation cause la création de plus de 1 000 fonctions littérales presque identiques et double l’espace pris par les chaînes de caractères dans la section data. Le chiffrement étant relativement simple la fonction en langage Go suivante permet de déchiffrer la chaîne d’origine à partir des deux nouvelles chaines correspondantes :

func decode(a, b string) string{
var slice1 = []byte(a)
var slice2 = []byte(b)
var size = len(slice1)
var sliceRes = make([]byte, size)
for i := 0; i < size; i++ {
sliceRes[i] = byte((int(slice1[i]) + i*2) ^ int(slice2[i]))
}
return string(sliceRes)
}

Une fois les chaînes déchiffrées nous avons trouvé, pour chacun des ransomwares les noms des fonctions importées dynamiquement et le nom des processus tués par le ransomwares. La totalité des chaînes déchiffrées est par exemple présente ici pour Enel. Nous observons aussi que la très grande majorité des chaînes déchiffrées obtenues sont présentes dans chacun des deux ransomwares.

La procédure de chiffrement

Nous avons ensuite cherché à comprendre le mécanisme de chiffrement du programme. Pour cela nous sommes partis des bibliothèques de chiffrement Go et avons regardé lesquelles sont utilisées. La première trouvée fut l’AES-256. Après avoir étudié le cheminement des entrées et des sorties de la fonction de chiffrement AES et des appels de fonctions documentées environnant nous avons pu déterminer la procédure de chiffrement, encore une fois la même pour les deux ransomwares. Tout d’abord un couple de clé publique, clé privée qui servira pour effectuer un chiffrement (et plus tard un déchiffrement) RSA est obtenue. La clé publique est écrite en dure dans les sources du programme tandis que la clé privée est conservée par les concepteurs du ransomware. Ainsi, seule la clé publique est présente dans l’exécutable. Précisons, que les ransomwares ayant ciblé Honda et Enel ont des clés publiques différentes. La seconde étape est le listage des fichiers. Les ransomwares parallélisent leur calcul afin de chiffrer plusieurs fichiers simultanément. Ensuite, pour chacun des fichiers trouvés, une clé de 256-bits est générée aléatoirement. Cette dernière est utilisée afin d’effectuer un chiffrement AES-256 sur le fichier. Elle est ensuite chiffrée avec un RSA utilisant la clé publique précédemment évoquée. Enfin, le résultat du RSA (la clé de l’AES chiffrée) est formaté avant d’être écrite à la fin du fichier chiffré. Rappelons, que puisque le RSA est un chiffrement asymétrique, c’est avec la clé privée que possède le concepteur du ransomware uniquement que l’on pourra déchiffrer la clé de l’AES présente à la fin du fichier et donc déchiffrer le fichier. Vous trouverez ci-dessous un schéma détaillant la procédure de chiffrement et de déchiffrement du ransomware.

Conclusion

Ainsi, nous pouvons dire que les ransomwares sont bien deux versions du même programme. Glimps Audit a détecté avec succès leurs importantes similitudes. De plus, l’outil de récupération des symboles Go s’est avéré efficace et a fortement facilité le travail de rétro-conception.

Aide au reverse-engineering avec GLIMPS-Audit

GLIMPS — Mon, 10 Aug 2020 21:15:30 +0000

Aide au reverse-engineering avec GLIMPS-Audit

Quoi de plus fastidieux, lorsqu’on débute la rétroconception d’un binaire, que ce soit pour une recherche de vulnérabilités ou une analyse de malware par exemple, de devoir commencer par retrouver le code connu ?

Dans certains firmwares, où il n’y a pas de symboles de debug et l’OS est propriétaire, on peut passer plusieurs mois simplement pour identifier les fonctions essentielles (memcpy, print to uart…).

GLIMPS-Audit permet de passer cette étape en quelques secondes. Un binaire poussé est immédiatement comparé à des millions de bibliothèques et autres binaires que nous avons rassemblé et pour lesquels nous avons les symboles. En quelques secondes, nous voyons quel code est inclu dans le binaire, et nous pouvons rapatrier la documentation vers notre nouvelle analyse.

Nous vous proposons de débuter la rétroconception d’un exécutable. Vous pouvez le télécharger ici (le binaire fait 35M… et ne contient pas de malware).

Dans notre exemple, nous avons un elf de 14000 fonctions, dont 2 seulement identifiées par IDA : « _init_proc » et « _term_proc ». En temps normal, on se dirait que la journée va être longue…

La capture d’écran ci-dessous montre la situation :

Passons maintenant le binaire dans GLIMPS-Audit. On obtient la liste de bibliothèques proches suivantes :

libgcrypt.so.20.2.4
libsqlite3.so.0.8.6
glxtrace.so
RSQLite.so
libsqlcipher.so.0.8.6
libxml2.so.2.9.4
egltrace.so
libssl.so.1.1
libgnutls.so.30.23.2
libc-2.28.so
libinproctrace.so
libgcrypt.so.20.2.5
libgcrypt.so.20.1.6
libicuuc.so.63.2
libcrypto.so.1.1
libcrypto.so.1.0.0
libstdc++.so.6.0.25
libaria2.so.0.0.0

On en sait déjà un peu plus sur notre binaire ! Ainsi, la libc est présente, de la crypto, du xml, du sqlite, et la libaria2.

On génère donc un idc pour notre binaire. Vous pouvez télécharger le résultat ici. En appliquant le script, 5592 fonctions sont immédiatement renommées parmi nos 14000 fonctions. Bien sûr, il vous reste encore du travail, mais avec des fonctions appelées déjà nommées, comme on peut le voir ci-dessous, ce sera plus facile. Avouez que vous avez gagné quelques semaines !

Protection de la messagerie avec GLIMPS Malware

GLIMPS — Mon, 10 Aug 2020 18:07:18 +0000

Protection de la messagerie avec GLIMPS Malware.

Depuis quelques semaines, suite à la crise du covid-19 et à la généralisation du télétravail, on a pu noter une très forte recrudescence des attaques par phishing, comme on peut le voir par exemple sur le site du gouvernement cybermalveillance ou cet article du monde.

Concernant le Coronavirus, nous ne pouvons pas faire grand chose à part rester sagement chez soi derrière nos écrans de pc. Les attaques informatiques par contre, c’est notre métier :-).

GLIMPS avait jusque-là laissé de côté le phishing : ces attaques sont la plupart du temps peu complexes, et il existe déjà de nombreuses solutions pour s’en prémunir.
Mais nous sommes bien obligés de constater dans l’actualité que le phishing fait actuellement beaucoup de dégâts, et que leur détection peut/doit donc être améliorée.

Adaptation de GLIMPS-Malware au phishing

Nous avons profité du week-end de Pâques pour monter une plateforme qui adapte GLIMPS-Malware pour la détection d’attaques par phishing.
L’idée est d’adapter et intégrer GLIMPS-Malware dans un environement comme celui-ci :

Commençons par les présentations : CSE-Assemblyline est une plateforme de détection et d’analyse de malwares développée par le Centre pour la cybersécurité canadien et mis en opensource fin 2017.
Ses grandes forces sont :

Un orchestrateur très performant qui permet d’ajuster la charge et de la distribuer sur plusieurs serveurs de manière transparente,
De nombreux plugins présents par défaut : antivirus, modules yaras, extracteurs…
La possibilité d’ajouter ses propres plugins facilement, tout en les intégrant avec les plugins existants, ce dont nous allons parler ici.

C’est un outil réellement performant, c’est la raison pour laquelle chez GLIMPS, nous l’utilisons beaucoup ! La plateforme est intégrée dans GLIMPS-Malware, mais une autre instance nous a également permis d’analyser et catégoriser des millions de malwares pour construire nos datasets. Nous en avons également dérivé une version pour construire en masse nos bases de concepts-codes de bibliothèques pour le produit GLIMPS-Audit.

La version 4 (actuellement en Beta) apporte par ailleurs de nombreux changements indispensables. Notamment, chaque plugin s’exécute désormais dans un docker, et l’ancienne base de données Riak qui nous posait quelques soucis a été remplacée par Elasticsearch, beaucoup plus facile à utiliser.

Nous avons donc encore une fois décidé d’utiliser AssemblyLine comme base d’une plateforme anti-phishing.

Le principe : un connecteur dans le serveur mail soumet chaque mail reçu à AssemblyLine. Le mail est analysé, et sont notamment extraites :

les pièces jointes,
les URIs.

AssemblyLine fonctionne comme un jeu de poupées russes : tout est récursif. Les pièces jointes sont ainsi elles-mêmes analysées : elles sont transmises à GLIMPS-Malware, mais également aux modules standards d’Assemblyline (antivirus, frankenstrings, etc). Ainsi, si quelqu’un transmet dans un mail une pièce jointe sous forme d’un zip contenant des mails contenant eux mêmes des URIs malveillantes… Ces URIs seront détectées et analysées. De même si une pièce jointe est un Excel contenant des liens…

Il manquait 2 plugins à la Beta d’AssemblyLinev4 pour monter une telle plateforme :

Un nouveau plugin de parsing de mails pour ALv4. Godfried Meesters (lien Github) en a proposé un sur le forum d’AssemblyLine juste avant que je fasse le mien, j’ai pu le réutiliser avec des modifications mineures (insertion des URIs dans des tags)
Un plugin qui vérifie l’ensemble des URIs détectées par rapport à une blacklist mise à jour très régulièrement.

Et voilà ! Sur les exemples testés, cela fonctionne parfaitement ! La plateforme détecte des mails contenant des liens de phishing, que ce soit dans le corps du mail ou dans des pièces jointes Excel par exemple. Tous les exécutables sont également analysés pour évaluer le caractère malveillant potentiel.

Dans notre exemple, chaque fichier est ainsi passé au crible des modules ci-dessous :

Nom	Type de fichiers	Description
emlParser	document/email\|code/html\|text	analyse les mails, extrait les URIs et les pièces jointes et formate la sortie pour une belle visualisation
Extract	*	Extrait les fichiers d'un grand nombre de types conteneurs (zip...)
Yara	*	Applique les règles yara...
GLIMPS-Malware	executable	GLIMPS-Malware génère du concept-code à partir d'un exécutable et le compare à une base de malwares classifiés pour identifier et caractériser les malwares.
Url-checker	tags	analyse toutes les URIs identifiées lors de l'analyse pour détecter des liens de type phishing
Unpacker	executable	Extrait les exécutables packés. GLIMPS a développé une version plus complète dans GLIMPS-Malware
ClamAV	*	Antivirus ClamAV
PDFId	document/pdf	Extrait les métadonnées des PDFs
PeePdf	(document/email\|code/html\|text)	Extrait et tente de désobfuscer le code JavaScript présent dans les PDFs
Characterize	*	Calcule l'entropy du fichier par partition.
PEFile	executable/windows
Beaver	*	compare les hashs à la base CCIRC
ViperMonkey	(document/email\|code/html\|text)	Analyse les macros VBA

Bien sûr, GLIMPS-Malware peut également être utilisé de façon bien plus étendue au sein de votre entreprise, notamment :

connecté au proxy web pour analyser les fichiers téléchargés,
comme guichet centralisé d’analyse de fichiers,
comme outil à destination du SOC de l’entreprise pour effectuer les levées de doute.

Le schéma ci-dessous reprend ces possibilités pour votre entreprise :

En conclusion, le code du plugin url-checker sera disponible d’ici fin Avril sur le Github GLIMPS.

N’hésitez pas à nous faire part de votre intérêt pour cette solution !

Détection et caractérisation de Malware avec GLIMPS Malware

GLIMPS — Mon, 10 Aug 2020 18:01:13 +0000

Détection et caractérisation de Malware avec GLIMPS Malware.

Comme pour le cas d’usage Threat-Intel, nous avons repris notre code source mirai, avec cette fois quelques modifications :

Afin d’être plus discret, nous avons enlevé les chaînes de caractères les plus flagrantes,
Nous n’avons pas utilisé le script de compilation fourni sur Github, à base de gcc. A la place, nous avons réécrit notre propre script utilisant clang.

En tout, l’opération n’a pas pris plus de 30 minutes.

Nous avons soumis à VirusTotal le binaire ainsi obtenu. Aucun antivirus n’a détecté ce nouveau sample de mirai.

Nous avons l’avons ensuite soumis à GLIMPS-Malware. Le fichier a immédiatement été détecté comme un malware, avec une bonne probabilité qu’il soit de la famille mirai.

A l’époque où ce test a été réalisé, nous n’avions jamais mis de binaires compilés en clang dans notre base d’apprentissage (il s’agit d’un effort en cours). Malgré tout, notre technologie de conceptualisation est parvenue à en extraire le sens avec exactitude. On voit d’ailleurs dans les résultats obtenus que le sample le plus proche identifié est pour une architecture ARM, tandis que nous avions poussé un binaire de type amd_64. Notre technologie s’abstrait de l’architecture cible.

Ce que nous avons fait avec mirai, c’est exactement ce que font les grands groupes d’attaquants avant de lancer une nouvelle campagne ou une attaque ciblée : ils ajustent la chaîne de production du malware pour, en réutilisant le maximum de code source parmi leur Propriété Intellectuelle (afin de réduire au maximum le coût de l’attaque), générer un code compilé qui soit suffisamment nouveau pour contourner les antivirus et chaînes de détection actuelles.

Grâce à GLIMPS-Malware, vous serez en mesure de détecter et stopper ces nouvelles attaques. Vous protégez non seulement votre Système d’Information classique, mais également votre Système Industriel vos Systèmes de Production ou les Systèmes Embarqués que vous concevez.

Contactez-nous pour plus de renseignement, une démonstration ou la plannification d’une évaluation.

Threat-Intel avec la technologie GLIMPS

GLIMPS — Mon, 10 Aug 2020 17:52:11 +0000

Threat-Intel avec la technologie GLIMPS.

Vous avez sans doute déjà entendu parler de Mirai : il s’agit d’un botnet très connu et répandu, dont les sources sont disponibles publiquement sur GitHub. Il en existe des versions pour de nombreuses architectures, et de multiples variantes.

Cela en fait donc un très bon cas d’espèce pour GLIMPS : nous pouvons le recompiler nous-mêmes pour différentes architectures, compilateurs et options de compilation, afin de mesurer la performance de notre technologie.

Ci-dessous, vous pouvez voir le résultat obtenu lors de l’analyse d’un fichier. Il s’agissait d’une instance de Mirai pour amd64, compilée avec gcc.

En observant les résultats, on peut voir que cet échantillon de Mirai était déjà présent dans la base (sha256 identique remonté en premier). Notre échantillon a bien 100% de corrélation avec lui-même, c’est plutôt rassurant !

Mais il est également corrélé avec d’autres échantillons de mirai, qui bien que différents (les hash du code sont différents du fichier analysé) remontent tout de même avec 100% de corrélation. En effet, la technologie GLIMPS permet de s’affranchir des artefacts induits par le processus de compilation. Du point de vue du concept-code, on voit que les 2 échantillons sont identiques. Notre binaire aurait ainsi été détecté comme un malware de type mirai même si le premier échantillon n’avait pas été présent dans la base.

C’est l’un des intérêts de GLIMPS-Malware : inutile de posséder les signatures de chaque variante d’un malware pour les détecter : quelques versions suffiront largement pour détecter l’ensemble des variantes, y compris celles qui n’ont pas encore été créées ou détectées. Vous pouvoir d’ailleurs voir notre Use Case Détection et caractérisation d’un malware inconnu à ce sujet.

Et le Threat-Intel dans tout cela ?

Premièrement, notre échantillon de Mirai a bien été détecté comme un exemplaire de la famille mirai… Mais ce qui est également très intéressant dans ce résultat, c’est qu’on voit également une autre famille apparaître : le taux de corrélation est bien entendu plus faible (15%), mais GLIMPS-Malware nous indique que Mirai est également proche d’exemplaires de la famille Bashlite.

En creusant un peu, on trouve des informations dans la littérature nous confirmant que Bashlite était l’ancêtre de Mirai. Il est donc logique que les 2 aient du code en commun, ce qui GLIMPS-Malware a détecté ! Nous avons voulu en avoir le coeur net… le temps de sortir notre logiciel de rétroconception préféré… GLIMPS-Audit bien sûr !!!

Analyse rapide par reverse-engineering… avec GLIMPS-Audit !

Notre échantillon Mirai ne possède aucun symbole de debug. Par contre, pour bashlite, l’attaquant avait oublié d’enlever les symboles de debug. Première étape, utiliser GLIMPS-Audit ! Nous allons ainsi pouvoir rapatrier la documentation de bashlite dans notre sample mirai.

En comparant nos 2 binaires, on trouve 25 associations dites « de confiance » :

Si on observe dans Ida une fonction au hasard, on voit que, même si dans le détail le code assembleur n’est pas identique, il s’agit bien du même code,et que les deux proviennent sans doute du même source d’origine (dans le cas précis de cette fonction que nous avons sélectionné parce qu’elle est particulièrement grande, ce qui permet à l’oeil humain de rapidement voir les similarités, les graphes sont même extrêmement proches !). Ici, une technique à base de hash aurait nécessairement échoué : dans une fonction de cette taille avec des versions de compilateurs différentes, il est quasiment impossible que toutes les instructions soient strictement identiques.

Dans le cas précis de Mirai dont une version des sources est disponible sur Github on peut même aller beaucoup plus loin : quel que soit le sample que l’on souhaite analyser, il est facile de rapatrier tous les symboles depuis la version publique en la compilant avec les symboles de debug.

Nous pourrions laisser cet exercice au lecteur… Mais ne vous inquiétez pas, GLIMPS-Malware le fait automatiquement pour vous !

Conclusion

Nous avons vu comment GLIMPS-Malware et GLIMPS-Audit pouvaient être utilisés efficacement en complémentarité dans une démarche de Threat-Intel.

Contactez-nous pour plus de renseignements, organiser une démonstration ou une évaluation !

GLIMPS-Malware

GLIMPS — Mon, 10 Aug 2020 17:45:53 +0000

La détection et caractérisation de nouvelles menaces, même sur vos systèmes industriels

Notre outil d’analyse de Malware s’appuie sur une technologie de détection de code, indépendante des options de compilation, de la chaîne de compilation utilisée et même de l’architecture (x86, ARM, PPC, MIPS…) ! Grâce à cela, nous sommes capables de détecter des menaces inconnues sur des systèmes non standards (IoT, caméras, automates…) car elles ont du code commun avec des souches connues sur un environnement plus classique.

Notre technologie étant également capable de détecter le code d’un binaire sous de multiples formes, elle peut détecter une menace qui cible spécifiquement votre entreprise même si elle a été modifiée pour échapper aux technologies de détection par signature.

La corrélation par concept code

En conceptualisant le code compilé, nous pouvons remonter à un niveau d’abstraction similaire à celui du code source, en s’abstrayant des modifications induites par la compilation, l’architecture cible, etc… Nous pouvons ainsi retrouver la présence de Propriété Intellectuelle d’un groupe d’attaquant dans un fichier, ce qui nous permet de détecter et caractériser immédiatement la menace.

Dans la figure suivante, un groupe d’attaquant, « APT 42 », possède un code « privé ». Une fois utilisé dans plusieurs malwares et plusieurs campagnes, il est très difficile de remonter à ce code commun. Grâce à notre technologie, nous transformons les différents malwares exploités par ce groupe en « Concept Code », et leurs caractéristiques propres étant indépendantes des chaînes de compilation et des architectures utilisées, nous sommes capables d’identifier la présence de code commun entre ces deux branches et d’affirmer que l’attaquant possède nécessairement un code source commun utilisé pour les produire : les deux sous-familles proviennent alors nécessairement de la même entité ! Bien sûr, auparavant, nous avons supprimé tout concept-code associé à du code public (runtimes, codes open-source…) que l’on peut retrouver dans de nombreux malwares.

Couplé à un orchestrateur performant

GLIMPS-Malware, ce n’est pas qu’une brique technologique ! Afin de pouvoir supporter les flux auxquels vous pouvez être confrontés, nous l’avons intégré dans un orchestrateur performant, grâce auquel nous avons déjà pu analyser des millions de fichiers. La capacité de la plateforme d’analyse est ainsi complètement ajustable à vos besoins, que vous souhaitiez analyser 10 binaires par jour ou les millions de fichiers de votre passerelle Internet. Par ailleurs, cela vous permet également de profiter de nombreux plugins supplémentaires : antivirus, plugins d’extraction et analyse de documents… Grâce à cela, vous disposez immédiatement d’un outil complet fournissant un rapport détaillé et performant de l’analyse d’un fichier et doté d’une capacité d’alerte automatique intégrable à votre solution SIEM.

Un gain de temps à chaque étape

Le tableau ci-dessous résume la valeur ajoutée de GLIMPS-Malware aux différentes étapes de détection et analyse d’un malware.

De nombreux Use Cases

GLIMPS-Malware trouve ainsi ses applications :

Comme solution de sécurité sur vos proxy mails ou web afin de détecter et bloquer des menaces.
Comme outil d’aide aux analystes de SOC afin d’identifier et caractériser finement les menaces, même sur des sytèmes embarqués des systèmes industriels ou de production,
Comme outil de Threat Intel pour aider à caractériser les malwares, comprendre les relations entre les groupes d’attaquants,
Comme serveur centralisé d’analyse de fichiers à l’usage de l’ensemble des employés de votre entreprise,

Contactez-nous dès maintenant pour intégrer GLIMPS-Malware dans votre solution de sécurité !

GLIMPS parmi les Lauréats du Grand Défi Cyber