Español

Herramientas de desarrollo · Codificador y decodificador Base64

Cómo decodificar un comando sospechoso de Base64 PowerShell sin ejecutarlo

· Por qué es importante

base64 seguridad

Una carga útil de PowerShell -EncodedCommand decodificada para revelar texto inofensivo sin ejecutarlo
Ilustración de vector original de ToolAcre

Los atacantes utilizan Base64 para ocultar scripts de una inspección casual. Esta publicación muestra cómo decodificar una carga útil -EncodedCommand sin ejecutarla, por qué la salida puede parecer extraña en un decodificador UTF-8 y qué buscar.

La tarea programada con un argumento de carácter 2,000: dónde aparecen los comandos codificados y por qué son una señal de alerta

Un administrador de sistemas descubre una tarea programada con un argumento 2,000-character -EncodedCommand que parece sospechoso. La tarea se ejecuta con una cuenta de servicio con altos privilegios.

La tentación de pegar el comando en PowerShell y ejecutarlo para ver qué hace es peligrosa; si el comando es malicioso, ejecutarlo compromete el sistema. El enfoque más seguro es decodificar Base64 localmente y leer el resultado como texto antes de decidir si ejecutar algo. Esta publicación explica cómo decodificar comandos de PowerShell de forma segura sin ejecutarlos, por qué la salida puede verse confusa en un decodificador UTF-8 estándar y qué buscar para evaluar si un comando es seguro o sospechoso.

Decodificar, nunca ejecutar: la regla que mantiene seguro el análisis y por qué un descodificador solo para navegador es una buena opción

La idea clave es que PowerShell usa codificación UTF-16LE para -EncodedCommand, no UTF-8, por lo que cada dos bytes es un cero que las herramientas estándar interpretan como terminadores nulos. La regla para analizar cualquier código sospechoso es simple: decodificar, nunca ejecutar. Esto se aplica a comandos codificados en Base64, scripts comprimidos, scripts de fuentes no confiables y cualquier cosa en una cadena de codificación desconocida. Ejecutar un script es el punto sin retorno; una vez que se ejecuta, se han producido cambios en el sistema, se ha concedido acceso y se han extraído datos.

Decodificar y leer el guión como texto le permite evaluarlo antes del paso irreversible. La segunda regla es utilizar una herramienta que se ejecute localmente y no realice solicitudes de red. Un decodificador basado en navegador es ideal porque es portátil, no requiere software adicional y mantiene la carga sospechosa en su dispositivo sin cargarla en ningún servidor. Si la herramienta es del tipo que se publica en un servicio de decodificador remoto, no la utilice; la carga útil luego se expone a ese servicio. El parámetro PowerShell -EncodedCommand acepta una cadena Base64 que, cuando se decodifica, contiene un script de PowerShell.

Por qué los bytes decodificados no se parecen al texto UTF-8: inspeccione el patrón de bytes UTF-16LE en hexadecimal en lugar de pedirle a esta herramienta de texto UTF-8 que lo interprete

Sin embargo, PowerShell no utiliza la codificación UTF-8 para esto; utiliza UTF-16LE (little-endian UTF-16). En UTF-16, cada carácter ASCII se representa como dos bytes: el código de carácter seguido de un byte cero. La letra A es 41 00 en hexadecimal. La letra B es 42 00. Una cadena como Hola aparece como 48 00 65 00 6C 00 6C 00 6F 00 en bytes UTF-16LE. Cuando está codificado en Base64, el resultado contiene la forma codificada de todos esos bytes, incluidos todos los ceros. La decodificación con un decodificador UTF-8 estándar produce texto confuso o trunca en el primer byte cero porque UTF-8 trata los bytes nulos como terminadores de cadena.

El resultado se parece a H e l o en lugar de Hello, con caracteres aparentemente aleatorios o texto faltante. Un ejemplo trabajado muestra el problema y la solución. Supongamos que un comando de PowerShell codifica la cadena simple Write-Host Hello. PowerShell UTF-16LE codifica esto en bytes, incluidos todos los ceros, Base64 codifica los bytes y produce una cadena larga como VwByAGkAdABlAC0ASwBvAHMAaAAgACIASABlAGwAbABvACIA. Copie esta cadena en el codificador y decodificador Base64 de su navegador y haga clic en Decodificar. El decodificador predeterminado intentará interpretar el resultado como texto UTF-8 y producirá una salida corrupta o truncada debido a los ceros incrustados.

Ejemplo resuelto: decodificar un comando codificado de muestra inofensivo: leer el texto más allá de los cero bytes intercalados

La solución es utilizar la vista hexadecimal. Cambie a la vista hexadecimal y verá los bytes: 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. Leer esos bytes como pares UTF-16LE produce W-r-i-t-e---K-o-s-h---H-e-l-l-o-. Con experiencia, puede leer UTF-16LE hexadecimal directamente o puede escribir los bytes en un archivo y decodificarlos con un script de PowerShell o Python ejecutándose localmente.

El enfoque práctico es observar el patrón y recordar que PowerShell usa UTF-16LE. Cuando decodifica PowerShell -EncodedCommand en el navegador y el resultado parece incorrecto, mire la vista hexadecimal en lugar de la vista de texto. La vista hexadecimal muestra cada byte individualmente. Cada carácter ASCII aparece como dos bytes con un cero entre ellos. Si los bytes detallan comandos maliciosos como New-AdminAccount, búsquedas inversas de DNS o exportación de credenciales de seguridad, el comando es sospechoso. Si los bytes indican algo inofensivo como una lista de directorio o un script simple, es probable que el comando sea benigno.

Codificación y compresión anidadas: Base64 dentro de Base64 y transmisiones gzip que no se pueden leer como texto

La vista hexadecimal es más difícil de leer que el texto sin formato, pero es más seguro que adivinar a partir de una salida UTF-8 corrupta. La codificación y compresión anidadas añaden complejidad al análisis de malware. Un comando de PowerShell puede codificar en Base64 otra cadena Base64 o comprimir un script con gzip y luego codificar en Base64 el resultado. En un escenario anidado, decodifica el Base64 externo, lee el resultado y descubre que él mismo es base64. Decodifica eso también y continúa hasta que encuentres texto legible o un formato binario que no puedas interpretar. Gzip y otros formatos de compresión comienzan con bytes mágicos (1F 8B para gzip) visibles en la vista hexadecimal.

Si decodifica Base64 y la vista hexadecimal comienza con 1F 8B, los bytes son una secuencia comprimida que requiere descompresión. El codificador y decodificador Base64 le muestra el hexadecimal, ayudándole a identificar estos patrones sin ejecutar nada. Las cargas útiles comprimidas o codificadas adicionalmente son sospechosas porque agregan capas de ofuscación.

Qué registrar para un informe de incidente: el texto decodificado, la fuente y los hashes en lugar de la carga útil en sí

Los comandos legítimos rara vez requieren múltiples pasos de codificación. Registrar los hallazgos para un informe de incidente requiere disciplina y precisión. Escriba la cadena Base64 exacta que analizó, dónde la encontró y cuándo. Si lo decodificaste y encontraste comandos sospechosos, describe los comandos pero no incluyas el script completo en el informe todavía; el guión puede ser complejo o largo.

Incluya un hash (SHA-256) del script decodificado para que se pueda verificar y rastrear el hallazgo. Si el comando es claramente malicioso o utiliza técnicas de explotación conocidas, involucre a los equipos de seguridad y respuesta a incidentes antes de tomar cualquier medida. Nunca ejecute el comando usted mismo para ver qué hace. Si los servicios de respuesta a incidentes necesitan ejecutarlo para realizar pruebas, lo hacen en un entorno aislado donde se contiene cualquier daño. Su trabajo consiste en decodificar y evaluar el riesgo a una distancia segura. Este artículo no cubre el alcance completo del análisis de malware, los entornos sandbox o la atribución de ataques.

Lo que esto no cubre: ejecución en sandbox, herramientas de análisis de malware y atribución

Esos son temas para profesionales de seguridad y equipos de respuesta a incidentes. El alcance aquí se centra estrictamente en decodificar de forma segura un comando PowerShell codificado sin ejecutarlo, para que pueda leer el script y evaluar si vale la pena investigar más a fondo. La codificación Base64 es ofuscación, no protección. Cualquiera que tenga la codificación y un decodificador puede extraer el script. Los atacantes utilizan Base64 para evadir la detección básica y evitar inspecciones casuales, no para ocultar su intención del análisis. Un comando de PowerShell decodificado que recupera y ejecuta un script remoto es malicioso, ya sea que lo decodifique usted mismo o lo haga una herramienta de seguridad.

El siguiente paso práctico después de decodificar un comando sospechoso es informarlo al equipo apropiado. Si es su propio sistema, determine si la tarea fue creada intencionalmente y por quién. Consulta la fecha de creación y la cuenta que la programó. Si la tarea no está autorizada, desactívela, conserve los detalles para análisis forenses e investigue cómo el atacante obtuvo el privilegio para crearla. Si el comando contiene solicitudes de red o mecanismos de persistencia como cambios en el registro o creación de tareas programadas, es casi seguro que sea malicioso.

Conclusión: Base64 es ofuscación, no protección: cómo el codificador y decodificador Base64 decodifica la carga útil localmente sin que salga de su máquina

Si realiza funciones de administración legítimas y los detalles de creación son normales, podría ser un script administrativo legítimo que esté codificado por razones relacionadas con la política de seguridad o la integración con una herramienta de automatización más grande. No lo ejecutes de ninguna manera; deje que su evaluación del texto decodificado informe su decisión. La descodificación segura de comandos sospechosos de Base64 PowerShell sigue un proceso sencillo. Utilice el codificador y decodificador Base64 para decodificar la cadena sin cargarla ni ejecutar nada. Mire la vista hexadecimal para comprender qué representan los bytes.

Si ve patrones UTF-16LE (cero bytes entrelazados), recuerde que PowerShell usa UTF-16LE y lea en consecuencia. Identifique cualquier patrón sospechoso, como solicitudes de red, elevación de privilegios o mecanismos de persistencia. Registre los detalles con precisión para su informe de incidente, incluida la cadena Base64 original y su hash. Nunca ejecute el comando usted mismo; Deje eso en manos del personal de respuesta a incidentes en un entorno controlado. Confíe en su decodificación local y en su evaluación del texto sin formato, y deje que eso guíe su próxima acción.