Parte: 12 — OSINT e ingeniería social · Fuente: NIST SP 800-50 · Social Engineering (C. Hadnagy) · ENISA ⏱️ Duración estimada: 110 min · Nivel: Intermedio
Diseñar un programa de defensa contra la ingeniería social que combine controles técnicos, procesos y cultura. El alumno terminará capaz de proponer medidas anti-phishing (SPF/DKIM/DMARC, MFA resistente, filtros), procedimientos de verificación de identidad y un programa de concienciación medible, cerrando el ciclo iniciado con el ataque autorizado.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | Autenticación de correo | Frena la suplantación de dominio |
| 2 | MFA resistente a phishing | Neutraliza el robo de credenciales |
| 3 | Filtros y sandboxing | Bloquea el gancho antes del clic |
| 4 | Verificación de identidad | Corta pretexting y vishing |
| 5 | Concienciación medible | Cambia el comportamiento |
| 6 | Botón de reporte | Convierte usuarios en sensores |
| 7 | Respuesta a incidentes SE | Contiene el daño rápido |
| 8 | Airdrops, wallets y firmas | La interfaz visible puede ocultar otra autorización |
| 9 | Recuperación por tipo de exposición | Un permiso, una seed y una sesión requieren respuestas distintas |
La concienciación ayuda, pero ninguna persona mantiene atención perfecta. La arquitectura debe asumir mensajes convincentes, cuentas comprometidas y momentos de presión. Se combinan controles preventivos, resistentes, detectivos y de recuperación: autenticación ligada al dominio, verificación de transacciones, filtrado, privilegios mínimos, reporte sencillo, revocación de sesiones y respuesta coordinada.
Autenticación y autorización de negocio no son lo mismo. Passkeys/WebAuthn bien configuradas resisten el phishing mediante vinculación al verificador, como describe NIST SP 800-63B-4; SMS y OTP introducidos manualmente no ofrecen esa propiedad frente a un intermediario. Aun con autenticación resistente, un usuario puede autorizar voluntariamente una transferencia falsa. Los procesos de alto impacto necesitan confirmación de datos, doble control y límites.
Un botón de reporte conserva encabezados y mensaje original, informa al usuario y alimenta automatización. SOC deduplica campañas, busca destinatarios, bloquea indicadores y evalúa cuentas. El canal debe aceptar dudas: penalizar falsos reportes reduce la detección temprana. Las métricas incluyen tiempo desde recepción hasta primer reporte y desde reporte hasta contención, además de cobertura de autenticación resistente y cumplimiento de callback.
Si alguien hizo clic, se determina qué se ejecutó y qué datos se entregaron. Si ingresó una contraseña, se restablece, revocan sesiones y tokens, se revisan reglas de correo y actividad posterior; cambiar la contraseña sin revocar sesiones puede ser insuficiente. Si aprobó una transacción, se activa fraude y recuperación. Si solo recibió el mensaje, todavía aporta inteligencia para proteger a otros.
Un lanzamiento viral combina palancas conocidas —autoridad aparente, prueba social, escasez, urgencia y recompensa— con una interfaz técnica poco familiar. El usuario ve un video, busca el token, llega a un dominio parecido, encuentra cuentas que se refuerzan entre sí y recibe un airdrop. La defensa no consiste en memorizar una lista de marcas confiables: consiste en preguntar qué identidad, origen, secreto o autoridad cambia en cada paso.
La cadena se lee así: video viral → búsqueda → sitio no corroborado o cuenta falsa/tomada → airdrop urgente → conexión → petición decodificada. Desde allí se bifurca: una sesión sin cambio de estado, una seed que compromete claves, o un permiso/transacción que crea capacidad de gasto y puede terminar en movimiento de activos.
El diagrama se lee como una serie de controles independientes. El video se valida por procedencia; la cuenta, por historia y sesión; el dominio, por un canal conocido; el activo, por red e identificador de contrato/mint; la petición, por sus efectos decodificados. Conectar una wallet no equivale por sí solo a mover activos. Puede revelar una dirección pública y permitir solicitudes posteriores. El riesgo material aparece cuando se firma una operación, se concede un permiso persistente, se firma un mensaje con uso autorizador o se entrega una frase semilla/clave. La semántica exacta depende de la red: contratos y programas no comparten un formato universal.
Un wallet drainer es el flujo que adquiere y usa capacidad para mover activos; no es una categoría mágica de botón. Puede apoyarse en approvals excesivos, firmas engañosas o secretos robados. Una solicitud de frase semilla debe detener el flujo: soporte legítimo no necesita el secreto raíz. Un ataque de portapapeles es otra ruta, ligada a malware de endpoint, que sustituye una dirección copiada. Y un rug pull es distinto de todos ellos: puede ocurrir con dominio y activo auténticos cuando promotores retiran liquidez, venden o abandonan en contradicción con lo prometido. Confundirlos lleva a respuestas inútiles.
La respuesta empieza deteniendo nuevas decisiones y preservando URL, dominio, cuentas, publicación, hora, petición decodificada, TXID y telemetría. Después se ramifica:
| Condición observada | Acción inicial | Por qué |
|---|---|---|
| solo visita o conexión, sin firma ni secreto | cerrar, desconectar sesión si aplica, vigilar y reportar | no afirmar pérdida que no se observa |
| approval/permiso peligroso sin gasto | revocar mediante canal/herramienta verificada y monitorear | el permiso puede seguir activo tras cerrar la web |
| transferencia confirmada | preservar transacción, proteger lo restante y contactar proveedores verificados | cambiar contraseña no revierte estado de la red |
| frase semilla o clave expuesta | tratar la wallet como comprometida y migrar desde un dispositivo limpio | el secreto no se «revoca» como una sesión |
| cuenta social tomada | revocar sesiones, recuperar identidad, preservar posts y avisar por otro canal | borrar el post sin cerrar sesiones deja la causa activa |
| sustitución de portapapeles | aislar y adquirir endpoint antes de volver a operar | la wallet puede estar sana mientras el host altera destinos |
Revocar, migrar o contactar un proveedor puede tener costes y riesgos; se ejecuta con el runbook de la wallet/red y autoridad apropiada. Nunca se pega una seed en una web de «recuperación» ni se paga a un supuesto recuperador que contacta de forma no solicitada.
Una víctima entrega contraseña y OTP a un proxy en tiempo real. El atacante obtiene sesión. La organización no concluye que «MFA no sirve»; identifica que ese autenticador no era resistente al phishing, revoca sesiones y migra accesos críticos a WebAuthn, manteniendo detección y recuperación. También revisa por qué la página falsa llegó y cómo se reportó.
| Término | Definición útil |
|---|---|
| Phishing resistance | Propiedad protocolaria que evita entregar una salida válida a un verificador impostor. |
| Session revocation | Invalidación de sesiones y tokens ya emitidos. |
| Callback | Verificación por un canal conocido e independiente. |
| Doble control | Participación de dos autorizadores en una acción crítica. |
| Triage | Clasificación inicial que determina alcance, urgencia y respuesta. |
| Approval / permiso | Autoridad concedida a un tercero para actuar sobre un activo según el protocolo. |
| Wallet drainer | Cadena que obtiene y usa autoridad para mover activos; requiere identificar el mecanismo concreto. |
| Frase semilla | Secreto raíz del que pueden derivarse claves; exponerla exige tratar la wallet como comprometida. |
| Rug pull | Riesgo de promotor/liquidez o abandono; no es sinónimo de phishing ni de drainer. |
El alumno domina la defensa cuando puede mapear una solicitud a controles técnicos y de proceso, diferenciar tipos de MFA, diseñar reporte y respuesta, y medir reducción de riesgo sin responsabilizar únicamente al usuario.
p=reject el dominio es difícil de suplantar.dig.dig TXT tudominio.com y revisa el registro._dmarc con v=DMARC1; p=none; rua=mailto:... y observa los reportes.p=quarantine y luego p=reject tras validar que el correo legítimo pasa.p=reject frustra un ataque de suplantación de dominio.Entrega un plan de defensa contra ingeniería social que cubra: autenticación de correo, MFA resistente, verificación de identidad, programa de concienciación con métricas y playbook de respuesta. Criterio de aceptación: el plan incluye configuración DMARC verificable, al menos un control por cada vector (phishing, vishing, pretexting y lanzamiento viral) y métricas que midan resiliencia, no solo víctimas. Para el caso viral debe separar conexión, firma/permiso, secreto y efecto observado.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| DMARC rompe correo legítimo | Se pasó a reject sin monitorizar. Empieza en p=none, analiza y sube gradualmente. |
| MFA por SMS eludido | Vulnerable a AiTM/SIM swap. Migra a FIDO2/passkeys. |
| Usuarios no reportan | No hay botón o hay miedo a represalias. Facilita el reporte y refuerza positivamente. |
| Awareness sin efecto | Formación anual aburrida. Usa simulacros frecuentes y feedback inmediato. |
| Helpdesk resetea sin validar | Falta verificación fuera de banda. Implanta preguntas y canal alternativo. |
| «El candado prueba que el airdrop es oficial» | TLS protege el canal al dominio visitado; corrobora dominio, cuenta y activo por vías independientes. |
| «Conectar drenó la wallet» | Busca la firma, permiso, transacción o secreto que creó capacidad; la conexión puede no cambiar estado. |
| Revocar approval tras exponer la seed | El permiso se revoca, la seed no; migra a una wallet nueva con un procedimiento seguro. |
| Llamar rug pull a una caída de precio | Exige evidencia de control, retiro/venta/abandono y relación con lo prometido. |
❓ ¿DMARC elimina el phishing? Reduce la suplantación de tu dominio, no los correos de dominios parecidos (typosquatting). Es una capa, no la solución completa.
❓ ¿Basta con formar a la gente? No. La concienciación es una capa junto a controles técnicos. Culpar solo al usuario es un antipatrón; diseña sistemas que fallen de forma segura.
❓ ¿Qué MFA resiste el phishing? FIDO2/WebAuthn y passkeys, porque la autenticación está ligada al origen y no puede reproducirse en una página falsa.
❓ ¿Una simulación de transacción garantiza seguridad? No. Ayuda a anticipar efectos de una ejecución bajo un estado concreto, pero puede tener cobertura o presentación incompleta y no prueba identidad del proyecto, seguridad futura ni ausencia de permisos persistentes. Se combina con decodificación, límites y verificación independiente.
Clase 258 — Campañas de phishing con GoPhish