Un Phishing bancario, un Spam en Unicode y la detección temprana

Ayer por la tarde me invitaron a ir a hablar en un programa de televisión sobre las tendencias en el cibercrimen y el fraude online. Una vez más, el tema que salió fue el de los ataques a cuentas bancarias y quiso el destino que me entrara un mensaje de phishing de una campaña de spam que había logrado saltarse el filtro antispam de nuestros servidores de coreo electrónico, así que aproveché dicho ejemplo para la intervención en el programa.

Figura 1: Un Phishing Bancario, un Spam en Unicode y la detección temprana

Este es el mensaje de correo electrónico que se saltó los filtros y hay varios detalles importantes que me gustaría contaros sobre él, ya que no es habitual que me entren este tipo de mensajes en mi inbox, así que os los paso a explicar.

Figura 2: Mensaje de spam con campaña de phishing recibido

Política AntiSpoofing

El equipo de seguridad responsable del dominio santander.com.mx tiene un registro el servidor DNS con una política antispoofing en el correo electrónico basada en SPF1 con valor -all. Esto quiere decir que todo servidor que reciba un correo electrónico de santander.com.mx, si no viene de una de las direcciones IP autorizadas por el registro DNS deberá marcarlo como spam y tirarlo a la carpeta de correo no deseado o directamente a la basura.

Figura 3: Política antispoofing de e-mail en santander.com.mx

En este caso, el correo electrónico ha sido enviado suplantado un subdominio de ese dominio, lo que hace que cuando se consulte la política SPF de ese subdominio el servidor de correo entrante no tiene información para discernir si esta autorizado o no. Esto lo ha aprovechado el atacante para saltarse la protección SPF.

Figura 4: Dirección de correo electrónico suplantada

Las alternativas para detectar esto sería aplicar en los servidores de correo entrantes medidas más exhaustivas en el análisis de correos de subdominios, o establecer políticas restrictivas SPF en todos los subdominios, pero a día de hoy no son eficientes ni 100 % efectivas, por lo que es una puerta que pueden utilizar los phishers. Eso sí, el dominio principal está protegido.

Codificación Unicode Extendida

Como se puede ver en el mensaje, se ha utilizado una codificación de UTF-8 extendida del asunto del mensaje. Esta codificación permite usar caracteres de alfabetos Unicode para lograr un efecto visual similar al que se obtiene con los caracteres con codificación Punycode. 

Figura 5: Asunto en codificación con caracteres del alfabeto Unicode

Si miramos el código fuente se puede ver que el asunto está codificado entre "=?utf-8?B?" y "?=", y si decodificamos con cualquier decoder para base 64 online se obtendrá el asunto que aparece.

Figura 6: Codificación Unicode UTF-8 del asunto

Este truco ayuda a evitar que los filtros basados en cadenas como "Banca" "Acceso a Banca" o "Bloqueado" detecten cualquier mensaje de correo que esté siendo procesado automáticamente.

Detección temprana

Una de las cosas que piensa la gente es que es fácil para los ladrones de estos sitios conseguir extraer dinero rápido con estos ataques de phishing, pero lo cierto es que cada vez lo tienen mucho más complicado. En este caso, la URL de la web tiene un phishing del Banco de Santander en México, y es bastante aparente.

Figura 7: Sitio web de Phishing

Yo notifiqué este phishing a nuestro equipo de Antifraude interno y me confirmaron que ya lo habían detectado y que tras comprobar que era un phishing activo, se había reportado automáticamente a las casas de antimalware, los servicios antifraude de navegadores y a las bases de datos de seguridad de nuestras alianzas. A los minutos ya estaba marcado en Google SafeBrowsing, como se puede ver.

Figura 8: Al los pocos minutos ya estaba detectado y bloqueado

Todos los que navegaran con Google SafeBrowsing activo ya recibirián una alerta de seguridad como la que puede verse a continuación, limitando el impacto de este phishing muchísimo.

Figura 9: Alerta de seguridad de phishing

Hoy ya está detectado, según Virus Total, también por un buen número de antivirus, lo que limita aún más su posible efectividad.

Figura 10: Detectado como Phishing por más escaners

Protecciones extras para evitar el uso de credenciales robados

Los equipos de seguridad de banca tienen además un buen número de controles para detectar que una credencial ha sido robada en el momento en que se quiere hacer una transacción. Muchos de ellos se basan en el análisis de hábitos de conexión de una determinada cuenta para saber si hay alguna anomalía. Para ello se hace un scoring de cada transacción y se comprueba que es un uso habitual desde una ubicación habitual por lo que si algo cambia, se bloquea la transacción.

Figura 11: Bloqueo de credenciales y transacciones en Caja Mar

Además, los sistemas tienen sistemas de firma de transacciones y protección de cuentas. Habitualmente han usado la famosa tarjeta de coordenadas, pero desde Europa ya se ha dado muerte a este sistema, por lo que muchos bancos pasan al uso de sistemas de firma de transacciones usando OTPs derivados de los datos de la transacción o plataformas como Latch. En el caso de todas las cajas del Grupo CajaMar, por ejemplo, además de proteger la cuenta se pueden restringir las transacciones, por lo que un acceso para consultar no podría realizar la transacción. 

Recomendaciones finales

Aun así, conviene recordar a todo el mundo que los ataques de phishing suelen llegar por e-mail así que no hay que pulsar en ningún enlace, y que el robo de credenciales bancarias más peligroso sigue siendo el de los troyanos bancarios que hacen Man in the Browser, por lo que lo mejor es que tengas un cuidado exquisito de tu equipo de trabajo y lo tengas fortificado al máximo para evitar cualquier sorpresa.

Saludos Malignos!