Durante la semana 40 de 2026, nuestro SOC analizó 1.435 indicadores SonicWall generados por firewalls SonicWall TZ270 y TZ370 desplegados en diferentes infraestructuras profesionales.
Las detecciones principales fueron:
- Port Scan Possible
- Port Scan Probable
- SMTP Server on RBL Blacklist
Sin embargo, existe una diferencia fundamental:
1.435 indicadores SonicWall no significan 1.435 ataques confirmados.
SonicWall detecta y registra los eventos. Después, nuestro SOC analiza los logs, su contexto, el servicio afectado y la actividad relacionada para determinar si estamos ante ruido de Internet, reconocimiento automatizado, un problema de reputación, una actividad legítima o una situación que merece investigación.
Además, en esta publicación no mostramos las direcciones IP ni los rangos observados. Para aportar contexto sin exponer telemetría sensible, resumimos únicamente las redes, proveedores y geolocalizaciones asociadas.
Indicadores SonicWall: qué detectamos durante la semana 40
La actividad registrada se concentró principalmente en tres tipos de eventos.
Port Scan Possible
Indica que SonicWall ha identificado un patrón compatible con un posible escaneo de puertos.
Este comportamiento puede aparecer cuando un sistema remoto prueba distintos servicios para conocer:
- qué puertos responden;
- qué protocolos están publicados;
- qué servicios pueden existir;
- qué superficie está accesible desde Internet.
Sin embargo:
Port Scan Possible no confirma una intrusión.
Es una detección que debe analizarse dentro de su contexto.
Port Scan Probable
La clasificación Port Scan Probable representa un patrón que SonicWall considera más consistente con una actividad de reconocimiento.
Aun así:
probable escaneo ≠ compromiso confirmado.
El dispositivo está indicando un comportamiento observado en el tráfico.
Después debemos revisar:
- puerto de destino;
- protocolo;
- regla de firewall;
- NAT;
- servicio publicado;
- frecuencia;
- duración;
- actividad posterior.
Solo con ese contexto podemos determinar la relevancia real.
SMTP Server on RBL Blacklist
También se registraron eventos:
SMTP Server on RBL Blacklist.
Una RBL es una lista de reputación utilizada principalmente en el ecosistema de correo electrónico.
Si una dirección aparece asociada a una lista de este tipo puede existir un historial relacionado con:
- spam;
- infraestructura comprometida;
- servidores mal configurados;
- envío de correo no deseado.
Pero nuevamente:
estar en una RBL no demuestra por sí mismo que una dirección esté intentando comprometer nuestra empresa.
Es un indicador de reputación que debemos valorar junto con el resto de la actividad.
Indicadores SonicWall: ¿los eventos fueron bloqueados?
Aquí debemos ser especialmente precisos.
Los eventos facilitados para este informe indican:
Port Scan Possible
Port Scan Probable
y:
SMTP Server on RBL Blacklist
pero no incluyen en su denominación una acción explícita como:
Blocked / Dropped / Prevented.
Por tanto, no sería correcto afirmar públicamente que:
“los 1.435 eventos fueron bloqueados”.
Cuando la telemetría no confirma expresamente el bloqueo, nuestro SOC revisa si:
- el tráfico alcanzó una regla permitida;
- existía un NAT publicado;
- el puerto estaba realmente abierto;
- el firewall descartó posteriormente la conexión;
- hubo respuesta del servicio;
- apareció actividad relacionada después.
Esta distinción es importante.
Detectar no significa necesariamente bloquear.
Indicadores SonicWall: cómo analizamos un Port Scan no confirmado como bloqueado
Imagine que SonicWall detecta un posible escaneo contra una dirección pública.
Nuestro análisis no termina en:
“hay un Port Scan”.
Revisamos primero:
1. Puerto de destino
No es igual detectar tráfico contra:
un puerto cerrado
que contra:
un servicio realmente publicado.
2. Regla de firewall
Comprobamos qué política procesa la conexión.
3. NAT
Determinamos si existe una publicación hacia algún equipo interno.
4. Respuesta
Analizamos si el tráfico fue:
- rechazado;
- descartado;
- permitido.
5. Actividad posterior
Buscamos si después aparecen:
- nuevas conexiones;
- autenticaciones;
- tráfico desde la misma infraestructura;
- eventos en otras fuentes.
Es esta segunda fase la que permite transformar:
una detección
en:
un análisis de seguridad.
Indicadores SonicWall y geolocalización de la semana 40
El análisis de las infraestructuras asociadas a los indicadores de esta semana muestra actividad vinculada a distintas regiones.
Entre las localizaciones observadas aparecen principalmente:
🌎 Estados Unidos
🇨🇦 Canadá
🇫🇷 Francia
🇳🇱 Países Bajos
🇸🇮 Eslovenia
🇸🇪 Suecia
🇨🇳 China
🇰🇷 Corea del Sur
y otras localizaciones europeas y asiáticas.
Sin embargo, la geolocalización de una dirección IP debe interpretarse con cuidado.
El país asociado a una IP no identifica la nacionalidad ni la ubicación física del atacante.
La infraestructura puede pertenecer a:
- hosting;
- VPS;
- cloud;
- VPN;
- proxy;
- red comprometida.
Por tanto:
geolocalización ≠ atribución.
Indicadores SonicWall: actividad asociada a proveedores cloud y hosting
Una parte de los indicadores de la semana 40 está asociada a redes de proveedores de infraestructura.
Entre las redes verificadas aparecen proveedores como:
- OVHcloud
- DigitalOcean
- Akamai Connected Cloud / Linode
- M247 Europe
- Spartan Host
- Virtuo
- OVPN / Obehosting
- Orange
- otras redes de alojamiento y conectividad
Por ejemplo, parte de la actividad analizada se encontraba asociada a redes de OVH, mientras que otras correspondían a DigitalOcean, Akamai Connected Cloud/Linode y M247. IPinfo
También identificamos infraestructura relacionada con proveedores especializados de hosting como Spartan Host y Virtuo. IPinfo
Esto tampoco significa que:
OVHcloud, DigitalOcean o cualquier otro proveedor esté atacando a nuestros clientes.
Un proveedor cloud puede alojar miles de servidores administrados por terceros.
Por tanto:
proveedor de hosting ≠ atacante.
¿Por qué aparecen tantos proveedores cloud en los indicadores SonicWall?
Porque alquilar infraestructura actualmente es:
- rápido;
- barato;
- automatizable;
- disponible globalmente.
Un servidor cloud puede crearse en minutos.
Y puede utilizarse legítimamente para:
✅ páginas web
✅ aplicaciones
✅ servicios empresariales
✅ desarrollo
pero también puede ser utilizado temporalmente por terceros para:
- escaneo;
- automatización;
- proxies;
- campañas abusivas.
La presencia de una red cloud en un log únicamente indica:
dónde estaba alojada la infraestructura observada.
No quién estaba detrás.
Indicadores SonicWall y redes asociadas a VPN
Parte de la actividad revisada también apareció relacionada con infraestructura de OVPN / Obehosting, cuyos rangos están asociados a servicios VPN. IPinfo
Esto introduce otro factor.
Una VPN puede ocultar:
la dirección original del usuario.
Por tanto, si SonicWall observa una conexión desde un nodo VPN, únicamente sabemos:
desde qué infraestructura salió el tráfico hacia nosotros.
No necesariamente:
desde dónde se originó realmente.
Indicadores SonicWall procedentes de redes asiáticas
También aparecieron redes asociadas a China y Corea del Sur.
Entre ellas se observan infraestructuras de ChinaNet y Sejong Networks. IPinfo
Además, algunos de los sistemas observados aparecen en fuentes públicas relacionados con patrones de escaneo.
Por ejemplo, SANS Internet Storm Center ha registrado actividad reciente de exploración asociada a parte de la infraestructura surcoreana presente en la muestra. SANS Internet Storm Center
Sin embargo, nuevamente debemos diferenciar:
red desde la que vemos tráfico
de:
persona responsable del tráfico.
Indicadores SonicWall: algunas redes presentan antecedentes de escaneo
Una de las redes observadas durante el periodo aparece en fuentes de inteligencia pública asociada a:
- actividad de reconocimiento;
- escaneo de múltiples puertos;
- presencia en listas de reputación.
En concreto, una de las infraestructuras europeas revisadas aparece registrada con eventos de ReconScanning y presencia en listas Spamhaus. Nerd
Este tipo de inteligencia aporta:
contexto adicional.
Pero tampoco convierte por sí sola cualquier conexión futura en:
un ataque confirmado.
Nuestro análisis debe seguir comprobando:
qué ocurrió realmente contra la infraestructura protegida.
Indicadores SonicWall: por qué no publicamos las direcciones IP
Deliberadamente no incluimos en este informe público:
- direcciones IP;
- rangos completos;
- destinos internos;
- servicios concretos de clientes.
La razón es sencilla:
un informe de ciberseguridad no debe convertirse en un mapa de la infraestructura que protegemos.
Podemos explicar:
- volumen;
- comportamiento;
- proveedores;
- regiones;
- tipología de eventos.
Sin publicar telemetría que pueda aportar información innecesaria sobre los entornos gestionados.
Indicadores SonicWall en administraciones de fincas
Los firewall analizados protegen, entre otros, entornos de:
administraciones de fincas.
Son organizaciones que manejan habitualmente:
- documentación;
- proveedores;
- propietarios;
- comunicaciones;
- información bancaria.
Por ello, la seguridad perimetral debe combinarse con:
- Endpoint;
- MFA;
- protección del correo;
- actualizaciones;
- monitorización.
Un firewall constituye una capa.
No toda la estrategia.
Indicadores SonicWall en asesorías contables y laborales
También protegemos:
asesorías contables y laborales.
Estos entornos trabajan habitualmente con:
- documentación fiscal;
- nóminas;
- DNI;
- certificados;
- información bancaria;
- datos de empresas.
Por tanto, un incidente puede afectar tanto:
a la asesoría
como:
a sus clientes.
La monitorización de firewall ayuda a detectar actividad de red, mientras que las demás capas permiten ampliar el contexto.
Indicadores SonicWall en despachos de abogados
Los despachos jurídicos pueden manejar:
- expedientes;
- contratos;
- documentación personal;
- comunicaciones confidenciales.
En estos entornos resulta especialmente importante controlar:
acceso remoto + identidad + red + dispositivos.
Por tanto, SonicWall forma parte de una estrategia donde también debemos considerar:
🔐 MFA
💻 Endpoint
☁️ Microsoft 365
📊 SIEM
🔎 SOC
Indicadores SonicWall en arquitectura e interiorismo
Los estudios de arquitectura e interiorismo utilizan cada vez más:
- almacenamiento cloud;
- NAS;
- aplicaciones remotas;
- VPN;
- intercambio de archivos.
La exposición de determinados servicios puede atraer:
escaneos automatizados.
Por eso no recomendamos publicar servicios innecesariamente.
Siempre que sea posible:
menos servicios expuestos = menor superficie de ataque.
Indicadores SonicWall en constructoras e ingeniería
Constructoras y empresas de ingeniería pueden depender de:
- servidores;
- ERP;
- NAS;
- VPN;
- aplicaciones técnicas;
- acceso remoto.
Esto crea múltiples puntos donde un atacante puede intentar:
reconocer la infraestructura.
Precisamente los eventos Port Scan Possible y Probable pueden servir como señal de esa fase inicial de reconocimiento.
Pero insistimos:
un escaneo no significa que la explotación haya tenido éxito.
Indicadores SonicWall en despachos profesionales desde el hogar
También existen profesionales que trabajan desde:
despachos ubicados en viviendas.
El hecho de trabajar desde casa no significa que debamos utilizar:
una seguridad doméstica.
Si desde ese entorno se gestionan:
- empresas;
- documentación profesional;
- información confidencial;
- servicios empresariales;
las necesidades pueden ser prácticamente equivalentes a una pequeña oficina.
Por eso desplegamos soluciones como SonicWall TZ270 y TZ370 también en este tipo de escenarios.
Indicadores SonicWall: ¿por qué se escanean puertos continuamente?
Internet es objeto de:
escaneos permanentes.
Bots y herramientas automatizadas pueden recorrer enormes cantidades de direcciones buscando:
- RDP;
- VPN;
- SSH;
- paneles web;
- NAS;
- cámaras;
- aplicaciones vulnerables.
Por tanto, una empresa no necesita convertirse previamente en:
un objetivo seleccionado manualmente.
Puede entrar en una campaña simplemente porque:
su dirección IP responde.
Estar en Internet significa recibir tráfico no solicitado
Una dirección pública puede recibir intentos de:
- reconocimiento;
- conexión;
- autenticación;
- enumeración.
Eso forma parte de la realidad de Internet.
La cuestión importante no es:
“¿alguien ha escaneado nuestra IP?”
La cuestión es:
¿qué servicios tenemos expuestos y qué podría conseguir alguien si encuentra uno?
Indicadores SonicWall: reducir superficie de ataque
Una de las medidas más eficaces consiste en revisar:
qué estamos publicando.
Por ejemplo:
❌ RDP directamente en Internet
debería evitarse siempre que sea posible.
Es preferible utilizar:
🔐 VPN
🔑 MFA
🔥 políticas de firewall
📋 logs
Además:
si un servicio no necesita estar publicado, debería cerrarse.
Indicadores SonicWall: NAT también debe revisarse
Las reglas NAT pueden ser necesarias.
Sin embargo, con el tiempo una empresa puede acumular:
- reglas antiguas;
- publicaciones temporales;
- servicios que ya no existen.
Cada regla debería responder a:
¿por qué necesitamos esto?
Si nadie puede responder:
deberíamos revisarla.
Indicadores SonicWall y acceso remoto mediante VPN
Una VPN proporciona una forma de acceder:
primero a la red
y después:
al recurso necesario.
Esto resulta preferible en muchos casos a publicar directamente:
- RDP;
- administración;
- aplicaciones internas.
Además, recomendamos combinar la VPN con:
MFA cuando la solución lo permita.
Porque:
VPN + contraseña
es mejor que un servicio directamente publicado.
Pero:
VPN + MFA
aporta otra barrera.
Indicadores SonicWall: actualizar el propio firewall
Los firewall también son:
software y firmware.
Por tanto, deben mantenerse:
- soportados;
- actualizados;
- correctamente configurados.
No tendría sentido utilizar un firewall para proteger una empresa y después:
ignorar sus propias actualizaciones de seguridad.
La gestión debe incluir:
firmware + configuración + monitorización.
SonicWall detecta; nuestro SOC analiza
Esta diferencia es central en nuestro servicio.
SonicWall puede detectar y registrar eventos.
Por ejemplo:
Port Scan Probable.
Después nuestro SOC pregunta:
¿qué servicio estaba intentando alcanzar?
¿existía NAT?
¿estaba permitido?
¿hubo más actividad?
Por tanto:
🔥 SonicWall aporta telemetría perimetral
y:
🔎 nuestro SOC aporta contexto.
Indicadores SonicWall y SIEM Wazuh
Los eventos de firewall pueden centralizarse en nuestro servicio de SIEM Wazuh para empresas.
Esto permite relacionarlos con otras fuentes, según cada infraestructura:
☁️ Microsoft 365
💻 Windows
🍎 macOS
🐧 Linux
🖥️ servidores
💾 NAS
📡 UniFi
🛡️ antivirus / Endpoint
Así dejamos de ver:
una alerta aislada del firewall
para poder buscar:
qué sucedió antes y después.
Indicadores SonicWall: un ejemplo de correlación
Imagine:
02:14
SonicWall detecta un escaneo.
02:15
Se intenta acceder a un servicio publicado.
02:16
Un servidor registra varios errores de autenticación.
02:20
Aparece un inicio de sesión correcto.
02:24
El Endpoint registra un proceso nuevo.
Ahora tenemos:
una secuencia.
Eso es mucho más interesante que:
cinco alertas independientes.
SIEM Wazuh permite añadir contexto
Wazuh puede ayudarnos a:
- centralizar;
- normalizar;
- correlacionar;
- almacenar.
Después nuestro SOC interpreta:
qué significa la secuencia.
Porque incluso la secuencia anterior podría acabar teniendo:
una explicación legítima.
El análisis sigue siendo necesario.
Indicadores SonicWall y correlaciones personalizadas
Cada empresa es diferente.
No tiene los mismos:
- servidores;
- usuarios;
- horarios;
- VPN;
- servicios publicados.
Por ello trabajamos con:
correlaciones personalizadas para cada infraestructura.
Una administración de fincas puede necesitar controles diferentes de:
una ingeniería.
Y un despacho jurídico puede tener prioridades distintas a:
un estudio de arquitectura.
Indicadores SonicWall y hasta 400 días de logs
Nuestro servicio puede conservar hasta 400 días de histórico de logs de las fuentes integradas.
¿Por qué?
Porque algunos incidentes se descubren:
meses después.
Imagine que hoy descubrimos una cuenta comprometida.
Después necesitamos comprobar:
¿qué actividad tuvo hace seis meses?
Sin logs:
no podemos volver atrás.
Los logs permiten investigación retrospectiva
Con histórico podemos investigar:
- conexiones;
- autenticaciones;
- firewall;
- Endpoint;
- Microsoft 365;
- servidores.
Esto resulta útil para:
🔎 incidentes
📋 auditorías
🕵️ threat hunting
⚖️ análisis retrospectivo
Por eso almacenar logs no es únicamente:
guardar datos.
Es conservar:
evidencia.
Indicadores SonicWall: qué debería revisar una pyme
Una empresa que quiera mejorar su seguridad perimetral puede empezar por preguntas sencillas:
¿Qué servicios tenemos publicados?
¿Necesitamos realmente todos los NAT actuales?
¿Hay RDP directamente expuesto?
¿La VPN utiliza MFA?
¿El firmware del firewall está actualizado?
¿Quién revisa los logs?
¿Conservamos histórico?
¿Relacionamos los eventos con Endpoint y servidores?
Estas preguntas pueden descubrir más problemas que:
comprar una nueva herramienta sin revisar la configuración actual.
Indicadores SonicWall: 1.435 eventos no son 1.435 ataques
Este es probablemente el mensaje más importante del informe.
Nuestro SOC ha analizado:
1.435 indicadores SonicWall
durante la semana 40.
Pero esto no significa:
1.435 ataques exitosos
ni:
1.435 intrusiones.
Los eventos incluyen comportamientos como:
🔎 Port Scan Possible
🔎 Port Scan Probable
📧 SMTP Server on RBL Blacklist
que necesitan:
contexto.
El objetivo de la monitorización no es:
crear miedo.
Es:
obtener visibilidad.
Indicadores SonicWall: conclusión de la semana 40
Durante la semana 40 de 2026, nuestro SOC analizó 1.435 indicadores SonicWall procedentes de firewalls TZ270 y TZ370 que protegen entornos profesionales de distintos sectores.
Los principales eventos fueron:
🔎 Port Scan Possible
🔎 Port Scan Probable
📧 SMTP Server on RBL Blacklist
Además, la infraestructura observada estaba relacionada con diferentes países y proveedores de cloud, hosting, conectividad y VPN.
Entre los proveedores verificados aparecen OVHcloud, DigitalOcean, Akamai Connected Cloud/Linode, M247 Europe, Spartan Host, Virtuo y OVPN/Obehosting, entre otros. IPinfo
Las geolocalizaciones asociadas incluyen infraestructuras en:
🌎 Norteamérica
🌍 Europa
🌏 Asia
con presencia, entre otros, de Estados Unidos, Canadá, Francia, Países Bajos, Eslovenia, Suecia, China y Corea del Sur. Ipregistry
Sin embargo:
el país de una IP no identifica al atacante.
Y:
el proveedor de hosting no es el atacante.
En GHM Soluciones Informáticas trabajamos con:
🔥 SonicWall TZ270 y TZ370
📊 SIEM Wazuh
🔗 correlaciones personalizadas
🎯 alertas de indicadores de compromiso
🔎 análisis por nuestro SOC
🗄️ hasta 400 días de histórico de logs
La diferencia está en pasar de:
“el firewall ha generado una alerta”
a:
“sabemos qué ocurrió, contra qué servicio, qué hizo el firewall y si hubo actividad relacionada después”.
Puede consultar nuestras soluciones de Endpoint y firewall para empresas y nuestro servicio de SIEM Wazuh para empresas.
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre indicadores SonicWall
¿Cuántos indicadores SonicWall se analizaron durante la semana 40?
Nuestro SOC analizó 1.435 eventos e indicadores generados por SonicWall TZ270 y TZ370.
¿Significa que hubo 1.435 ataques?
No. Un indicador o evento no equivale a un ataque confirmado.
¿Qué detecciones fueron las más relevantes?
Port Scan Possible, Port Scan Probable y SMTP Server on RBL Blacklist.
¿Qué significa Port Scan Possible?
SonicWall ha observado un patrón compatible con un posible reconocimiento de puertos, pero no confirma por sí mismo un compromiso.
¿Qué significa Port Scan Probable?
El patrón observado tiene mayor consistencia con un escaneo de puertos, aunque sigue siendo necesario analizar su contexto.
¿Un escaneo significa que han entrado en la empresa?
No. Reconocimiento y compromiso son conceptos diferentes.
¿Los escaneos fueron bloqueados?
Con la información facilitada no podemos afirmar que todos fueran bloqueados. Para confirmarlo hay que revisar la acción registrada por el firewall, la política aplicada, NAT y respuesta del destino.
¿Qué significa SMTP Server on RBL Blacklist?
Indica una asociación con una lista de reputación utilizada en correo. No confirma automáticamente malware ni una intrusión.
¿De qué países procedía la infraestructura observada?
Aparecieron redes asociadas a distintos países de Norteamérica, Europa y Asia.
¿El país de una IP identifica al atacante?
No. Una dirección puede corresponder a cloud, VPN, proxy, hosting o un equipo previamente comprometido.
¿Qué proveedores aparecieron en la muestra?
Entre las redes verificadas se encuentran OVHcloud, DigitalOcean, Akamai Connected Cloud/Linode, M247 Europe, Spartan Host, Virtuo y OVPN/Obehosting. IPinfo
¿Significa que esos proveedores están realizando los ataques?
No. Los proveedores únicamente alojan o transportan infraestructura utilizada por terceros.
¿Por qué no publicamos las IP?
Porque preferimos no exponer públicamente telemetría innecesaria de los entornos que protegemos.
¿Qué sectores protegen estos SonicWall?
Administraciones de fincas, asesorías contables y laborales, despachos de abogados, arquitectura, interiorismo, construcción, ingeniería y despachos profesionales ubicados en viviendas.
¿Qué aporta SonicWall?
Visibilidad y protección de red, control de tráfico, políticas, NAT y generación de registros de seguridad.
¿Qué aporta SIEM Wazuh?
Centraliza y correlaciona los eventos del firewall con otras fuentes de la infraestructura.
¿Qué aporta nuestro SOC?
Nuestro SOC analiza los logs generados por SonicWall y el resto de fuentes para determinar su contexto y relevancia.
¿Por qué conservar hasta 400 días de logs?
Porque algunos incidentes se descubren meses después y necesitamos poder realizar investigaciones retrospectivas.
¿Cuál es la principal recomendación?
Reducir la superficie expuesta, mantener SonicWall actualizado, revisar NAT y servicios publicados, proteger el acceso remoto con VPN y MFA y centralizar los logs para poder investigar la actividad realmente relevante.
