VBScript permet aux acteurs de la menace de voler des données personnelles et rendre les victimes vulnérables aux keyloggers, aux logiciels bancaires malveillants et aux ransomwares.
Au cours des derniers jours, nous avons analysé un développement avec le botnet Necurs - une opération de cybercriminalité datant de 2012 qui est rapidement devenue l'un des plus grands botnets de spam dans le monde.
Nous publierons prochainement deux articles sur l'infâme cybergang responsable de la distribution de campagnes mondiales de logiciels malveillants tels que "Locky" et "GlobeImposter" qui expliqueront comment les logiciels malveillants sont diffusés via Necurs. Nous avons vu dorénavant observé un nouveau lien vers cette chaîne avec des attaquants servant de nouveaux fichiers via le même botnet. Ces fichiers propagent des scripts Visual Basic malveillants (VBScripts) et notre analyse suggère que les auteurs utilisent les services fournis par le botnet Necurs pour atteindre plus de victimes.
Le but ultime des attaquants est de rendre les systèmes vulnérables aux attaques avec la possibilité de voler des données personnelles et de les infecter avec des keyloggers, des logiciels malveillants bancaires et des rançongiciels.
Un examen du code source suggère que les VBScripts hébergent une forme sévère de malware connue sous le nom de Rootkit Agony utilisé pour infecter le Master Boot Record (MBR) des ordinateurs. Cela peut être particulièrement destructeur. En infectant le MBR, le malware est capable de s'exécuter avant le démarrage du système, lui permettant de contourner le logiciel de sécurité. Il insère ensuite une porte dérobée dans le système d'exploitation qui donne à l'attaquant le contrôle total de la machine. Avec ces droits d'administration, l'attaquant peut installer des vers, des enregistreurs de frappe et d'autres fichiers malveillants. Ils peuvent également accéder aux données stockées, y compris les informations personnelles ou financières, ce qui met les utilisateurs en danger.
Voici des exemples de VBScripts en action. À première vue, il semble inclure des combinaisons numériques aléatoires qui pourraient être jetées comme indésirables, éventuellement ajoutées pour modifier la structure du code afin d'échapper à la détection. Cependant, nous avons passé du temps à étudier le code via la fonction de déchiffrage et avons repéré une logique derrière sa construction.
Les scripts eux-mêmes sont d'environ 72 Ko et sont de composition similaire à l'exception de quelques petits changements dans les méthodes d'obfuscation.
Le script est vraiment facile à désobfusquer ; le seul problème est la suppression des commentaires - qui est souvent présente dans les outils d'analyse - qui peut induire en erreur les analystes.
Après avoir déchiffré ces commentaires, dans la première version, nous avons repéré un joli morceau de code qui pourrait être utilisé comme exemple de modélisation "Comment écrire le panneau de contrôle pour votre malware dans VBS". La prochaine version est moins explicite et lisible.
Il est probable que les auteurs de VBScripts se soient connectés avec les auteurs du botnet Necurs en raison de son ampleur et de son potentiel pour les escroqueries par email omniprésentes. Les scripts semblent fonctionner comme un téléchargeur et un panneau de contrôle pour le rootkit Agony, mais la modification de la charge utile est particulièrement facile. Cela pourrait ouvrir la porte à des infections de logiciels malveillants plus graves pour les victimes à l'avenir, tels que les rançongiciels ou les chevaux de Troie bancaires.
Le code lui-même contient des variables très bien nommées ainsi que la sortie de débogage dans un fichier journal. Cependant, le débogage est désactivé par défaut lorsque la variable isDebug est définie sur false . La sortie de débogage informe sur chaque sous-programme important et contient des chaînes telles que :
Fait intéressant, cela rend ce code exceptionnellement beau, car nous tombons rarement sur un morceau de code relativement bien structuré et « commenté » avec des noms auto-documentés, en particulier lorsque le sujet est un logiciel malveillant.
De plus, le code révèle des informations importantes sur son créateur. L'auteur semble avoir un problème avec le passé des verbes irréguliers comme to get ou o send. En outre, plusieurs entrées de journal utilisent une construction de phrase en anglais incorrecte, telle que "Panel maybe die!" (Panneau peut-être mourrir !). Il pourrait suggérer que la première langue de l'auteur n'est pas l'anglais, mais cela pourrait bien être mis en scène.
Le script initialise ses variables telles que les adresses de commande et de contrôle (C & C), divers chemins et plusieurs objets utilisés pour interfacer les fonctions du système. Ensuite, le script essaie de s'installer dans le dossier %APPDATA% sous les noms <HWID>.vbs, g_<HWID>.vbs_w.vbs (HWID étant une séquence aléatoire de lettres chargées à partir du registre ou générées au démarrage), et éventuellement <static_number_sequence>_log.txt, et se relance depuis le répertoire% APPDATA%. Après l'installation initiale, il vérifie si une autre instance du script est en cours d'exécution. La persistance est la clé, donc si une seule instance est en cours d'exécution, une tâche nommée ChromeUpdate est créé pour lancer le premier fichier sur la connexion de l'utilisateur. En outre, plusieurs entrées de registre qui lancent le script au démarrage sont créées. Sinon, le script se ferme.
Une fois que le script a survécu à l'initialisation, il doit demander des commandes aux serveurs C & C et les traiter. C'est là qu'intervient une boucle d'événement traditionnelle. La vérification que le script se trouve dans le répertoire %APPDATA% doit d'abord être passée, sinon agony est invoquée six fois avant de passer à l'itération suivante. Supposons que ce test est passé. Maintenant, le script envoie une requête POST avec une chaîne de données GET plutôt longue, par exemple :
os=Windows 10 Enterprise&user=Evzen@DEMO-PC&av=Avast AntivirusWindows Defender&7045Mb # Intel(R) Core(TM)CPU E5-2690 v4 @ 2.60GHz # Standard VGA Graphics Adapter&hwid=AABBccddEEFFGGhhiiJJKKLLm&x=64
Les seuls champs nécessitant une discussion sont _fw_ et _hwid_. "fw" décrit le matériel (en particulier la taille de la RAM # CPU info # GPU info ), tandis que "hwid" est une chaîne aléatoire de 25 caractères générée au premier lancement et sauvegardée dans le registre de HKEY_CURRENT_USER\Software\ARRSSS.
La réponse contient une commande. Ces commandes ont une structure très similaire et chaque commande déclenche une confirmation qui est envoyée à nouveau en tant que requête POST à la même adresse qu'une demande de commande, mais la chaîne de données diffère :
ok=<zid>&hwid=<hwid> en cas de succès
error=<zid>&hwid=<hwid> en cas d'erreur
La valeur <zid> est donnée par la chaîne de commande. Toutes les commandes disponibles sont répertoriées ci-dessous :
|
command |
Command string |
Cction |
|
download |
download!<url>!<zid> |
Télécharge un fichier depuis <url> et l'exécute. |
|
update |
update!<url>!<zid> |
Télécharge un fichier PE depuis <url>, l'enregistre dans %TEMP% et l'exécute. |
|
pluging |
download!<url>!<zid> |
Télécharge une DLL depuis <url>, l'enregistre dans %TEMP% utilise RUNDLL32.exe pour l'exécuter. |
|
uninstall |
uninstall!<data>!<zid> |
Remplace les fichiers supprimés et un journal par un fichier avec un espace. |
|
ddos |
ddos!<url>!<count> |
Envoi les requêtes <count> POST à <url>. |
L'attaque de déni de service (DDoS,) qui peut être provoquée par la commande ci-dessus initiée par ce script, contient également des données. Il semble que ces attaques peuvent être identifiées par les données associées, car tous les scripts collectés jusqu'à présent ont les données POST codées en dur :
ufgiweugdiqwfgqofwg = 325872346782356786426526349865923659
Maintenant, le script se termine également par plusieurs invocations d'agonie . La fonction agonie a trois objectifs. Il vérifie si le script est en cours d'exécution dans le répertoire d'installation. Le résultat affecte uniquement la copie des scripts lancée si aucune instance de %APPDATA%\<HWID>.vbs or g_%APPDATA%\<HWID>.vbs_w.vbs n'est en cours d'exécution, et l'entrée de journal suggère que cela est prévu cela comme une auto-défense. De plus, si le script n'est pas nommé <HWID> .vbs et situé dans % APPDATA% , il écrase ses deux fichiers par <static_number_sequence> _log.txt et s'ajoute au démarrage via les entrées de registre :
HKEY_CURRENT_USER\software\microsoft\windows\currentversion\run\
HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\run\
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run\
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell
Chaque agonie se termine avec 500 millisecondes d'un Sleep, une fonction qui suspend l'exécution du code pour un temps donné.
Une nouvelle version, découverte environ un jour après la sortie du script décrit, a apporté plusieurs mises à jour. Dans la nouvelle version, la charge utile est cachée au-delà d'un autre fichier .vbs qui agit comme un téléchargeur pour l'étape suivante. De plus, ses fonctions semblent avoir été refactorisées car par exemple la fonction agony est maintenant supprimée au profit d'un simple Sleep et la détection d'un antivirus installé sur le système est maintenant cachée dans une fonction appelée func15. En outre, le script s'installe uniquement sur %APPDATA%/<HWID>.vbs , ce qui simplifie la recherche des instances en cours d'exécution, et signifie qu'une seule fonction est nécessaire pour la vérification.
La structure de commande est simplifiée pour inclure uniquement les fonctions téléchargement, mise à jour et désinstallation. La mise à jour de la commande attend maintenant un script Visual Basic, tandis que la mise à jour attend un fichier PE (Portable Executable).
Le dernier ajout important est une nouvelle fonction appelée psCommand qui, comme prévu, exécute une commande dans PowerShell. Pour le moment, ceci est seulement utilisé dans l'initialisation.
Décodeur VBS: 0089A6E7E92B75952F5C2E3A04A7AB65133F4CCA732BC96ECB0A34389D8FC7F4 (v1)
Dae17df6225f05e99bf0e84b3a8438560befc7eb6bd07a7b4d4e451ec33b6a5f (v2)
Panneau de contrôle VBS :
3011126B5210298D843D6D3B84143BE292633A4A7C0D14E947AE6BE11B74CE2F (v1)
676abca2210742e57b432558276b616b1e4e5286c772aed8c63efed230ff2430 (v2)
Merci d’utiliser Avast Antivirus et de nous recommander à vos amis et votre famille.
1988 - 2024 Copyright © Avast Software s.r.o. | Sitemap Politique de Confidentialité