← Volver al blog
Casos forenses · 8 de mayo de 2026 · Edición institucional MMXXVI

Smishing bancario en España

En el primer trimestre de 2026, el Centro de Respuesta a Incidentes de Seguridad de INCIBE registró un repunte significativo de campañas de smishing dirigidas a clientes de entidad…

En el primer trimestre de 2026, el Centro de Respuesta a Incidentes de Seguridad de INCIBE registró un repunte significativo de campañas de smishing dirigidas a clientes de entidades financieras españolas, con dominios de suplantación activos durante ventanas inferiores a 72 horas para eludir los mecanismos de bloqueo reactivo. La tipología dominante: un SMS aparentemente emitido por el banco legítimo, con remitente alfanumérico falsificado, que instruye al destinatario a verificar una operación sospechosa a través de una URL acortada o de un dominio registrado horas antes.

El smishing bancario en España en 2026 consiste en el envío masivo de mensajes SMS fraudulentos que suplantan la identidad de entidades financieras para redirigir al cliente a páginas de captura de credenciales o datos de tarjeta. La amenaza se distingue por la falsificación del identificador alfanumérico del remitente —técnica conocida como sender ID spoofing— que inserta el mensaje directamente en el hilo de conversación legítimo del banco en el dispositivo del usuario, eliminando el indicador visual más básico de desconfianza.

"Las entidades financieras deben implantar mecanismos de autenticación reforzada y canales de comunicación verificables con sus clientes, en línea con lo dispuesto en el artículo 97 de la Directiva PSD2 (Directiva UE 2015/2366) y las Directrices EBA sobre seguridad de pagos en internet (EBA/GL/2014/12)."

— Banco de España, Memoria de Supervisión 2024, apartado de riesgos operativos en banca minorista.

¿Por qué este problema es urgente ahora para su entidad?

La convergencia de tres factores hace que el smishing bancario sea una prioridad de primer orden para cualquier comité de riesgos en 2026. Primero, el marco DORA (Reglamento UE 2022/2554), aplicable desde enero de 2025, exige en su artículo 5 que las entidades financieras dispongan de capacidades de gestión del riesgo de las tecnologías de la información y la comunicación que cubran explícitamente los vectores de ingeniería social dirigidos al cliente final. Segundo, el artículo 97 de PSD2 obliga a la autenticación reforzada, pero no blinda el canal SMS previo al inicio de la sesión: es precisamente ahí donde opera el smishing. Tercero, el riesgo reputacional es inmediato y medible: según datos del Banco de España, las reclamaciones por fraude en medios de pago electrónico representaron el principal motivo de queja en banca minorista durante 2024, con una tasa de resolución desfavorable para la entidad que supera el 60 % en los casos donde el canal SMS estuvo implicado en el inicio del fraude.

¿Cómo se construye técnicamente un SMS de suplantación bancaria?

Fase 1 — Registro de infraestructura y falsificación del remitente

El ciclo de vida de una campaña de smishing bancario comienza entre 48 y 96 horas antes del envío masivo. El operador fraudulento registra un dominio con estructura semántica engañosa —patrón habitual: banco-operaciones.net/verificar o alertas-banca-segura.es/acceso— en registradores con ciclos de verificación laxos, a menudo fuera de la Unión Europea. Simultáneamente, configura una ruta de envío SMS a través de agregadores que permiten establecer el campo Sender ID como cadena alfanumérica libre: en la práctica, el mensaje llega al dispositivo del usuario con el identificador del banco legítimo. Los operadores españoles tienen capacidad técnica para filtrar este tráfico, pero la fragmentación de rutas internacionales y el uso de interconexiones grises dificulta el bloqueo en origen. La CNMC ha abierto vías de coordinación con operadores para el filtrado en capa de red, si bien la implementación es heterogénea.

Fase 2 — El mensaje: ingeniería semántica de alta presión

El cuerpo del SMS está diseñado para provocar acción inmediata. Los patrones más frecuentes en campañas analizadas durante Q1 2026 comparten cuatro elementos estructurales: urgencia temporal explícita ("su cuenta quedará bloqueada en 24 horas"), referencia a una operación concreta con importe verosímil, instrucción de acción única y URL que visualmente imita el dominio del banco. La URL suele ir acortada o presentada con un subdominio del tipo seguridad.banco-alertas.com, donde el ojo no entrenado lee primero la palabra "seguridad". El texto evita errores ortográficos groseros —característica de campañas anteriores— porque las herramientas de generación de texto han normalizado la redacción en castellano formal. Esto elimina uno de los indicadores de sospecha más utilizados en formación a empleados y clientes.

Fase 3 — Página de captura y exfiltración

La URL despliega una réplica visual de la banca digital de la entidad suplantada, servida con certificado TLS válido —lo que invalida el consejo clásico de "compruebe el candado"— y optimizada para móvil. El formulario captura, en secuencia, el número de documento de identidad, las credenciales de acceso y, en la variante más sofisticada, el código de verificación de un solo uso generado por la entidad real mediante un ataque de retransmisión en tiempo real. El dominio fraudulento permanece activo entre 18 y 72 horas según los datos de seguimiento de campañas en España, tiempo suficiente para comprometer varios miles de dispositivos antes de que los mecanismos de bloqueo reactivo —notificación a registrador, comunicación a operadores, actualización de listas de bloqueo— surtan efecto.

¿Qué aporta VeriMsg en la detección de smishing antes de que el daño sea irreversible?

El SOC de su entidad opera sobre infraestructura interna y tráfico ya dentro del perímetro. El gap operativo en smishing está en el canal exterior: el SMS llega al cliente antes de que cualquier sistema interno tenga visibilidad sobre él. VeriMsg actúa como capa de verificación en ese espacio intermedio, entre el remitente declarado y el dispositivo del usuario final, cubriendo tres funciones que el SOC convencional no cubre por diseño.

Primera: análisis de remitente en tiempo real. VeriMsg contrasta el identificador alfanumérico del mensaje contra el registro de Sender IDs legítimos declarados por la entidad, generando una señal de discrepancia antes de que el mensaje complete su entrega cuando el operador coopera en el filtrado. Segunda: inspección semántica y de URL sin necesidad de que el cliente interactúe. El motor evalúa la URL embebida —incluyendo dominios acortados mediante resolución de cadena— contra patrones de infraestructura conocida de campañas activas, con trazabilidad de señal por fase auditables por su equipo de cumplimiento, alineada con los requisitos de registro de incidentes del artículo 17 de DORA. Tercera: emisión de veredicto con puntuación y señales desagregadas, de forma que su comité de riesgos y sus auditores disponen de una traza estructurada —no una caja negra— que documenta por qué un mensaje fue marcado como fraudulento, con qué grado de confianza y qué señales lo fundamentan.

Esta arquitectura no sustituye al SOC: lo complementa aguas arriba, en el canal que el SOC no vigila porque no es su perímetro.

Preguntas frecuentes

¿Puede una entidad bancaria española ser considerada responsable del smishing que suplanta su marca?

La normativa no imputa responsabilidad directa por la acción del tercero fraudulento, pero el Banco de España evalúa si la entidad adoptó medidas razonables de protección del cliente. La ausencia de controles activos sobre el canal SMS puede agravar la valoración de la reclamación y el riesgo reputacional asociado.

¿El filtrado de Sender ID por parte de los operadores resuelve el problema?

Parcialmente. El filtrado en capa de red elimina una porción del tráfico ilegítimo, pero la fragmentación de rutas internacionales y el uso de interconexiones no reguladas deja una ventana de exposición significativa. Es una capa necesaria, no suficiente, que debe complementarse con análisis en la capa de contenido y URL.

¿Cómo se alinea la detección de smishing con los requisitos de DORA?

El artículo 5 de DORA obliga a una gestión del riesgo TIC que cubra los vectores de ingeniería social. El artículo 17 exige registro y trazabilidad de incidentes. Una solución de detección de smishing que emita veredictos auditables con señales desagregadas cubre ambos requisitos de forma documentable para supervisores y auditores externos.

¿Qué distingue una URL de smishing de una URL legítima con solo inspeccionarla?

En campañas recientes, la distinción visual es prácticamente nula para el usuario no entrenado: certificado TLS válido, diseño fiel y dominio con palabras clave del banco. La detección requiere análisis de antigüedad del dominio, infraestructura de hospedaje, patrones de registro y correlación con campañas activas conocidas, no inspección manual.

Checklist ejecutivo: tres acciones accionables para su comité de riesgos

  1. Audite su inventario de Sender IDs declarados ante operadores. Si su entidad no tiene formalizado un registro de los identificadores alfanuméricos legítimos utilizados en comunicaciones SMS —por línea de negocio, proveedor y operador—, cualquier sistema de detección de discrepancias opera sin referencia. Este inventario es también documentación exigible en una inspección bajo DORA. Plazo recomendado: 30 días.
  2. Implante un protocolo de respuesta ante campaña activa con ventana de actuación inferior a cuatro horas. El smishing opera en ventanas de 18 a 72 horas. Un protocolo que tarde más de cuatro horas en notificar a operadores, activar bloqueo de dominio ante el registrador y alertar a clientes a través de canal alternativo garantiza exposición máxima. Defina responsables, escalados y plantillas de comunicación antes de que la campaña ocurra.
  3. Incorpore análisis de URL embebida en SMS como señal de primer orden en su modelo de riesgo de canal. La URL es la señal más discriminante y la más ignorada en los modelos de riesgo centrados en comportamiento de sesión. Una capa de verificación de URL en tiempo real —con resolución de acortadores y análisis de infraestructura de dominio— cierra el gap entre el canal de comunicación y el perímetro del SOC. Evalúe la cobertura de su modelo actual y el gap específico en este vector antes de la próxima revisión de riesgo operacional.

Si su entidad quiere evaluar la cobertura concreta de su exposición actual en canal SMS, el Pilot Readiness Pack de VeriMsg proporciona un análisis estructurado de su inventario de remitentes, simulación de detección sobre tipologías activas en España y documentación de trazabilidad alineada con los requerimientos de reporte de DORA. Sin compromiso de implantación. Con entregable auditable.

¿Evaluamos un piloto TrustLayer en su entidad?

Un analista prepara el alcance del piloto en 10 días hábiles. Sin coste, sin compromiso.

Pilot Readiness Pack