He conseguido una shell: ¿y ahora qué?

1. El orden importa: contexto antes que profundidad

Este checklist está pensado para los primeros quince minutos después de obtener una shell. Su objetivo no es escalar privilegios ni moverse a otro sistema, sino responder de forma reproducible: quién soy, dónde estoy, qué red ve el host, qué actividad sostiene su funcióny qué rutas merecen una revisión posterior autorizada. Ejecuta un bloque, interpreta su salida y anota el límite antes de continuar.

• □Confirmar activo, horario, cuenta permitida y contacto de emergencia
• □Registrar identidad efectiva, terminal o proceso de shell y hora con zona horaria
• □Identificar hostname, versión y arquitectura del sistema operativo
• □Inventariar interfaces, direcciones, DNS y rutas sin generar tráfico de reconocimiento
• □Observar usuarios, procesos, servicios y sockets; no detener ni modificar ninguno
• □Revisar solo metadatos de archivos dentro de rutas autorizadas
• □Conservar salida mínima, errores y conclusiones separando hecho de inferencia

2. Checklist: identidad, hostname y sistema operativo

Empieza por la identidad efectiva, no por el nombre que te hayan dado. En Windows, whoami /allmuestra usuario, grupos y privilegios del token actual; en Linux, id muestra UID, GID y grupos. La hora sirve para correlacionar tu actividad con registros defensivos. El proceso de la shell ayuda a explicar por qué una propiedad o comando puede no estar disponible.

Comprueba ahora que el nombre del host pertenece al activo autorizado. Una versión de kernel no equivale siempre a la distribución; por eso Linux combina uname con /etc/os-release. En Windows,Get-ComputerInfo reúne producto, versión, build y arquitectura. Una ruta de proceso vacía o un campo omitido puede ser un límite de permisos o de compatibilidad, no una invitación a elevarlos.

3. Checklist: interfaces, DNS y rutas

Estas órdenes leen la configuración local: no escanean subredes ni prueban conectividad con otros hosts. Relaciona cada dirección con su interfaz y busca la ruta por defecto. Una interfaz de contenedor, VPN o loopback no demuestra por sí sola que exista una red alcanzable desde fuera. DNS indica resolutores configurados; no confirma que respondan.

4. Checklist: usuarios, procesos, servicios y escuchas

Separa cuentas configuradas, sesiones activas y procesos. No son la misma cosa. La lista de cuentas ayuda a entender el rol del host, mientras que las sesiones y procesos son una fotografía cambiante. En Linux,getent respeta las fuentes de identidad configuradas; en Windows, Get-LocalUser muestra cuentas locales y puede no estar disponible en PowerShell de 32 bits sobre un sistema de 64 bits.

Ordena procesos para reducir ruido, pero no interpretes consumo alto como actividad maliciosa. Después cruza servicios activos con sockets en escucha. Un puerto confirma una escucha local, no su exposición desde otra red. Algunos nombres de proceso o rutas solo son visibles con permisos superiores; registra esa ausencia.

5. Checklist: qué significa «archivo interesante»

Interesante significa relevante para el rol técnico del activo: configuración de la aplicación, logs, directorios temporales, despliegues recientes o rutas autorizadas con permisos inesperados. Empieza por metadatos. No abras el contenido hasta que la necesidad y la autorización estén documentadas. Limita siempre la raíz, el sistema de archivos y la profundidad; una búsqueda desde / o C:\ añade ruido, carga y datos fuera del objetivo.

6. Guarda evidencia mínima sin ensuciar el objetivo

La opción preferida es capturar la transcripción desde la estación del analista. Si las reglas permiten crear archivos temporales en el objetivo, usa una carpeta dedicada, permisos restrictivos y solo las consultas necesarias. No incluyas el listado de archivos sensibles. Calcula el hash después de cerrar el archivo: un hash demuestra si cambió, no quién lo creó ni si su contenido es verdadero.

7. Interpreta, comunica y cierra la sesión

Convierte la salida en frases verificables: «observé una ruta por defecto mediante interfaz X» es un hecho; «el host puede alcanzar toda la red» es una hipótesis que requeriría una prueba adicional autorizada. Una ausencia también necesita contexto: un servicio puede usar otro gestor, un cmdlet puede faltar o la shell puede estar dentro de un contenedor.

• □El hostname y el activo autorizado coinciden; si no, detuve la actividad
• □He registrado usuario, grupos, hora, proceso de shell, SO y arquitectura
• □He asociado interfaces con direcciones y rutas sin conectar a nuevos destinos
• □He distinguido cuentas, sesiones, procesos, servicios y sockets
• □Solo he recogido metadatos de rutas explícitamente autorizadas
• □Los errores de permisos figuran como límites y no intenté elevar privilegios
• □La evidencia mínima tiene fecha, autor, ubicación, hash y acceso restringido
• □Cada conclusión separa observación, inferencia y siguiente validación autorizada

Glosario