Evolución de los rootkits

Este es el segundo de una serie de artículos dedicados a la evolución de los virus y de las soluciones antivirus. Personalmente, veo la evolución desde dos puntos de vista: como una serie cronológica de eventos; y como una conexión lógica derivada de varios cambios. Por ello, mi objetivo es presentar cada tema de una forma muy lógica y cronológica, de manera que sea interesante para cualquier lector.

Introducción

La primera vez que vi un rootkit fue en 2004, cuando todavía era una analista de virus novata. En ese momento tenía sólo vagas nociones sobre los rootkits para UNIX. Un día me topé con un archivo ejecutable para Windows que parecía no hacer nada cuando lo activé. Pero tenía un presentimiento al respecto y lo analicé con mayor detenimiento… descubrí un archivo en la lista de módulos instalados que no figuraba en el disco. Obviamente, tuve suerte en detectarlo sólo con la mirada, pues el rootkit tenía errores en su código. Hoy necesitaría varias herramientas dedicadas para lograr el mismo resultado y aún así podrían resultar insuficientes.

El rootkit que descubrí no se parecía en nada al primer rootkit para Windows. Sin embargo, era nuevo para mí y me sirvió como portal a un nuevo mundo, un mundo en el que los programas jugaban con el sistema operativo, eran capaces de romper reglas y de desaparecer milagrosamente de las listas de procesos y de archivos. Pasé horas y horas analizando los controladores que el programa utilizaba para esconderse en el sistema. El llamado Trojan-Dropper.Win32.SmallProxy era un programa diseñado para atacar un sistema específico y para desplegarse en determinadas ubicaciones, lo cual era algo relativamente complejo e inusual para aquella época.

Este artículo se enfoca en los rootkits para Windows por varias razones: son los más numerosos, siguen evolucionando, representan una seria amenaza para los usuarios, y porque siendo Windows el sistema operativo más popular, en la actualidad son los preferidos de los autores de virus. Yo defino los rootkits como programas que evaden o burlan los mecanismos estándar del sistema mediante técnicas furtivas para ocultar objetos del sistema: archivos, procesos, controladores, servicios, llaves de registro, puertos abiertos, conexiones, y otros.

Rootkits para UNIX

En cualquier discusión sobre los rootkits es imposible no mencionar la etimología del término (inglés) “rootkit”. En los sistemas UNIX, “root” designa un administrador con todos los privilegios, y “kit” se refiere a una serie de herramientas. Entonces, el término “rootkit” se describe una serie de herramientas que se pueden utilizar con intenciones maliciosas para lograr acceder al sistema de manera invisible ante el administrador real. Estas herramientas aparecieron por primera vez para UNIX a principios de los años 90. Aún están en circulación, pero ya no evolucionan de manera significativa.

Sin embargo, es importante recordar que aunque los rootkits para Windows heredaron el nombre “rootkit” del entorno UNIX, los programas maliciosos para Windows descienden directamente de los virus invisibles para DOS y no de los rootkits para UNIX

Virus invisibles

Los virus invisibles para DOS hicieron su aparición allá por 1990, casi al mismo tiempo que los rootkits para UNIX. A diferencia de los rootkits para UNIX, que se diseñaron para acceder al sistema y ser imperceptibles, los virus invisibles para DOS sólo se ocultaban del usuario y de las soluciones antivirus. Esto es exactamente lo que hacen los modernos rootkits para Windows. Las técnicas que utilizaban los virus invisibles para DOS son muy similares a las que usan los actuales rootkits para Windows. Por ejemplo, los virus invisibles se basan en técnicas como la intercepción de llamadas del sistema y la ocultación de códigos maliciosos mediante la provisión de datos falsos en el disco o en el contenido de la memoria. Los rootkits para Windows también recurren en gran medida a estas técnicas.
Los rootkits para Windows aparecieron 10 años después. En vez de designar a estos nuevos programas como virus invisibles, o con otra denominación más lógica, se los llamó “rootkits”, gracias a Greg Hoglund. Él fue uno de los primeros en construir una herramienta diseñada para ocultar datos en el sistema mediante la combinación de varias técnicas de evasión de las características de protección de Windows. Publicó sus resultados en la revista en línea PHRACK; en esta publicación bautizó la herramienta con el nombre de NT Rootkit. Así se la utilizó en muchos elementos de programas maliciosos. En realidad, NT Rootkit sigue intrigando e inspirando a los modernos investigadores y autores de rootkits.

Orígenes y popularización

El artículo de Hoglund se publicó en 1999 en base a una investigación sobre el núcleo de Windows llevada a cabo el año anterior y publicada en Usenet por un programador de Sri Lanka.

Ya en 1995, Jeffrey Richter, un gurú de la programación en Windows, descubrió técnicas para interceptar llamadas al sistema en modo de usuario y las publicó en su famoso libro “Advanced Windows”, cuya cuarta edición se tituló “Programming Applications for Microsoft Windows”. Estas técnicas se implementaron posteriormente en muchos rootkits e incluso se llegó al extremo de copiar el código fuente directamente del libro.

Las técnicas para interceptar llamadas del sistema en modo de núcleo se hicieron públicas en dos manuales clásicos de programación: “Undocumented Windows 2000 Secrets” de Schreiber, publicado en 2001, y “Undocumented Windows NT” de P. Dabak y otros co-autores, en 1999.

El primer rootkit para Windows

Los investigadores siguieron estudiando la protección del sistema Windows y, poco después de la aparición de NTRootkit, surgieron más herramientas, todas ellas diseñadas para ocultar objetos en el sistema operativo:

• 2000 – he4hook, diseñada por un programador ruso. Esta herramienta no es maliciosa, pero oculta archivos. Funciona en el modo de núcleo. Resulta curioso que el mismo autor no se refiera a su programa como un rootkit.
• 2002 – Hacker Defender (aka HacDef). Esta también es una herramienta pero más poderosa: Se la puede utilizar para ocultar archivos, procesos y llaves de registro con parámetros flexibles en el archivo de configuración. También funciona por lo general en el modo de usuario.
• 2003 – Vanquish. Esta herramienta se puede utilizar para ocultar archivos, directorios y llaves de registro. Además, conlleva una carga maliciosa: es capaz de registrar contraseñas. Vanquish funciona en modo de usuario.

Cabe concluir que el pensamiento de los investigadores experimentó un giro cuyo enfoque se trasladó de las herramientas neutrales a las herramientas diseñadas con otros fines, incluso maliciosos.

• 2003 – Haxdoor (aka A-311 Death and Nuclear Grabber, una variante modificada del mismo programa). Esta va más allá de ser una herramienta ya que es una puerta trasera que recurre a técnicas de rootkits para ocultar su presencia en el sistema. Funciona básicamente en modo de núcleo.
• 2004 – FU es una herramienta utilizada para ocultar procesos. Esta herramienta introduce una nueva técnica basada en la modificación de la estructura del mismo sistema en vez de modificar el acceso al sistema. Funciona en el modo de núcleo.

Esta no es una lista completa pero incluye los rootkits claves para comprender la evolución de los rootkits para Windows, especialmente HacDef, Haxdoor y FU. Era común encontrar estos 3 rootkits circulando en Internet en combinación con otros programas maliciosos.

Los rootkits surgidos entre 2000 y 2004 encajan bien en el sistema estándar (ya obsoleto) de clasificación: Pueden funcionar tanto en el nivel de usuario como en el de núcleo gracias a Execution Path Modification o a Direct Kernel Object Manipulation. Esta clasificación ha sido objeto de interminables discusiones; si desea conocer más al respecto, consulte: www.securitylab.ru
(Russian); http://z-oleg.com
(Russian); www.securityfocus.com

Producción masiva de rootkits

A medida que los rootkits evolucionaban, se empezaron a utilizar también en programas maliciosos. En aquel entonces resultaba difícil crear tecnologías furtivas de manera independiente ya que había poca literatura sobre el tema. En consecuencia, el reducido número de rootkits maliciosos podía dividirse en tres categorías:

• Troyanos que para ocultarse utilizaban herramientas hechas a medida y bibliotecas. La inmensa mayoría de estos troyanos utilizaba Hacker Defender y FU.
• Rootkist maliciosos hechos a solicitud que podían descargarse o adquirirse y que el usuario podía modificar. Un ejemplo es Haxdoor. Al igual que HacDef, Haxdoor se hizo muy popular en el otoño de 2005. En aquel entonces, Kaspersky Lab añadía cerca de diez firmas diarias a su base de datos para neutralizar las nuevas variantes de Haxdoor.
• Los rootkits hechos bajo demanda empezaron a desarrollarse para realizar ataques dirigidos a blancos específicos. Los desarrolladores de soluciones antivirus solían enterarse de estos rootkits directamente por sus clientes, la mayoría de los cuales eran grandes compañías. Por lo general, los analistas de virus llevaban a cabo investigaciones forenses in-situ, de forma manual, cuando los administradores de redes no lograban identificar la causa del problema. Este grupo de rootkits era muy reducido, pero los ejemplares estudiados demostraban un alto nivel de sofisticación técnica.

En 2005, casi el 80% de los rootkits existentes eran variantes de HacDef y Haxdoor. Rbot y Sdbot fueron los primeros troyanos de puerta trasera multifuncionales que incorporaban tecnologías rootkit. La razón era evidente, pues cualquier tecnología que mejorara la funcionalidad general de un troyano comercial se convertía en una ganancia monetaria adicional para el autor o el controlador. Tanto es así que los autores de bots fueron los primeros en entrar en la rueda de las tecnologías rootkit furtivas.

En 2006, observamos tecnologías rootkit implementadas en gusanos comunes de correo, como Bagle; en programas troyanos espía, como Goldun; y en programas Mailbot, como Rustock. Esta tendencia se convirtió en un serio desafío para los desarrolladores de soluciones antivirus.

Sin embargo, cuando las tecnologías rootkits basadas en troyanos se estandarizaron, ya existía una cantidad de herramientas antirootkit, tanto individuales como incorporadas en productos. Se había reestablecido el equilibrio de poder.

Rootkits y escándalos

En 2005, el uso de tecnologías rootkit en programas maliciosos estaba tan expandido que captó la atención de los medios de comunicación y, por supuesto, de los desarrolladores de soluciones de seguridad. Los representantes de Microsoft plantearon el asunto en la conferencia RSA.

El gran número de escándalos suscitados por las tecnologías rootkit en varios productos de software y de hardware en 2006 demostraba sin duda alguna que los rootkits se habían convertido en tema de interés público.

1. La tecnología de protección de copias Sony DRM, en algunos CDs, ocultaba sus archivos a los usuarios. Además, esta tecnología se implementó de tal manera que creó una grave vulnerabilidad: el usuario podía poner nombres especiales a los archivos y la tecnología Sony DRM se encargaba de ocultarlos.
2. Symantec incluía una característica parecida en sus productos: usaba un directorio oculto a los usuarios. Este incidente no deja de ser divertido, pues Symantec documentó su “protected basket” y resultaba fácil desactivarla. En realidad, el concepto de ocultar archivos en esta carpeta oculta no es tan interesante como el concepto de ocultar archivos en las profundidades del árbol del directorio del sistema, al cual ningún usuario suele acceder.
3. La siguiente víctima de los escándalos relacionados con los rootkits fue el mismo Kaspersky Anti-Virus, puesto que el producto era capaz de restaurar los datos en los flujos de archivos, es decir, en aquellas partes del sistema generalmente ocultas a los usuarios. Aunque aún no era claro el peligro que esto representaba, el uso del término ‘rootkit’ logró asustar a mucha gente.

Histeria antirootkit

Otro aspecto importante en la evolución de los rootkits fue la histeria antirootkit que la acompañó. A mediados de 2006, todos los principales desarrolladores de soluciones antivirus admitieron que era necesario reaccionar ante la amenaza que representaban los rootkits. Y cada compañía reaccionó de forma aislada. Algunos modificaron sus productos para que accedieran a objetos ocultos durante los análisis antivirus regulares. Otros lanzaron herramientas antirootkit individuales. Otro grupo respondió incluyendo el análisis antirootkit en sus productos; se podía acceder a esta función a través de la interfaz del producto.

En honor a la verdad, nadie en particular tuvo éxito; era como abrir el paraguas después de empaparse.

Dado el empeoramiento de la situación, F-Secure, cuya herramienta antirootkit fue lanzada poco después de que Sysinternals lanzara su Rootkit Revealer, fue uno de los primeros desarrolladores en tomar una acción notable. La herramienta de F-Secure sólo detectaba procesos ocultos, pero se basaba en tecnologías de prueba de concepto.

Antirootkits de desarrolladores independientes

Las herramientas antirootkit de desarrolladores independientes aparecieron incluso antes, alrededor de 2005. A diferencia de las soluciones de los fabricantes de productos antivirus, que necesitaban evidenciar que protegían a sus usuarios, los desarrolladores independientes sólo pretendían desvelar la mayor cantidad de datos ocultos. Por esta razón, estas herramientas resultaron ser más profesionales, más poderosas, y más capaces de reaccionar de forma adecuada al entorno cambiante.

Las primeras herramientas antirootkit se diseñaron para revelar un solo tipo de objeto, por ejemplo, los archivos ocultos. A medida que pasaba el tiempo, se hicieron progresivamente multifuncionales y utilizaban un enfoque sistemático. Hoy en día, las herramientas antirootkit generales más útiles son GMER y Rootkit Unhooker, que ya no cuenta con soporte. Ambas herramientas posibilitan la realización de un análisis superficial y rápido, desde distintos ángulos, del estado de un sistema. También se pueden usar, si fuera necesario, para análisis más profundos y especializados.

Hoy en día hay al menos 20 herramientas antirootkit gratuitas
, cada una basada en una serie de enfoques para la detección de rootkits (para más detalles ver http://z-oleg.com
y www.securityfocus.com ). Pero la batalla no cesa.

Una de las últimas tendencias en la evolución de los rootkits es el uso de la tecnología Bluepill (es decir, la virtualización del hardware) que no se puede detectar mediante las actuales tecnologías antirootkit. Sucede que no existen herramientas antirootkits completamente funcionales capaces de detectar rootkits de tecnología Bluepill. Por otro lado, tampoco existen programas maliciosos totalmente funcionales que usen esta técnica, sino sólo códigos de prueba de concepto.

Sin embargo, se están realizando trabajos y estudios sobre la detección de estas hipotéticas amenazas. Sé de dos proyectos en curso que investigan los rootkits; uno es el de la firma rusa North Security Labs
, y el otro de la americana Hypervista Technologies
. Hasta la fecha, Hypervista sólo ha publicado alguna información teórica; mientras que North Security Labs ha lanzado una versión beta de su Hypersight Rootkit Detector, descargable desde su sitio Internet. Aunque el proyecto aún se encuentra en su etapa inicial, no deja de ser interesante.

Rootkits basados en el código ‘prueba de concepto’

En 2006, la mayoría de los rootkits se detectaron mediante herramientas antirootkit, lo que dio inicio al ocaso del ‘boom’ de los rootkits. Naturalmente, esto llevó a los investigadores, legítimos y rufianes, a estudiar nuevas técnicas potencialmente indetectables.

La mayoría de ellos se enfocó en el concepto de la virtualización del hardware (integrado en los nuevos procesadores Intel y AMD) para hacerse con el control del sistema operativo. Este método permite la creación de rootkits indetectables para las actuales herramientas antirootkit.

En 2006 se lanzaron tres rootkits ‘prueba de concepto’: SubVirt (pdf), BluePill (pdf)
y Vitrio (pdf). En el momento de escribir este artículo, la detección de estos rootkits es aún un tema sin solución. Sin embargo, y hasta donde sabemos, estos rootkits todavía no han entrado en circulación en Internet.

La segunda área importante de estudio por parte de los investigadores son los rootkits que se desarrollan en el sector de arranque, conocidos como ‘bootkits’. Este grupo de rootkits logra hacerse con el control total del sistema mientras éste arranca. Esta técnica se remonta a los virus tipo ‘boot’ que dominaron en la era del DOS. El primer rootkit ‘prueba de concepto’ dirigido al sector de arranque fue eEye Bootroot (pdf), que apareció en 2005. Vbootkit (pdf), un rootkit similar, apareció en 2007 y se presentó como muestra de una investigación dedicada al tema candente en ese momento: la seguridad de Vista.

Últimas tendencias

Tras un periodo relativamente largo durante el cual no surgieron nuevos rootkits, 2008 trae consigo nuevos retos para la industria antivirus. Un nuevo programa malicioso que supuestamente ataca al sector de arranque ha entrado en escena. Se lo conoce por varios nombres: Sinowal, Mebroot y StealthMBR. La mayoría de las soluciones antivirus no logran detectarlo y mucho menos son capaces de desinfectar los equipos.

Este rootkit, o ‘bootkit’, como habitualmente se lo conoce debido a que se ejecuta durante la secuencia de arranque, se basa en el código eEye Bootroot. En esencia, no es tanto un programa malicioso separado, sino más bien una herramienta para ocultar troyanos… cualquier tipo de troyano. Por tanto, parece razonable concluir que Sinowal es compartido (quizás con algún coste) en ciertos círculos, y que no hemos visto ni un ápice de lo que en realidad es.

Aunque no se le ha dado la debida atención, otra importante y reciente técnica es el uso de funciones CmRegisterCallback, creadas por Microsoft para ayudar a los desarrolladores a ocultar objetos en el registro. Varios de los programas maliciosos más sofisticados, incluyendo Bulknet, recurren a esta técnica.

El mítico rootkit

A finales de 2006, los foros de seguridad se saturaron de rumores sobre Rustock.c, un nuevo rootkit supuestamente indetectable. Se suponía que este nuevo rootkit era la más reciente versión de la familia Rustock de ‘bots’ no deseados. Un año y medio después, los investigadores de Dr. Web, una compañía rusa antivirus, anunciaron que habían encontrado una muestra de Rustock.c y analizado su rutina de propagación. Por desgracia, aún no se dispone de todos los detalles, por lo cual no está clara la verdadera magnitud de la amenaza. Los datos proporcionados por Dr. Web parecen indicar que este rootkit en realidad se creó en septiembre de 2007, y no a finales de 2006.

Sin embargo, lo que está claro es que no es imposible detectar Rustock.c. El programa no recurre a ninguna avanzada tecnología que prevenga su detección. Aunque logra evadir los actuales métodos de detección, esto no es difícil en absoluto, pues un gran número de programas menos conocidos también logran eludir medidas de seguridad.

En resumen, Rustock.c resultó ser más interesante desde el punto de vista del flujo de información que desde una perspectiva técnica. Los rumores que aparecieron a finales de 2006 carecían de fundamento pero de alguna manera prepararon el terreno para futuros eventos. Cuando una muestra verdadera apareció por fin, todos se emocionaron por poder darle una mirada al ‘indetectable’ rootkit, aunque en realidad Rustock.c no reviste interés alguno desde un punto de vista técnico. En mi opinión, Rustock.c fue más importante por la reacción que provocó en la comunidad informática que por ser un gran avance tecnológico.

Para mayores detalles sobre la historia de Rustock.c, ver: www.viruslist.com

Rootkits no dirigidos a Windows

De vez en cuando los laboratorios antivirus obtienen una muestra de rootkits dirigidos a sistemas UNIX menos comunes, como es el caso de Solaris. Esto es normal si una organización no monitoriza sus servidores, configurados hace mucho tiempo y que permanecen sin alteraciones desde entonces. Es fácil irrumpir en uno de estos sistemas y plantar un rootkit que se detecta de manera accidental años después, tras descubrir que la filtración de gran cantidad de información propietaria o confidencial ha ocasionado importantes pérdidas económicas.

Hay varios rootkits elaborados para el sistema operativo OS X de Macintosh, e incluso hay una herramienta antirootkit para este sistema: OS X Rootkit Hunter. Además, debido a que OS X está basado en UNIX, algunos rootkits para UNIX se pueden modificar para que funcionen en OS X. Aunque, en general, no hemos presenciado una evolución significativa de los rootkits para Macintosh, ni ninguna seria amenaza para este entorno.

Que yo sepa, los sistemas operativos para dispositivos móviles como Windows Mobile, Symbian, etc., aún no han sido víctimas de ataques de rootkits. Hay elativamente pocos programas maliciosos para los dispositivos con tales plataformas, y pocas personas utilizan soluciones antivirus, lo que hace innecesaria la tecnología rootkit.

Casi rootkits

En este artículo decidí no referirme a algunos programas maliciosos del tipo ‘prueba de concepto’ ya que no pueden clasificarse como rootkits y la mayoría de los investigadores no los consideran como tales. Si establecemos que un rootkit es un programa capaz de eludir los sistemas de seguridad del sistema operativo y capaz de ocultar su propia actividad, entonces el programa malicioso detallado a continuación está fuera de esta definición.

Existen programas maliciosos que se ocultan en el sistema operativo, pero de una manera ‘honesta’. Tales programas no modifican el sistema ni eluden la seguridad incorporada. Por ejemplo, hay programas maliciosos que se ubican en el directorio del flujo de archivos. Luego, están aquellos que utilizan funciones documentadas del sistema para instalar interceptores de eventos. Estos programas no se consideran rootkits, aunque demuestren un comportamiento furtivo.

En segundo lugar, hay programas cuya invisibilidad se logra gracias a la arquitectura interna del programa, como por ejemplo, el gusano CodeRed
, que no crea archivos en el disco ni procesos en la memoria.

En tercer lugar, existen técnicas sofisticadas para engañar al sistema operativo. Un programa malicioso puede servirse de estas técnicas no para ocultar las huellas de su actividad, sino para infiltrarse en el sistema o para evadir soluciones antivirus. Para más detalles sobre esta técnica, puede leer mi artículo, с.51 (en inglés).

Rootkits – reflexiones finales

Los casos extremos arriba mencionados llevan a la conclusión de que no existen los rootkits maliciosos, sino varias técnicas furtivas utilizadas para evadir la protección de un sistema y ocultar programas en el sistema. Al igual que cualquier otra potente tecnología, estas técnicas también se pueden utilizar con éxito tanto para fines legítimos como maliciosos. Por ejemplo, los rootkits proactivos generalmente combaten el fuego con fuego, utilizando los mismos enfoques que los rootkits, tales como la intercepción de funciones del sistema y otros similares.

Cualquiera o todas estas técnicas se pueden clasificar como rootkits en mayor o menor grado. En el análisis final, definir qué es exactamente un rootkit significa alinearse con la mayoría (la definición generalmente aceptada) o con la competente opinión de la minoría, es decir, los expertos.

Así, ¿es necesaria una definición precisa? Sin ella, corremos el riesgo de caer en facilismos verbales sobre casos extremos, tales como los incidentes en que se detectan los así llamados rootkits en ciertos productos de software. Es crucial analizar en detalle el código y las técnicas usadas en cada caso, en vez de simplemente etiquetar una técnica como rootkit, lo que sólo crea pánico y mucho ruido sobre el incidente.

Por ejemplo, el así llamado rootkit; www.kaspersky.com
que se identificó en la aplicación Kaspersky Anti-Virus. La técnica utilizada en este producto fue calificada como arriesgada ya que almacenaba información adicional en los flujos de archivos del sistema, es decir, en áreas del sistema de archivos que resultan difíciles de monitorear de manera directa.

¿Es esta una técnica para eludir el sistema operativo? Los ‘no-flujos’ son una función documentada del sistema operativo. ¿Constituye el ocultamiento de datos en estos flujos una actividad maliciosa? No. En este caso, sólo se oculta la información de servicios. ¿Constituye esta técnica una vulnerabilidad, es decir, se la puede utilizar con fines maliciosos? No. Un usuario malicioso sólo puede usar los flujos para ocultar códigos maliciosos (y esta técnica ya ha sido implementada en varios programas maliciosos), pero ésta es una vulnerabilidad del sistema operativo, no una vulnerabilidad de una aplicación. Entonces… ¿dónde está el rootkit? No se encuentra en Kaspersky Anit-Virus, y por lo mismo, en ningún otro producto en el que una vulnerabilidad del sistema se confunda con una vulnerabilidad de una aplicación.

El incidente de Sony DRM es un poco diferente. Las técnicas utilizadas en la protección de copias resultaron en una vulnerabilidad en el sentido en el que permitían a los usuarios maliciosos nombrar sus programas maliciosos para que se vuelvan invisibles. Hoy en día, sabemos que varios programas maliciosos explotan esta vulnerabilidad, aunque para ser justos, el programa malicioso apareció sólo después de que la vulnerabilidad se descubriera y debatiera.

 
Cronología de los rootkits

Conclusión

En general, la evolución de los rootkits sigue los mismos pasos que la evolución de los programas espía (spyware). Primero, se identificaron los rootkits como un tipo distinto de programa malicioso. Luego, hubo un revuelo en los medios de comunicación que llevó al surgimiento de varias herramientas y productos antirootkit con una notable reacción de la industria antivirus. Hoy en día, tanto los rootkits como los programas espía se han sumergido en la corriente de los programas maliciosos y ya no causan especial agitación. Sin embargo, el concepto de evadir las prestaciones del sistema para ocultar algo, obviamente sigue estando vigente y es muy probable que seamos testigos de nuevas amenazas de tipo furtivo.