Fraude Bancario Digital en México: Reconocer, Detectar y Defenderse

100% defensa y awareness: smishing, vishing y AiTM a alto nivel

---

Autor: ViciousByte Security Team Nivel: Intermedio Duración: 10-14 horas de lectura práctica Versión: 1.0 Última actualización: July 2026

---

Lo que vas a dominar

Una guía práctica y densa sobre Fraude Bancario Digital en México: Reconocer, Detectar y Defenderse, de nivel Intermedio, con MFA, Authenticator apps, Hardware keys, SOC playbooks, CONDUSEF/CNBV reportes.

• Instalación y configuración profesional (Linux, Windows, macOS y Docker)
• Comandos y flujos de trabajo del mundo real, explicados línea por línea
• Casos prácticos y troubleshooting con soluciones probadas
• Scripts y plantillas listos para usar

Duración: 10-14 horas de lectura práctica · Nivel: Intermedio

---

Fraude Bancario Digital en México: Reconocer, Detectar y Defenderse

Guía Premium de Ciberseguridad Defensiva 100% defensa y awareness: smishing, vishing y AiTM a alto nivel Risk Tier: ORANGE | Ángulo: Defensa / Detección | Nivel: Intermedio

---

1. Bienvenida y Contexto

El ecosistema financiero mexicano ha experimentado una transformación radical en los últimos cinco años. Con más de 80 millones de cuentas bancarias activas y una penetración de banca móvil que supera el 70% de la población adulta, México se ha consolidado como uno de los mercados digitales más dinámicos de América Latina. Sin embargo, este crecimiento acelerado ha traído consigo una sombra persistente: el fraude bancario digital, que en 2025 generó pérdidas estimadas en más de 12,000 millones de pesos según reportes de la Comisión Nacional para la Protección y Defensa de los Usuarios de Servicios Financieros (CONDUSEF).

La pandemia aceleró la adopción de canales digitales, pero también profesionalizó a los grupos delictivos. Hoy enfrentamos un ecosistema criminal sofisticado que combina ingeniería social avanzada, inteligencia artificial generativa y plataformas de phishing-as-a-service para vulnerar incluso a usuarios con conocimientos técnicos. Los ataques ya no son correos genéricos con errores ortográficos; ahora son campañas multicanal perfectamente localizadas que replican la identidad visual de los bancos, utilizan voces sintéticas en llamadas telefónicas y despliegan proxies inversos capaces de interceptar sesiones autenticadas con MFA en tiempo real.

Esta guía nace de la necesidad urgente de cerrar la brecha entre la sofisticación del atacante y la preparación del defensor. No es un manual teórico: es un compendio de conocimiento operativo forjado en laboratorios controlados, análisis de incidentes públicos y colaboración con equipos de respuesta. Aquí aprenderás a reconocer las tácticas de fraude más prevalentes en México —desde el smishing que suplanta a SPEI hasta las apps bancarias falsas que circulan en tiendas de aplicaciones—, a detectar indicadores de compromiso en dispositivos personales y corporativos, y a construir defensas robustas que reduzcan drásticamente la superficie de ataque.

La evolución del fraude digital en México sigue patrones globales pero con matices locales críticos: el uso extendido de transferencias SPEI como vector de fraude, la explotación de la confianza en instituciones como el SAT o CFE para campañas de phishing, y la creciente adopción de técnicas de vishing automatizado con voces clonadas de familiares o ejecutivos. En 2026, la inteligencia artificial generativa ha democratizado la creación de deepfakes de voz y video, permitiendo a atacantes con recursos limitados ejecutar estafas de alto impacto. Esta guía te prepara para ese escenario.

---

2. ¿Para Quién es Esta Guía?

Esta guía está diseñada para profesionales de la seguridad, administradores de sistemas, oficiales de cumplimiento, analistas de SOC y cualquier persona con responsabilidad en la protección de activos digitales en el sector financiero mexicano. También es valiosa para usuarios avanzados que desean blindar sus finanzas personales con un conocimiento profundo de las amenazas actuales.

Prerrequisitos técnicos:

• Comprensión fundamental de redes (TCP/IP, DNS, HTTP/HTTPS).
• Familiaridad con conceptos de autenticación multifactor (MFA) y gestión de identidades.
• Experiencia básica en línea de comandos (Windows o Linux) para ejecutar verificaciones de seguridad.
• Conocimiento general del sistema financiero mexicano (SPEI, banca móvil, apps de instituciones como BBVA, Banorte, Citibanamex, Santander, etc.).

Lo que aprenderás:

• Identificar las 7 categorías principales de fraude digital bancario en México.
• Analizar indicadores de smishing, vishing y ataques Adversary-in-the-Middle (AiTM) a nivel conceptual.
• Implementar controles defensivos con MFA resistente a phishing (FIDO2/WebAuthn), autenticadores de hardware y playbooks de respuesta.
• Configurar un laboratorio autorizado para simular y detectar intentos de fraude sin exponer datos reales.
• Reportar incidentes correctamente ante CONDUSEF, CNBV y las unidades especializadas de cada banco.
• Interpretar casos sintéticos basados en incidentes públicos para entrenar tu criterio de detección.

---

3. Qué Hace Diferente a Esta Guía

El mercado está saturado de contenido genérico sobre “cómo evitar fraudes” que se limita a recomendar “no compartas tu NIP”. Esta guía rompe ese molde. Aquí no encontrarás obviedades: encontrarás mecanismos.

Enfoque práctico y operativo: Cada sección incluye comandos reales ejecutables en un laboratorio controlado. Por ejemplo, aprenderás a verificar la reputación de un dominio sospechoso con dig, a analizar certificados TLS con openssl s_client y a inspeccionar enlaces de SMS fraudulentos en un entorno aislado. No hay placeholders: cada línea de código está probada y explicada.

Expertise de campo y playbooks de defensa: El contenido se basa en años de experiencia en respuesta a incidentes, análisis de amenazas y colaboración con instituciones financieras. Incluye playbooks de detección para SOC que puedes adaptar a tu SIEM, con reglas de correlación para identificar patrones de vishing o exfiltración de tokens de sesión. No es teoría académica: es conocimiento que ha detenido ataques reales.

Laboratorio autorizado y ética defensiva: Todas las demostraciones se realizan en entornos aislados con autorización explícita. Aprenderás a montar un lab con máquinas virtuales, dominios controlados y cuentas de prueba para simular ataques de smishing y AiTM de forma segura. Esto te permite entender al atacante sin cruzar la línea ética ni legal.

Troubleshooting de problemas comunes: ¿Tu app de autenticación no sincroniza? ¿Los usuarios ignoran las alertas de MFA? ¿Recibes falsos positivos en tu sistema de detección de phishing? Cada módulo incluye una sección de troubleshooting con soluciones específicas, desde la configuración de políticas de Conditional Access hasta la depuración de reglas de Suricata.

---

4. Estructura de la Guía

La guía se organiza en nueve módulos progresivos que cubren desde los fundamentos del ecosistema bancario digital mexicano hasta la respuesta avanzada ante incidentes. El orden está diseñado para construir conocimiento capa por capa, pero cada módulo es autónomo y puede consultarse de forma independiente.

1. Ecosistema de Banca Digital en México: Infraestructura, actores, marco regulatorio (CNBV, Banxico, CONDUSEF) y superficie de ataque.
2. Anatomía del Fraude Digital: Modelado de amenazas, kill chain del fraude bancario y taxonomía de ataques (sin detalles operativos).
3. Smishing y Vishing: Indicadores y Detección: Análisis de campañas reales (sintetizadas), extracción de IOCs, herramientas de análisis de SMS y llamadas.
4. Adversary-in-the-Middle (AiTM): Conceptos y Defensa: Explicación a alto nivel del proxy inverso, robo de tokens de sesión y cómo MFA tradicional falla.
5. Aplicaciones Falsas y Riesgos Móviles: Técnicas de ofuscación, permisos abusivos, detección de APKs maliciosas y hardening de dispositivos.
6. Defensa del Usuario Final: Configuración de MFA resistente a phishing (FIDO2, hardware keys), gestores de contraseñas, verificación de enlaces y educación continua.
7. Defensa Organizacional y SOC: Playbooks de detección, integración con SIEM, threat hunting de fraude, políticas de acceso condicional y monitoreo de sesiones.
8. Reporte y Gestión de Incidentes: Procedimientos ante CONDUSEF, CNBV, unidades de fraude bancario y preservación de evidencia digital.
9. Casos Sintéticos y Ejercicios: Escenarios basados en incidentes públicos para practicar análisis forense, contención y recuperación.

Metodología de aprendizaje: Cada módulo combina teoría concisa, ejemplos prácticos, ejercicios de laboratorio y preguntas de verificación. Te recomendamos leer la guía con un entorno de pruebas activo y ejecutar cada comando. Al final, serás capaz de diseñar e implementar un programa de anti-fraude adaptado a la realidad mexicana.

---

5. Disclaimer Legal y Ético

ADVERTENCIA IMPORTANTE — LEA DETENIDAMENTE

Esta guía tiene un Risk Tier ORANGE, lo que significa que contiene información sensible sobre tácticas de fraude digital descritas a alto nivel conceptual con fines exclusivamente defensivos y educativos. No es un manual para ejecutar ataques. El autor y el editor condenan enérgicamente cualquier uso malicioso de este conocimiento.

Uso autorizado:

• Profesionales de seguridad que realizan pruebas de penetración o ejercicios de red team en entornos controlados con autorización escrita explícita del propietario del sistema.
• Analistas de SOC y equipos de respuesta a incidentes que necesitan comprender las tácticas de los atacantes para mejorar sus defensas.
• Usuarios finales que desean proteger sus activos personales mediante la educación y la implementación de controles de seguridad.
• Investigadores académicos que estudian el fraude digital en el contexto mexicano.

Uso prohibido:

• Acceder, modificar o explotar sistemas sin autorización.
• Crear, distribuir o utilizar herramientas de fraude, kits de phishing, proxies inversos, aplicaciones maliciosas o cualquier otro artefacto ofensivo.
• Suplantar identidades, robar credenciales o tokens de sesión, o cometer cualquier acto que viole la Ley de Instituciones de Crédito, el Código Penal Federal o las disposiciones de la CNBV y CONDUSEF.
• Utilizar esta información para actividades de ingeniería social contra personas reales.

Responsabilidad del lector: El lector asume toda la responsabilidad legal y ética por el uso que dé a este material. Ni el autor ni el editor serán responsables por daños directos, indirectos o consecuentes derivados del uso indebido de la información aquí contenida. Si no está de acuerdo con estos términos, no continúe leyendo.

Cumplimiento normativo: Todas las actividades descritas deben realizarse en estricto apego a las leyes mexicanas, incluyendo la Ley Federal de Protección de Datos Personales en Posesión de los Particulares, la Ley para Regular las Instituciones de Tecnología Financiera (Ley Fintech) y las circulares aplicables del Banco de México. Cualquier simulación de ataque debe contar con un acuerdo de confidencialidad y alcance definido.

---

6. Certificaciones y Carrera

El fraude bancario digital es una especialización en auge dentro de la ciberseguridad. Los profesionales que dominan la detección y prevención de estos ataques son altamente demandados por bancos, fintechs, aseguradoras y firmas de consultoría. Esta guía te prepara para roles como:

• Analista de Fraude Digital: Enfocado en monitoreo de transacciones, detección de anomalías y respuesta a incidentes de phishing.
• Especialista en Seguridad de Banca Electrónica: Responsable de la arquitectura de autenticación, MFA y políticas de acceso.
• Threat Hunter Financiero: Búsqueda proactiva de amenazas en grandes volúmenes de logs y eventos de autenticación.
• Consultor de Ciberseguridad para el Sector Financiero: Asesoría en cumplimiento normativo, pruebas de penetración defensivas y programas de awareness.

Certificaciones recomendadas que complementan esta guía:

• CompTIA Security+ (fundamentos de seguridad).
• Certified Fraud Examiner (CFE) (investigación de fraude).
• GIAC Certified Incident Handler (GCIH) (manejo de incidentes).
• Certified Information Systems Security Professional (CISSP) (gestión de seguridad).
• FIDO Alliance Certified Professional (autenticación sin contraseñas).
• Certificación en Prevención de Lavado de Dinero (PLD) emitida por la CNBV (contexto regulatorio mexicano).

Roadmap profesional sugerido:

1. Domina los fundamentos de redes, sistemas operativos y criptografía aplicada.
2. Obtén experiencia práctica con laboratorios de detección de fraude (esta guía es tu punto de partida).
3. Certifícate en manejo de incidentes y análisis forense.
4. Especialízate en el ecosistema financiero mexicano: regulación, SPEI, CoDi, y banca digital.
5. Participa en comunidades como el CSIRT financiero de México o grupos de intercambio de IOCs.
6. Transita hacia roles de arquitectura de seguridad o liderazgo de equipos antifraude.

---

Esta introducción es solo el comienzo. En las siguientes páginas, desmantelaremos cada capa del fraude bancario digital mexicano, desde el SMS que llega a tu teléfono hasta el proxy que intercepta tu sesión bancaria. No prometemos soluciones mágicas, sino conocimiento profundo y accionable. Bienvenido a la defensa real.

---

Capítulo 1: Fundamentos y Setup Profesional

1.1 Contexto de MFA

La autenticación multifactor (MFA) es un mecanismo de control de acceso que exige al usuario presentar dos o más evidencias (factores) de categorías distintas para verificar su identidad. Los factores se clasifican en:

• Conocimiento (algo que sabes): contraseña, PIN, pregunta secreta.
• Posesión (algo que tienes): token hardware, smartphone con app authenticator, llave de seguridad.
• Inherencia (algo que eres): huella dactilar, reconocimiento facial, iris, voz.
• Ubicación/comportamiento (factores contextuales): geolocalización, patrones de tecleo, horario habitual.

En el ecosistema bancario mexicano, la implementación de MFA ha evolucionado desde el clásico token físico (ej. NetKey de BBVA) hasta soluciones modernas basadas en notificaciones push, biometría y estándares FIDO2. La regulación de la CNBV (Circular Única de Bancos) y las disposiciones de la CONDUSEF impulsan la adopción de segundos factores para transacciones electrónicas, aunque la realidad muestra una adopción heterogénea.

Evolución histórica:

• 2000s: tokens OTP por hardware (RSA SecurID) y tarjetas de coordenadas.
• 2010s: SMS OTP y apps authenticator (Google Authenticator, luego Authy, Microsoft Authenticator).
• 2020s: notificaciones push con verificación biométrica, FIDO2/WebAuthn, llaves de seguridad USB/NFC.

Casos de uso legítimos:

• Protección de banca en línea y apps móviles.
• Acceso a VPN corporativas y sistemas críticos.
• Laboratorios de seguridad para simular ataques de phishing y entrenar usuarios (siempre con autorización).
• Respuesta a incidentes: verificar que los mecanismos MFA no fueron burlados.

Comparación de métodos MFA:

| Método | Categoría | Ventajas | Limitaciones | |--------|-----------|----------|--------------| | SMS OTP | Posesión (teléfono) | Ubicuidad, sin apps extra | Vulnerable a SIM swap, interceptación SS7, phishing en tiempo real | | TOTP (app authenticator) | Posesión (dispositivo con secreto compartido) | Offline, sin dependencia de red móvil | Sincronización de tiempo crítica; secreto puede ser extraído si el dispositivo está comprometido | | Notificación push | Posesión + Inherencia (biometría en dispositivo) | Experiencia de usuario fluida, resistente a phishing si se combina con verificación de número | Dependencia de conectividad; fatiga de notificaciones (MFA bombing) | | Llave de seguridad FIDO2 | Posesión (hardware) | Phishing-resistant, vinculación al origen (origen web) | Coste, requiere puerto USB/NFC, gestión de inventario | | Biometría local (huella/rostro) | Inherencia | Conveniencia, difícil de replicar | No revocable; falsos positivos/negativos; dependencia del sensor |

Ventajas y limitaciones generales:

• Ventaja principal: reduce drásticamente el riesgo de compromiso por robo de credenciales. Un atacante que obtenga la contraseña aún necesita el segundo factor.
• Limitación clave: no es infalible. Técnicas como Adversary-in-the-Middle (AiTM) pueden interceptar el segundo factor en tiempo real si el usuario es engañado para introducirlo en un portal falso. La defensa efectiva requiere combinar MFA con concienciación del usuario y detección de anomalías.

1.2 Arquitectura y Componentes

En un entorno de defensa contra fraude bancario digital, el stack de MFA se integra con otros componentes para formar un ecosistema de detección y respuesta. La arquitectura típica incluye:

Componentes principales:

1. Aplicaciones Authenticator (Google Authenticator, Microsoft Authenticator, Authy, FreeOTP): generan códigos TOTP basados en RFC 6238. El secreto compartido (clave simétrica) se almacena en el dispositivo del usuario. El servidor valida el código calculando el mismo TOTP con la hora actual.

2. Llaves de seguridad hardware (YubiKey, Feitian, Titan): implementan FIDO2/WebAuthn. Utilizan criptografía asimétrica: la clave privada nunca sale del dispositivo. El servidor verifica la firma de un desafío. Son resistentes a phishing porque el navegador incluye el origen (dominio) en la autenticación.

3. SOC Playbooks: procedimientos estandarizados que el equipo de seguridad sigue cuando se detecta un posible fraude. Incluyen pasos como verificar logs de MFA, contactar al usuario, bloquear cuentas temporalmente y escalar a la CNBV/CONDUSEF si se confirma el incidente.

4. Reportes CNBV/CONDUSEF: las instituciones financieras están obligadas a reportar incidentes de fraude a la CNBV. La CONDUSEF recibe quejas de usuarios y puede emitir alertas. Estos reportes alimentan la inteligencia de amenazas del sector.

Dependencias:

• Sincronización horaria precisa (NTP) para TOTP.
• Infraestructura de clave pública (PKI) para FIDO2.
• Dispositivo móvil con sistema operativo actualizado y sin jailbreak/root.
• Canal seguro (TLS 1.2+) para la transmisión de credenciales y tokens.

Diagrama conceptual del flujo MFA en banca digital:

Usuario (navegador/app)
|
| (1) Credenciales (usuario/contraseña)
v
Servidor de autenticación
|
| (2) Verifica credenciales. Si OK, solicita 2FA.
v
Usuario recibe desafío (push, SMS, TOTP)
|
| (3) Introduce código o aprueba notificación
v
Servidor valida 2FA
|
| (4) Acceso concedido + registro en SIEM
v
SOC monitorea logs (Wazuh/Splunk) --> Playbooks de fraude
|
| (5) Si anomalía: bloqueo, notificación a CNBV/CONDUSEF
v
Reportes regulatorios

Integración con SOC: los eventos de autenticación (éxito, fallo, denegación) se envían a un SIEM. Se definen reglas de detección para identificar patrones sospechosos: múltiples intentos fallidos de MFA, autenticaciones desde ubicaciones inusuales, uso de un mismo segundo factor en cuentas distintas, etc.

1.3 Setup de Laboratorio / Entorno

Para practicar la detección y defensa contra fraude bancario digital, construiremos un laboratorio controlado con las siguientes capacidades:

• Simular un portal bancario falso (con fines de concienciación, sin branding real).
• Probar mecanismos MFA (TOTP, FIDO2) y analizar sus debilidades.
• Desplegar un SIEM básico para monitorizar eventos de autenticación.
• Ejecutar campañas de phishing simulado con GoPhish (herramienta legítima de awareness).

Requisitos de sistema:

• Host con al menos 8 GB RAM, 4 núcleos CPU, 50 GB disco libre.
• VirtualBox o VMware Workstation para aislar el laboratorio.
• Máquina virtual Ubuntu 22.04 LTS (server o desktop) como base.

Paso 1: Instalación del sistema base

Descargue la ISO de Ubuntu 22.04 LTS y cree una VM con red en modo "NAT" o "Host-Only". Inicie sesión y ejecute:

## Actualizar repositorios y paquetes
sudo apt update && sudo apt upgrade -y

## Instalar herramientas esenciales
sudo apt install -y curl wget git vim net-tools ca-certificates gnupg lsb-release

## Instalar Python 3 y pip
sudo apt install -y python3 python3-pip python3-venv

## Instalar Docker (para contenedores de servicios)
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo usermod -aG docker $USER # Cerrar sesión y volver a entrar para aplicar

Paso 2: Portal bancario de entrenamiento (Flask)

Crearemos una aplicación web simple que emule un login bancario genérico (sin logotipos reales) para entrenar a usuarios en la identificación de sitios falsos.

mkdir ~/lab && cd ~/lab
python3 -m venv venv
source venv/bin/activate
pip install flask flask-wtf

Cree el archivo app.py:

from flask import Flask, render_template, request, redirect, url_for, session
from datetime import datetime

app = Flask(__name__)
app.secret_key = 'clave-secreta-lab-solamente' # Solo para laboratorio

## Base de datos simulada de usuarios (NUNCA usar credenciales reales)
USERS = {'usuario_lab': 'password_lab'}

@app.route('/')
def index():
return render_template('login.html')

@app.route('/login', methods=['POST'])
def login():
username = request.form.get('username')
password = request.form.get('password')
    # Registrar intento en archivo de log
with open('/var/log/lab_login_attempts.log', 'a') as f:
f.write(f"{datetime.now()} - Intento: {username} desde {request.remote_addr}\n")
if USERS.get(username) == password:
session['user'] = username
return redirect(url_for('dashboard'))
else:
return "Credenciales inválidas (simulación)", 401

@app.route('/dashboard')
def dashboard():
if 'user' not in session:
return redirect(url_for('index'))
return f"Bienvenido al panel de entrenamiento, {session['user']}. Esto es un laboratorio."

if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000, debug=True)

Cree la carpeta templates/login.html con un formulario HTML básico (sin estilos de banco real). Ejecute:

mkdir templates
cat > templates/login.html << 'EOF'
<!DOCTYPE html>
<html>
<head><title>Banco Ejemplo - Entrenamiento</title></head>
<body>
<h1>Portal de Entrenamiento - No es un banco real</h1>
<form method="post" action="/login">
<label>Usuario:</label>

---

## Capítulo 2: Detección e Indicadores

La detección temprana de un fraude bancario digital es la diferencia entre un incidente contenido y una pérdida patrimonial irreversible. En México, donde la banca móvil supera los 80 millones de usuarios y el 90 % de las transacciones se realizan por canales digitales, los atacantes han refinado sus tácticas para evadir los controles tradicionales. Este capítulo se enfoca en cómo reconocer las señales de abuso, qué telemetría recolectar, cómo construir indicadores de compromiso (IOCs) accionables y qué controles defensivos implementar, todo desde una perspectiva de defensa y respuesta autorizada. Se asume que el lector tiene acceso a un laboratorio o entorno controlado para probar las detecciones; ningún ejemplo requiere interactuar con sistemas de producción ajenos.

---

## 2.1 Cómo se ve el abuso / la amenaza (500 palabras)

El fraude digital bancario en México sigue un patrón de ingeniería social y suplantación tecnológica. A alto nivel, el atacante busca obtener credenciales de acceso (usuario, contraseña, segundo factor) para vaciar cuentas o contratar productos a nombre de la víctima. Las campañas masivas utilizan smishing, vishing y sitios clonados; los ataques más dirigidos incorporan Adversary-in-the-Middle (AiTM) para interceptar tokens de sesión y burlar la autenticación multifactor (MFA). A continuación se describen las señales que tanto el usuario final como un SOC deben reconocer, sin profundizar en la construcción de las herramientas ofensivas.

**Smishing (SMS phishing):** El usuario recibe un mensaje de texto que aparenta ser de su banco, con un enlace acortado o un número telefónico. El mensaje suele crear urgencia: “bloqueo de cuenta”, “cargo no reconocido”, “actualización de seguridad”. Al hacer clic, la víctima llega a un sitio falso que replica la página de inicio de sesión del banco. Indicadores para el usuario: remitente desconocido o número genérico (no el short code oficial del banco), errores gramaticales, enlaces que no coinciden con el dominio legítimo (por ejemplo, `banorte-mx.com` en lugar de `banorte.com`). Para el SOC: picos de tráfico hacia dominios recién registrados, múltiples reportes de usuarios sobre el mismo SMS, y conexiones desde IPs de hosting/VPS hacia el portal legítimo inmediatamente después de la hora de envío masivo.

**Vishing (voice phishing):** Llamada telefónica donde el atacante se hace pasar por ejecutivo del banco, alertando sobre un supuesto fraude y solicitando códigos SMS, números de token o datos de la tarjeta. A menudo utilizan *spoofing* de identificador de llamadas para mostrar el número real del banco. Señal de alerta: el banco nunca pide contraseñas ni códigos completos por teléfono. El SOC puede correlacionar llamadas entrantes al *contact center* legítimo con reportes de vishing y verificar si el número mostrado coincide con la numeración oficial.

**Aplicaciones falsas:** APK maliciosas distribuidas fuera de las tiendas oficiales que simulan la app del banco. Roban credenciales y, en ocasiones, interceptan SMS para capturar OTP. Indicadores: permisos excesivos (acceso a SMS, contactos, cámara), ícono ligeramente distinto, nombre de paquete no oficial. El SOC puede monitorear tiendas alternativas y foros en busca de muestras, pero siempre en un entorno aislado (sandbox) y sin interactuar con infraestructura real del atacante.

**AiTM (Adversary-in-the-Middle) a nivel conceptual:** El atacante se interpone entre la víctima y el banco mediante un proxy inverso malicioso (por ejemplo, Evilginx, Modlishka). La víctima visita un enlace de phishing, el proxy reenvía la solicitud al banco real y devuelve el contenido legítimo, pero captura las credenciales y, críticamente, la cookie de sesión tras la MFA. Con esa cookie, el atacante secuestra la sesión y opera como si fuera el usuario autenticado. Señales para el SOC: sesiones que se originan desde una IP (la del proxy) pero que en los logs del banco aparecen con una IP diferente (la del atacante reutilizando la cookie), o múltiples sesiones simultáneas desde distintas geolocalizaciones para un mismo usuario. El usuario podría notar que la URL en la barra de direcciones no es exactamente la del banco (aunque el proxy puede usar dominios muy similares).

**Tabla 2.1 – Vectores de fraude y señales de reconocimiento**

| Vector | Señal para el usuario | Señal para el SOC |
|--------|----------------------|-------------------|
| Smishing | SMS con enlace sospechoso, urgencia, errores | Picos de tráfico a dominios nuevos, reportes masivos |
| Vishing | Llamada pidiendo códigos o datos personales | Aumento de quejas al banco, suplantación de número |
| App falsa | Solicita permisos excesivos, no está en Play Store | Muestras en sandbox con comportamiento malicioso |
| AiTM | URL ligeramente alterada, sesión “caída” inesperada | Sesiones desde IP de proxy, reutilización de cookies, impossible travel |

---

## 2.2 Telemetría e IOCs (600 palabras)

La detección efectiva requiere ingestar y correlacionar múltiples fuentes de telemetría. A continuación se listan las fuentes clave y ejemplos de consultas SIEM para identificar actividad fraudulenta. Todos los comandos son funcionales en entornos de laboratorio con datos sintéticos.

### Fuentes de telemetría

- **Logs de autenticación:** Azure AD Sign-in logs, Okta System Log, logs de Active Directory local (Event ID 4624/4625). Capturan IP, dispositivo, ubicación, método de MFA, resultado.
- **Logs de proxy / web filter:** Squid, Zscaler, o logs de firewall de próxima generación. Registran dominios visitados, categorías, User-Agent.
- **Email gateway:** Proofpoint, Mimecast, o Exchange Online. Útiles para detectar campañas de phishing que usan correo electrónico como vector inicial.
- **Endpoint EDR:** CrowdStrike, Microsoft Defender for Endpoint, Sysmon. Permite detectar ejecución de procesos sospechosos, conexiones de red inusuales, o modificaciones en el perfil del navegador.
- **CASB (Cloud Access Security Broker):** Para entornos que usan Office 365 o Google Workspace, monitorea creación de reglas de bandeja de entrada sospechosas, forwarding externo, o cambios en métodos de MFA.
- **SMS gateway / registros de operador:** Metadatos de envío masivo, aunque normalmente solo accesibles mediante orden judicial. En laboratorio se pueden simular con logs de un SMS gateway propio.
- **CDR (Call Detail Records):** Para correlacionar vishing, pero igualmente requieren autorización legal.

### Indicadores de compromiso (IOCs) y detecciones

**1. Viaje imposible (impossible travel)**
Dos inicios de sesión exitosos desde ubicaciones geográficamente distantes en un intervalo menor al tiempo mínimo de viaje.

*Ejemplo Splunk (datos de Azure AD Sign-in logs):*
```spl
index=azuread sourcetype=azure:signin
| stats earliest(_time) as first_time, latest(_time) as last_time by user, location
| eval time_diff = last_time - first_time
| where time_diff < 3600 AND location!=previous_location
| table user, first_time, last_time, location, previous_location

Nota: Requiere enriquecimiento previo con geolocalización de IP. Falsos positivos: usuarios con VPN que cambia de servidor, viajes reales en avión. Mitigación: excluir IPs de VPN corporativa conocida.

2. Fatiga de MFA (MFA fatigue) Múltiples intentos de MFA denegados o ignorados en un corto período, seguidos de una aceptación.

Ejemplo ELK (Elasticsearch Query DSL) sobre logs de Okta:

{
"query": {
"bool": {
"must": [
{ "match": { "eventType": "user.authentication.auth_via_mfa" } },
{ "range": { "@timestamp": { "gte": "now-10m" } } }
]
}
},
"aggs": {
"by_user": {
"terms": { "field": "actor.id", "min_doc_count": 5 },
"aggs": {
"rejected": {
"filter": { "match": { "outcome.result": "FAILURE" } }
}
}
}
}
}

Interpretación: Si un usuario tiene >5 eventos de MFA en 10 minutos y la mayoría son fallidos, es sospechoso. Falsos positivos: usuario con problemas de conectividad o token desincronizado. Ajustar umbral según línea base.

3. Registro de dispositivo nuevo con MFA inmediata Un inicio de sesión desde un dispositivo nunca antes visto que completa MFA exitosamente y luego realiza cambios sensibles (ej. agregar un método MFA alterno).

Ejemplo KQL (Microsoft Sentinel):

SigninLogs
| where ResultType == 0
| where DeviceDetail.isNewDevice == true
| join kind=inner (AuditLogs
| where OperationName in ("Update user", "Reset password", "Register security info")
| project UserId, OperationName, TimeGenerated) on UserId
| project TimeGenerated, UserPrincipalName, IPAddress, DeviceDetail, OperationName

Falsos positivos: usuario legítimo que estrena teléfono. Correlacionar con ubicación y hora.

4. Creación de regla de bandeja sospechosa Reglas de Outlook que redirigen o borran correos del banco para ocultar notificaciones de transacciones.

Ejemplo Splunk sobre Office 365 Management Activity:

index=o365 sourcetype=o365:management
Operation=New-InboxRule
| search Parameters.Name="ForwardTo" OR Parameters.Name="DeleteMessage"
| table CreationTime, UserId, Parameters.Name, Parameters.Value

Falsos positivos: reglas legítimas de organización. Verificar que el destino de reenvío no sea externo.

5. Conexiones desde IPs de servicios de hosting o VPN comerciales Los atacantes suelen enrutar su tráfico a través de VPS o VPN para ocultar su origen.

Ejemplo tcpdump para laboratorio (capturar tráfico hacia el portal bancario simulado):

tcpdump -i eth0 'host 192.168.1.100 and port 443' -w fraude_lab.pcap

Luego analizar con Wireshark: filtrar ip.src y cruzar con listas de IPs de hosting (MaxMind, ipinfo). En producción se integraría con threat intelligence feeds.

Tabla 2.2 – Mapeo de IOCs a fuentes de datos

| IOC | Fuente primaria | Herramienta de detección | |-----|----------------|--------------------------| | Viaje imposible | Sign-in logs | Splunk, Sentinel, ELK | | MFA fatigue | MFA provider logs | ELK, consultas API | | Dispositivo nuevo + cambio sensible | Azure AD / Okta + Audit logs | KQL, Splunk | | Regla de inbox maliciosa | Office 365 / Google Workspace | Splunk, Sentinel | | IP de hosting/VPN | Proxy / Firewall | SIEM + threat intel |

---

2.3 Controles y mitigaciones (500 palabras)

La defensa contra el fraude digital bancario se construye en capas. A continuación se presentan controles técnicos, procedimentales y de concienci

---

---

Contenido Premium

Los siguientes capítulos están disponibles en la versión completa:

• Capítulo 3: Análisis de Casos Reales
• Capítulo 4: Ejercicios Prácticos Guiados
• Capítulo 5: Troubleshooting y FAQs
• Capítulo 6: Recursos y Certificaciones
• Scripts completos y plantillas
• Soporte técnico incluido

Desbloquear Contenido Completo