Ataques dirigidos y fraude corporativo: pretexting, BEC y manipulación de procesos

Ataques dirigidos: qué los hace diferentes

Un ataque dirigido no se basa en enviar mensajes masivos, sino en construir un caso creíble con datos específicos de la organización o de una persona: organigramas publicados, ofertas de empleo, notas de prensa, proveedores visibles en facturas, firmas de correo filtradas, credenciales expuestas o documentos internos obtenidos en brechas. Con esa información, el atacante diseña un guion (pretexto) y lo inserta en un proceso real (pagos, altas de proveedor, cambios bancarios, nómina, soporte), buscando que el propio flujo interno “valide” el fraude.

Fuentes típicas de información que habilitan el ataque

• Información pública: web corporativa, LinkedIn, licitaciones, memorias, comunicados, directorios, calendarios de eventos, fotos de oficinas con pizarras o credenciales.
• Filtraciones y brechas: correos y contraseñas reutilizadas, plantillas de facturas, firmas, organigramas, tickets de soporte, documentos con metadatos.
• Relación con terceros: nombres de proveedores, bancos, números de pedido, rutinas de aprobación, horarios de cierre contable.

Pretexting corporativo: guiones creíbles para activar procesos

El pretexting es la creación de una historia falsa pero plausible para obtener una acción concreta: aprobar un pago, compartir un documento, cambiar un dato maestro o saltarse un control. En entornos corporativos, los pretextos más efectivos se apoyan en roles con autoridad percibida (auditoría, RR. HH., dirección, proveedor estratégico) y en momentos de presión (cierres, auditorías, incidencias).

Pretextos frecuentes y qué buscan

• “Auditoría / cumplimiento”: solicita listados de pagos, extractos, contratos, accesos temporales o “evidencias” con urgencia.
• “RR. HH.”: pide cambios de cuenta de nómina, datos personales, certificados, o que se “verifique” información de empleados.
• “Proveedor”: comunica cambio de cuenta bancaria, reenvía factura “pendiente”, o pide que se acelere un pago por “bloqueo de servicio”.
• “Soporte / TI / seguridad”: solicita restablecer credenciales, desactivar MFA, aprobar un dispositivo o reenviar códigos.

Señales operativas (no genéricas) que delatan pretexting

• El solicitante intenta cambiar el canal (“responde por aquí”, “no llames, estoy en reunión”).
• La petición evita el flujo normal (“solo esta vez”, “no abras ticket”, “no involucres a compras”).
• Se apoya en urgencia de cierre o en autoridad delegada (“viene de dirección”, “lo aprobó el CFO”).
• Pide datos maestros (cuentas bancarias, direcciones, beneficiarios) o acciones irreversibles (transferencias, altas, cambios).

BEC (Business Email Compromise): fraude por correo orientado a pagos

El BEC es un fraude en el que el atacante manipula comunicaciones empresariales para provocar pagos a cuentas controladas por él. Puede implicar suplantación del dominio, compromiso de una cuenta real o uso de hilos previos robados. El objetivo típico es un cambio de cuenta bancaria o una transferencia urgente fuera de procedimiento.

Patrones de BEC centrados en “cambio de cuenta”

• Proveedor legítimo, cuenta bancaria falsa: “Hemos cambiado de banco, actualiza nuestros datos para la próxima factura”.
• Dirección/finanzas suplantadas: “Necesito que pagues hoy a este beneficiario; es confidencial”.
• Secuestro de hilo: el atacante responde dentro de una conversación real con adjuntos y referencias correctas, insertando el cambio de pago.

Fraude de facturas: cómo se inserta en compras y cuentas por pagar

El fraude de facturas puede ocurrir sin comprometer correos: basta con introducir una factura con apariencia válida (logo, formato, número de pedido) o modificar una factura real (IBAN, beneficiario, importe). Suele explotar debilidades en el matching (pedido-recepción-factura), en el alta de proveedores o en la validación de datos bancarios.

Cómo se explotan procesos internos (y cómo cerrarlos)

1) Aprobaciones: cuando el flujo valida el fraude

Los atacantes buscan que una aprobación “formal” ocurra, aunque esté basada en información falsa. Esto sucede cuando el aprobador confía en el canal (correo) en lugar de validar el hecho (cambio real, proveedor real, cuenta real).

Continúa en nuestra aplicación.

• Escuche el audio con la pantalla apagada.
• Obtenga un certificado al finalizar.
• ¡Más de 5000 cursos para que explores!

O continúa leyendo más abajo...

Descargar la aplicación

Control operativo: separar “aprobación de gasto” de “aprobación de datos maestros”. Un pago puede estar aprobado, pero el cambio de cuenta debe pasar por un control distinto.

2) Urgencias de dirección: la excepción como puerta de entrada

El mensaje suele forzar una excepción: “paga hoy”, “no escales”, “es confidencial”. La urgencia reduce la verificación y aumenta la probabilidad de saltarse el procedimiento.

Control operativo: definir por política que la urgencia incrementa controles (doble canal obligatorio, escalado automático, límites más bajos).

3) Cambios de última hora: el momento perfecto

Los cambios cerca de cierres contables, vacaciones o cambios de personal son ideales: hay menos revisión y más carga de trabajo.

Control operativo: ventanas de cambio para datos críticos (por ejemplo, cambios bancarios solo en días/horas definidos) o “cooling-off period” (p. ej., 24–48 h) salvo verificación reforzada.

4) Segregación de funciones (SoD): cuando una persona puede “crear y pagar”

Si la misma persona puede dar de alta un proveedor, modificar su cuenta y aprobar el pago, el fraude puede ocurrir incluso sin ingeniería social externa (o con mínima presión).

Control operativo: SoD estricta: alta/modificación de proveedor, aprobación de factura y ejecución de pago deben estar distribuidas. Si no es posible por tamaño, aplicar compensatorios: revisión posterior independiente, límites bajos y alertas.

Guía práctica paso a paso: validación de cambios de pago y prevención de BEC

Flujo recomendado para cambios de cuenta bancaria (proveedores y empleados)

1. Recepción: cualquier solicitud de cambio de cuenta se registra como ticket/caso (no se gestiona “solo por email”). Se captura: solicitante, proveedor/empleado, motivo, fecha, canal, adjuntos.
2. Bloqueo preventivo: si hay facturas próximas a pago, se marca el proveedor/empleado con “cambio en verificación” para evitar pagos automáticos a nuevos datos.
3. Verificación por doble canal: se valida usando un canal distinto al de la solicitud. Ejemplos: llamada a número de la lista blanca (contrato/ERP), portal de proveedores, videollamada con verificación, o confirmación firmada a través de plataforma corporativa.
4. Validación de titularidad: se solicita evidencia controlada: carta bancaria, certificado de titularidad o documento equivalente. Se verifica coherencia: nombre legal, país, moneda, banco, coincidencia con contrato.
5. Regla de “no usar datos del email”: el número a llamar o el enlace a usar nunca se toma del mensaje recibido; se toma del ERP/contrato o de un directorio interno.
6. Aprobación dual: al menos dos aprobaciones: (a) responsable de datos maestros/proveedores, (b) finanzas/cuentas por pagar. En nómina: RR. HH. + finanzas.
7. Registro de aprobaciones: se guarda evidencia: quién validó, cuándo, por qué canal, qué documento revisó, resultado de la llamada (fecha/hora/número marcado).
8. Periodo de seguridad: el primer pago a una cuenta nueva requiere verificación adicional (por ejemplo, confirmación de importe pequeño o confirmación posterior al pago por canal seguro).
9. Monitoreo y alertas: alertas por cambios de IBAN, cambios repetidos, cuentas en países inusuales, cambios cerca de fechas de pago, o cambios solicitados por dominios nuevos.

Checklist rápido para cuentas por pagar (antes de ejecutar un pago)

• ¿El IBAN/beneficiario coincide con el registrado y verificado previamente?
• Si cambió: ¿hay ticket, doble canal y aprobaciones duales registradas?
• ¿La factura hace referencia a pedido/contrato y recepción (si aplica)?
• ¿El importe y la moneda están dentro de patrones históricos?
• ¿La urgencia está documentada y escalada según política?

Controles operativos clave (implementables)

Verificación por doble canal

Regla: cualquier cambio de pago o solicitud de transferencia no rutinaria se confirma por un canal alternativo controlado. Canales típicos: llamada a número verificado, portal de proveedores, sistema de tickets, mensajería corporativa con identidad gestionada.

Listas blancas (allowlist) de cuentas y beneficiarios

• Allowlist de cuentas bancarias: solo se paga a cuentas verificadas y asociadas a un proveedor/empleado validado.
• Allowlist de contactos: números de teléfono y dominios autorizados por proveedor (mantenidos en ERP).
• Restricción por país/moneda: pagos fuera de patrón requieren aprobación adicional.

Validación de cambios de pago

Separar el “dato maestro” del “pago”: un cambio de IBAN no debe poder aplicarse y pagarse en el mismo día sin controles reforzados. Implementar estados: Pendiente de verificación, Verificado, Activo.

Límites y escalados

• Umbrales por importe: a mayor importe, más aprobaciones y verificación reforzada.
• Umbrales por riesgo: cambios de IBAN, primer pago, proveedor nuevo, urgencia, pagos internacionales.
• Escalado automático: si se detecta urgencia o confidencialidad, se notifica a un rol de control (finanzas/seguridad).

Registro de aprobaciones y trazabilidad

Todo debe quedar trazado en un sistema: ticket, aprobaciones, evidencias, y relación con factura/pedido. Esto reduce el “no sabía” y permite auditoría y respuesta rápida.

Políticas de comunicación segura por áreas críticas (ejemplos listos para adaptar)

Finanzas / Tesorería

• Política: “No se ejecutan transferencias basadas únicamente en correo. Toda instrucción de pago extraordinaria requiere ticket y verificación por doble canal.”
• Política: “Cambios de beneficiario/IBAN requieren aprobación dual y confirmación por canal alternativo usando contactos del ERP.”
• Política: “Las solicitudes ‘confidenciales’ no eximen controles; activan escalado al responsable de tesorería y control interno.”

Compras / Gestión de proveedores

• Política: “Altas y cambios de proveedor se gestionan solo por portal o sistema interno; no se aceptan cambios bancarios por email sin verificación.”
• Política: “Los contactos de proveedor (teléfono/dominio) se registran y cualquier cambio requiere verificación independiente.”
• Política: “Facturas sin referencia de pedido/contrato siguen un flujo de excepción con revisión adicional.”

Soporte / TI

• Política: “No se desactiva MFA ni se restablecen credenciales por solicitud de correo; se requiere verificación de identidad y ticket.”
• Política: “Solicitudes de acceso temporal o elevación de privilegios requieren aprobación del dueño del sistema y registro de motivo/tiempo.”
• Política: “Cualquier petición de ‘urgencia’ que implique saltarse controles se reporta como incidente potencial.”

RR. HH. / Nómina

• Política: “Cambios de cuenta de nómina solo por portal de empleado o formulario interno con verificación reforzada; nunca por email.”
• Política: “Solicitudes de datos personales o documentos se comparten solo mediante repositorios corporativos con control de acceso, no como adjuntos.”
• Política: “Cualquier solicitud que invoque ‘auditoría’ debe validarse con el responsable interno de cumplimiento antes de entregar información.”

Escenarios prácticos (con respuesta operativa)

Escenario 1: “Proveedor cambia de banco por fusión”

Situación: llega un correo con tono formal, adjunta una carta y pide actualizar el IBAN “para evitar impagos”.

Respuesta:

• Registrar ticket y marcar proveedor como “cambio en verificación”.
• Llamar al contacto del proveedor en la lista blanca (ERP/contrato), no al número del correo.
• Confirmar: cambio, fecha efectiva, titularidad y que la carta sea auténtica.
• Aplicar aprobación dual y registrar evidencias.
• Primer pago a nueva cuenta con verificación adicional.

Escenario 2: “Dirección solicita transferencia urgente y confidencial”

Situación: un mensaje aparenta venir de un directivo y pide una transferencia hoy, evitando a otros equipos.

Respuesta:

• Activar política de urgencia: doble canal obligatorio.
• Verificar por canal corporativo alternativo (llamada a número interno verificado o reunión breve) y registrar confirmación.
• Si no se logra verificación: no ejecutar, escalar a tesorería/control interno.

Escenario 3: “Factura con pedido real pero IBAN distinto”

Situación: la factura coincide con un pedido real, pero el IBAN no coincide con el maestro del proveedor.

Respuesta:

• Detener pago automáticamente por discrepancia de datos maestros.
• Iniciar flujo de cambio de cuenta: ticket + doble canal + aprobaciones.
• Revisar si hubo cambios recientes en el maestro del proveedor y quién los aprobó.