Cómo transferir archivos entre tu máquina y el objetivo

1. Elige por dirección, confianza y requisitos

Una transferencia tiene cinco piezas: origen, destino, iniciador, transporte y verificación. En un pull, el objetivo solicita un archivo a tu máquina; en un push, el origen lo envía a un servicio autorizado. Antes de copiar, decide qué lado puede escuchar, qué puerto permite la red y qué autenticación exige la política.

• □Origen y destino son 192.168.56.10 y 192.168.56.20 dentro de una red host-only propia
• □Solo se moverán muestra.txt y resultado-lab.txt, ambos creados para el ejercicio
• □El archivo final no reemplazará uno existente: primero se guarda con sufijo .part
• □El hash SHA-256 de origen se conoce antes de iniciar la copia
• □Existe una hora de cierre y un responsable para autorizar cambios de firewall o servicios

2. Prepara un archivo inocuo y una verificación independiente

La máquina del analista usa 192.168.56.10 y el objetivo de laboratorio192.168.56.20. Sustituye estas direcciones únicamente por las de tu red privada autorizada. Crea el archivo fuera de cualquier carpeta con datos reales y calcula su hash antes de iniciar un servidor.

Los archivos creados por PowerShell y por printf pueden tener bytes distintos por codificación o final de línea; no compares hashes entre recetas. Compara siempre el hash del archivo concreto servido con el recibido. Un nombre igual no demuestra integridad.

3. HTTP temporal: Python, curl y wget

python -m http.server sirve el directorio indicado y, si no especificas --bind, puede escuchar en todas las interfaces. En este laboratorio se vincula solo a la interfaz host-only del analista. No lo uses para archivos sensibles ni redes compartidas: no tiene autenticación ni TLS. Déjalo en primer plano para ver solicitudes y detenlo con Ctrl+C al terminar.

En el objetivo Linux, descarga primero a .part. curl --fail devuelve error ante códigos HTTP 400 o superiores y --show-error conserva el diagnóstico. Wget es una alternativa; su opción-O crea o trunca el destino al comenzar, por lo que también usa un nombre parcial. Renombra solo después de que el hash coincida con el origen.

4. SCP sobre SSH: cifrado, autenticación y ambos sentidos

SCP requiere un servidor SSH ya autorizado en el lado remoto y una cuenta válida. Desde OpenSSH 9.0,scp usa SFTP por defecto. En el primer contacto, compara la huella de la clave del host por un canal independiente; no uses StrictHostKeyChecking=no ni aceptes una clave cambiada sin investigación. La opción -p conserva fechas y modos, así que omítela si la política exige permisos nuevos del destino.

Para comprobar el sentido inverso, crea en el objetivo un archivo ficticio y envíalo a la carpeta de entrada del analista. Este paso requiere que el analista tenga un servidor SSH autorizado; si solo dispone de cliente, inicia el scp desde el analista y usa la sintaxis remota como origen.

5. SMB: usa un recurso administrado, no uno improvisado

SMB permite leer y escribir mediante una ruta UNC como \\192.168.56.10\CubixLab. Esta guía asume que un administrador ya creó el recurso con carpetas salida e entrada, una cuenta individual, auditoría y permisos mínimos. No habilites SMB1, acceso guest ni una regla global de firewall para completar el ejercicio. Introduce la credencial de forma interactiva; nunca la pongas en la línea de comandos, una URL, un script o el historial.

En Linux, smbclient ofrece una interfaz de cliente sin montar el recurso. -U recibe el usuario y solicita la contraseña; no añadas %contraseña. Verifica el hash y limita las operaciones a los dos archivos de laboratorio.

6. Alternativas nativas cuando Windows no tiene la primera herramienta

Comprueba disponibilidad antes de cambiar de técnica. curl.exe evita la ambigüedad del aliascurl en Windows PowerShell antiguo. Invoke-WebRequest existe desde PowerShell 3 y-OutFile guarda la respuesta. BITS es apropiado para un endpoint HTTP(S) o SMB administrado y puede ofrecer diagnóstico del trabajo, pero depende del servicio BITS y de las políticas del equipo.

Si BITS entra en estado de error, consulta Get-BitsTransfer -AllUsers solo con autorización administrativa; desde una cuenta normal usa Get-BitsTransfer para tus propios trabajos. No fuerces credenciales almacenadas ni relajes validación TLS para hacerlo funcionar.

7. Cuando falla: diagnostica de abajo arriba

Cambiar de herramienta sin localizar la capa suele repetir el mismo fallo. Empieza por el nombre o la IP, continúa con ruta y puerto, confirma el servicio, revisa la respuesta del protocolo y termina en permisos e integridad. Ejecuta una sola prueba por vez y conserva el mensaje completo.

Un error TLS se corrige usando el nombre esperado y una CA confiable, no con -k,--no-check-certificate o -SkipCertificateCheck. Si EDR, AppLocker, firewall o proxy bloquean la transferencia, registra producto, regla, hora y operación; solicita el canal corporativo aprobado. Ese bloqueo es una señal defensiva válida, no un obstáculo que esta guía deba sortear.

8. Ejercicio verificable y limpieza

Completa dos recorridos: muestra.txt del analista al objetivo yresultado-lab.txt del objetivo al analista. Usa HTTP para el primero y SCP o el recurso SMB administrado para el segundo. Registra método, iniciador, origen, destino, tamaño, hash, hora y resultado. El ejercicio termina cuando ambos hashes coinciden y los servicios temporales están detenidos.

• □Los únicos archivos transferidos fueron muestra.txt y resultado-lab.txt
• □Cada descarga usó un nombre .part hasta verificar SHA-256
• □Python escuchó solo en 192.168.56.10 y terminó con Ctrl+C
• □SCP verificó la clave del host y no desactivó StrictHostKeyChecking
• □SMB usó cuenta individual, recurso autorizado y credencial interactiva
• □No se desactivó EDR, firewall, proxy, TLS, firma SMB ni otro control
• □Los fallos se clasificaron por capa antes de elegir una alternativa
• □La bitácora conserva hashes y mensajes, pero no credenciales ni contenido sensible

Glosario