Strumenti per sviluppatori · Codificatore e decodificatore Base64
Come decodificare un comando PowerShell Base64 sospetto senza eseguirlo
· Perché è importante
base64 sicurezza
Gli aggressori utilizzano Base64 per nascondere gli script da ispezioni casuali. Questo post mostra come decodificare un payload -EncodedCommand senza eseguirlo, perché l'output potrebbe sembrare strano in un decoder UTF-8 e cosa cercare.
L'attività pianificata con un argomento di caratteri 2,000: dove vengono visualizzati i comandi codificati e perché rappresentano un segnale di allarme
Un amministratore di sistema rileva un'attività pianificata con un argomento 2,000 di carattere -EncodedCommand che sembra sospetto. L'attività viene eseguita con un account di servizio con privilegi elevati.
La tentazione di incollare il comando in PowerShell ed eseguirlo per vedere cosa fa è pericolosa; se il comando è dannoso, la sua esecuzione compromette il sistema. L'approccio più sicuro è decodificare Base64 localmente e leggere l'output come testo prima di decidere se eseguire qualcosa. Questo post spiega come decodificare i comandi PowerShell in modo sicuro senza eseguirli, perché l'output potrebbe apparire confuso in un decodificatore UTF-8 standard e cosa cercare per valutare se un comando è sicuro o sospetto.
Decodifica, non eseguire mai: la regola che mantiene l'analisi sicura e perché un decodificatore solo per browser è una buona soluzione
L'aspetto fondamentale è che PowerShell utilizza la codifica UTF-16LE per -EncodedCommand, non UTF-8, quindi ogni altro byte è uno zero che gli strumenti standard interpretano come terminatori null. La regola per analizzare qualsiasi codice sospetto è semplice: decodifica, non esegui mai. Questo vale per comandi con codifica Base64, script compressi, script provenienti da fonti non attendibili e qualsiasi cosa in una catena di codifica sconosciuta. L'esecuzione di uno script è il punto di non ritorno; una volta eseguito, si sono verificate modifiche al sistema, l'accesso è stato concesso e i dati sono stati esfiltrati.
Decodificare e leggere lo script come testo consente di valutarlo prima del passaggio irreversibile. La seconda regola è utilizzare uno strumento che venga eseguito localmente e non effettui richieste di rete. Un decoder basato su browser è l'ideale perché è portatile, non richiede software aggiuntivo e mantiene il payload sospetto sul tuo dispositivo senza caricarlo su alcun server. Se lo strumento è del tipo che si collega a un servizio di decoder remoto, non utilizzarlo; il carico utile viene quindi esposto a quel servizio. Il parametro PowerShell -EncodedCommand accetta una stringa Base64 che, una volta decodificata, contiene uno script PowerShell.
Perché i byte decodificati sembrano diversi dal testo UTF-8: controlla il pattern di byte UTF-16LE in esadecimale anziché chiedere a questo strumento di testo UTF-8 di interpretarlo
Tuttavia, PowerShell non utilizza la codifica UTF-8 per questo; utilizza UTF-16LE (little-endian UTF-16). In UTF-16, ogni carattere ASCII è rappresentato come due byte: il codice del carattere seguito da un byte zero. La lettera A è 41 00 in formato esadecimale. La lettera B è 42 00. Una stringa come Hello viene visualizzata come 48 00 65 00 6C 00 6C 00 6F 00 in UTF-16LE byte. Quando questo è codificato Base64, il risultato contiene la forma codificata di tutti quei byte, inclusi tutti gli zeri. La decodifica con un decodificatore UTF-8 standard produce testo confuso o tronca al primo byte zero perché UTF-8 tratta i byte null come terminatori di stringa.
L'output appare come H e l o invece di Hello, con caratteri apparentemente casuali o testo mancante. Un esempio pratico mostra il problema e la soluzione. Supponiamo che un comando di PowerShell codifichi la semplice stringa Write-Host Hello. PowerShell UTF-16LE codifica questo in byte inclusi tutti gli zeri, Base64 codifica i byte e produce una stringa lunga come VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Copia questa stringa nel codificatore e decodificatore Base64 nel tuo browser e fai clic su Decodifica. Il decodificatore predefinito proverà a interpretare il risultato come testo UTF-8 e produrrà un output danneggiato o troncato a causa degli zeri incorporati.
Esempio realizzato: decodificare un comando codificato campione innocuo: leggere il testo oltre gli zero byte interlacciati
La soluzione è invece utilizzare la vista esadecimale. Passa alla vista esadecimale e vedrai i byte: 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. Leggendo quei byte come coppie UTF-16LE si ottiene W-r-i-t-e---K-o-s-h---H-e-l-l-o-. Con esperienza puoi leggere direttamente UTF-16LE esadecimale oppure puoi scrivere i byte in un file e decodificarli con uno script PowerShell o Python in esecuzione localmente.
L'approccio pratico consiste nell'annotare il modello e ricordare che PowerShell usa UTF-16LE. Quando decodifichi PowerShell -EncodedCommand nel browser e l'output sembra sbagliato, guarda la visualizzazione esadecimale anziché la visualizzazione testo. La vista esadecimale mostra ciascun byte individualmente. Ogni carattere ASCII viene visualizzato come due byte separati da uno zero. Se i byte indicano comandi dannosi come New-AdminAccount, ricerche DNS inverse o esportazione di credenziali di sicurezza, il comando è sospetto. Se i byte descrivono qualcosa di innocuo come l'elenco di una directory o un semplice script, è probabile che il comando sia innocuo.
Codifica e compressione nidificate: Base64 all'interno di Base64 e flussi gzip che non puoi leggere come testo
La visualizzazione esadecimale è più difficile da leggere rispetto al testo normale, ma è più sicura che indovinare dall'output UTF-8 danneggiato. La codifica e la compressione annidate aggiungono complessità all'analisi del malware. Un comando di PowerShell potrebbe codificare in Base64 un'altra stringa Base64 oppure comprimere uno script con gzip e quindi codificare in Base64 il risultato. In uno scenario nidificato decodifichi il Base64 esterno, leggi il risultato e scopri che è esso stesso Base64. Decodifica anche quello e continua finché non trovi un testo leggibile o un formato binario che non puoi interpretare. Gzip e altri formati di compressione iniziano con magic byte (1F 8B per gzip) visibili nella vista esadecimale.
Se decodifichi Base64 e la vista esadecimale inizia con 1F 8B, i byte sono un flusso compresso che richiede la decompressione. Il codificatore e decodificatore Base64 ti mostra l'esadecimale, aiutandoti a identificare questi modelli senza eseguire nulla. I payload compressi o ulteriormente codificati sono sospetti perché aggiungono livelli di offuscamento.
Cosa registrare per un rapporto sull'incidente: il testo decodificato, la fonte e gli hash anziché il payload stesso
I comandi legittimi raramente richiedono più passaggi di codifica. La registrazione dei risultati per un rapporto sull'incidente richiede disciplina e accuratezza. Annota l'esatta stringa Base64 che hai analizzato, dove l'hai trovata e quando. Se lo hai decodificato e hai trovato comandi sospetti, descrivi i comandi ma non includere ancora lo script completo nel rapporto; la sceneggiatura potrebbe essere complessa o lunga.
Includere un hash (SHA-256) dello script decodificato in modo che il risultato possa essere verificato e tracciato. Se il comando è chiaramente dannoso o utilizza tecniche di sfruttamento note, coinvolgere i team di sicurezza e di risposta agli incidenti prima di intraprendere qualsiasi azione. Non eseguire mai tu stesso il comando per vedere cosa fa. Se gli addetti all'intervento devono eseguirlo a scopo di test, lo fanno in un ambiente sandbox in cui eventuali danni sono contenuti. Il tuo compito è decodificare e valutare il rischio a distanza di sicurezza. Questo articolo non copre l'intero ambito dell'analisi del malware, degli ambienti sandbox o dell'attribuzione degli attacchi.
Ciò che questo non copre: esecuzione sandbox, strumenti di analisi del malware e attribuzione
Questi sono argomenti per i professionisti della sicurezza e i team di risposta agli incidenti. L'ambito qui è strettamente focalizzato sulla decodifica sicura di un comando PowerShell codificato senza eseguirlo, in modo da poter leggere lo script e valutare se vale la pena indagare ulteriormente. La codifica Base64 è offuscamento, non protezione. Chiunque abbia la codifica e un decodificatore può estrarre lo script. Gli aggressori utilizzano Base64 per eludere il rilevamento di base e impedire ispezioni casuali, non per nascondere le proprie intenzioni all'analisi. Un comando PowerShell decodificato che recupera ed esegue uno script remoto è dannoso sia che lo decodifichi tu stesso o che lo faccia uno strumento di sicurezza.
Il prossimo passo pratico dopo aver decodificato un comando sospetto è segnalarlo al team appropriato. Se si tratta del tuo sistema, determina se l'attività è stata creata intenzionalmente e da chi. Controlla la data di creazione e l'account che l'ha pianificata. Se l'attività non è autorizzata, disattivala, conserva i dettagli per gli esperti forensi e indaga su come l'aggressore ha ottenuto il privilegio di crearla. Se il comando contiene richieste di rete o meccanismi di persistenza come modifiche al registro o creazione di attività pianificate, è quasi certamente dannoso.
Conclusione: Base64 è offuscamento, non protezione: come il codificatore e decodificatore Base64 decodifica il carico utile localmente senza che questo lasci mai la macchina
Se esegue funzioni amministrative legittime e i dettagli di creazione sono normali, potrebbe trattarsi di uno script amministrativo legittimo codificato per motivi legati alla politica di sicurezza o all'integrazione con uno strumento di automazione più ampio. Non eseguirlo in alcun modo; lascia che la tua valutazione del testo decodificato influisca sulla tua decisione. La decodifica sicura dei comandi PowerShell Base64 sospetti segue un processo semplice. Utilizza il codificatore e decodificatore Base64 per decodificare la stringa senza caricarla o eseguire nulla. Guarda la vista esadecimale per capire cosa rappresentano i byte.
Se vedi modelli UTF-16LE (zero byte interleaved) ricorda che PowerShell utilizza UTF-16LE e leggi di conseguenza. Identifica eventuali modelli sospetti come richieste di rete, elevazione dei privilegi o meccanismi di persistenza. Registra accuratamente i dettagli per il rapporto sull'incidente, inclusa la stringa Base64 originale e il relativo hash. Non eseguire mai il comando da soli; lascialo ai soccorritori in un ambiente controllato. Fidati della tua decodificazione locale e della tua valutazione del testo in chiaro e lascia che guidino la tua prossima azione.