Hacking ético en Windows

Escrito por

Hacking ético en Windows

Montar un laboratorio de hacking ético en Windows é totalmente viable e non require unha inversión económica elevada. A clave está en combinar virtualización (para crear unha contorna illada, segura e repetible), xunto coas ferramentas axeitadas. Aquí tes unha guía paso a paso, dende os cimentos ata as prácticas máis avanzadas.

⚖️ Paso 0: Principios éticos e legais (o primeiro!)

Antes de instalar nada, ten claro que este laboratorio debe estar destinado ao uso educativo e en sistemas propios, ou en contornas con autorización expresa.

[!WARNING]

Practicar técnicas de hacking contra sistemas alleos, sen autorización explícita, é ilegal e pode conlevar problemas legais.

Todo o tráfico das prácticas debe quedar confinado dentro do laboratorio – con máquinas virtuais ou contedores-, sen que o tráfico "se escape" á túa rede doméstica ou a Internet.

💻 Paso 1: Preparando o hardware e o software base

No necesitas un equipo de gama alta para empezar, pero sí unos mínimos para que todo flúa.

  • Hardware mínimo:
    • Un procesador de 4 núcleos con virtualización habilitada no firmware/UEFI (VT-x en Intel/AMD-V en AMD)
    • 16GB de RAM é o recomendable. Aínda que con 8GB poderías empezar, vas ir moi xusto se queres ter varias máquinas á vez – maquina atacante/máquina vítima, simular unha pequena rede,…-.
    • Espazo en disco: idealmente un SSD e con bastante espazo, xa que as máquinas virtuais ocupan moito.
  • Hipervisor (o corazón do laboratorio): É o software que che permite crear e xestionar máquinas virtuais (VMs). Tes varias opcións gratuítas:
    • VirtualBox: Unha opción libre, gratuíta e moi popular, ideal para empezar.
    • VMware Workstation Pro: Considerado por moitos o estándar da industria polo seu rendemento. É gratuíto para uso persoal desde fai tempo, o que o convirte nunha excelente opción.
    • Hyper-V: Xa ven integrado nas versións Pro de Windows. É unha alternativa nativa e eficiente, especialmente si planeas montar un laboratorio de Active Directory.

🌐 Paso 2: Configurar unha rede illada (o paso máis crítico)

Este é o punto que garante que o teu laboratorio sexa seguro. Non uses a configuración de rede por defecto (NAT ou Bridge) para as túas máquinas de prácticas, xa que poderían ter acceso á túa rede real.

A solución é crear unha rede interna ou "Host-Only". Nesta configuración, as máquinas virtuais só poden comunicarse entre elas e co teu equipo anfitrión, pero non teñen saída a Internet, mantendo todo o tráfico de probas contido.

  • En VirtualBox: Vai a `File → Host Network Manager e crea unha nova rede (ej. vboxnet0). Logo, na configuración de rede de cada VM, selecciona "Host-only" e elixe esa rede.
  • En VMware: Podes usar o "Virtual Network Editor" para crear unha rede "Host-only" personalizada (ej. VMnet1) e asignarlla ás túas VMs.

🎯 Paso 3: Desprega as máquinas virtuais clave

Co hipervisor e a rede listos, é o momento de crear as VMs. A estrutura clásica é unha máquina atacante e unha ou varias máquinas obxectivo.

1. A máquina atacante: Kali Linux
Kali Linux é a distribución de referencia para pentesting, con máis de 600 ferramentas preinstaladas. A forma máis sinxela de tela é descargar a imaxe OVA desde a súa web oficial e importala directamente no teu hipervisor (VirtualBox ou VMware).

2. As máquinas obxectivo (vulnerables a propósito)
Aquí tes un abanico de opcións, dende clásicas ata modernas:

  • Metasploitable 2/3: A opción clásica para principiantes. Unha VM Linux chea de vulnerabilidades coñecidas, perfecta para aprender os fundamentos.
  • OWASP Juice Shop: Unha aplicación web moderna, deliberadamente vulnerable, ideal para practicar seguridade web (SQLi, XSS, etc.).
  • GOAD (Game of Active Directory): Unha entorna completa e vulnerable de Active Directory. É máis avanzado e require máis recursos, pero é excelente para practicar ataques a directorios activos.
  • Windows 10/11 de avaliación: Podes descargar unha ISO de avaliación de Microsoft e instalala como VM para practicar técnicas de escalada de privilexios en Windows.
  • A pouco que te vaias interesando polo tema veras que existen centos de máquinas expresamente preparadas para experimentar todo tipo de ataques e explotar as súas vulnerabilidades.

💎 Notas sobre a filosofía do laboratorio

A grande vantaxe deste enfoque é a desbotabilidade. Se un contedor de prácticas queda comprometido ou simplemente se "rompe", non hai problema: elimínao (podman rm) e volve crear un novo a partir da imaxe base en segundos. O teu sistema anfitrión permanece intacto. Isto é precisamente o que buscas nun laboratorio de seguridade.

🧰 Paso 4: Complementa con ferramentas nativas de Windows

Aínda que Kali dentro dunha VM ou en WSL2 é a túa navalla suíza, Windows tamén ten ferramentas nativas moi potentes que vale a pena instalar no teu sistema anfitrión (ou nunha VM de Windows se o prefires):

  • Burp Suite (Community): O proxy de interceptación web por excelencia para auditar aplicacións.
  • Nmap/Zenmap: Para o descubrimento de redes e o escanéo de portos. Zenmap é a súa interface gráfica.
  • Wireshark: O analizador de tráfico de rede máis coñecido, para inspeccionar paquetes a baixo nivel.
  • Ferramentas de Active Directory: Se o teu obxectivo é este eido, BloodHound (para mapear rutas de escalada de privilexgios) e Mimikatz (para o volcado de credenciais) son fundamentais e se executan de forma nativa en Windows.

Podes instalar moitas destas ferramentas de forma masiva e sinxela usando o xestor de paquetes de Windows, winget, con comandos como: winget install --id Insecure.Nmap ou winget install --id WiresharkFoundation.Wireshark.

💡 Boas prácticas para o teu laboratorio

  • Instantáneas (Snapshots): Toma sempre unha instantánea dunha VM xusto antes de empezar a "hackeala". Se algo se rompe ou queres reiniciar o exercicio, poderás volver a ese estado limpo en segundos.
  • Documentación: Leva un rexistro do que fas. Practicar a escritura dun breve "informe" despois de cada máquina (vulnerabilidade atopada, exploit usado, solución) é unha habilidade tan importante como a técnica.
  • Empeza simple e escala: Comeza cunha Kali e unha Metasploitable en rede Host-Only. Cando domines iso, engade Juice Shop, unha Windows de avaliación, e finalmente a contorna AD.

Montar este laboratorio é unha inversión de tempo que che proporcionará un espazo seguro e repetible para aprender e practicar sen riscos (aínda que xa deberías saber que o risco cero non existe!).

⚡ Alternativa lixeira: Kali en WSL2 + Podman

Se o teu equipo ten recursos limitados ou prefires non usar VMs completas, podes montar un laboratorio moi funcional usando WSL2 (Subsistema de Windows para Linux).

O obxectivo é ter un contedor de Kali Linux funcionando nunha rede illada, listo para as prácticas.

Paso 1: Preparar o terreo (WSL2)

Podman en Windows non corre de forma nativa; necesita unha máquina virtual Linux. A forma máis lixeira é usar WSL2.

  1. Abre PowerShell como administrador.

  2. Instala WSL2 sen unha distribución Linux predeterminada. Isto evita duplicar recursos, xa que Podman xestionará a súa propia máquina:

    wsl --install --no-distribution

  3. Reinicia o equipo para que os cambios se apliquen.

Paso 2: Instalar Podman Desktop

A forma máis sinxela de xestionar Podman e a súa máquina virtual en Windows é a través da súa aplicación de escritorio.

  1. Descarga o instalador desde a web oficial de Podman Desktop
  2. Executa o instalador e segue os pasos. Podes elixir instalalo para todos os usuarios ou só para o actual.

Paso 3: Crear e configurar a "Podman machine"

Ao iniciar Podman Desktop por primeira vez, este guiarache para crear a máquina virtual que executará os contedores.

  • Punto clave (aforro de recursos): No asistente de creación, podes axustar os recursos (CPU, memoria, disco). Para un laboratorio lixeiro, podes asignarlle uns 2 CPUs e 4 GB de RAM, que é suficiente para un contedor de Kali.
  • Opción de rede: Se usas VPN ou tes problemas de conectividade, podes activar a opción "User-mode networking" (rede en modo usuario), que fai que o tráfico se encamiñe a través do host.

Se prefires a liña de comandos, podes crear a máquina directamente co comando podman machine init. A documentación oficial indica que, en Windows, o provedor por defecto é WSL.

⚠️ Advertencia importante sobre systemd: Un erro moi común é tentar activar systemd dentro da máquina de WSL. Non o fagas. A documentación de Podman e os propios mantenedores indican que Podman non é compatible con systemd activado en WSL e que este debe estar desactivado para un funcionamento correcto.

Paso 4: Obter e executar a imaxe de Kali Linux

Kali Linux ofrece imaxes oficiais de contedor. Podes descargala e executala dende a terminal integrada de Podman Desktop ou dende PowerShell.

  1. Descarga a imaxe oficial:

    podman pull docker.io/kalilinux/kali-rolling

  2. Executa un contedor interactivo. O seguinte comando inicia un contedor de Kali, expón o porto 22 (SSH, se o necesitas) e mapea o porto 8080 do host ao 80 do contedor (útil para ferramentas web):

    podman run -it --name kali-lab -p 8080:80 docker.io/kalilinux/kali-rolling /bin/bash

    Unha vez dentro, podes actualizar e instalar as ferramentas que necesites (Metasploit, Nmap, etc.).

Paso 5: Configurar a rede illada do laboratorio

Aquí está a diferenza crave con respecto a un laboratorio con VMs tradicionais. En Podman, o illamento lógrase mediante redes definidas polo usuario (redes bridge personalizadas).

O modo de rede predeterminado para contedores rootless é pasta, que ofrece unha conectividade eficiente pero, por defecto, illa o contedor da rede local. Para que os teus contedores (por exemplo, Kali e Metasploitable2) se comuniquen entre si pero non co exterior, debes crear unha rede dedicada.

  1. Crea unha rede illada:

    podman network create --subnet 10.89.0.0/24 lab-net

  2. Conecta os contedores a esa rede. Ao executar un contedor, usa a opción --network para unilo á rede que creaches:

    podman run -it --name kali-lab --network lab-net docker.io/kalilinux/kali-rolling /bin/bash

  3. Fai o mesmo cos obxectivos. Por exemplo, para un contedor de Metasploitable2:

    podman run -d --name metasploitable --network lab-net

Desta forma, kali-lab e metasploitable poderán resolverse por nome e comunicarse dentro da rede 10.89.0.0/24, pero o tráfico non sairá cara á túa rede doméstica.

🧰 Solución de problemas comúns (e esperados)

Como vimos, a integración de Podman con WSL2 ten algún pequeno atranco ("papercut"). Aquí tes os máis habituais e como resolvelos:

  • Erro de cgroups v2: Se ao executar podman stats ves un erro relacionado con cgroups, tes que forzar a v2. Crea ou edita o arquivo %UserProfile%\.wslconfig e engade:

    [wsl2]
kernelCommandLine = cgroup_no_v1=all

    Despois, executa wsl --shutdown e reinicia Podman.

  • Advertencia de "shared mount": Se ves un aviso de que / non é unha montaxe compartida, podes executar estes comandos dentro da túa sesión de WSL (non persistirá tras un reinicio, pero serve como solución temporal):

    sudo mount -o remount,shared /
podman system reset

  • Problemas de permisos con contedores *rootless*: Se atopas erros de permisos ao crear arquivos, podes engadir a opción --userns=keep-id ao comando podman run para mapear o teu usuario do host co do contedor.

[!TIP]

Para un laboratorio de seguridade web, a opción profesionalmente máis sólida é unha máquina virtual completa (Hyper-V, que xa tes en Windows Pro, ou VirtualBox) cunha distribución Linux lixeira (Kali, Debian, Ubuntu Server). Dentro desa VM, podes executar Podman con redes --internal para os escenarios con múltiples contedores. A vantaxe é que a VM ten kernel e hardware virtual independentes, polo que unha escalada desde un contedor queda contida dentro da VM, e non toca o teu Windows nin o teu WSL2 de desenvolvemento.

O fluxo de traballo sería:

  1. VM anfitrioa do laboratorio: unha VM Linux dedicada, con Podman instalado.
  2. Contedores de práctica dentro da VM: Kali, aplicacións vulnerables, etc., conectados a unha rede --internal de Podman.
  3. Illamento total: a VM non comparte cartafoles con Windows, non ten acceso á túa rede doméstica (configuración de rede host-only ou internal no hipervisor), e podes tomar instantáneas (snapshots) para revertir a un estado limpo tras cada práctica.
Etiquetas: