Base64 imbriqué : éplucher les couches et compter la profondeur

Tout autre exercice de décodage demande ce que dit le message. Celui-ci demande à quelle profondeur il a été enterré, ce qui est une compétence différente et étonnamment pratique. Les analystes rencontrent constamment de l'encodage imbriqué, dans des droppers obfusqués, des pièces jointes de phishing et des payloads d'exfiltration, et le réflexe qui compte est de ne pas s'arrêter au premier décodage réussi.

Le piège, c'est que la sortie du base64 est elle-même une entrée base64 valide. Décodez une couche d'un emballage à sept couches et vous obtenez un autre bloc dénué de sens du même alphabet, qui ressemble exactement à un décodage raté d'un blob chiffré. Les analystes qui s'arrêtent là concluent que les données sont chiffrées et passent à autre chose. La bonne habitude est de continuer à décoder tant que la sortie garde la forme de l'encodage, et de s'arrêter seulement quand elle cesse de l'avoir.

Ici, ce point arrive après sept appuis, où la sortie se lit comme une phrase en anglais. Le huitième appui est la confirmation, et elle est sans équivoque : le texte en clair contient des espaces et des points, qui sont en dehors de l'alphabet base64, donc le décodeur échoue et le laboratoire affiche un marqueur d'erreur au lieu de renvoyer silencieusement quelque chose de plausible. Sept décodages atteignent le texte et le huitième échoue, la profondeur est donc exactement 7.

Un détail à remarquer en cours de route : la chaîne s'allonge à chaque couche au lieu de se raccourcir, car le base64 encode trois octets en quatre caractères et augmente la taille des données d'environ un tiers à chaque fois. Sept couches d'emballage coûtent beaucoup de taille et n'apportent aucune confidentialité, car n'importe qui peut toutes les inverser sans clé. Les trois autres boutons sont des leurres qui s'appliquent proprement au texte base64 et renvoient un charabia convaincant, ce qui est la cause habituelle d'une erreur de comptage.

• Compter les caractères ou estimer à partir de la longueur. Le compte correspond au nombre d'étapes de décodage, que la pile affiche directement.
• S'arrêter trop tôt parce que la sortie ressemble encore à de l'encodage. Chaque couche intermédiaire ressemble à du base64. C'est tout le piège.
• Répondre 8 après l'appui échoué. Le huitième appui produit une erreur et n'épluche pas de couche, donc il ne compte pas.
• Mélanger les transformations leurres. rot13, reverse et hex s'appliquent sans problème au texte base64 et corrompent la chaîne, rendant le comptage peu fiable. Utilisez Annuler et Réinitialiser si cela arrive.
• Soumettre le texte du message. La phrase finale sert à vous indiquer que vous avez terminé ; la réponse est le nombre de couches.

L'encodage imbriqué est une technique d'obfuscation et d'évasion de détection, pas une protection, et les deux aspects comptent.

• Ne traitez jamais le base64 comme un contrôle de sécurité. Il est réversible par n'importe qui, sans clé, à n'importe quelle profondeur.
• Dans les outils de détection, décodez récursivement avec une limite de profondeur raisonnable et scannez la sortie à chaque niveau, car les signatures qui ne correspondent qu'à la couche la plus externe sont trivialement contournées par un emballage supplémentaire.
• Traitez l'imbrication profonde comme un signal en soi. Les données légitimes sont rarement encodées sept fois, donc la profondeur est une caractéristique utile pour le tri.
• Surveillez l'indice de taille : l'encodage répété gonfle les payloads d'environ un tiers par couche, ce qui fait ressortir le contenu fortement emballé par son volume.
• Quand vous avez réellement besoin de confidentialité, utilisez un chiffrement authentifié avec une clé gérée, et réservez l'encodage à son véritable usage, à savoir le transport sûr d'octets à travers des canaux texte uniquement.