Practicar en el laboratorio y ver los eventos en Kibana

Empezar: descubrir equipos

Con el túnel activo, desde tu máquina de ataque (yo uso NetExec en WSL):

$ nxc smb 10.2.10.0/24

Debe listar los tres Windows con su nombre, dominio, versión y si firman SMB. Alternativa con nmap:

$ nmap -Pn -p 445,5985,3389,1433,88 --open 10.2.10.0/24

Los puertos que salen aquí (88, 5985, 3389...) son los mismos que luego aparecen en Kibana como conexiones entrantes registradas.

Escanea 10.2.10.0/24 (GOAD). La 10.2.20.0/24 es Elastic. A partir de aquí es el flujo normal: SMB y LDAP anónimos, Kerberos, enumeración y movimiento lateral.

$ nxc smb 10.2.10.10 -u '' -p '' --shares$ nxc ldap 10.2.10.10 -u '' -p ''

Dónde se ve cada cosa en Kibana

Hay dos sitios y se confunden:

• Discover → eventos crudos. Aquí aparece todo lo que registran los hosts
• Security → Alerts → solo lo que dispara una regla de detección

Crea una data view logs-* con campo de tiempo @timestamp y pon el selector de tiempo en Last 15 minutes. Estos son los data streams que llegan:

• system.security → eventos de Seguridad de Windows
• windows.sysmon_operational → Sysmon
• windows.powershell → PowerShell
• endpoint.events.* → Elastic Defend

Ver tu propio nxc en Kibana y en Elasticsearch

Justo después de lanzar los comandos de arriba, abre Discover en https://10.2.20.2:5601/app/discover, elige la data view logs-*, pon Last 15 minutes y pega esta consulta con la IP de tu túnel WireGuard (la de Address en tu .conf):

source.ip: "198.51.100.3"

Lo que aparece con seguridad es el inicio de sesión anónimo en red: eventos 4624 (y 4634 al cerrar) con user.name: ANONYMOUS LOGON en los tres hosts. El resto (el STATUS_ACCESS_DENIED de los shares o el bind de LDAP rechazado) depende de la auditoría de cada equipo, así que compruébalo con la propia consulta. Y recuerda: es un evento en Discover, no una alerta, porque ninguna regla por defecto cubre el logon anónimo.

Si prefieres consultar Elasticsearch directamente, usa la consola de Kibana, en https://10.2.20.2:5601/app/dev_tools#/console:

GET logs-*/_search
{
  "size": 5,
  "sort": [{ "@timestamp": "desc" }],
  "_source": ["@timestamp", "host.name", "event.code", "user.name", "source.ip"],
  "query": {
    "bool": {
      "filter": [
        { "term": { "source.ip": "198.51.100.3" } },
        { "range": { "@timestamp": { "gte": "now-15m" } } }
      ]
    }
  }
}

La API también responde en el puerto 9200 (https://10.2.20.2:9200) con el usuario elastic, pero desde la consola de Kibana te ahorras gestionar el certificado y la autenticación.

Qué genera cada acción de nxc

• Login SMB o WinRM fallido → Security 4625
• Login válido → Security 4624 (y 4768/4769 con Kerberos)
• Enumerar usuarios y grupos → Security 4798 y 4799
• Kerberoast / AS-REP → 4769 / 4768
• Acceso a shares → 5140 / 5145
• Ejecución por WinRM → proceso wsmprovhost.exe

Y consultas KQL para pegar en Discover:

event.dataset: "system.security" and winlog.event_id: (4625 or 4771 or 4776)

winlog.event_id: (4798 or 4799)

process.name: "wsmprovhost.exe" or process.parent.name: "wsmprovhost.exe"

Para ver solo tu actividad, filtra por la IP de tu túnel WireGuard (la de Address en tu .conf):

source.ip: "<IP-de-tu-túnel>"

Lo que sí salta y lo que no

Un descubrimiento con nxc smb sin credenciales genera eventos 4624 de ANONYMOUS LOGON (tipo de inicio de sesión de red) en los tres hosts, con tu IP del túnel como origen. Aparece en Discover pero no en Alerts, porque no hay una regla por defecto para eso.

• Escaneo de puertos sin autenticar → no genera ningún inicio de sesión, pero Elastic Defend sí registra las conexiones entrantes (endpoint.events.network, event.action: connection_accepted, con tu IP como source.ip y el puerto en destination.port). Aparece en Discover, no como alerta
• Null session o enumeración → eventos en Discover, y alerta si una regla lo cubre ("Windows Account or Group Discovery")
• Ejecución por WinRM → alerta "Incoming Execution via WinRM Remote Shell"
• Volcado de LSASS, DCSync → tienen reglas predefinidas
• Kerberoast → la regla predefinida solo salta con tickets RC4 (0x17). En mi laboratorio los tickets salieron con AES256 (0x12) y no saltó nada: hizo falta una regla propia
• Fuerza bruta SMB con -u usuarios -p contraseñas → quedan como eventos 4625 y no saltan solos

Para que un barrido o una fuerza bruta aparezcan en Alerts hay que crear una regla de umbral propia. Por ejemplo:

• Nombre: "Brute force SMB - fallos 4625"
• Índice: logs-system.security-*
• Consulta: event.dataset: system.security and winlog.event_id: 4625
• Umbral: más de 10 en 5 minutos, agrupado por host.name o user.name

Los pings no se ven

El ICMP no crea conexión, así que ni el log de Seguridad, ni Sysmon (evento 3 es solo TCP/UDP), ni Elastic Defend lo registran. Si quieres verlo:

• Activar la auditoría de la plataforma de filtrado de Windows, que genera 5156/5157 e incluye ICMP:

auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable

• Añadir Packetbeat o la integración network_traffic con ICMP activado
• Usar tcpdump -ni any icmp en el router del laboratorio (10.2.10.254), que ve todo el tráfico de la VLAN

Detalles que ayudan

• Kibana pinta las fechas en tu zona horaria, pero @timestamp se guarda en UTC. Si no cuadra con tu reloj, mira Problemas y soluciones
• Los logs propios de nxc están en tu máquina atacante (~/.nxc/logs), no en Elastic
• El source.ip en los hosts puede salir como el del router del laboratorio si hay NAT de por medio
• Antes de una práctica seria, haz snapshots de las VMs desde Proxmox para poder volver atrás

Ideas de qué practicar

• Enumeración sin credenciales: SMB, LDAP, Kerberos
• Kerberoasting y AS-REP roasting, y comprobar qué regla salta
• Movimiento lateral con WinRM y ver el rastro de wsmprovhost.exe
• Ataques a ADCS y ACL de AD, que GOAD configura a propósito
• Cada ataque, después, mirado desde Kibana: qué dejó, qué detectó Elastic y qué no