El Wi‑Fi de aeropuertos, plazas y recintos feriales puede ser una trampa: en 2026 los "evil‑twin", la interceptación y las fugas DNS ganan sofisticación. Quien viaja o asiste a eventos convive con riesgo concreto de robo de credenciales y seguimiento; conviene comprobar BSSID, fuerza de señal y portal cautivo sospechoso antes de conectar, y activar verificaciones básicas de HTTPS y DNS.
El Wi‑Fi público sigue siendo un vector clave para robos de credenciales, seguimiento y fraude; los informes sobre riesgos de ciberseguridad en 2026 confirman que las tácticas incluyen evil‑twin, MITM e fugas DNS. En minutos se podrá detectar redes maliciosas, configurar y testear una VPN en Android/iOS/Windows/macOS, verificar certificados y activar DNS over HTTPS, y aplicar una checklist práctica para viajeros y organizadores.
Por qué el Wi‑Fi público es tan vulnerable en 2026
El crecimiento de dispositivos y hotspots ha creado más superficie de ataque en 2024–2026. Más puntos de acceso implican más posibilidades para rogue AP y evil‑twin.
Las cadenas de suministro y servicios gestionados contribuyen al riesgo. Organizaciones como INCIBE y ENISA han emitido alertas sobre certificados reemitidos y DNS hijacking. ENISA
La evidencia muestra un aumento en campañas organizadas. Entre 2024 y 2026 ataques dirigidos a eventos y aeropuertos crecieron en alcance y profesionalidad.
La recomendación clara: asumir que una red abierta puede ser comprometida. Exigir cifrado efectivo y verificar entidades antes de confiar en una red pública.
El siguiente párrafo ofrece una recomendación directa: usar VPN con kill‑switch y verificar certificados TLS locales antes de entrar a servicios sensibles. Esto funciona bien en la práctica solo si la VPN protege DNS y el dispositivo no tiene malware. Si la VPN no aplica DoH/DoT dentro del túnel, la protección es parcial y hay que activar DoH en el sistema. Quien viaja con datos sensibles debe comprobar todo esto antes de partir.
Vectores que marcan la tendencia
Evil‑twin y rogue AP crean puntos de acceso falsos que replican el SSID oficial. Si hay duplicados del mismo nombre, hay riesgo elevado.
DNS spoofing y secuestro de sesión desvían nombres de dominio a servidores maliciosos. El resultado es páginas fraudulentas aun cuando el navegador muestra HTTPS válido.
Certificados reemitidos por proveedores o intermediarios autorizados complican la detección. CCN‑CERT y ENISA han documentado este tipo de incidentes.
Principales vectores en redes públicas 2026
Evil‑twin consiste en un punto de acceso malicioso que copia un SSID legítimo. Probar la BSSID antes de conectar reduce mucho el riesgo.
DNS spoofing redirige nombres de dominio a IPs controladas por el atacante. Activar DoH o DoT minimiza este vector.
Interposición de proxies con certificados reemitidos puede mostrar TLS válido. Ver la huella SHA‑256 del certificado aclara si hay reemisión.
Evil twin y rogue AP
Comprobar el BSSID (MAC del AP) y el canal del punto de acceso antes de conectar evita trampas. Si el BSSID no coincide con el suministrado por el local, no conectarse.
El error más frecuente en este punto es fiarse solo del nombre del SSID. El SSID se copia fácilmente; la MAC no.
DNS spoofing y secuestro de sesión
Una señal común es que ciertos dominios cargan contenido distinto al habitual. Usar dig o nslookup antes de acceder a servicios reduce riesgos.
Si el navegador fuerza redirecciones extrañas, cerrar la sesión y cambiar credenciales desde una red segura es la opción inmediata.
Cómo aplicarlo: detectar, proteger y comprobar
Antes de conectar, comprobar la BSSID y la potencia de la señal. Si hay dos SSID idénticos con BSSID distintos, no usar la red.
Desactivar la compartición de archivos y exigir conexión HTTPS y captive portal por HTTPS. Evitar transacciones sensibles en redes abiertas.
Usar VPN con protocolos sólidos, kill‑switch y protección DNS dentro del túnel. Probar fugas antes de usar banca o servicios corporativos.
Detección rápida de un evil‑twin
En Android abrir Ajustes Wi‑Fi y ver la información de red para comprobar la MAC del AP. En iOS usar la app Airport Utility con permiso para ver BSSID.
Si el personal del local confirma un BSSID oficial, compararlo antes de aceptar el captive portal. Pedir al personal el nombre exacto y la MAC evita errores.
Ajustes previos en el dispositivo
En Windows desactivar "Descubrimiento de redes" y en macOS desactivar "Compartir archivos". Mantener el firewall activado y el sistema actualizado.
Probar que las aplicaciones usan HTTPS y que MFA está activo para servicios críticos. MFA reduce el daño si las credenciales se filtran.
Antes de aceptar una conexión al Wi‑Fi público hay comprobaciones muy rápidas y útiles contra un posible evil‑twin:
- primero, comparar el BSSID que ofrece el establecimiento con el que muestra tu móvil (Ajustes Wi‑Fi en Android o Airport Utility en iOS)
- segundo, desconfiar de captive portals que no usan HTTPS o que piden información inusual
- tocar el icono del candado en el navegador y revisar la comprobación de certificados básicos (nombre del emisor y fecha). Para usuarios no técnicos, usar apps de escaneo de redes (por ejemplo WiFiman, Fing o similares) permite ver SSID duplicados, canales y potencias: si aparece el mismo SSID en dos canales o con BSSID distintos y potencias discordantes, es señal de riesgo. Otra comprobación útil es intentar hacer ping a una IP conocida (8.8.8.8) o abrir directamente una web por IP
- si la conexión falla o muestra redirecciones extrañas, no conectarse
En entornos de seguridad en aeropuertos o seguridad en eventos masivos, combinar estas comprobaciones con la petición directa al personal del local del BSSID oficial reduce la probabilidad de caer en un Rogue AP o Man-in-the-Middle (MitM).
Configurar y probar una VPN en android, iOS, windows y macOS
Una VPN segura en 2026 usará WireGuard o IKEv2 y ofrecerá kill‑switch y DNS dentro del túnel. Exigir esos parámetros al proveedor.
Verificar fugas de IP y DNS con pruebas locales antes de operar con datos sensibles. Comandos y servicios permiten comprobar si la VPN filtra información.
En la tabla se detallan criterios medibles para elegir proveedor y configurar la VPN.
Android e iOS
Instalar la app oficial del proveedor y elegir WireGuard o IKEv2 si están disponibles. Activar kill‑switch desde la app.
Probar la fuga DNS: tras conectar, en Android ejecutar una consulta a 1.1.1.1 con la app "Termux" o usar una app de test de fuga DNS. La IP pública debe cambiar al de la VPN.
Si la fuga muestra tu IP real, desconectar y cambiar de proveedor o ajustar el cliente VPN. Esto significa que la VPN no encapsula todo el tráfico.
Comandos útiles móviles: usar curl desde Termux para comprobar ipinfo.io/ip. El resultado debe coincidir con la IP del proveedor VPN.
Windows y macOS
En Windows instalar el cliente oficial y activar kill‑switch en opciones de conexión. En macOS usar el cliente nativo o app del proveedor con WireGuard.
Ver IP pública con curl https://ifconfig.me o con PowerShell Invoke‑WebRequest. Si la IP pública coincide con la del proveedor, no hay fuga evidente.
Comprobar DNS con nslookup o dig hacia un dominio controlado. La respuesta debe venir de los resolvedores del proveedor VPN.
Requisito mínimo para una VPN en eventos masivos: protocolo WireGuard o IKEv2, kill‑switch operativo, DNS dentro del túnel y logs de conexión reducidos a 0‑7 días según normativa.
Para una verificación práctica de la VPN en cada dispositivo conviene seguir pasos concretos: en Android, instalar la app oficial de WireGuard o el cliente del proveedor (por ejemplo Mullvad o ProtonVPN), importar el perfil .conf o registrarse en la app, activar “Always‑on VPN”/kill‑switch en Ajustes > Red e Internet y comprobar que IPv4 e IPv6 están encapsulados; en iOS elegir IKEv2 o WireGuard en la app del proveedor y activar la opción equivalente a “Always‑on” o usar un perfil de configuración MDM para Forzar VPN. En macOS y Windows instalar el cliente oficial (WireGuard o IKEv2), habilitar el kill‑switch y, ya conectado, ejecutar pruebas: curl https://ifconfig.me para verificar la IP pública, probar la resolución DNS con nslookup o dig (por ejemplo dig +short ejemplo.com) y usar un test de fuga DNS (por ejemplo dnsleaktest.com) para comprobar que el resolvedor reportado pertenece al proveedor VPN.
No olvidar comprobar fugas IPv6 (si hay IPv6 en el operador) y repetir la prueba tras forzar desconexión del túnel para validar que el cambio se produce correctamente. Si cualquiera de estas pruebas muestra la IP real o resolvedores distintos a los esperados, la VPN no está encapsulando tráfico correctamente y hay que revisar la configuración o cambiar de proveedor.
Verificar certificados TLS y activar DoH/DoT en móvil y PC
La huella SHA‑256 del certificado del sitio ofrece una verificación local frente a reemisores. Comparar la huella previene MitM con certificados reemitidos.
Activar DNS over HTTPS (DoH) o DNS over TLS (DoT) en el sistema evita la mayor parte del DNS spoofing en redes públicas. Esto debe coexistir con la VPN.
Si HTTPS falla y el certificado no coincide con la huella esperada, no ingresar credenciales. Puede tratarse de un proxy con capacidad de reemisión.
En macOS y Linux usar openssl: openssl s_client -connect ejemplo.com:443 | openssl x509 -noout -fingerprint -sha256. La huella debe verificarse con una fuente fiable.
En Windows usar PowerShell: (Invoke‑WebRequest https://ejemplo.com).RawContentStream o herramientas como Certutil. Comparar huella con la del servicio oficial.
Si la huella no coincide, desconectar y alertar al proveedor del servicio. La discrepancia indica reemisión o interceptación.
Activar DoH y comprobar fugas DNS
En Android 9+ activar "DNS privado" y configurar un proveedor DoT o DoH. En iOS usar configuración en Ajustes > DNS o apps de terceros.
En Windows 10/11 activar DoH en configuración de red o usar un resolvedor local que soporte DoH. En macOS usar perfiles o apps como Cloudflare Warp.
Probar con dig o nslookup y confirmar que el resolvedor reportado es el configurado por DoH/DoT o por la VPN. Si no coincide, existe fuga DNS.
Matriz comparativa para elegir VPN y configuración
| Proveedor |
Protocolo |
Kill‑switch |
DoH/DoT integrado |
Prueba de fugas |
Precio medio España (€/mes) |
| Proveedor A |
WireGuard / IKEv2 |
Sí |
Sí |
0 fugas en 3 tests |
3–6 €/mes |
| Proveedor B |
OpenVPN / IKEv2 |
Sí |
Parcial |
1 fuga en 3 tests |
4–8 €/mes |
| Proveedor C |
WireGuard |
No |
No |
Varias fugas |
2–5 €/mes |
Columnas y umbrales medibles
Protocolo: preferir WireGuard o IKEv2 por latencia y seguridad comprobada. Kill‑switch: obligatoria para uso en entornos públicos.
DoH/DoT integrado evita fugas DNS fuera del túnel. Exigir que la VPN permita forzar DNS dentro del túnel.
Precio: en España en 2026 la media de mercado para un servicio fiable se sitúa entre 3 € y 8 € al mes. Precios por debajo de 2 € suelen implicar compromisos.
Medidas para organizadores y admins de eventos
Los organizadores deben publicar BSSID oficiales y canales de cada AP antes del evento. Esto permite a usuarios verificar la autenticidad.
Implementar WPA3‑Enterprise con RADIUS y segmentación por VLAN por usuario reduce el riesgo interno. También reduce la exposición a rogue AP.
Registrar y conservar logs esenciales 30 días ayuda a la investigación posterior. La retención debe respetar LOPDGDD y NIS2.
Checklist técnico para admins
Configurar WPA3‑Enterprise y RADIUS para autenticación por usuario. Usar certificados válidos gestionados por autoridad confiable.
Segmentar por VLAN por servicio y por usuario. Limitar acceso a la gestión del AP a red segregada.
Publicar BSSID y canal en la web del evento y en la recepción. Indicar claramente el SSID oficial y la MAC del AP.
Comunicación y soporte al usuario
Formar al personal de atención para indicar BSSID y pasos de verificación. Incluir en la FAQ del evento instrucciones de comprobación.
Instalar páginas de asistencia con HTTPS y huella del certificado visible. Esto ayuda a detectar captive portals falsos.
Para organizadores y administradores es crucial complementar la publicación de BSSID con medidas técnicas proactivas: desplegar un sistema WIDS/WIPS que detecte Rogue AP y genere alertas en tiempo real, habilitar DHCP snooping y Dynamic ARP Inspection en los switches para evitar ARP spoofing, y aplicar segmentación estricta de VLAN para invitados con reglas de firewall por VLAN. Implantar 802.1X (WPA3‑Enterprise con EAP‑TLS) y gestionar el ciclo de vida de certificados (rotación periódica y revocación) reduce el riesgo de certificados TLS reemitidos o comprometidos. Además, firmar el captive portal con un certificado gestionado centralmente y publicar su huella SHA‑256 en la web del evento facilita la comprobación por usuarios.
Finalmente, disponer de un playbook de respuesta —detectar Rogue AP, aislar SSID afectado, notificar asistentes por canales oficiales, revocar certificados si procede y conservar registros para investigación— acelera la contención frente a ataques como DNS hijacking o ataques MITM durante eventos masivos.
Si sospechas que te interceptaron: contención y recuperación
Desconectar de la red inmediatamente y cambiar credenciales desde una red segura. Usar datos móviles o una VPN confiable para el cambio.
Recoger evidencias: capturas del SSID, BSSID, hora y comportamiento del captive portal. Estas evidencias ayudan en la denuncia.
Notificar a Policía Nacional, Guardia Civil e INCIBE según gravedad. INCIBE ofrece guía y ayuda técnica para incidentes en España.
Contención rápida y restauración
Cerrar sesiones activas en servicios críticos y revocar tokens si es posible. Cambiar contraseñas desde una red segura.
Comprobar dispositivos por malware con un antivirus actualizado y análisis completo. Si hay sospecha de compromiso grave, restaurar desde copia limpia.
Notificar autoridades y conservar
Contactar a Policía Nacional y a INCIBE con la evidencia recopilada. INCIBE dispone de canales para notificar incidentes.
Conservar logs y capturas al menos 30 días para investigaciones, respetando la normativa de datos personales.
Quien viaje en las próximas 48 horas comprobará la VPN, la huella TLS del servicio y activará DoH antes de conectar en aeropuertos o eventos.
El plan concreto
Aplicar este plan en 10 minutos antes de salir: comprobar BSSID, activar VPN con kill‑switch, verificar IP y DNS, comprobar huella TLS y activar DoH. Si todo encaja, usar la red con restricciones.
Checklist imprimible:
- Comprobar SSID y pedir BSSID al personal.
- Comparar BSSID con el listado oficial del evento o local.
- Desactivar compartición de archivos en el dispositivo.
- Activar VPN con WireGuard o IKEv2 y kill‑switch.
- Verificar IP pública y realizar un test de fuga DNS (3 tests).
- Extraer huella SHA‑256 del certificado del servicio crítico.
- Cambiar contraseñas desde red segura si hay sospecha de filtración.
Código para un checklist simple que se puede copiar e imprimir:
[ ] Pedir BSSID oficial al personal
[ ] Comparar BSSID antes de conectar
[ ] Activar VPN (WireGuard/IKEv2) con kill‑switch
[ ] Comprobar IP pública: curl https://ifconfig.me
[ ] Comprobar DNS: dig +short ejemplo.com
[ ] Verificar huella TLS: openssl s_client -connect ejemplo.com:443
[ ] Usar MFA en servicios críticos
No aplicar estas medidas cuando se usa exclusivamente datos móviles con tarjeta celular, cuando la red es corporativa gestionada con MDM y certificados comprobables, o cuando el dispositivo está comprometido por malware local.
Preguntas frecuentes sobre Wi‑Fi público y seguridad
¿Qué riesgos tengo al usar un Wi‑Fi público?
Los riesgos principales son robo de credenciales, seguimiento y fraude. Entre 2024 y 2026 entre 30% y 45% de incidentes en eventos masivos involucraron MitM o DNS hijacking.
Evitar transacciones sensibles y usar VPN con kill‑switch reduce el riesgo. Si no hay VPN, usar datos móviles para operaciones financieras.
¿Cómo detecto un evil twin antes de conectar?
Comprobar la BSSID y el canal del AP antes de aceptar el captive portal. Si hay duplicados del mismo SSID y BSSID distintos, no conectarse.
Pedir al personal del local el nombre exacto del SSID y la MAC del AP facilita la comprobación.
¿Una página con HTTPS me protege siempre?
No siempre: si hay reemisión de certificados o proxy autorizado, el navegador puede mostrar HTTPS válido. Comparar la huella SHA‑256 del certificado aclara la autenticidad.
Si la huella no coincide con la conocida del servicio, no introducir credenciales.
¿Qué pruebas rápidas hacer en el móvil antes de conectar?
Comprobar IP pública con curl o apps de red y verificar que coincide con la IP del proveedor VPN. Ejecutar una consulta DNS y confirmar el resolvedor esperado.
Si la IP o el DNS no coincide con la VPN, la conexión filtra y no es segura.
¿Qué VPN elegir para eventos y viajes en 2026?
Elegir una VPN que ofrezca WireGuard o IKEv2, kill‑switch y DNS dentro del túnel. En España el rango de precio fiable suele ser 3–8 € al mes.
Probar la VPN con 3 tests de fuga antes del viaje y exigir documentación del proveedor sobre políticas de logs.
¿A quién debo avisar si sospecho robo en Wi‑Fi?
Si hay pérdida de datos personales o fraude, avisar a Policía Nacional y a INCIBE. INCIBE ofrece guía técnica y registro de incidentes en España.
También notificar a la entidad financiera y cambiar credenciales desde red segura.
Fuentes y siguientes pasos
INCIBE y CCN‑CERT publican guías prácticas y alertas sobre ataques en redes públicas en España. Consultar sus recomendaciones ayuda a alinear medidas técnicas con la normativa.
Para profundizar, revisar alertas de ENISA y Europol sobre ataques a infraestructuras públicas en 2024–2026. La evidencia técnica y las capturas de prueba facilitan la denuncia.
Si se va a asistir a un evento, el organizador debe publicar BSSID oficiales y políticas de seguridad. Esto facilita la comprobación por parte de los asistentes.
