Outils de développement · Encodeur et décodeur Base64
Comment décoder une commande PowerShell Base64 suspecte sans l'exécuter
· Pourquoi c'est important
base64 sécurité
Les attaquants utilisent Base64 pour cacher les scripts à une inspection occasionnelle. Cet article montre comment décoder une charge utile -EncodedCommand sans l'exécuter, pourquoi la sortie peut sembler étrange dans un décodeur UTF-8 et ce qu'il faut rechercher.
La tâche planifiée avec un argument de caractère 2,000 - où les commandes codées apparaissent et pourquoi elles sont un signal d'alarme
Un administrateur système découvre une tâche planifiée avec un argument 2,000-character -EncodedCommand qui semble suspect. La tâche s'exécute sous un compte de service doté de privilèges élevés.
La tentation de coller la commande dans PowerShell et de l'exécuter pour voir ce qu'elle fait est dangereuse ; si la commande est malveillante, son exécution compromet le système. L'approche la plus sûre consiste à décoder le Base64 localement et à lire le résultat sous forme de texte avant de décider d'exécuter quoi que ce soit. Cet article explique comment décoder les commandes PowerShell en toute sécurité sans les exécuter, pourquoi la sortie peut sembler tronquée dans un décodeur UTF-8 standard et ce qu'il faut rechercher pour évaluer si une commande est sûre ou suspecte.
Décoder, ne jamais exécuter : la règle qui garantit la sécurité de l'analyse et pourquoi un décodeur uniquement par navigateur est un bon choix
L'idée clé est que PowerShell utilise le codage UTF-16LE pour -EncodedCommand, et non UTF-8, donc un octet sur deux est un zéro que les outils standard interprètent comme des terminateurs nuls. La règle pour analyser tout code suspect est simple : décoder, ne jamais exécuter. Cela s'applique aux commandes codées en Base64, aux scripts compressés, aux scripts provenant de sources non fiables et à tout ce qui se trouve dans une chaîne de codage inconnu. L'exécution d'un script est un point de non-retour ; une fois exécuté, des modifications ont été apportées au système, l'accès a été accordé et les données ont été exfiltrées.
Décoder et lire le script sous forme de texte vous permet de l'évaluer avant l'étape irréversible. La deuxième règle consiste à utiliser un outil qui s'exécute localement et ne fait aucune requête réseau. Un décodeur basé sur un navigateur est idéal car il est portable, ne nécessite aucun logiciel supplémentaire et conserve la charge utile suspecte sur votre appareil sans la télécharger sur un serveur. Si l’outil est du type à publier sur un service de décodeur distant, ne l’utilisez pas ; la charge utile est ensuite exposée à ce service. Le paramètre PowerShell -EncodedCommand accepte une chaîne Base64 qui, une fois décodée, contient un script PowerShell.
Pourquoi les octets décodés ne ressemblent pas au texte UTF-8 — inspectez le modèle d'octet UTF-16LE en hexadécimal plutôt que de demander à cet outil de texte UTF-8 de l'interpréter
Cependant, PowerShell n'utilise pas l'encodage UTF-8 pour cela ; il utilise UTF-16LE (UTF-16 petit-boutiste). Dans UTF-16, chaque caractère ASCII est représenté sous forme de deux octets : le code du caractère suivi d'un octet zéro. La lettre A est 41 00 en hexadécimal. La lettre B est 42 00. Une chaîne comme Hello apparaît sous la forme 48 00 65 00 6C 00 6C 00 6F 00 en octets UTF-16LE. Lorsqu'il est codé en Base64, le résultat contient la forme codée de tous ces octets, y compris tous les zéros. Le décodage avec un décodeur UTF-8 standard produit un texte tronqué ou tronqué au premier octet zéro, car UTF-8 traite les octets nuls comme des terminateurs de chaîne.
La sortie ressemble à H e l o au lieu de Hello, avec des caractères apparemment aléatoires ou du texte manquant. Un exemple concret montre le problème et la solution. Supposons qu’une commande PowerShell code la simple chaîne Write-Host Hello. PowerShell UTF-16LE code cela en octets incluant tous les zéros, Base64 code les octets et produit une longue chaîne comme VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Copiez cette chaîne dans l'encodeur et le décodeur Base64 de votre navigateur et cliquez sur Décoder. Le décodeur par défaut tentera d'interpréter le résultat sous forme de texte UTF-8 et produira une sortie corrompue ou tronquée en raison des zéros incorporés.
Exemple concret : décodage d'un échantillon de commande codé inoffensif - lecture du texte au-delà des zéros octets entrelacés
La solution consiste à utiliser la vue hexadécimale à la place. Passez à la vue hexadécimale et vous voyez les octets : 57 00 72 00 69 00 74 00 65 00 2D 00 4B 00 6F 00 73 00 68 00 20 00 22 00 48 00 65 00 6C 00 6C 00 6F 00 22 00. La lecture de ces octets sous forme de paires UTF-16LE donne W-r-i-t-e---K-o-s-h---H-e-l-l-o-. Avec de l'expérience, vous pouvez lire directement l'hexadécimal UTF-16LE ou écrire les octets dans un fichier et les décoder avec un script PowerShell ou Python exécuté localement.
L'approche pratique consiste à noter le modèle et à se rappeler que PowerShell utilise UTF-16LE. Lorsque vous décodez PowerShell -EncodedCommand dans le navigateur et que le résultat semble erroné, regardez la vue hexadécimale au lieu de la vue texte. La vue hexadécimale affiche chaque octet individuellement. Chaque caractère ASCII apparaît sous la forme de deux octets séparés par un zéro. Si les octets épellent des commandes malveillantes telles que New-AdminAccount, des recherches DNS inversées ou l'exportation d'informations d'identification de sécurité, la commande est suspecte. Si les octets énoncent quelque chose d'inoffensif comme une liste de répertoires ou un simple script, la commande est probablement inoffensive.
Encodage et compression imbriqués : Base64 dans Base64 et flux gzip que vous ne pouvez pas lire sous forme de texte
La vue hexadécimale est plus difficile à lire que le texte brut, mais elle est plus sûre que de deviner à partir d'une sortie UTF-8 corrompue. L'encodage et la compression imbriqués ajoutent de la complexité à l'analyse des logiciels malveillants. Une commande PowerShell peut encoder en Base64 une autre chaîne Base64, ou compresser un script avec gzip, puis encoder en Base64 le résultat. Dans un scénario imbriqué, vous décodez le Base64 externe, lisez le résultat et découvrez qu'il s'agit lui-même de base64. Décodez-le également et continuez jusqu'à ce que vous trouviez un texte lisible ou un format binaire que vous ne pouvez pas interpréter. Gzip et d'autres formats de compression commencent par des octets magiques (1F 8B pour gzip) visibles dans la vue hexadécimale.
Si vous décodez Base64 et que la vue hexadécimale commence par 1F 8B, les octets sont un flux compressé qui nécessite une décompression. L'encodeur et décodeur Base64 vous montre l'hexadécimal, vous aidant à identifier ces modèles sans rien exécuter. Les charges utiles compressées ou codées davantage sont suspectes car elles ajoutent des couches d’obscurcissement.
Ce qu'il faut enregistrer pour un rapport d'incident : le texte décodé, la source et les hachages plutôt que la charge utile elle-même
Les commandes légitimes nécessitent rarement plusieurs étapes de codage. L’enregistrement des résultats pour un rapport d’incident nécessite discipline et précision. Notez la chaîne Base64 exacte que vous avez analysée, où vous l'avez trouvée et quand. Si vous l'avez décodé et trouvé des commandes suspectes, décrivez les commandes mais n'incluez pas encore le script complet dans le rapport ; le script peut être complexe ou long.
Incluez un hachage (SHA-256) du script décodé afin que le résultat puisse être vérifié et suivi. Si la commande est clairement malveillante ou utilise des techniques d’exploitation connues, impliquez les équipes de réponse aux incidents et de sécurité avant de prendre toute mesure. N'exécutez jamais la commande vous-même pour voir ce qu'elle fait. Si les intervenants en cas d'incident doivent l'exécuter à des fins de test, ils le font dans un environnement sandbox où tout dommage est contenu. Votre travail consiste à décoder et à évaluer le risque à distance de sécurité. Cet article ne couvre pas toute la portée de l’analyse des logiciels malveillants, des environnements sandbox ou de l’attribution des attaques.
Ce que cela ne couvre pas : exécution du bac à sable, outils d'analyse des logiciels malveillants et attribution
Ce sont des sujets destinés aux professionnels de la sécurité et aux équipes de réponse aux incidents. La portée ici est étroitement axée sur le décodage en toute sécurité d'une commande PowerShell codée sans l'exécuter, afin que vous puissiez lire le script et évaluer s'il vaut la peine d'étudier plus en profondeur. Le codage Base64 est un obscurcissement, pas une protection. Toute personne disposant de l'encodage et d'un décodeur peut extraire le script. Les attaquants utilisent Base64 pour échapper à la détection de base et empêcher une inspection occasionnelle, et non pour dissimuler leur intention à l'analyse. Une commande PowerShell décodée qui récupère et exécute un script distant est malveillante, que vous la décodiez vous-même ou qu'un outil de sécurité le fasse.
La prochaine étape pratique après le décodage d'une commande suspecte consiste à la signaler à l'équipe appropriée. S'il s'agit de votre propre système, déterminez si la tâche a été créée intentionnellement et par qui. Vérifiez la date de création et le compte qui l'a planifiée. Si la tâche n'est pas autorisée, désactivez-la, conservez les détails à des fins d'investigation et étudiez comment l'attaquant a obtenu le privilège de la créer. Si la commande contient des requêtes réseau ou des mécanismes de persistance tels que des modifications de registre ou la création de tâches planifiées, elle est presque certainement malveillante.
À retenir : Base64 est un obscurcissement, pas une protection – comment l'encodeur et le décodeur Base64 décode la charge utile localement sans qu'elle ne quitte jamais votre machine
S'il exécute des fonctions d'administration légitimes et que les détails de création sont normaux, il peut s'agir d'un script d'administration légitime qui se trouve être codé pour des raisons liées à la politique de sécurité ou à l'intégration avec un outil d'automatisation plus vaste. Ne l’exécutez pas de toute façon ; laissez votre évaluation du texte décodé éclairer votre décision. Le décodage sécurisé des commandes Base64 PowerShell suspectes suit un processus simple. Utilisez l'encodeur et le décodeur Base64 pour décoder la chaîne sans la télécharger ni exécuter quoi que ce soit. Regardez la vue hexadécimale pour comprendre ce que représentent les octets.
Si vous voyez des modèles UTF-16LE (zéro octets entrelacés), rappelez-vous que PowerShell utilise UTF-16LE et lisez en conséquence. Identifiez tout modèle suspect comme les requêtes réseau, l’élévation de privilèges ou les mécanismes de persistance. Enregistrez les détails avec précision pour votre rapport d'incident, y compris la chaîne Base64 d'origine et son hachage. N'exécutez jamais la commande vous-même ; laissez cela aux intervenants en cas d’incident dans un environnement contrôlé. Faites confiance à votre décodage local et à votre évaluation du texte brut, et laissez-les guider votre prochaine action.