Introduction

Dans cet article, je vais me plonger dans la détection de contrebande HTML, en suivant le processus d'ingénierie de détection que j'ai décrit dans mes deux derniers articles. Ce processus comprend la recherche, les tests et le développement de nouveaux concepts de détection. Contrairement à mes messages précédents, cette fois, nous allons observer, profiler et détecter de vrais logiciels malveillants QakBot dans le laboratoire. Avec cet article, j'espère montrer comment les ingénieurs de détection actuels et futurs peuvent aller au-delà des défis simulés de type CTF pour étudier et détecter les techniques d'attaque du monde réel, en les signalant pour notre SOC et en permettant à nos collègues de réponse aux incidents de neutraliser la menace.

Notre itinéraire

Après quelques informations générales et la définition de l'objectif, je montrerai comment nous pouvons exécuter le logiciel malveillant QakBot HTML Smuggling en laboratoire, en suivant son comportement dans Splunk. Ensuite, je vais séquencer les événements observables de cette attaque et identifier les points de détection utiles (que je considère comme des « éléments constitutifs », ou maillons de la chaîne d'attaque). J'introduirai également la corrélation (en particulier les règles de chaîne), un outil crucial dans votre boîte à outils de détection des menaces. Pour illustrer à quoi cela ressemble, je vais discuter et démontrer une capacité encore inédite de Sigma, appelée Sigma Correlations. Je conclurai en testant une nouvelle règle de chaîne contre 10 échantillons supplémentaires de logiciels malveillants QakBot HTML Smuggling pour voir comment il fonctionne.

Commençons!

Fond

Au début de mon parcours dans la cybersécurité, John Strand de Black Hills Information Security a dit quelque chose qui m'a marqué : "Il n'y a pas de journal "VOUS AVEZ ÉTÉ HACKÉ". Les journaux d'événements peuvent être déroutants et difficiles à lire, même lors d'une bonne journée. Il est difficile de tirer des informations utiles et exploitables des journaux ! Le défi nécessite parfois une analyse approfondie et des techniques spécialisées pour réussir.

J'ai eu cette leçon en tête tout au long de ma carrière dans la sécurité, et c'est dans cet esprit qu'il y a quelques mois, j'ai commencé à voir des tonnes de messages comme celui-ci de @pr0xylife :

J'aime la façon dont pr0xylife et leurs pairs résument ces attaques si succinctement, et je me suis retrouvé à répéter à voix haute la séquence des types de fichiers - presque comme une forme de poésie étrange !

Je voulais en savoir plus, mais je ne savais pas par où commencer. J'avais passé en revue d'excellentes recherches sur QakBot par l'équipe de Trellix, donc je connaissais un peu leurs techniques. (Si vous n'avez jamais entendu parler de QakBot, veuillez lire le rapport Trellix !) Lorsque j'ai commencé à suivre l'activité de QakBot et à creuser plus profondément, j'ai réalisé que pr0xylife et d'autres décrivaient les combinaisons subtiles et les variations dans la façon dont QakBot pouvait tromper ses victimes et échapper à notre défenses. Quelques exemples:

• Il utilise HTML Smuggling , où un fichier HTML malveillant contenant du JavaScript codé est exécuté par le navigateur de la victime, téléchargeant l'étape suivante de la charge utile.
• Il utilise des fichiers zip protégés par mot de passe pour bloquer l'analyse de sandboxing.
• Il utilise un format d'image disque appelé fichier .iso pour échapper à la protection Mark-of-the-Web, comme l' explique très bien Red Canary .
• Fichiers LNK déguisés pour inciter les utilisateurs à exécuter des fichiers .CMD et .DLL cachés.
• Et ainsi de suite avec des astuces toujours plus trompeuses !

L'objectif

Il existe des détections de contrebande HTML et d'autres techniques liées à QakBot. Celles-ci sont principalement basées sur la correspondance d'événements de journal suspects, comme celui-ci d'Elastic Security :

Je voulais voir si je pouvais construire mes propres détections, en utilisant la corrélation (par opposition à une simple correspondance) pour les rendre résistantes aux changements subtils du comportement d'attaque.

TBH, j'en avais aussi marre de la chicanerie stupide de QakBot et je voulais un moyen fiable de le placer directement dans notre champ de vision.

Observation initiale et analyse des logiciels malveillants QakBot

Pour atteindre mon objectif, je devais aller au-delà des rapports de renseignement sur les menaces des fournisseurs de sécurité et des tests de l'Atomic Red Team ; J'avais besoin de mes propres données créées à partir d'échantillons de logiciels malveillants réels. Je me suis tourné vers un ancien favori : malware-traffic-analysis.net de Brad Duncan (@malware_traffic). Ce site fait partie des ressources éducatives les plus utiles que j'ai rencontrées en matière de sécurité. En plus des didacticiels Wireshark et des exercices pratiques sur le trafic réseau, le site propose une analyse de qualité d'échantillons de logiciels malveillants réels, y compris des fichiers de contrebande HTML QakBot.

Après avoir fait des instantanés de mes machines virtuelles de laboratoire, j'ai lancé mon laboratoire de détection virtuel et visité une entrée récente. Attention, les fichiers hébergés sur ce site ne sont pas sécurisés !

J'ai téléchargé le fichier zip des artefacts et l'ai extrait dans mon dossier de téléchargements à l'aide de l'utilitaire WinRAR intégré à mon laboratoire de détection :

Les notes du CIO ont été extrêmement utiles pour donner un contexte aux fichiers inclus. Parmi les notes figuraient les suivantes, qui m'ont fait savoir que la chaîne d'infection a commencé avec le fichier HTML, appelé SCAN_DT6281.html.

2022-12-09 (FRIDAY) - HTML SMUGGLING FOR QAKBOT (QBOT) DISTRIBUTION TAG: AZD

DISTRIBUTION:

- Unknown source, possibly email --> HTML file --> password-protected zip archive --> extracted ISO image with .img file extension

… bien sûr, ouvrons le fichier zip, pourquoi pas ?

Le fichier zip était protégé par un mot de passe mais pouvait être ouvert à l'aide du mot de passe affiché sur la page HTML. Le fichier zip contenait un seul fichier .img, que je sais être un autre format de fichier d'image de disque montable. Double-cliquer dessus a monté le fichier en tant que lecteur D sur mon système :

J'ai également remarqué un répertoire caché appelé IncomingPay, qui contenait un fichier .lnk, deux fichiers texte contenant (je ne plaisante pas) des extraits de la page Wikipedia sur la psychologie, un fichier .cmd et un fichier .lc .

En tant que professionnel de la sécurité et observateur consciencieux de la formation de sensibilisation à la sécurité de l'entreprise, tous mes étaient debout et agitaient dans la brise. Mais c'est pour la science, alors je prends l'appât et double-clique sur le fichier LNK, tout comme l'attaquant veut que la victime le fasse. Une fenêtre de ligne de commande apparaît quelques secondes, puis disparaît :

La propriété cible du fichier LNK est intéressante :

C:\Windows\System32\cmd.exe /c IncomingPay\Issues.cmd A B C D E F G H I J K L M N O P Q R S T U V W X Y Z 0 1 2 3 4 5 6 7 8 9

Comment savoir quelles recherches exécuter ? Pas vraiment, mais grâce à mon expérience en tant qu'analyste et chercheur, je sais que certains types de preuves peuvent apparaître dans mes journaux - exécutions de processus, créations de fichiers, connexions réseau, etc. C'est là que l'expérience sur le terrain en tant qu'analyste de sécurité ou une bonne dose de formations de type CTF (comme celles disponibles chez CyberDefenders ou LetsDefend ) sont utiles.

Après avoir rafraîchi mes recherches plusieurs fois et me suis demandé si j'avais fait quelque chose de mal, j'ai remarqué un signe certain et incontestable d'une intrusion : une explosion d'activité de reconnaissance sur mon hôte victime :

En regardant ces commandes, j'ai noté la période de temps au cours de laquelle elles se sont produites - le tout en l'espace de quelques secondes ! En outre, les processus ont tous été générés par un parent inhabituel - wermgr.exe (le gestionnaire de rapports d'erreurs Windows). Une bonne opportunité de détection, peut-être ? L'administrateur le plus confus ou le logiciel [légitime] le plus confus n'exécutera pas toutes ces commandes de reconnaissance suspectes dans un délai aussi court, et jamais en tant qu'enfant d'un wermgr.exe. En passant à mes connexions réseau, j'ai remarqué que wermgr.exe était soudainement devenu extrêmement bavard avec des adresses IP externes :

Suite à cette évaluation initiale de mes données, j'ai déterminé que :

• L'échantillon de malware contenait un vecteur d'accès initial malveillant (duh, la galerie de voyous des fichiers .html, .zip, .img, .lnk, .cmd et .lc).
• Le logiciel malveillant téléchargeait le fichier zip après avoir ouvert la page HTML dans un navigateur, et le fichier zip contenait un fichier .img montable.
• Le lecteur monté contenait un raccourci malveillant qui entraînait l'exécution de commandes supplémentaires.
• Un processus wermgr.exe injecté a engendré une rafale automatisée d'activité de reconnaissance, puis s'est connecté à des adresses IP externes suspectes, probablement pour envoyer à l'attaquant des informations sur notre système et notre réseau.

Décomposer l'attaque en blocs de détection

Après avoir effectué une première exécution de la technique de contrebande HTML QakBot dans le laboratoire et être revenu à mes instantanés de machine virtuelle, il était temps de creuser davantage dans les journaux pour voir ce qui se passait.

En passant en revue les différents types d'événements générés par l'attaque, j'ai commencé à développer une compréhension narrative en langage simple de ce qui se passait :

« Un attaquant envoie à une victime un fichier HTML censé contenir un rapport, une facture ou tout autre document qui l'intéresse. Fondamentalement, un leurre de phishing. Lorsque la victime ouvre le fichier dans son navigateur, le code JavaScript intégré s'exécute, qui télécharge ou crée un fichier zip protégé par mot de passe sur le système de la victime. Lorsque la victime décompresse l'archive , l'extraction crée un fichier image disque montable . Après avoir monté le lecteur , l'utilisateur voit un raccourci qui, selon lui, l'amènera à la ressource qu'il essaie de trouver. Mais le raccourci appelle en fait une commande ou un interpréteur de script qui exécute d'autres fichiers malveillantsqui sont cachés sur le lecteur de disque, ce qui entraîne une compromission initiale de l'accès. »

C'est un morceau de prose verbeux là, mais ça a du sens dans ma tête. Si je dois détecter quelque chose, je dois d'abord le comprendre ! Notez le texte en gras : j'ai utilisé mon récit pour mettre en évidence les événements que je pourrais utiliser pour détecter la chaîne d'attaque. Sur la base de cet examen, j'ai analysé les journaux de l'attaque, en essayant d'isoler les événements suivants :

1. E-mail de phishing envoyé à la victime contenant une pièce jointe HTML.
2. Création d'un fichier HTML dans des emplacements suspects.
3. Ouverture d'un fichier HTML autonome dans une application de navigateur.
4. Téléchargement/création d'un fichier zip par l'application navigateur.
5. Ouverture/extraction d'un fichier zip protégé par mot de passe.
6. Création d'un format de fichier de lecteur de disque montable (.iso, .img, etc.).
7. Montage d'un lecteur.
8. Exécution du processus sur un lecteur externe (soit à partir d'un exécutable sur ce lecteur, soit d'un exécutable système touchant des fichiers sur ce lecteur).

La bonne nouvelle

La bonne nouvelle était qu'il existe des moyens de détecter presque tous les événements énumérés ci-dessus ! Cela signifie que j'ai eu de nombreuses idées sur la façon d'interroger et de filtrer les journaux disponibles pour extraire les événements significatifs (blocs de construction) pour les détections futures.

Les mauvaises nouvelles

La mauvaise nouvelle était qu'aucun de ces nombreux événements n'est, à lui seul, malveillant. Encore une fois, il n'y a pas de journal VOUS AVEZ ÉTÉ HACKÉ : chacun de ces événements peut se produire dans le cours normal des affaires et être totalement sûr et bénin. La solution serait de corréler ces événements, dans une séquence ordonnée ou non, en les regroupant par un attribut commun comme le nom d'hôte, et en déclenchant une alerte lorsque tout cela se produit dans une fenêtre temporelle, comme une heure. Le problème est, d'après mon analyse et mes tests (plus à ce sujet dans un instant), enchaînant ou corrélant que de nombreux événements entraîneraient une détection fragile.

Fragile ou Résilient

La « fragilité » décrit le degré auquel une idée de détection s'effondre face à des changements subtils dans les techniques de l'attaquant, des variations dans les actions effectuées par la victime, des problèmes de journalisation ou d'autres facteurs hors de notre contrôle. Les détections fragiles contrastent avec les détections « résilientes », qui sont flexibles et peuvent résister à ces changements subtils.

Ce n'est pas aussi simple que de dire « fragile = mauvais et résilient = bon ». Une détection fragile pourrait être très ciblée, avec une « ouverture » étroite. L'avantage pourrait être que, si une règle de détection fragile se déclenche, il y a une très forte probabilité qu'il s'agisse d'un vrai positif. Les détections résilientes peuvent avoir une ouverture plus large et peuvent correspondre à davantage d'activités malveillantes potentielles. Cependant, cela pourrait conduire à des faux positifs et à un SOC frustré s'ils ne sont pas développés avec soin.

Dans cet esprit, je suis revenu à ma liste d'événements d'en haut.

Détermination des blocs de construction à tester

Dans le contexte, j'ai réalisé que les éléments un à trois de la liste ci-dessus n'étaient peut-être pas de bons composants de ma détection de contrebande HTML. Le manque de visibilité et un volume élevé de comportements innocents entraveraient l'élément 1. J'ai frappé l'élément deux parce que j'avais une capacité limitée à tester cet événement, et l'élément trois s'est avéré peu fiable selon le navigateur que j'ai utilisé. De plus, bien qu'il ne s'agisse pas techniquement de contrebande HTML, une grande partie de l'activité de QakBot utilise des URL, plutôt que des fichiers HTML autonomes, pour fournir la charge utile initiale.

L'item cinq (extraction d'un fichier zip protégé par mot de passe) a beaucoup de potentiel, et peut être détecté grâce à cette règle écrite par Florian Roth et inspirée des recherches de @SBousseaden . Cependant, je l'ai laissé hors de mon champ d'application car 1) cet événement ne se connectait pas dans mon laboratoire et 2) une documentation indique qu'il ne s'applique qu'à certains systèmes d'exploitation.

Après avoir exploré mes données, énuméré les éléments de base de détection possibles pour ma corrélation et vanné cette liste en fonction d'une analyse plus approfondie, j'avais les éléments de base suivants :

1. Le navigateur Web crée (télécharge) un fichier d'archive Zip (représente l'ouverture du fichier HTML malveillant dans un navigateur).
2. ISO, VHD, LNK ou IMG File Extracted from Zip (extraction du fichier image disque malveillant).
3. Disk Image Mount (montage de l'image - celle-ci que j'ai tirée directement de Sigma).
4. Exécution suspecte d'un processus initié par l'utilisateur sur un lecteur externe (en cliquant sur le fichier .lnk qui exécute ou référence des fichiers sur le lecteur externe).

Corrélations sigma

La corrélation nous permet de suivre les événements du journal dans le temps. Plutôt que de déclencher une alerte pour chacun des quatre événements listés ci-dessus, une corrélation de règles en chaîne nous permet d'alerter uniquement lorsque les quatre événements se produisent dans l'ordre sur le même hôte par le même utilisateur, ce qui est beaucoup plus suspect. De nombreux produits SIEM et leurs langages de requête correspondants prennent en charge ce type de chaînage (bien que certains ne le fassent pas).

Pour prendre en charge cette fonctionnalité, Sigma a une norme de corrélations en cours qui nous permettra d'écrire des règles de corrélation personnalisées dans un format commun, puis de les convertir en tout produit SIEM prenant en charge cette logique. Le projet de norme peut être consulté ici :

À quoi cela pourrait-il ressembler ? Il s'agit d'un projet de norme susceptible d'être modifié , mais un exemple simple de règle de chaîne de force brute pourrait ressembler à ceci :

action: correlation
type: temporal
rule:
    - many_failed_logins
    - successful_login
group-by:
    - User
timespan: 1h
ordered: true

Mon projet de règle de corrélations ressemble à ceci :

title: HTML Smuggling Activity - Chain Rule
id: 0952f2fa-e29b-4eb5-831c-ce21520c56e3
status: experimental
description: Detects HTML smuggling-style compromise (such as HTML > ZIP > ISO/IMG/VHD > CMD/BAT/VBS > DLL). Includes rules to detect zipfile dropped by browser, ISO/IMG/VHD/LNK file extraction, disk image mount, followed by user-initiated process creation on an external drive.
references:
    - https://blog.talosintelligence.com/html-smugglers-turn-to-svg-images/#:~:text=HTML%20smuggling%20is%20a%20technique,directly%20on%20the%20victim's%20device.
    - https://www.malwarebytes.com/blog/news/2021/11/evasive-maneuvers-html-smuggling-explained
    - Original research and analysis performed off of QakBot intelligence gathered at https://github.com/pr0xylife/Qakbot, https://www.malware-traffic-analysis.net/, and https://github.com/executemalware/Malware-IOCs
author: Micah Babinski
date: 2022/12/27
tags:
    - attack.s0650
    - attack.s0483
    - attack.initial_access
    - attack.defense_evasion
    - attack.execution
    - attack.t1564
    - attack.t1566.001
    - attack.t1566
    - attack.t1027
    - attack.t1027.006
    - attack.t1059
    - attack.t1204
    - attack.t1204.002
action: correlation
type: temporal
rule:
    - 1_win_zipfile_drop.yml
    - 2_win_susp_file_extraction.yml
    - 3_win_security_iso_mount.yml
    - 4_win_process_creation_ext_drive.yml
group-by:
    - ComputerName
    - User
timespan: 1h
ordered: true
falsepositives:
    - Unknown
level: high

Encore une fois, la spécification Sigma Correlations est en cours de développement et est sujette à modification. Néanmoins, ce sera une extension très utile des capacités de Sigma, alors je voulais vous en donner un aperçu maintenant !

Tester la corrélation

Avec ce concept de détection prenant forme et une hypothèse développée sous la forme de ma règle de corrélation, il était temps de tester la détection avec un échantillon plus important. Je me suis appuyé sur le référentiel MalwareBazaar d'Abuse.ch, qui fournit une bibliothèque utile d'échantillons de logiciels malveillants marqués. J'ai téléchargé 10 échantillons HTML QakBot, principalement signalés par pr0xylife, dont la date de première vue va du 11 juillet au 22 décembre 2022. J'ai préparé les échantillons sur la machine virtuelle de mon laboratoire et nommé chacun en fonction de sa date de première vue et de son "humanhash". propriété (une séquence aléatoire et unique de mots lisibles par l'homme, tels que ("dakota-earth-mockingbird-march") :

Pour suivre mes résultats, j'ai créé un tableau simple dans Google Sheets :

J'ai fait un instantané propre et pré-test de mon hôte VM victime pour y revenir après chaque test, et j'ai commencé le test. Après avoir testé sept des dix échantillons, ma séquence de quatre blocs de construction avait une couverture parfaite ! Lorsque j'ai atteint le huitième échantillon, cependant, la quatrième règle de la chaîne ne s'est pas déclenchée, car le fichier .lnk s'appelait directement RunDLL32.exe, au lieu de cmd.exe ou wscript.exe. C'était bien - j'ai simplement ajusté les conditions de ma règle Sigma, retesté et obtenu des correspondances parfaites ! J'ai été ravi des résultats et ravi de partager le cas d'utilisation de la détection avec la communauté.

Tour bonus !

De nombreuses attaques de phishing QakBot n'utilisent pas de pièces jointes .html, mais utilisent à la place des fichiers .pdf malveillants avec des liens intégrés, ou simplement de bons liens de phishing à l'ancienne qui pointent vers des fichiers zip hébergés sur un site Web compromis. Pour tester si ma détection était suffisamment flexible pour attraper ces instances également, je les ai testées sur quelques exemples récents du référentiel IOC maintenu par @ExecuteMalware, et j'ai constaté que ces attaques driveby basées sur des URL étaient également capturées par la détection. Celui documenté ici comprenait même un fichier .wsf (Windows Script File) - un type de fichier avec lequel je n'étais pas familier mais qui a néanmoins été détecté par ma détection.

Hourra pour la résilience !

Conclusion

Toutes nos félicitations! Vous avez atteint la fin d'un long article sur des sujets denses et compliqués. Vous pouvez trouver toutes les règles référencées ici . Merci d'avoir lu, et j'espère que vous avez apprécié mes divagations sur QakBot, la contrebande HTML, Sigma et les corrélations. Je suis vraiment ravi du lancement de Sigma Correlations. Ce sera une grande victoire pour la communauté des ingénieurs de détection et nous permettra de partager des cas d'utilisation de détection plus sophistiqués.

J'ai été vraiment satisfait du déroulement de mes tests, en particulier lorsqu'ils ont montré que l'un des éléments constitutifs de ma règle de chaîne avait échoué et avait besoin d'être ajusté ! Après tout, pourquoi tester si vous pensez que votre travail est déjà parfait ? Enfin, cette expérience m'a fait comprendre ce que j'avais déjà commencé à croire - que nous ne pouvons pas détecter ce que nous ne comprenons pas. Rien ne remplace une expérience de première main avec de vrais logiciels malveillants en direct si vous essayez de voir ce qu'ils font.

Grâce au projet Detection Lab qui m'a enthousiasmé dans les articles précédents, cette expérience réelle est à la portée de plus de gens que jamais. Enfin, merci à pr0xylife, Brad (malware_traffic) et executemalware pour avoir fourni des référentiels vierges d'échantillons de logiciels malveillants QakBot bien documentés auxquels nous pouvons accéder, analyser et comprendre. Ce sont vraiment des trésors pédagogiques !

N'hésitez pas à m'envoyer des idées, des commentaires ou des suggestions sur la façon dont je peux m'améliorer. Je suis encore nouveau dans ce domaine et j'accueille les commentaires et critiques respectueux sous toutes leurs formes.

Comme toujours, bonne analyse !