lunes, 30 de junio de 2014

HackingTeam 2.0: La historia se moviliza

Ha pasado más de un año desde la publicación de nuestro último artículo sobre HackingTeam, la compañía italiana que desarrolla una herramienta spyware “legal” conocida como Sistema de Control Remoto (RCS). Desde entonces, muchas cosas han sucedido, por lo que es tiempo de actualizar los resultados de nuestra investigación sobre el programa malicioso RCS.

Localización de los servidores de comando


Una de las cosas más importantes que hemos descubierto durante nuestra prolongada y extensa investigación es una característica específica que puede usarse para localizar los servidores de comando de RCS. En la conferencia Virus Bulletin 2013 presentamos los detalles de esta metodología.
En resumen, cuando una petición especial se envía a un servidor HackingTeam RCS C&C “inofensivo”, este responde con el siguiente mensaje de error:


Imagen de nuestra presentación en VB 2013 con la huella digital del servidor C&C de HackingTeam.

En primer lugar, aparece el identificador ‘RCS’. Bien. No estábamos seguros acerca del ‘Collector’ mencionado en la respuesta. Quizás se refiera al hecho de que el servidor ‘recopila’ información de sus víctimas. Utilizamos este particular método de huellas digitales para analizar todo el espacio IPv4, lo que nos permitió encontrar todas las direcciones IP de los servidores C&C de RCS en todo el mundo e identificarlos en un mapa. En total, identificamos 326 servidores C&C.

Cantidad de servidores C&CPaís
64Estados Unidos
49Kazajistán
35Ecuador
32Reino Unido
24Canadá
15China
12Colombia
7Polonia
7Nueva Zelandia
6Perú
6Indonesia
6Brasil
6Bolivia
6Argentina
5Federación Rusa
5India
4Hong Kong
4Australia
3España
2Arabia Saudita
2Malasia
2Italia
2Alemania
2Francia
2Egipto
1Ucrania
1Tailandia
1Suecia
1Singapur
1Rumania
1Paraguay
1Marruecos
1Lituania
1Kenia
1Japón
1Irlanda
1Hungría
1Dinamarca
1República Checa
1Chipre
1Bélgica
1Azerbaiyán
1Otros


Mapa con los países que alojan a servidores de HackingTeam

La mayor cantidad de servidores identificados se encontraba en Estados Unidos, Kazajistán y Ecuador. Por desgracia, no estamos seguros si los LEAs de un determinado país utilizan los servidores de ese país. Sin embargo, tendría sentido si los LEAs ponen sus servidores C&C en sus propios países para evitar problemas legales internacionales y la captura de los servidores. Sin embargo, identificamos varias IPs relacionadas con “gobiernos” en base a su información WHOIS lo que nos dio una clara indicación de quiénes son sus dueños.

Módulos móviles

Por algún tiempo se sabía que los productos de HackingTeam incluían programas maliciosos para teléfonos móviles, pero rara vez se los veía. En particular, nunca se habían detectado los troyanos para iOS y Android y representaban uno de los vacíos en la historia. A principios de este año descubrimos varios módulos de programas maliciosos móviles provenientes de HackingTeam para las siguientes plataformas:

  • Android

  • iOS

  • Windows Mobile

  • BlackBerry

Todos estos módulos se controlan con el mismo tipo de configuración, lo que es un buen indicio de que están relacionados y que pertenecen a la misma familia de productos.

Archivo de configuración de los módulos móviles de RCS

Sin duda, nuestro principal interés durante el análisis de los módulos móviles se centraba en iOS y Android, por su popularidad. El módulo iOS funciona sólo en dispositivos decodificados. La siguiente es una descripción de la función principal del módulo iOS:
  • Control de Wi-Fi, GPS, GPRS.

  • Grabación de voz.

  • E-mail, SMS, MMS.

  • Listado de archivos.

  • Cookies.

  • URLs visitadas.

  • Páginas web en caché.

  • Libreta de direcciones.

  • Historial de llamadas.

  • Notas.

  • Calendario.

  • Portapapeles.

  • Lista de aplicaciones.

  • Cambio de SIM.

  • Micrófono en vivo.

  • Uso de la cámara.

  • Conversaciones en WhatsApp, Skype, Viber.

  • Registro de actividades en el teclado para todas las aplicaciones y ventanas mediante libinjection.
Código desarticulado del módulo iOS.

El módulo Android está protegido por el optimizador/ofuscador DexGuard y por eso resulta muy difícil de analizar. Sin embargo, descubrimos (ver el rastro debajo) que la muestra tiene todas las funciones del módulo iOS que hemos mencionado arriba, además de soporte para robar información de la siguientes aplicaciones:

  • com.tencent.mm

  • com.google.android.gm

  • android.calendar

  • com.facebook

  • jp.naver.line.android

  • com.google.android.talk


Rastro de una muestra de RCS Android.

Infectadores móviles

Otro aspecto de particular interés para nosotros era la forma en que los programas maliciosos se instalaban en los dispositivos móviles. Descubrimos varios módulos que infectaban los dispositivos móviles conectados a ordenadores Windows o Mac OS X infectados.
Como ya hemos mencionado, el módulo iOS sirve sólo en dispositivos decodificados. Es por eso que el infectador iOS utiliza el protocolo de transferencia AFP2. El ‘infectador’ posee una agradable GUI que le permite la instalación si tiene acceso físico al dispositivo de la víctima o acceso al administrador remoto de un ordenador infectado.

Ventana principal del infectador iOS

iPhone1,1iPhone1,2iPhone2,1
iPhone3,1iPhone3,2iPhone3,3
iPhone4,1iPhone5,1iPhone5,2
iPad1,1iPad2,1iPad2,2
iPad2,3iPad2,4iPad3,1
iPad3,2iPad3,3iPad3,4
iPad3,5iPad3,6iPhone
iPhone 3GiPhone 3GSiPhone 4
iPhone 4iPhone 4 (cdma)iPhone 4s
iPhone 5 (gsm)iPhone 5iPad
iPad2 (Wi-Fi)iPad2 (gsm)iPad2 (cdma)
iPad2 (Wi-Fi)iPad3 (Wi-Fi)iPad3 (gsm)
iPad3iPad4 (Wi-Fi)iPad4 (gsm)
iPad4  

Lista de dispositivos Apple compatibles con el infectador iOS.
Después de conectarse, el infectador iOS copia varios archivos en el iOS y ejecuta el archivo install.sh:

Segmento del archivo install.sh que se ejecuta en un dispositivo iOS infectado.

Como hemos mencionado más arriba, el acceso al administrador remoto de un ordenador infectado es una de las posibles formas en que se instala el programa malicioso en un dispositivo móvil conectado. El hecho de que sólo los dispositivos iOS decodificados sean compatibles puede ser un factor limitante, pero este no es un problema grave puesto que el atacante también puede ejecutar una herramienta decodificadora como Evasi0n a través del mismo ordenador infectado. En este caso, lo único que puede proteger al usuario contra una decodificación remota e infección de su dispositivo, es su clave de acceso. Sin embargo, si el dispositivo no está protegido mientras está conectado a un ordenador infectado, el atacante podrá infectarlo.
Otro interesante infectador móvil es el desarrollado para los dispositivos BlackBerry, que usa la aplicación JavaLoader para cargar programas maliciosos en BB 4.5 y 5.0. Cuando desarticulamos su código encontramos una ruta al archivo depurador PDB, que al parecer sus autores cometieron el error de olvidarlo. El proyecto original se encontraba en ‘C:\HT\RCSBlackBerry\Workspace\RCS_BB_Infection_Agent\’ cuando se creó este programa malicioso.

Segmento del código de un infectador Blackberry con una ruta al archivo PDB.

Resumen

En la última entrega de nuestra investigación descubrimos una enorme infraestructura utilizada para controlar los implantes de programas maliciosos RCS. En nuestra investigación más reciente hemos identificado módulos móviles que funcionan en todas las plataformas móviles de renombre, incluyendo iOS y Android. Estos módulos se instalan mediante infectadores especiales para Windows o Mac que se ejecutan en ordenadores ya infectados. Estos infectadores toman el control total del ambiente interno y externo del ordenador de la víctima. Mediante la activación secreta del micrófono y capturas regulares de pantalla ejercen una vigilancia permanente de la víctima, lo que es una forma mucho más poderosa que las tradicionales operaciones a capa y espada.
Los nuevos datos que publicamos sobre el RCS de HackingTeam son de máxima importancia porque muestran el grado de sofisticación y la escala que alcanzaron estas herramientas de vigilancia. Quisiéramos creer que si logramos proteger a nuestros clientes contra estas avanzadas amenazas, con seguridad no tendremos problemas con otras amenazas menores y más comunes propias de los ciberpiratas.

Apéndice:


MD5s de infectadores móviles:
  • 14b03ada92dd81d6ce57f43889810087 – infectador BlackBerry

  • 35c4f9f242aae60edbd1fe150bc952d5 – infectador iOS

MD5s de muestras Android:
  • ff8e7f09232198d6529d9194c86c0791

  • 36ab980a954b02a26d3af4378f6c04b4

  • a2a659d66e83ffe66b6d728a52130b72

  • 9f06db99d2e5b27b01113f78b745ff28

  • a43ea939e883cc33fc766dd0bcac9f6a

  • a465ead1fd61afe72238306c7ed048fe

MD5s de muestras Windows:

  • bf8aba6f7640f470a8f75e9adc5b940d

  • b04ab81b9b796042c46966705cd2d201

  • 1be71818a228e88918dac0a8140dbd34

  • c7268b341fd68cf334fc92269f07503a


Lista de servidores C&C activos en 19.06.2014:
  • 50.63.180.***

  • 146.185.30.***

  • 204.188.221.***

  • 91.109.17.***

  • 106.186.17.***

  • 119.59.123.***

  • 95.141.46.***

  • 192.71.245.***

  • 106.187.99.***

  • 93.95.219.***

  • 106.187.96.***

  • 124.217.245.***

  • 23.92.30.***

  • 82.146.58.***

  • 93.95.219.***

  • 209.59.205.***

Módulos RCS (con los nombres de clasificación de Kaspersky Lab):
  • Backdoor.OSX.Morcut

  • Rootkit.OSX.Morcut

  • Trojan.OSX.Morcut

  • Backdoor.Win32.Korablin

  • Backdoor.Win64.Korablin

  • Rootkit.Win32.Korablin

  • Rootkit.Win64.Korablin

  • Trojan.Multi.Korablin

  • Trojan-Dropper.Win32.Korablin

  • Backdoor.AndroidOS.Criag

  • Trojan-Spy.AndroidOS.Mekir

  • Trojan.Win32.BBInfector

  • Trojan.Win32.IOSinfector

  • Trojan.OSX.IOSinfector

  • Trojan-Spy.IphoneOS.Mekir

  • Trojan-Spy.WinCE.Mekir

  • Trojan-Spy.BlackberryOS.Mekir

Saludos.
Lexer Pars.

domingo, 29 de junio de 2014

Ataques antes de que arranque el sistema

Uno de los principales objetivos de los autores de malware es que sus códigos maliciosos se activen tan pronto como sea posible, para que puedan realizar modificaciones claves (como instalar conexiones) en el código del sistema operativo y en las unidades del sistema, antes de que los componentes de la solución antivirus se inicien. Como resultado, los programas maliciosos y las soluciones antimalware juegan al gato y al ratón ya que operan al mismo nivel: el sistema operativo, las unidades del sistema y los paquetes raíz operan en modo kernel.
Los paquetes de arranque, o bootkits, representan hoy la tecnología más avanzada que poseen los ciberdelincuentes, y que permite que sus códigos maliciosos arranquen antes de que lo haga el sistema operativo. Esta tecnología está implementada en numerosos programas maliciosos.

Ya hemos escrito sobre bootkits como XPAJ y TDSS (TDL4). La última publicación sobre bootkits describe escenarios de ataques selectivos en base a tecnologías bootkit como la utilizada en la campaña de Careto/La Máscara. Sin embargo, estas investigaciones no se publican frecuentemente, por lo que algunos expertos pueden tener la impresión de que los bootkits, como los archivos de virus, están ‘muertos’, que Trusted Boot ha hecho su trabajo y que la amenaza ha dejado de ser relevante.

Pero los bootkits existen, tienen demanda en el mercado negro y los ciberdelincuentes los usan ampliamente con propósitos que incluyen ataques selectivos.




Fragmento del código cargador TDSS en MBR

Datos estadísticos

Primero, veamos las estadísticas de KSN. La siguiente tabla muestra la clasificación de los programas maliciosos que hemos detectado como Rootkit.Boot.*, entre el 19 de mayo de 2013 y el 19 de mayo de 2014.
FamiliaUsuariosNotificaciones
Rootkit.Boot.Cidox4579760787
Rootkit.Boot.Pihar2549075320
Rootkit.Boot.Harbinger1985634427
Rootkit.Boot.Sinowal18762420549
Rootkit.Boot.SST859073079
Rootkit.Boot.Tdss538819071
Rootkit.Boot.Backboot43449148
Rootkit.Boot.Wistler423013014
Rootkit.Boot.Qvod11891727
Rootkit.Boot.Xpaj6902483
Rootkit.Boot.Mybios4425073
Rootkit.Boot.Plite422648
Rootkit.Boot.Trup3007395
Rootkit.Boot.Prothean2171407
Rootkit.Boot.Phanta1675475
Rootkit.Boot.GoodKit120131
Rootkit.Boot.Smitnyl1003934
Rootkit.Boot.Stoned6996
Rootkit.Boot.Geth60166
Rootkit.Boot.Nimnul5384
Rootkit.Boot.Niwa37121
Rootkit.Boot.Fisp35344
Rootkit.Boot.CPD2539
Rootkit.Boot.Lapka1921
Rootkit.Boot.Yurn818
Rootkit.Boot.Aeon66
Rootkit.Boot.Mebusta55
Rootkit.Boot.Khnorr44
Rootkit.Boot.Sawlam47
Rootkit.Boot.Xkit420
Rootkit.Boot.Clones11
Rootkit.Boot.Finfish11
Total136435734601


La tecnología de comportamiento detecta proactivamente la mayoría de los bootkits apenas se han instalado en el sistema. También pueden detectarse por primera vez cuando la solución antivirus realiza un análisis automático después del arranque del sistema, que inicia el proceso de eliminación de infecciones activas. Las estadísticas mencionadas incluyen sólo las detecciones de infecciones en el Registro de Arranque Principal (MBR). Las cifras también incluyen los datos recibidos de equipos infectados con anterioridad y en los cuales se instaló nuestra solución antivirus después de que se infectaron.
Podemos ver en la tabla anterior que los derivados de TDSS, Pihar y SST, se encuentran en el Top 5 de los bootkits detectados. El bootkit Harbinger, que ‘cubre’ el adware, se encuentra en la tercera posición y Sinowal en la cuarta. La primera plaza le corresponde, con diferencia, a Rootkit.Boot.Cidox. Puesto que Cidox tiene un rol especial en la evolución de los bootkits, nos referiremos a su historia en detalle.

Cidox: código abierto al público

Cidox se ofrece como complemento a otros programas maliciosos y se usa para proteger los programas maliciosos junto a los cuales se distribuye. Esto significa que este bootkit no se usa para construir su propia red de robots, o botnet, tipo TDSS.
Las versiones iniciales de este programa malicioso estaban incluidas en las bases de datos antivirus de Kaspersky Lab hace tres años, el 28 de junio de 2011. En ese entonces, Cidox era un hito en la tecnología maliciosa porque fue el primero en infectar el VBR en lugar del MBR.

Cidox se usaba para proteger el troyano banquero Carberp, además de otros programas maliciosos. Cuando se publicó el código fuente de Carberp, también 'se filtró’ el código fuente del bootkit. Como resultado, Cidox volvió a personificar la historia del famoso troyano ZeuS (Zbot). La ‘fuga’ del código fuente de ZeuS facilitó en gran medida el robo de dinero desde los sistemas bancarios online, y la publicación del código fuente de Cidox hizo que cualquier programador medianamente experto pueda escribir programas maliciosos capaces de funcionar en los niveles más bajos, antes de que el sistema operativo arranque.




Fragmento del código fuente de Cidox


Cidox se usa hoy para cargar y proteger una variedad de programas maliciosos, incluyendo crimeware, bloqueadores y malware diseñado para robar dinero desde sistemas bancarios online.

Таргетированные атаки

La campaña de Careto/La Máscara que mencionamos antes, no fue un caso aislado de bootkits utilizados en ataques selectivos. Hace poco escribimos sobre Hacking Team, una compañía cuyos programas (incluyendo bootkits) se usan para realizar operaciones policiales en varios países del mundo. Otra compañía, FinFisher, ofrece servicios similares, y entre los programas que desarrolla también se encuentra un bootkit, Rootkit.Boot.Finfish, que se encuentra en el último lugar de nuestra clasificación.




Lista de productos y servicios de la página oficial de FinFisher


Kaspersky Lab presentó un análisis de los productos de FinFisher en una conferencia de Virus Bulletin. La presentación se encuentra en el sitio web de VB.

BIOS. La búsqueda de nuevos puntos de inicio.

La incesante lucha entre las soluciones antivirus y los códigos maliciosos está llevando a ambos a la próxima fase de su evolución. Los autores de programas maliciosos tienen que buscar nuevos puntos de inicio, y el BIOS puede ser uno de ellos. Sin embargo, apenas se ha pasado de la etapa de pruebas de investigación, debido a que la modificación masiva del BIOS es una operación ‘inconveniente’ para los autores de programas maliciosos, pues exige considerables esfuerzos y por lo tanto sólo puede hacerse en el caso de ataques altamente selectivos.

¿En qué se convertirán los sueños?

El sistema BIOS clásico es una verdadera reliquia difícil de usar y con numerosas limitaciones. Es por esto que el consorcio UEFI Forum ha desarrollado una interfaz modular unificada completamente nueva, UEFI, en base a especificaciones provistas originalmente por Intel.

¿Qué ofrece UEFI?

  • Compatibilidad con equipos modernos.

  • Arquitectura modular.

  • Código EFI Byte: arquitectura y controladores independientes del tipo de CPU (x86, x86-64, ARM/ARMv8).

  • Varios complementos para UEFI, que se descargan para diferentes dispositivos, incluyendo los portátiles.

  • Desarrollo en base a un lenguaje de programación de alto nivel (un dialecto de C).

  • Arranque seguro (Secure Boot).

  • Arranque de red.

También recomendamos leer las 10 confusiones más comunes sobre UEFI.
Los siguientes sistemas operativos son compatibles con UEFI:
  • Linux con Lilo o una versión especial del gestor de arranque GRUB.

  • FreeBSD.

  • Apple Mac OS X para sistemas compatibles con Intel (v10.4 y v10.5 son parcialmente compatibles; 10.8 es completamente compatible).

  • Microsoft Windows, desde Windows Server 2008 y Windows Vista SP1 x86-64. Microsoft Windows 8 es compatible con UEFI, incluyendo UEFI 32 bit, y un arranque seguro.

En resumen, ¿qué ofrece UEFI? Un método conveniente, unificado, bien documentado y fácil de entender para desarrollar sin recurrir al lenguaje ensamblador 16-bit.

Desde el punto de vista de una solución antimalware, UEFI es un lugar muy bueno para implementar un disco de rescate. Primero, el código del disco de rescate se ejecuta antes que arranquen el sistema operativo y el gestor de arranque. Segundo, UEFI ofrece un fácil acceso al disco duro, y un acceso relativamente fácil a la red. Tercero, se puede crear un GUI sencillo y fácil de entender. Es exactamente la receta para tratar amenazas sofisticadas y altamente resistentes, como los bootkits.

Desde el punto de vista de los autores de códigos maliciosos, todo lo dicho es también una ventaja para un bootkit, pues proporciona una protección confiable a los programas maliciosos. Por lo menos hasta que los desarrolladores de firmware se preocupen por implementar una protección adecuada.

Sin embargo, antes de pasar a la funcionalidad de la protección, nos gustaría tocar un tema importante. Los fabricantes de equipos desarrollan su propio firmware y toman sus propias decisiones sobre el soporte para características opcionales que ofrece la especificación UEFI. Estas características incluyen, antes que nada, firmware de seguridad en SPI Flash contra modificaciones yarranque seguro. En el caso de UEFI, tenemos el problema clásico de conveniencia versus seguridad.

Amenazas y mecanismos de protección

No es sorprendente que, a medida que UEFI se hizo más universal, atrajera el interés de investigadores independientes como un potencial vector de ataque (unodostres). La lista de los posibles puntos de penetración es bastante amplia e incluye gestores de arranque del sistema operativo y EFI comprometidos (inyectando, remplazando o infectando), controladores UEFI comprometidos, acceso directo a SPI Flash desde el sistema operativo, y otros. En el caso del arranque en el modo UEFI+Legacy (CSM), siguen siendo efectivos los viejos métodos que usaban los desarrolladores de bookits para infectar el sistema. También es muy obvio que si se compromete el ambiente de ejecución en pre-arranque, todos los mecanismos de seguridad de Windows, como Patch Guard, la verificación de firmas de controladores, etc., quedarán inutilizados.
La especificación UEFI versión 2.2 incluía un nuevo protocolo de arranque seguro que tenía que proporcionar un ambiente seguro de ejecución en pre-arranque, así como protección contra códigos maliciosos ejecutados desde puntos potencialmente vulnerables.
El protocolo de arranque seguro define el proceso usado para verificar los módulos que se están cargando, como los controladores, el gestor de arranque del sistema operativo y aplicaciones. Estos módulos deben estar firmados con una llave especial y la firma digital debe verificarse antes de cargar el módulo. Las llaves que se usan para verificar los módulos deben guardarse en una base de datos dedicada y protegida contra penetraciones, como una TPM. Las llaves pueden añadirse o modificarse con otras llaves, lo que proporciona un método seguro para modificar la misma base de datos.
En base a lo anterior, la implementación de los siguientes mecanismos de seguridad de parte de los desarrolladores de firmware y de sistemas operativos puede considerarse óptima desde el punto de vista de la seguridad:
  • Proteger SPI Flash contra modificaciones maliciosas. Soporte de desactivación para la actualización de firmas desde el sistema operativo.

  • Bloquear el acceso a secciones críticas del UEFI, incluyendo la mayoría de la variables del ambiente.

  • Abandonar por completo el uso de CSM.

  • Proteger contra modificaciones maliciosas el volumen del sistema que contiene los controladores UEFI, el gestor de arranque y aplicaciones.

  • Los desarrolladores de firmware y de sistemas operativos deben implementar y activar el Arranque Seguro (así como el mecanismo Trusted Boot implementado en el sistema operativo Windows).

  • Proteger el almacenamiento de las llaves contra modificaciones.

  • Proteger el mecanismo usado para duplicar la base de datos en la que se guardan las llaves contra ataques tipo spoofing y otros.

  • Implementar una protección contra los ataques “Evil Maid” que incluyen el acceso físico al equipo.

  • Usar la experiencia acumulada de las compañías antimalware e implementar tecnologías antimalware a nivel del firmware.


Sin embargo, hay que tener en cuenta que cuanto más avanzados sean los mecanismos de protección que se implementen, los ciberdelincuentes sacarán de la galera ataques más avanzados contra el UEFI. Los métodos que hoy se usan están basados en el remplazo del gestor de arranque UEFI para el sistema operativo Windows 8. Durante su inicialización, el gestor malicioso del sistema operativo carga en la memoria un gestor remplazado en la memoria, desactiva los mecanismos de seguridad Patch Guard y la verificación de firmas del controlador con un método u otro, establece las conexiones necesarias y le otorga el control al código del gestor original.
En el caso del sistema operativo Mac con cifrado completo del disco, se utiliza un enfoque original basado en la implementación de un sencillo capturador de teclado, o keylogger, UEFI para obtener la contraseña secreta que introduce el usuario mediante el teclado para descifrar los contenidos del disco duro en el arranque del sistema. En los demás aspectos, el método basado en el remplazo o la infección del gestor de arranque del sistema también se aplica en este caso.

Conclusiones

Los bootkits han evolucionado desde el desarrollo de la Prueba de concepto hasta su propagación masiva, llegando a convertirse hoy en software de código abierto. El lanzamiento del código malicioso desde el Registro de Arranque Principal (MBR) o el Registro de Arranque del Volumen (VBR) les permite a los ciberdelincuentes controlar todas las etapas del inicio del sistema de arranque. Este tipo de infección se ha convertido en un estándar entre los autores de programas maliciosos. Su implementación se basa en tecnologías probadas y de profunda investigación. Lo importante es que estas tecnologías están disponibles, en la forma de un código fuente, en una variedad de recursos. En el futuro, esto puede conducir a un significativo aumento en la cantidad de programas maliciosos basados en estas tecnologías, con apenas pequeñas modificaciones en la lógica de operación de los programas individuales. Prevemos que aparezcan nuevas modificaciones de TDSS y Cridex, que ya son comunes entre los ciberdelincuentes. También nos preocupa que los ciberdelincuentes usen estos programas maliciosos para lanzar ataques contra sistemas que usan tecnologías Default Deny.
Es crucial remarcar que las tecnologías de punta antimalware implementadas en nuestros productos anulan exitosamente estas infecciones. Puesto que resulta difícil predecir en este momento qué métodos específicos de enmascaramiento, bloqueo o de resistencia contra las soluciones antimalware llegarán a inventar los ciberdelincuentes en un futuro cercano,la implementación de las tecnologías antimalware a nivel del firmware, en combinación con los mecanismos de protección arriba descritos, permitirá que las soluciones de seguridad neutralicen los rootkits y bootkits antes de que los códigos maliciosos tomen el control. Asimismo, la incorporación de un módulo antimalware en UEFI simplificará el proceso de eliminación de infecciones y el desarrollo de nuevos métodos para detectar bootkits recién desarrollados que usan tecnologías nuevas y avanzadas de enmascaramiento, y rootkits que interfieren con el funcionamiento del sistema o de la solución antimalware.

P.D. Los autores agradecen especialmente a Vasily Berdnikov por su ayuda en el material de investigación para este análisis

Saludos.
Lexer Pars.