Manejo seguro de llaves criptográficas y accesos

Los operadores interactúan con docenas de servidores virtuales en la nube para gestionar redirigidores y proxies. Cada servidor debe configurarse con autenticación por llave pública SSH, desactivando por completo el acceso con contraseña mediante PasswordAuthentication no.

Las llaves privadas SSH almacenadas en el equipo del operador deben protegerse siempre con una frase de paso (passphrase) robusta y, preferiblemente, custodiadas en dispositivos de seguridad física (tokens de hardware como llaves FIDO2 o YubiKeys), evitando que un malware en la estación de trabajo extraiga llaves privadas en texto plano.

Abre fugas_comunes.txt en la consola del laboratorio. Revisa la cuarta viñeta de la lista.

Cuando se despliegan canales C2 HTTPS cifrados, cada dominio y canal debe contar con certificados TLS independientes emitidos específicamente para ese nombre de host. Si un equipo genera un certificado autofirmado con un número de serie o datos organizacionales idénticos, o reutiliza un certificado wildcard en múltiples clientes diferentes, los analistas de inteligencia defensiva correlacionan de inmediato ambas campañas como originadas por el mismo actor.

Los frameworks modernos de C2 registran en bases de datos SQLite o PostgreSQL cada comando ejecutado, cada captura de pantalla obtenida y cada hash extraído del cliente.

Si el servidor de equipo (Teamserver) es requisado o analizado tras una detección defensiva, el disco no debe revelar credenciales ni datos confidenciales del cliente en texto plano. Todos los volúmenes de almacenamiento deben implementar cifrado de disco completo (LUKS / dm-crypt) con llaves que no residan en el propio proveedor de nube.