El enfoque estándar del phishing es que es un problema de personas — una falla de concienciación del usuario que una mejor capacitación puede corregir. Este enfoque es incorrecto, o al menos peligrosamente incompleto. El phishing también es un problema de infraestructura, y las soluciones de infraestructura son más confiables que la capacitación porque no dependen de que cada persona tome la decisión correcta cada vez.
Un correo de phishing que obtiene credenciales exitosamente no es el fin del ataque. Es el comienzo. Lo que sucede después — qué tan lejos llega el atacante, cuánto daño causa, cuánto tiempo lleva detectarlo — está determinado casi en su totalidad por la infraestructura en la que aterriza. Esa es la parte que puedes diseñar.
Qué intenta lograr realmente un ataque de phishing
La mayoría de las campañas de phishing dirigidas a empresas no intentan instalar malware directamente. Intentan obtener credenciales válidas o tokens de sesión que le permitan al atacante autenticarse como un usuario legítimo. Una vez que tienen esas credenciales, no necesitan exploits ni malware — simplemente inician sesión.
Esto importa porque significa que el ataque elude la mayoría de los controles de seguridad perimetral. Los firewalls, los sistemas IDS y el antivirus son en gran medida irrelevantes una vez que un atacante se está autenticando con credenciales válidas. Los únicos controles que siguen siendo efectivos son los que gobiernan lo que los usuarios autenticados pueden hacer.
La capa de infraestructura de correo electrónico
La primera defensa de infraestructura contra el phishing está en la capa de correo electrónico, y es en gran medida un problema de configuración de DNS. Tres registros — SPF, DKIM y DMARC — forman el marco de autenticación para el correo electrónico.
SPF (Sender Policy Framework) especifica qué direcciones IP están autorizadas a enviar correo en nombre de tu dominio.
DKIM (DomainKeys Identified Mail) agrega una firma criptográfica al correo saliente que el servidor receptor puede verificar. Un correo falsificado no puede llevar una firma DKIM válida.
DMARC une SPF y DKIM y especifica qué hacer con los mensajes que fallan: monitorear, poner en cuarentena o rechazar. Una política DMARC de p=reject le indica a los servidores de correo receptores que descarten directamente el correo no autenticado que dice ser de tu dominio.
Muchas organizaciones tienen registros SPF pero no tienen política DMARC, o una política DMARC configurada en p=none (solo monitoreo). Esto significa que los correos falsificados que se hacen pasar por tu dominio aún llegan a los destinatarios. Configurar DMARC en p=reject elimina toda una categoría de ataques de suplantación de identidad contra tus clientes y socios.
Lo que las credenciales robadas pueden hacer depende de tu arquitectura
Si un ataque de phishing obtiene exitosamente un conjunto de credenciales, el daño que puede causar está acotado por lo que esas credenciales pueden acceder. En un entorno mal segmentado con permisos amplios, una sola cuenta comprometida puede acceder a correo electrónico, recursos compartidos de archivos, sistemas internos e interfaces administrativas. En un entorno bien arquitectado, las mismas credenciales podrían acceder a una sola aplicación con exposición de datos limitada.
Los controles de infraestructura que contienen el compromiso de credenciales son:
Autenticación multifactor en todo el acceso remoto. MFA no evita el robo de credenciales, pero hace que las credenciales robadas sean inútiles para el acceso remoto sin el segundo factor. Un atacante con una contraseña válida pero sin token MFA no puede autenticarse.
Control de acceso de mínimo privilegio. Cada usuario, cuenta de servicio y aplicación debe tener acceso exactamente a los recursos que necesita y nada más. El compromiso de una cuenta de correo no debería proporcionar acceso a servidores de bases de datos.
Segmentación de red. Incluso si un atacante se autentica exitosamente, los controles a nivel de red determinan a dónde puede ir desde allí. Un usuario cuyas credenciales están comprometidas no debería poder alcanzar directamente las subredes de servidores internos.
Tiempos de sesión cortos y detección de anomalías. Las sesiones que persisten durante días o semanas le dan al atacante una ventana amplia para operar. Tiempos de sesión más cortos y requisitos de reautenticación para acciones sensibles reducen esa ventana. Registrar todos los eventos de autenticación y alertar sobre anomalías crea oportunidades de detección incluso cuando el atacante tiene credenciales válidas.
Por qué la capacitación sola no es suficiente
La capacitación en concienciación del usuario reduce las tasas de clics en phishing. No las elimina. En organizaciones grandes que ejecutan campañas de phishing simulado, las tasas de clics del 5-10% se consideran buenos resultados. Eso significa que en una organización de 200 personas, entre 10 y 20 personas harán clic en un correo de phishing bien elaborado incluso después de la capacitación.
Los controles de infraestructura que asumen que cierta fracción de usuarios siempre será víctima de phishing son más robustos que los controles que asumen un comportamiento perfecto del usuario. El objetivo no es hacer a los usuarios infalibles — es asegurar que un phishing exitoso resulte en el menor radio de impacto posible.
Auditando tu exposición actual
Una infraestructura resistente al phishing requiere una combinación de configuración de autenticación de correo, aplicación de MFA, diseño de control de acceso y segmentación de red. Si no estás seguro de cuáles de estos controles tienes en su lugar y si están correctamente configurados, la respuesta es averiguarlo antes de que lo haga un atacante.
En Solvanta, las auditorías de seguridad cubren todas estas capas: verificamos tus registros de autenticación de correo, revisamos tus políticas de control de acceso, mapeamos tu segmentación de red y verificamos tu cobertura de registro y alertas. Contáctanos para programar una auditoría.