Auditoría práctica con Seguridad de Windows y PowerShell
Tener un antivirus instalado y ver el icono del Firewall activo no significa que conozcamos realmente cómo está protegido un ordenador.
En esta práctica se audita un equipo real con Windows 11 utilizando únicamente las herramientas incluidas en el sistema y PowerShell. El objetivo consiste en comprobar qué antivirus protege realmente el equipo, qué funciones de Microsoft Defender están activas, qué exclusiones existen, qué detecta el antivirus y qué política aplica el Firewall de Windows.
Además, se realiza una comprobación práctica con qBittorrent para demostrar una diferencia importante:
Que exista una regla permitida en el Firewall no significa necesariamente que exista un puerto abierto.
1. Entorno de la prueba
- Windows 11.
- Microsoft Defender Antivirus.
- Firewall de Windows.
- PowerShell 5.1.
- Malwarebytes Premium instalado como protección adicional.
No se desactiva ninguna protección ni se realizan cambios deliberados en la configuración durante la auditoría.
2. ¿Qué antivirus está protegiendo realmente Windows?
La primera comprobación se realiza desde:
Seguridad de Windows → Configuración → Administrar proveedores
En el equipo analizado Windows muestra:
- Antivirus de Microsoft Defender: activo.
- Firewall de Windows: activo.
Aunque Malwarebytes Premium se encuentra instalado, Microsoft Defender continúa registrado como antivirus activo.
Esto ya permite descartar una suposición frecuente: instalar otro producto de seguridad no implica necesariamente que Defender pase a modo pasivo.
3. Comprobar las protecciones desde la interfaz
En:
Seguridad de Windows → Protección antivirus y contra amenazas → Administrar la configuración
se comprueba que están activadas:
- Protección en tiempo real.
- Protección basada en la nube.
- Envío automático de muestras.
- Protección contra alteraciones.
- Protección de unidad para desarrolladores.
Sin embargo, una auditoría no debería quedarse únicamente en la interfaz gráfica. Se contrasta el estado mediante PowerShell.
4. Obtener el estado real de Microsoft Defender con PowerShell
Se abre PowerShell como administrador y se ejecuta:
Get-MpComputerStatusEntre todos los campos disponibles, se identifican varios especialmente relevantes:
AMRunningMode : Normal
AntivirusEnabled : True
BehaviorMonitorEnabled : True
OnAccessProtectionEnabled : True
RealTimeProtectionEnabled : True
IoavProtectionEnabled : True
NISEnabled : True
IsTamperProtected : True
DefenderSignaturesOutOfDate : False
RebootRequired : FalseInterpretación
El resultado permite confirmar que Microsoft Defender funciona realmente como antivirus activo.
El campo:
AMRunningMode : Normalindica que Defender trabaja en funcionamiento normal y no simplemente como antivirus pasivo.
También se confirma que permanecen activas:
- la protección en tiempo real;
- el análisis de comportamiento;
- la protección al acceder a archivos;
- la inspección de red;
- la protección contra alteraciones.
Las firmas aparecen actualizadas el mismo día de la prueba.
Por tanto, en este equipo no solo se observa Defender en la interfaz: PowerShell confirma que sus principales componentes se encuentran funcionando.
5. Revisar configuración avanzada de Defender
A continuación se consulta una selección concreta de preferencias:
Get-MpPreference | Select-Object MAPSReporting,SubmitSamplesConsent,PUAProtection,EnableControlledFolderAccess,DisableRealtimeMonitoring,DisableBehaviorMonitoring,ExclusionPath,ExclusionProcess,ExclusionExtensionEl resultado observado incluye:
MAPSReporting : 2
SubmitSamplesConsent : 1
PUAProtection : 1
EnableControlledFolderAccess : 0
DisableRealtimeMonitoring : False
DisableBehaviorMonitoring : FalseQué se obtiene de estos datos
La protección en la nube y el envío de muestras se encuentran configurados y la protección frente a aplicaciones potencialmente no deseadas está activada.
También se vuelve a confirmar que:
DisableRealtimeMonitoring : Falsey:
DisableBehaviorMonitoring : FalseEs decir, no se encuentran deshabilitadas ni la protección en tiempo real ni la supervisión de comportamiento.
Sin embargo, aparece un elemento interesante:
EnableControlledFolderAccess : 0El Acceso controlado a carpetas se encuentra desactivado.
Este mecanismo puede añadir protección frente a modificaciones no autorizadas de archivos, especialmente ante determinados comportamientos asociados con ransomware, pero no se activa automáticamente durante esta auditoría. Antes de modificarlo conviene comprobar la compatibilidad con los programas utilizados habitualmente.
6. Revisar las exclusiones de Microsoft Defender
Las exclusiones merecen especial atención porque permiten que determinados archivos o carpetas no se analicen de la misma forma que el resto del sistema.
Se consultan con:
Get-MpPreference | Select-Object -ExpandProperty ExclusionPathEn el equipo aparecen cuatro exclusiones relacionadas con desarrollo:
C:\Users\USUARIO\.gradle
C:\Users\USUARIO\AppData\Local\Android\Sdk
C:\Users\USUARIO\AppData\Local\Google\AndroidStudio...
C:\Users\USUARIO\...\proyecto-desarrolloLas carpetas corresponden a:
- Gradle.
- Android SDK.
- Android Studio.
- Un proyecto de desarrollo.
No se eliminan automáticamente.
La conclusión correcta no consiste en afirmar que sean peligrosas, sino en comprobar si siguen siendo necesarias.
Una exclusión legítima también reduce la superficie que analiza el antivirus. Por ello conviene mantener únicamente las que tengan una justificación real.
7. Comprobar si Defender actúa realmente
Se revisa:
Seguridad de Windows → Historial de protección
El historial muestra detecciones reales recientes.
Entre ellas aparecen varias aplicaciones potencialmente no deseadas y diferentes archivos pertenecientes a paquetes de una distribución Kali Linux utilizada para laboratorios de seguridad.
Este punto permite extraer una lección importante de análisis:
Una detección necesita contexto.
Encontrar herramientas como Commix, BloodHound u otros componentes ofensivos en un equipo normal puede justificar una investigación inmediata.
Encontrarlos dentro de una distribución Kali descargada deliberadamente para un laboratorio tiene una explicación conocida.
Eso no significa que Defender deba ignorarlos. El antivirus los identifica y actúa sobre ellos precisamente porque presentan funcionalidades consideradas peligrosas.
8. Consultar las detecciones desde PowerShell
La información se contrasta mediante:
Get-MpThreatDetection | Sort-Object InitialDetectionTime -Descending | Select-Object -First 10 InitialDetectionTime,ThreatID,ActionSuccess,CurrentThreatExecutionStatusID,ResourcesEntre los resultados aparecen:
- fecha y hora de detección;
- identificador de amenaza;
- resultado de la acción;
- estado;
- archivo o recurso afectado.
En las detecciones revisadas aparece:
ActionSuccess : TrueLa información coincide con el historial mostrado por Seguridad de Windows.
Esto constituye una evidencia mucho más sólida que limitarse a comprobar si el interruptor del antivirus aparece activado.
9. Auditoría del Firewall de Windows
Una vez comprobado Defender, se analiza el Firewall.
Primero se identifica qué perfil de red utiliza realmente Windows:
Get-NetConnectionProfileEl resultado muestra:
InterfaceAlias : Wi-Fi
NetworkCategory : Public
IPv4Connectivity : InternetLa conexión actual está clasificada como red pública.
Este dato es importante porque Windows puede aplicar reglas diferentes según el perfil:
- Domain.
- Private.
- Public.
10. Comprobar los tres perfiles del Firewall
Se ejecuta:
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction,DefaultOutboundActionEl resultado muestra:
Name Enabled
---- -------
Domain True
Private True
Public TrueLos tres perfiles se encuentran habilitados.
Sin embargo, las acciones predeterminadas aparecen como:
NotConfiguredEsto demuestra otra razón por la que no conviene interpretar un único comando de forma aislada.
Se consulta entonces la política efectiva del perfil actual.
11. Comprobar la política efectiva del Firewall
Se utiliza:
netsh advfirewall show currentprofileEl resultado relevante es:
Configuración de Perfil público:
Estado ACTIVAR
Directiva de firewall BlockInbound,AllowOutbound
RemoteManagement Deshabilitar
Registro:
LogAllowedConnections Deshabilitar
LogDroppedConnections DeshabilitarAhora sí tenemos evidencia de la política aplicada.
Interpretación
La política:
BlockInbound,AllowOutboundsignifica que:
- las conexiones entrantes se bloquean por defecto;
- las conexiones salientes se permiten por defecto;
- una regla concreta puede crear una excepción.
También se observa que el registro de conexiones permitidas y descartadas está deshabilitado.
Esto no desactiva el Firewall, pero limita la información disponible posteriormente para investigar tráfico mediante su archivo de log.
12. Revisar las reglas de entrada
Listar todas las propiedades de todas las reglas genera demasiada información. Se realiza un filtrado:
Get-NetFirewallRule -Direction Inbound -Enabled True | Select-Object DisplayName,Profile,Action | Sort-Object Profile,DisplayNameAparecen numerosas reglas pertenecientes tanto a Windows como a programas instalados.
Entre ellas se encuentran reglas relacionadas con:
- mDNS;
- Microsoft Edge;
- Microsoft Teams;
- ADB;
- qBittorrent;
- RAD Studio;
- Steam;
- componentes de Windows.
Algunas reglas también son aplicables al perfil Public.
Esto no significa automáticamente que todas esas aplicaciones tengan puertos abiertos.
13. Caso práctico: analizar una regla de qBittorrent
Para demostrar la diferencia entre una regla del Firewall y un servicio realmente escuchando, se seleccionan las reglas de qBittorrent.
Comprobar puertos y protocolo
Get-NetFirewallRule -DisplayName "qBittorrent" | Get-NetFirewallPortFilterEl resultado muestra:
Protocol : UDP
LocalPort : Any
RemotePort : Any
Protocol : TCP
LocalPort : Any
RemotePort : AnyA primera vista parecen reglas muy amplias.
Pero todavía falta conocer otro dato: a qué programa se aplican.
14. Comprobar el ejecutable asociado
Get-NetFirewallRule -DisplayName "qBittorrent" | Get-NetFirewallApplicationFilterEl resultado muestra:
Program : C:\Program Files\qBittorrent\qbittorrent.exeLas reglas no se aplican indiscriminadamente a cualquier programa.
Se encuentran vinculadas específicamente a:
qbittorrent.exeEsto reduce considerablemente el alcance respecto a una regla genérica aplicable a cualquier proceso.
15. Comprobar las direcciones permitidas
Se ejecuta:
Get-NetFirewallRule -DisplayName "qBittorrent" | Get-NetFirewallAddressFilterEl resultado es:
LocalAddress : Any
RemoteAddress : AnyLa regla no limita explícitamente las direcciones remotas.
Pero incluso así todavía no podemos afirmar que exista un puerto abierto.
16. ¿Existe realmente algún puerto TCP escuchando?
Con qBittorrent cerrado se ejecuta:
Get-NetTCPConnection -State Listen | Where-Object { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName -eq "qbittorrent" } | Select-Object LocalAddress,LocalPort,State,OwningProcessEl comando no devuelve ningún resultado.
También se comprueba directamente si el proceso existe:
Get-Process qBittorrent -ErrorAction SilentlyContinueTampoco devuelve nada.
Por tanto:
Las reglas del Firewall existen, pero qBittorrent está cerrado y no existe ningún listener TCP asociado al programa.
Esta es una comprobación muy importante:
Regla habilitada ≠ puerto abierto.
17. Abrir qBittorrent y repetir la prueba
Se inicia qBittorrent y se repite exactamente el mismo comando:
Get-NetTCPConnection -State Listen | Where-Object { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName -eq "qbittorrent" } | Select-Object LocalAddress,LocalPort,State,OwningProcessAhora sí aparecen varios listeners TCP asociados al proceso:
LocalAddress LocalPort State
192.168.1.X 65392 Listen
192.168.1.X 65332 Listen
192.168.1.X 65329 Listen
192.168.1.X 65307 ListenEl proceso que antes no existía ahora crea sockets de escucha.
La prueba permite comprobar experimentalmente que la exposición depende de varios elementos:
- la existencia de una regla;
- el proceso en ejecución;
- el puerto realmente utilizado;
- la interfaz de red;
- la configuración del propio programa.
18. Comprobar también UDP
Se ejecuta:
Get-NetUDPEndpoint | Where-Object { (Get-Process -Id $_.OwningProcess -ErrorAction SilentlyContinue).ProcessName -eq "qbittorrent" } | Select-Object LocalAddress,LocalPort,OwningProcessAparecen varios endpoints UDP del proceso.
Entre ellos se encuentra el puerto configurado posteriormente en qBittorrent:
55153También aparecen endpoints vinculados a:
- la dirección IPv4 local;
- loopback;
- interfaces virtuales;
- IPv6 local;
- otras funciones de descubrimiento.
19. Comprobar la configuración interna de qBittorrent
Desde:
Herramientas → Opciones → Conexión
se comprueba:
Puerto utilizado para conexiones entrantes: 55153
Usar reenvío de puertos UPnP / NAT-PMP del router: ACTIVADOEsto significa que qBittorrent solicita al router la creación automática de una redirección mediante UPnP/NAT-PMP.
Sin embargo:
Que la opción esté activada no demuestra que el router haya aceptado la petición ni que el puerto sea accesible desde Internet.
20. Comprobar específicamente TCP 55153
Se realiza una última comprobación:
Get-NetTCPConnection -LocalPort 55153 -ErrorAction SilentlyContinue | Select-Object LocalAddress,LocalPort,RemoteAddress,RemotePort,State,OwningProcessEn el momento de la prueba no se obtiene ningún resultado.
Por tanto, durante esa comprobación no existe evidencia de un listener TCP en el puerto 55153, aunque sí se observan endpoints UDP asociados a ese puerto.
Tampoco se verifica durante esta sesión si UPnP/NAT-PMP ha creado realmente una redirección en el router.
21. Resultados confirmados de la auditoría
Microsoft Defender
- Microsoft Defender Antivirus actúa como antivirus activo.
AMRunningModeaparece comoNormal.- La protección en tiempo real está activa.
- La supervisión de comportamiento está activa.
- La protección en la nube está activa.
- El envío automático de muestras está activo.
- La protección contra alteraciones está activa.
- La protección PUA está activa.
- Las firmas se encuentran actualizadas durante la auditoría.
- Existen detecciones recientes verificables.
- El acceso controlado a carpetas está desactivado.
- Existen varias exclusiones relacionadas con herramientas de desarrollo.
Firewall de Windows
- Domain, Private y Public se encuentran habilitados.
- El perfil activo durante la prueba es Public.
- La política efectiva es
BlockInbound,AllowOutbound. - La administración remota aparece deshabilitada para el perfil comprobado.
- El registro de conexiones permitidas está desactivado.
- El registro de conexiones bloqueadas está desactivado.
- Existen reglas de entrada para distintas aplicaciones.
- Una regla habilitada no implica necesariamente un socket escuchando.
22. Qué no demuestra esta auditoría
También resulta importante establecer los límites de las conclusiones.
La práctica no demuestra que:
- el equipo sea completamente seguro;
- no pueda existir malware no detectado;
- todas las reglas del Firewall sean necesarias;
- las exclusiones de Defender sean óptimas;
- un listener local sea automáticamente accesible desde Internet;
- UPnP haya creado efectivamente una redirección en el router;
- un archivo detectado dentro de Kali implique una infección de Windows.
23. Posibles mejoras a revisar
La auditoría identifica varios puntos que pueden estudiarse posteriormente sin realizar cambios precipitados:
- Revisar si todas las exclusiones de Defender siguen siendo necesarias.
- Evaluar el Acceso controlado a carpetas y su compatibilidad con el software utilizado.
- Valorar la activación del registro de conexiones bloqueadas del Firewall.
- Revisar reglas aplicables al perfil Public que correspondan a programas que ya no se utilizan.
- Comprobar en el router qué redirecciones UPnP/NAT-PMP existen realmente.
La metodología consiste primero en detectar y entender la configuración existente y solo después decidir si conviene modificar algo.
24. Conclusión
Esta auditoría demuestra por qué comprobar la seguridad de Windows requiere ir más allá de verificar que Defender y el Firewall muestran un icono verde.
PowerShell permite obtener evidencia sobre el estado efectivo de Microsoft Defender, sus protecciones, exclusiones y detecciones, mientras que las herramientas de red permiten estudiar la política real del Firewall y el comportamiento de las aplicaciones.
El caso de qBittorrent resulta especialmente ilustrativo:
Una regla de Firewall habilitada no equivale por sí sola a un puerto abierto.
Cuando la aplicación está cerrada no existen listeners asociados. Cuando se inicia, aparecen sockets y endpoints propios del proceso.
La seguridad se analiza así:
Configuración → estado efectivo → evidencia → contexto → interpretación.
No se trata de asumir que una configuración es segura o insegura. Se trata de comprobar qué está ocurriendo realmente.
Práctica: [LAB-WIN-02] Auditoría de Microsoft Defender y Firewall — Windows 11
Proyecto: CIBERMURO / InformatOLI — seguridad digital práctica y laboratorio Blue Team.
Acerca del autor
