Ingeniería social en la práctica
Objetivos: Al terminar este tema, podrás…
- Identificar las técnicas psicológicas usadas en ataques de ingeniería social
- Construir un ataque de phishing o vishing verosímil aplicando principios de influencia
- Analizar un ataque recibido para identificar sus técnicas y señales de alerta
- Distinguir entre defensas que funcionan y defensas que solo crean sensación de seguridad
Antes de cualquier teoría: escucha esto
El siguiente es un fragmento de una llamada de vishing, con un atacante haciéndose pasar por soporte técnico de un banco. La víctima es una empleada administrativa de una empresa mediana.
“Buenos días, le habla Daniel Ospina del área de Seguridad Digital del Banco Mercantil. Estamos viendo movimientos inusuales en la cuenta empresarial de su empresa: hubo tres intentos de transferencia desde una IP en el exterior hace unos minutos. Necesitamos verificar su identidad antes de que el sistema bloquee el acceso automáticamente. ¿Tiene su número de token a mano?”
[La empleada dice que va a buscar el token]
“Entendido. Mientras tanto, voy a necesitar confirmar el número de cuenta principal para anotarla en el reporte del incidente. Es solo para el registro interno, no se va a usar para ninguna transacción.”
[La empleada dice el número de cuenta]
“Perfecto. Y el nombre del titular que aparece en el sistema, ¿es el mismo que tiene en sus registros? Necesito que me confirme para cuadrar el reporte.”
Para discutir
- ¿En qué momento casi lo creíste?
- ¿Cuántas técnicas de manipulación puedes identificar en ese fragmento?
- ¿Qué habría hecho la empleada diferente si hubiera recibido capacitación estándar de “no compartas tus contraseñas”?
- ¿Por qué el atacante nunca pidió directamente una contraseña?
Análisis de la llamada
El atacante usó al menos cinco técnicas:
- Autoridad: se identifica como “Seguridad Digital del banco”, una figura de autoridad técnica que la empleada no tiene motivo para cuestionar en el momento.
- Urgencia: “el sistema va a bloquearse automáticamente” crea presión de tiempo que inhibe el pensamiento crítico. Cuando hay urgencia, el cerebro prioriza acción rápida sobre análisis.
- Legitimidad por detalle: menciona “IP en el exterior”, “tres intentos”, “reporte interno”: detalles técnicos que suenan auténticos aunque son inventados. Los detalles específicos aumentan la credibilidad percibida.
- Minimización: “es solo para el registro interno, no se va a usar para ninguna transacción” reduce activamente la percepción de riesgo del paso que sigue.
- Escalada gradual: nunca pide lo más sensible primero. Empieza con “verificar identidad” (razonable), luego número de cuenta (parece administrativo), luego más. Cada paso pequeño hace el siguiente más fácil.
La capacitación estándar dice “no compartas tus contraseñas.” El atacante nunca pidió la contraseña: pidió el número de cuenta y el token. La capacitación no entrenó a la empleada para este vector específico.
Esta es la brecha fundamental de la ingeniería social: el ataque siempre va un paso adelante de la defensa genérica.
Por qué funciona: los principios de influencia
Robert Cialdini, psicólogo social, identificó seis principios que gobiernan cómo los seres humanos tomamos decisiones de compliance, es decir, cuándo decimos sí a solicitudes. Los atacantes los usan sistemáticamente, a veces sin saberlo, porque son patrones que funcionan en la práctica.
1. Autoridad
Las personas siguen instrucciones de figuras de autoridad incluso cuando el contenido de esas instrucciones es cuestionable. No verificamos credenciales de quienes parecen tener autoridad, algo que en contextos legítimos sería socialmente costoso.
En ataques: el atacante se presenta como soporte técnico, auditor, gerencia, ente regulador. La víctima coopera porque cuestionar a una figura de autoridad tiene un costo social percibido mayor que obedecer.
2. Urgencia / Escasez
Cuando hay presión de tiempo o recursos limitados, el pensamiento analítico se reduce. El instinto de actuar rápido toma el control. Es un mecanismo evolutivo que en entornos ancestrales servía para sobrevivir; en entornos modernos se convierte en un vector de ataque.
En ataques: “su cuenta será bloqueada en 10 minutos”, “el sistema cierra en dos horas”, “solo queda un cupo para el proceso de verificación”.
3. Prueba social
Las personas asumen que si “todos” o “muchos” hacen algo, debe ser lo correcto o lo seguro. Reduce el costo cognitivo de tomar decisiones en situaciones desconocidas.
En ataques: “todos los empleados del área de contabilidad ya completaron este proceso”, “otros usuarios han reportado el mismo problema y lo resolvieron así”.
4. Reciprocidad
Cuando alguien nos da algo (información, un favor, ayuda con un problema), sentimos obligación de devolver. Es una norma social tan fuerte que funciona incluso cuando el regalo fue no solicitado.
En ataques: el atacante “ayuda” a la víctima con un problema fabricado, creando una deuda de reciprocidad que la víctima siente que debe saldar cooperando.
5. Compromiso y coherencia
Una vez que alguien toma una posición o hace algo pequeño, tiende a mantenerse coherente con esa posición cuando se escalan las solicitudes. Cambiar de posición tiene un costo de identidad.
En ataques: empezar con solicitudes menores (“¿es usted la encargada de pagos?”, “¿trabaja con el sistema X?”) antes de las solicitudes de alto riesgo. Cada sí pequeño hace el siguiente sí más probable.
6. Simpatía
Las personas dicen sí más fácilmente a quienes les caen bien: personas similares a ellas, quienes las elogian, quienes comparten un enemigo común. Los atacantes hacen OSINT previo para encontrar puntos de conexión genuinos.
En ataques: “vi que también estudió en la Javeriana”, “coincido con usted en que el sistema anterior era más fácil de usar”, “¿usted también estuvo en la conferencia de la semana pasada?“.
Para discutir
- De los seis principios, ¿cuál crees que es más difícil de defenderse? ¿Por qué?
- ¿Hay alguno que crees que no te afecta personalmente? ¿Por qué crees eso?
- ¿Cuáles se combinarían de manera más efectiva en un mismo ataque?
Actividad en clase: dos rondas
Cómo funciona
Trabajan en grupos de 3 a 4. El profesor asigna a cada grupo un escenario de empresa objetivo con suficiente contexto para construir un ataque verosímil. Hay dos rondas seguidas.
Ronda 1 — Construir el ataque (15 minutos)
Su grupo elige construir una de las dos opciones:
- (A) Un correo de phishing dirigido a un empleado específico de la empresa objetivo
- (B) Un script de vishing para llamar a alguien en la empresa haciéndose pasar por un proveedor, auditor o soporte técnico
Requisitos:
- Deben usar al menos dos principios de Cialdini explícitamente (anoten cuáles usaron y dónde)
- Deben basarse en información que un atacante real podría haber encontrado mediante OSINT del escenario
- El objetivo del ataque debe ser claro: ¿qué quieren lograr? (credenciales, transferencia, acceso, instalación de software)
- El ataque no debe pedir una contraseña directamente
Al terminar, presentan su ataque en voz alta. El grupo explica brevemente su razonamiento: qué principios usaron y por qué ese vector específico.
Ronda 2 — Analizar el ataque del otro grupo (10 minutos)
Los grupos intercambian ataques con otro grupo. Ahora son el equipo de seguridad que recibió ese intento.
Su tarea:
- Identificar todos los principios de Cialdini presentes, incluyendo los que el grupo no listó explícitamente
- Señalar las señales de alerta que delatan que es un ataque, y argumentar por qué un empleado real podría no notarlas en el momento
- Escribir el comunicado interno de advertencia que enviarían a los empleados de la empresa, en máximo tres oraciones, sin jerga técnica, que un empleado de contabilidad pueda entender y recordar en una situación de presión
Debrief
Para discutir después de la actividad
- ¿Qué hizo que algunos ataques fueran más convincentes que otros? ¿El principio psicológico, el nivel de detalle, el tono, algo más?
- El comunicado de advertencia que escribieron: ¿realmente habría prevenido el ataque? ¿O un empleado bajo presión real lo habría olvidado?
- Si no pueden confiar en que los empleados detecten todos los ataques, ¿qué cambios al sistema o al proceso harían que el ataque no funcionara aunque el empleado fuera completamente engañado?
- ¿Hay algún ataque que no tenga defensa técnica posible?
Lo que el debrief busca revelar
El punto central que vale la pena construir al final: la concienciación de usuarios tiene un ROI bajo como defensa principal contra ingeniería social.
Los estudios de simulaciones de phishing muestran que incluso después de capacitación, una fracción significativa de empleados cae en phishing bien diseñado. Y la ingeniería social más sofisticada apunta precisamente a las personas con más acceso, que suelen ser las más ocupadas y con mayor presión.
Las defensas que funcionan son técnicas y de proceso:
- Autenticación multifactor: las credenciales robadas son insuficientes si se requiere un segundo factor
- Separación de funciones: ninguna persona sola puede autorizar una transferencia de alto valor
- Verificación fuera de banda: cualquier solicitud urgente e inusual se verifica por un canal diferente al que llegó (si el “banco” llama, cuelgas y llamas al número oficial del banco)
- Límites técnicos: el sistema no puede hacer ciertas cosas aunque el operador quiera (transferencias sobre umbral requieren aprobación secundaria antes de ejecutarse)
La capacitación no es inútil: eleva el costo del ataque y reduce la tasa de éxito en ataques masivos no dirigidos. Pero asumir que es suficiente como defensa principal es el error que antecede a la mayoría de los ataques de ingeniería social exitosos contra organizaciones.
Escenarios de empresa objetivo
Escenario 1 — TechFlow SAS
TechFlow SAS: empresa de desarrollo de software, 80 empleados, sede en Bogotá.
Contexto: Acaban de anunciar una Serie A de financiación (nota de prensa pública). Tienen 15 desarrolladores. Usan Microsoft 365 y Slack (mencionado en ofertas de trabajo publicadas). El CTO es Ramón Herrera (activo en LinkedIn). Recientemente publicaron una convocatoria para un cargo de DevOps Senior.
Objetivo del ataque sugerido: Conseguir que alguien del área técnica instale una “actualización de seguridad urgente” o comparta credenciales de acceso al repositorio de código.
Escenario 2 — Salud+ IPS
Salud+ IPS: proveedor de salud con 5 clínicas en Bucaramanga.
Contexto: Migraron recientemente de sistema de historias clínicas (hay quejas sobre el proceso en un foro de empleados de salud público). La directora de TI es Lucía Vargas (visible en LinkedIn). La empresa tiene un proveedor de soporte técnico externo llamado “SoporteIT Colombia” (mencionado en una licitación pública).
Objetivo del ataque sugerido: Conseguir acceso remoto a un computador administrativo haciéndose pasar por el proveedor de soporte durante “la migración del sistema que quedó pendiente.”
Escenario 3 — LogiCarga Ltda
LogiCarga Ltda: empresa de logística y transporte, 200 empleados, Cali.
Contexto: Fusión reciente con un competidor (anunciada en prensa). Hay confusión interna sobre proveedores y procesos. El CFO es Jorge Prada (LinkedIn). El área de cuentas por pagar tiene tres personas. La empresa hace pagos regulares a proveedores de combustible (visible en el SECOP por contratos anteriores).
Objetivo del ataque sugerido: Conseguir que el área de cuentas por pagar “actualice los datos bancarios” de un proveedor de combustible existente, redirigiendo un pago a una cuenta del atacante.
Lo que distingue un ataque convincente de uno torpe
Después de ver los ataques de todos los grupos, hay patrones claros.
Lo que hace un ataque convincente:
- Usa información específica real o verosímil (refleja que hubo reconocimiento previo)
- Tiene un pretext coherente de principio a fin, con todo el contexto construido, no solo el anzuelo
- La solicitud parece razonable dentro del flujo normal de trabajo de la víctima
- La urgencia está justificada por el contexto, no simplemente declarada
- No pide directamente lo más sensible; llega ahí por pasos
Lo que delata un ataque torpe:
- Urgencia injustificada o exagerada sin contexto que la explique
- El “soporte técnico” no sabe el nombre del sistema que supuestamente está soportando
- Solicitudes que van directamente a lo más sensible sin construcción de confianza previa
- Detalles técnicos incorrectos o inconsistentes
- El remitente del correo o el número de teléfono no coincide con lo que el atacante dice ser
La defensa no es simplemente "ser más desconfiado"
Un empleado que desconfía de todo también rechaza solicitudes legítimas, lo que genera fricción operacional real. Las organizaciones resuelven esto con protocolos, no con paranoia: cualquier solicitud fuera del flujo normal se verifica por un canal establecido, independientemente de cuán urgente parezca.
Casos documentados
El hackeo a Twitter (2020)
En julio de 2020, atacantes obtuvieron acceso a las cuentas verificadas de Barack Obama, Elon Musk, Jeff Bezos, Apple, y decenas más. Las usaron para promover una estafa de Bitcoin que recaudó cientos de miles de dólares en horas.
El vector no fue técnico. Los atacantes llamaron a empleados de Twitter haciéndose pasar por el equipo de TI interno. Los convencieron de dar acceso a herramientas administrativas internas. Con esas herramientas, pudieron tomar control de cualquier cuenta de la plataforma.
Los atacantes eran adolescentes. El mayor tenía 19 años. El más joven, 17.
Para discutir
- ¿Qué proceso habría prevenido esto sin bloquear el trabajo legítimo del equipo de soporte?
- Twitter tenía sofisticados controles técnicos de seguridad. ¿Por qué no ayudaron aquí?
- ¿Qué dice sobre los ataques de ingeniería social el hecho de que los ejecutores eran adolescentes sin experiencia técnica avanzada?
CEO fraud — FACC (2016)
FACC, fabricante austriaco de componentes aeroespaciales para Airbus y Boeing, perdió €50 millones en una sola transferencia.
Un empleado del área financiera recibió un correo del “CEO” solicitando una transferencia urgente y confidencial para una “adquisición estratégica en curso.” El correo venía de una dirección ligeramente diferente a la real. El empleado realizó la transferencia sin verificar por otro canal. El dinero desapareció.
El CFO y el CEO de FACC fueron despedidos por “no implementar los controles necesarios.”
Para discutir
- El empleado siguió las instrucciones de quien parecía ser su CEO. ¿Fue un error suyo?
- ¿Qué control de proceso hubiera hecho imposible este ataque, incluso si el empleado era completamente engañado?
- El CFO y el CEO fueron despedidos. ¿Quién debería haber cargado con la responsabilidad?
Conceptos clave
| Término | Definición |
|---|---|
| Ingeniería social | Manipulación psicológica de personas para obtener acceso, información o acciones no autorizadas |
| Phishing | Ataque por correo electrónico que imita una entidad de confianza para robar información o instalar malware |
| Spear phishing | Phishing personalizado con información específica del objetivo, construido sobre reconocimiento OSINT previo |
| Vishing | Ingeniería social por voz (llamada telefónica) |
| Pretexting | Construcción de un escenario ficticio creíble para justificar la solicitud del atacante |
| BEC (Business Email Compromise) | Fraude que suplanta correos de ejecutivos para autorizar transferencias o acciones no autorizadas |
| Principios de Cialdini | Los seis mecanismos psicológicos de influencia: autoridad, urgencia/escasez, prueba social, reciprocidad, compromiso, simpatía |
| Verificación fuera de banda | Confirmar una solicitud inusual por un canal diferente al que la originó |
Nota de evaluación: La nota de clase se divide en dos partes iguales: calidad del ataque construido (uso de técnicas, verosimilitud, claridad del objetivo) y calidad del análisis defensivo (identificación de técnicas, señales de alerta, comunicado de advertencia).