ES2857102T3 - Detección de comportamiento de malware utilizando una máquina virtual de interpretación - Google Patents

Detección de comportamiento de malware utilizando una máquina virtual de interpretación Download PDF

Info

Publication number
ES2857102T3
ES2857102T3 ES16730294T ES16730294T ES2857102T3 ES 2857102 T3 ES2857102 T3 ES 2857102T3 ES 16730294 T ES16730294 T ES 16730294T ES 16730294 T ES16730294 T ES 16730294T ES 2857102 T3 ES2857102 T3 ES 2857102T3
Authority
ES
Spain
Prior art keywords
malware
routine
bytecode
client system
event
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES16730294T
Other languages
English (en)
Inventor
Gheorghe-Florin Hajmasan
Sandor Lukacs
Botond Fulop
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bitdefender IPR Management Ltd
Original Assignee
Bitdefender IPR Management Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bitdefender IPR Management Ltd filed Critical Bitdefender IPR Management Ltd
Application granted granted Critical
Publication of ES2857102T3 publication Critical patent/ES2857102T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/56—Computer malware detection or handling, e.g. anti-virus arrangements
    • G06F21/566—Dynamic detection, i.e. detection performed at run-time, e.g. emulation, suspicious activities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Virology (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Debugging And Monitoring (AREA)
  • Storage Device Security (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Un sistema cliente que comprende al menos un procesador de hardware configurado para ejecutar un despachador [32] de rutinas, una máquina virtual [34] de traducción de código de bytes y un motor [38] de evaluación del comportamiento, en donde : el despachador [32[ de rutinas está configurado, en respuesta a la detección de la ocurrencia de un evento desencadenante, para seleccionar una rutina de código de bytes anti-malware para su ejecución a partir de una pluralidad de rutinas de código de bytes anti-malware, siendo la rutina de código de bytes anti-malware seleccionada según el evento desencadenante, en donde la ocurrencia del evento desencadenante es causada por un proceso monitoreado que se ejecuta dentro del sistema cliente; la máquina virtual [34] de traducción de código de bytes está configurada, en respuesta al despachador [32] de rutinas que selecciona la rutina de código de bytes anti-malware, para ejecutar la rutina de código de bytes anti- malware para determinar si la ocurrencia del evento desencadenante es indicativa de malware, en donde la ejecución de la rutina de código de bytes anti-malware comprende: traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador, y ejecutar la secuencia de instrucciones nativas de procesador; y el motor [38] de evaluación del comportamiento está configurado para determinar si el sistema cliente comprende malware según un resultado de la máquina virtual [34] de traducción de código de bytes que ejecuta la rutina de código de bytes anti-malware.

Description

DESCRIPCIÓN
Detección de comportamiento de malware utilizando una máquina virtual de interpretación
Antecedentes
La invención se refiere a sistemas y métodos para proteger los sistemas informáticos del malware.
El software malicioso, también conocido como malware, afecta a una gran cantidad de sistemas informáticos en todo el mundo. En sus diversas formas, tales como virus informáticos, gusanos, “rootkits”, adware no solicitado, ransomware y spyware, el malware representa un riesgo grave para millones de usuarios de ordenadores, haciéndolos vulnerables a la pérdida de datos e información confidencial, robo de identidad y pérdida de productividad, entre otros. Además, el malware puede mostrar material que algunos usuarios consideran obsceno, excesivamente violento, acosador u objetable de cualquier otro modo.
El software de seguridad se puede utilizar para detectar malware que infecta el sistema informático de un usuario y, además, para eliminar o inhabilitar tal malware. Se conocen en la técnica varias técnicas de detección de malware. Algunos confían en hacer coincidir un fragmento de código del agente de malware con una biblioteca de firmas indicativas de malware. Otros métodos convencionales detectan un conjunto de comportamientos indicativos de malware del agente de malware. Un ejemplo de este tipo se muestra en la Publicación previa a la concesión de EE.UU. No. 2015/007325 A1 de E. Eliseev et al., que describe un método de comportamiento anti-malware que comprende monitorear el comportamiento de un programa de software en un entorno informático de una máquina virtual Java y evaluar la respuesta del programa de software a un evento desencadenante que se sabe que desencadena un comportamiento malicioso en programas infectados.
El malware evoluciona rápidamente, para adelantarse a los algoritmos de detección. Para abordar tales amenazas que cambian rápidamente, los proveedores de software de seguridad suelen ajustar los métodos y/o parámetros de detección en una escala de minutos a horas, por ejemplo, entrenando nuevamente a los clasificadores para detectar nuevas versiones de malware. Normalmente, tal nuevo entrenamiento es computacionalmente costoso. Además, la introducción de un nuevo algoritmo de detección de comportamiento, o incluso el cambio de uno existente, normalmente requiere pruebas exhaustivas, así como una nueva compilación del código fuente del software de seguridad respectivo. Solo entonces se puede entregar la nueva versión de software a los clientes, por ejemplo, como una actualización de software. Por el contrario, en los sistemas de detección basados en firmas, se puede añadir fácilmente una nueva firma de malware a un conjunto de firmas existente.
Por lo tanto, existe un gran interés en desarrollar soluciones anti-malware capaces de actualizar rápidamente algoritmos y/o parámetros, para seguir el ritmo de la naturaleza siempre cambiante del malware.
Compendio
Según un aspecto, un sistema cliente comprende al menos un procesador de hardware configurado para formar un despachador de rutinas, una máquina virtual de traducción de códigos de bytes y un motor de evaluación del comportamiento. El despachador de rutinas está configurado, en respuesta a la detección de la ocurrencia de un evento desencadenante, para seleccionar una rutina de código de bytes anti-malware para su ejecución entre una pluralidad de rutinas de código de bytes anti-malware, la rutina de código de bytes anti-malware seleccionada según el evento desencadenante . La ocurrencia del evento desencadenante es causada por un proceso monitoreo que se ejecuta dentro del sistema cliente. La máquina virtual de traducción de código de bytes está configurada para ejecutar la rutina de código de bytes anti-malware para determinar si la ocurrencia del evento desencadenante es indicativo de malware, en donde la ejecución de la rutina de código de bytes anti-malware comprende traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador y ejecutar la secuencia de instrucciones nativas de procesador. El motor de evaluación del comportamiento está configurado para determinar si el sistema cliente comprende malware según el resultado de la máquina virtual de traducción de código de bytes que ejecuta la rutina de código de bytes antimalware.
Según otro aspecto, un método implementado por ordenador comprende emplear al menos un procesador de hardware de un sistema cliente, en respuesta a la detección de la ocurrencia de un evento desencadenante, para seleccionar una rutina de código de bytes anti-malware de una pluralidad de rutinas de código de bytes según el evento desencadenante, la rutina de código de bytes anti-malware configurada para determinar si la ocurrencia del evento desencadenante es indicativa de malware. El evento desencadenante es causado por un proceso monitoreado que se ejecuta dentro del sistema cliente. El método comprende además emplear al menos un procesador de hardware del sistema cliente, en respuesta a la selección de la rutina de código de bytes antimalware, para traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador, y para ejecutar la secuencia de instrucciones nativas de procesador. El método comprende además emplear al menos un procesador de hardware del sistema cliente para determinar si el sistema cliente comprende malware según el resultado de ejecutar la secuencia de instrucciones nativas de procesador.
Según otro aspecto, un medio legible por ordenador no transitorio almacena un programa informático que, cuando es ejecutado por al menos un procesador de hardware de un sistema cliente, hace que el sistema cliente forme un despachador de rutinas, una máquina virtual de traducción de código bytes y una motor de evaluación del comportamiento. El despachador de rutinas está configurado, en respuesta a la detección de la ocurrencia de un evento desencadenante, para seleccionar una rutina de código de bytes anti-malware para su ejecución a partir de una pluralidad de rutinas de código de bytes anti-malware según el evento desencadenante, la rutina de código de bytes anti-malware configurada para determinar si la ocurrencia del evento desencadenante es indicativa de malware. El evento desencadenante es causado por un proceso monitoreado que se ejecuta dentro del sistema cliente. La máquina virtual de traducción de código de bytes está configurada para ejecutar la rutina de código de bytes anti-malware, en donde la ejecución de la rutina de código de bytes anti-malware comprende traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador y ejecutar la secuencia de las instrucciones nativas de procesador. El motor de evaluación del comportamiento está configurado para determinar si el sistema cliente comprende malware según el resultado de la máquina virtual de traducción de código de bytes que ejecuta la rutina de código de bytes antimalware.
Según otro aspecto, un medio legible por ordenador no transitorio almacena una rutina de código de bytes antimalware, comprendiendo la rutina de código de bytes anti-malware ejecutable por una máquina virtual de traducción de código de bytes formada en un sistema cliente al menos un procesador de hardware, en donde ejecutar - la rutina de código de bytes anti-malware hace que al menos un procesador de hardware determine si la ocurrencia de un evento desencadenante dentro del sistema cliente es indicativa de malware. La ejecución de la rutina de código de bytes anti-malware comprende traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador y ejecutar la secuencia de instrucciones nativas de procesador. El sistema cliente comprende además un despachador de rutinas y un motor de evaluación del comportamiento. El despachador de rutinas está configurado, en respuesta a la detección de la ocurrencia del evento desencadenante, para seleccionar la rutina de código de bytes anti-malware de la pluralidad de rutinas de código de bytes según el evento desencadenante. El motor de evaluación del comportamiento está configurado para determinar si el sistema cliente comprende malware según el resultado de la máquina virtual de traducción de código de bytes que ejecuta la rutina de código de bytes anti-malware.
Breve descripción de los dibujos
Los aspectos y ventajas anteriores de la presente invención se comprenderán mejor al leer la siguiente descripción detallada y al hacer referencia a los dibujos en los que:
La Figura 1 muestra un sistema cliente ejemplar protegido contra amenazas a la seguridad informática (por ejemplo, malware) según algunas realizaciones de la presente invención.
La Figura 2 muestra una configuración de hardware ejemplar de un sistema informático cliente según algunas realizaciones de la presente invención.
La Figura 3 ilustra una estructura ejemplar de una aplicación de seguridad según algunas formas de realización de la presente invención.
La Figura 4 ilustra un flujo de ejecución ejemplar de un conjunto de procesos en un entorno Windows®. Las flechas continuas indican el flujo en ausencia de interceptores de eventos. Las flechas discontinuas indican modificaciones al flujo de ejecución, las modificaciones introducidas por una pluralidad de interceptores de eventos que operan según algunas realizaciones de la presente invención.
La Figura 5 muestra una secuencia ejemplar de etapas realizadas por la aplicación de seguridad para configurar la detección de malware según algunas realizaciones de la presente invención.
La Figura 6 muestra una rutina de código de bytes ejemplar según algunas realizaciones de la presente invención. La Figura 7 ilustra una secuencia ejemplar de etapas realizadas por el despachador de rutinas (Figura 3) según algunas realizaciones de la presente invención.
La Figura 8 muestra una secuencia ejemplar de etapas realizadas por el despachador de rutinas para procesar una cola de eventos según algunas realizaciones de la presente invención.
La Figura 9 muestra una secuencia ejemplar de etapas realizadas por la traducción de código de bytes VM (Figura 3) según algunas realizaciones de la presente invención.
La Figura 10 ilustra un proceso de actualización de software ejemplar según algunas realizaciones de la presente invención.
Descripción detallada de realizaciones preferidas
En la siguiente descripción, se entiende que todas las conexiones enumeradas entre estructuras pueden ser conexiones operativas directas o conexiones operativas indirectas a través de estructuras intermedias. Un conjunto de elementos incluye uno o más elementos. Se entiende que cualquier enumeración de un elemento se refiere al menos a un elemento. Una pluralidad de elementos incluye al menos dos elementos. A menos que se requiera lo contrario, cualquier etapa del método descrito no necesita realizarse necesariamente en un orden ilustrado particular. Un primer elemento (por ejemplo, datos) derivado de un segundo elemento abarca un primer elemento igual al segundo elemento, así como un primer elemento generado procesando el segundo elemento y opcionalmente otros datos. Tomar una determinación o decisión según un parámetro comprende tomar la determinación o decisión según el parámetro y opcionalmente según otros datos. A menos que se especifique lo contrario, un indicador de alguna cantidad/datos puede ser la cantidad/datos en sí, o un indicador diferente de la cantidad/datos en sí. La seguridad informática abarca la protección de los usuarios y el equipo contra el acceso no intencionado o no autorizado a los datos y/o hardware, contra la modificación no intencionada o no autorizada de datos y/o hardware, y contra la destrucción de datos y/o hardware. Un programa informático es una secuencia de instrucciones del procesador que lleva a cabo una tarea. Los programas informáticos descritos en algunas realizaciones de la presente invención pueden ser entidades o subentidades de software independientes (por ejemplo, subrutinas, bibliotecas) de otros programas informáticos. A menos que se especifique lo contrario, un proceso es una instancia de un programa informático, tal como una aplicación o una parte de un sistema operativo, y se caracteriza por tener al menos un hilo de ejecución y un espacio de memoria virtual asignado, en donde un contenido del respectivo espacio de memoria virtual incluye código ejecutable. El término plataforma se usa para indicar una configuración de hardware físico o virtualizado específico (por ejemplo, que comprende un modelo específico o familia de procesadores). Una plataforma virtual comprende hardware virtualizado, por ejemplo, un procesador virtualizado. El término código de bytes en la presente memoria se refiere a una codificación de múltiples plataformas de un programa informático, en el sentido de que las instrucciones de código de bytes pueden entregarse de forma idéntica a diferentes plataformas. A diferencia de las instrucciones de código de bytes, las instrucciones nativas de procesador comprenden instrucciones de una arquitectura de conjunto de instrucciones (ISA) específica para la plataforma física o virtual que ejecuta las respectivas instrucciones nativas de procesador. Los medios legibles por ordenador abarcan medios no transitorios tales como medios de almacenamiento magnéticos, ópticos y semiconductores (por ejemplo, discos duros, discos ópticos, memoria flash, DRAM), así como enlaces de comunicación tales como cables conductores y enlaces de fibra óptica. Según algunas realizaciones, la presente invención proporciona, entre otros, sistemas informáticos que comprenden hardware (por ejemplo, uno o más microprocesadores) programados para realizar los métodos descritos en la presente memoria, así como instrucciones de codificación de medios legibles por ordenador para realizar los métodos descritos en la presente memoria.
La siguiente descripción ilustra realizaciones de la invención a modo de ejemplo y no necesariamente a modo de limitación.
La Figura 1 muestra un conjunto ejemplar de objetos de software que se ejecutan en un sistema cliente 10 protegido contra amenazas a la seguridad informática según algunas realizaciones de la presente invención. El sistema cliente 10 puede representar un sistema informático (por ejemplo, un ordenador de usuario final, un servidor corporativo, etc.). Otros sistemas cliente 10 ejemplares incluyen dispositivos informáticos móviles (por ejemplo, ordenadores portátiles, tabletas), dispositivos de telecomunicaciones (por ejemplo, teléfonos inteligentes), dispositivos de entretenimiento digital (televisores, consolas de juegos, etc.), dispositivos informáticos portátiles (por ejemplo, relojes inteligentes) o cualquier otro dispositivo electrónico que tenga un procesador y una memoria, y requieren protección de seguridad informática.
En algunas realizaciones, un sistema operativo (OS) 30 comprende un software que proporciona una interfaz al hardware del sistema cliente 10, y actúa como anfitrión para un conjunto de aplicaciones 32a-c y 40 de software.
OS 30 puede comprender cualquier sistema operativo ampliamente disponible, tal como Windows®, MacOS®, Linux®, iOS® o Android®, entre otros. Las aplicaciones 32a-c representan genéricamente un software de usuario, que puede incluir, por ejemplo, procesamiento de texto, procesamiento de imágenes, base de datos, navegador y aplicaciones de comunicación electrónica, entre otros. En algunas realizaciones, una aplicación 40 de seguridad se ejecuta al mismo tiempo que las aplicaciones 32a-c y está configurada para determinar si algún software que se ejecuta en el sistema cliente 10 (incluyendo las aplicaciones 32a-c y OS 30) representa una amenaza para la seguridad informática. Por ejemplo, aplicación 40 puede detectar un malware (por ejemplo, virus, spyware, adware, etc.) que operan en el sistema cliente 10. La aplicación 40 puede configurarse además para borrar o de otra manera incapacitar tal software malicioso y para alertar a un usuario del sistema cliente 10 o un administrador del sistema. La aplicación 40 de seguridad puede ser un programa independiente o puede formar parte de un paquete de software que comprende, entre otros, componentes antimalware, anti-spam y anti-fraude. El funcionamiento de la aplicación 40 de seguridad se describe en detalle a continuación.
La Figura 2 ilustra una configuración de hardware ejemplar del sistema cliente 10, en donde el sistema cliente 10 es un sistema informático. Un experto en la técnica apreciará que la configuración de hardware de otros dispositivos tales como tabletas, teléfonos móviles, relojes inteligentes, etc., puede diferir de la configuración ilustrada, pero que la presente descripción puede adaptarse a tales dispositivos. El sistema cliente 10 comprende un conjunto de dispositivos físicos, incluyendo un procesador 12 de hardware, una unidad 14 de memoria, un conjunto de dispositivos 16 de entrada, un conjunto de dispositivos 18 de salida, un conjunto de dispositivos 20 de almacenamiento, y un conjunto de adaptadores 22 de red, todo interconectado por un concentrador 24 de controlador .
En algunas realizaciones, el procesador 12 comprende un dispositivo físico (por ejemplo, microprocesador, circuito integrado de múltiples núcleos formado sobre un sustrato semiconductor) configurado para ejecutar operaciones lógicas y/o computacionales con un conjunto de señales y/o datos. En algunas realizaciones, tales operaciones lógicas se transmiten al procesador 12 desde la unidad 14 de memoria, en forma de una secuencia de instrucciones del procesador (por ejemplo, código de máquina u otro tipo de software). La unidad 14 de memoria puede comprender medios legibles por ordenador volátiles (por ejemplo, RAM) que almacenan datos/señales a los que se accede o generados por el procesador 12 en el curso de la realización de instrucciones. Los dispositivos 16 de entrada pueden incluir teclados, ratones y micrófonos de ordenador, entre otros, incluyendo las respectivas interfaces de hardware y/o adaptadores que permiten al usuario introducir datos y/o instrucciones en el sistema cliente 10. Los dispositivos 18 de salida pueden incluir dispositivos de visualización tales como monitores y altavoces, entre otros, así como interfaces/adaptadores de hardware tales como tarjetas gráficas, lo que permite al sistema cliente 10 comunicar datos a un usuario. En algunas realizaciones, los dispositivos 16 de entrada y los dispositivos 18 de salida pueden compartir una pieza común de hardware, como en el caso de los dispositivos de pantalla táctil. Los dispositivos 20 de almacenamiento incluyen medios legibles por ordenador que permiten el almacenamiento, la lectura y la escritura no volátiles de instrucciones y/o datos del procesador. Los dispositivos 20 de almacenamiento ejemplares incluyen discos ópticos y magnéticos y dispositivos de memoria flash, así como medios extraíbles tales como unidades y discos CD y/o DVD. El conjunto de adaptadores 22 de red habilita el sistema cliente 10 para conectarse a una red (por ejemplo, una red de área local, red inalámbrica, etc.) y/o a otros dispositivos/sistemas informáticos. El concentrador 24 de controlador representa genéricamente la pluralidad de buses de sistema, periféricos y/o conjuntos de chips, y/o todos los demás circuitos que permiten la comunicación entre el procesador 12 y los dispositivos 14, 16, 18, 20 y 22. Por ejemplo, el concentrador 22 de controlador puede comprender un procesador 12 de conexión de puente norte a la memoria 14, y/o un procesador 12 de conexión de puente sur a los dispositivos 16, 18, 20 y 22.
En algunas realizaciones, el sistema cliente 10 está configurado para operar una plataforma virtual (por ejemplo, una máquina virtual). Tales configuraciones pueden establecerse utilizando tecnología de virtualización de hardware, por ejemplo, un hipervisor. La plataforma virtual puede comprender componentes de hardware virtualizados, emulando cada uno de tales componentes virtualizados, al menos en parte, la funcionalidad de un componente de hardware correspondiente del sistema cliente. 10. Por ejemplo, una plataforma virtual puede incluir un procesador virtualizado, una unidad de memoria virtualizada y dispositivos de entrada/salida virtuales. El sistema operativo 30, así como las aplicaciones 32a-c y la aplicación 40 de seguridad, pueden ejecutarse en la plataforma virtual respectiva, interactuando con el hardware virtualizado. Se dice que el software se ejecuta en una plataforma virtual cuando emplea un procesador virtualizado de la plataforma respectiva para su ejecución.
La Figura 3 muestra componentes ejemplares de la aplicación 40 de seguridad según algunas realizaciones de la presente invención. La aplicación 40 de seguridad comprende un despachador 32 de rutinas, un motor 38 de evaluación del comportamiento y una máquina virtual 34 de traducción de código de bytes (BTVM) conectada al despachador 32 y motor 38 de evaluación. En algunas realizaciones, la aplicación 40 además comprende un módulo auxiliar 36 conectado a BTVM 34 y/o al motor 38 de evaluación. El despachador 32 de rutinas puede administrar aún más una cola 31 de eventos, como se detalla más abajo.
En algunas realizaciones, el despachador 32 de rutinas recibe un conjunto de notificaciones 42 de eventos de un conjunto de interceptores 28a-c de eventos instalado dentro de diferentes objetos de software que se ejecutan en el sistema cliente 10. Las notificaciones 42 de eventos pueden así informar al despachador 32 sobre la ocurrencia de diferentes eventos durante la ejecución del software. Los eventos notificados ejemplares pueden incluir, entre otros, la creación de un proceso o hilo, inyección de código, una llamada al sistema, un intento de crear un nuevo archivo de disco, un intento de escribir en un archivo de disco existente, un intento de editar una clave de registro del sistema, y un intento de escribir en una sección de memoria particular. Algunos de los eventos notificados pueden ser indicativos de malware. Es posible que otros eventos no sean en sí mismos indicativos de una amenaza a la seguridad, pero pueden indicar una amenaza potencial cuando ocurren junto con otros eventos. En respuesta a la recepción de la(s) notificación(es) 42, algunas realizaciones del despachador 32 pueden seleccionar una rutina de código de bytes según los detalles de la notificación 42, y enviar la rutina de código de bytes respectiva a la VM 34 de traducción de código de bytes para su ejecución, junto con un conjunto de parámetros 47 de eventos del evento notificado. La ejecución de la rutina de código de bytes respectiva puede proporcionar un indicador 50 de evaluación al motor 38 de evaluación del comportamiento. El motor 38 puede mantener una pluralidad de tales indicadores de evaluación (por ejemplo, puntuaciones), y puede generar una alerta cuando al menos uno de tales indicadores indica una amenaza a la seguridad informática. El funcionamiento de los componentes 32, 34, y 38 se describe en detalle a continuación.
Para ilustrar el funcionamiento de los interceptores 28a-c de eventos, la Figura 4 muestra un flujo de ejecución ejemplar de un conjunto de entidades 60a-b de software según algunas formas de realización de la presente invención. Por simplicidad, las entidades 60a-b elegidas son procesos que se ejecutan en una instancia de un sistema operativa Windows®; se pueden representar diagramas similares para otros sistemas operativos tales como Linux, por ejemplo. Las flechas continuas representan el flujo de ejecución en ausencia de interceptores de eventos. Las flechas discontinuas representan modificaciones en el flujo debido a la presencia de interceptores 28a-c de eventos que se ejecutan según algunas realizaciones de la presente invención.
El proceso ejemplar 60a carga una pluralidad de bibliotecas vinculadas dinámicamente (DLL) 62a-c; en el ejemplo de la Figura 4, DLL 62c se inyecta en el proceso 60a mediante el proceso 60b (posiblemente malicioso). Cuando el proceso 60a (o una de sus DLL cargadas) ejecuta una instrucción que solicita alguna funcionalidad del sistema, por ejemplo, para escribir algo en un archivo de disco, o para editar una clave de registro, la instrucción respectiva llama a una API en modo usuario tal como KERNEL32.DLL o NTDLL.DLL. En el ejemplo de la Figura 4, la respectiva llamada API en modo usuario es interceptada por un interceptor 28a de eventos a nivel de usuario. Tales intercepciones se pueden lograr mediante un método tal como la inyección de DLL o el enganche, entre otros. El enlace es un término genérico utilizado en la técnica para un método de interceptar llamadas a funciones, mensajes o eventos que se transmiten entre componentes de software. Un método de enlace ejemplar comprende alterar el punto de entrada de una función objetivo, insertando una instrucción (en este caso, el interceptor 28a de eventos) volviendo a direccionar la ejecución a una segunda función. Después de dicho enlace, la segunda función se puede ejecutar en lugar o antes de la función objetivo. En el ejemplo de la Figura 4, la aplicación 40 de seguridad puede enlazarse a ciertas funciones de las bibliotecas KERNEL32.DLL y/o NTDLL.DLL, para instruir a las funciones respectivas para volver a dirigir la ejecución a un componente de la aplicación 40. Por lo tanto, la aplicación 40 puede ser notificada cada vez que el proceso 60a está intentando realizar una acción en particular, identificada según la función enlazada.
En un flujo típico de ejecución, la función API en modo usuario llamada por la entidad 60a puede solicitar servicio desde el núcleo del sistema operativo. En algunas realizaciones, tales operaciones se llevan a cabo emitiendo una llamada al sistema, tal como SYSCALL y SYSENTER en plataformas x86. En el ejemplo de la Figura 4, tales llamadas al sistema son interceptadas por el interceptor 28b de eventos. En algunas realizaciones, tal interceptación comprende, por ejemplo, modificar una rutina del operario informático de llamadas al sistema cambiando un valor almacenado en un registro específico del modelo (MSR) del procesador 12, que vuelve a dirigir efectivamente la ejecución de la rutina del operario informático respectivo al interceptor 28b o directamente a un componente de la aplicación 40. Tales técnicas se conocen en la técnica como enlace MSR y pueden permitir que la aplicación 40 de seguridad sea notificada siempre que una entidad de software esté intentando realizar ciertas llamadas al sistema.
Después de la llamada al sistema, el control del procesador generalmente se entrega al núcleo del sistema operativo 30. En algunas realizaciones, un interceptor 28c de eventos a nivel del núcleo está configurado para interceptar ciertas acciones del núcleo l del sistema operativo y, por lo tanto, determinar que el proceso evaluado está intentando realizar ciertas operaciones, que pueden ser indicativas de malware. Para interceptar tales acciones, algunas realizaciones pueden emplear un conjunto de mecanismos de filtrado integrados y expuestos por el sistema operativo 30. Por ejemplo, en un sistema operativo Windows®, FltRegisterFilter se puede utilizar para interceptar operaciones como crear, abrir, escribir y eliminar un archivo. En otro ejemplo, el interceptor 28c de eventos puede usar ObRegisterCallback para interceptar la creación o duplicación de operaciones de manejo de objetos, o PsSetCreateProcessNotifyRoutine para interceptar la creación de nuevos procesos. Aún en otro ejemplo, las operaciones de registro de Windows, tales como la creación y configuración de claves/valores de registro, pueden interceptarse mediante CmRegisterCallbackEx. Se conocen en la técnica mecanismos de filtrado de eventos similares para otros sistemas operativos tales como Linux®. En respuesta a la detección de la ocurrencia de un evento/acción particular, el interceptor 28 de eventos puede transmitir notificación(es) 42 a la aplicación 40 de seguridad.
La Figura 5 muestra una secuencia ejemplar de etapas realizadas por la aplicación 40 de seguridad para configurar la detección de amenazas a la seguridad informática según algunas realizaciones de la presente invención. La secuencia ilustrada de etapas se puede ejecutar, por ejemplo, cuando la aplicación 40 de seguridad es lanzada. En una etapa 102, la aplicación 40 instala interceptores 28a-c de eventos, por ejemplo, enlazando diferentes funciones del sistema operativo 30, modificando una entrada de una tabla de despacho, etc. En la técnica se conocen diferentes métodos para instalar tales interceptores (por ejemplo, parcheo, enlace de MSR, inyección de código, etc.). Una etapa 104 configura la cola 31 de eventos, utilizada por algunas realizaciones del despachador de rutinas para almacenar información sobre eventos notificados y el orden en que tales eventos han ocurrido. En algunas formas de realización, la cola 31 de eventos está organizada como una cola de primero en entrar, primero en salir (FIFO). Una cola 31 ejemplar puede ser una cola enlazada simple, sin bloqueo, de múltiples productores y de múltiples consumidores.
Una secuencia de etapas 106-108 accede a una base de datos 26 de rutina (véase, por ejemplo, la Figura 3) y carga un conjunto de rutinas de código de bytes de la base de datos 26 en una sección de la memoria. La base de datos 26 puede residir en dispositivos 20 de almacenamiento del sistema cliente 10 o en medios legibles por ordenador acoplados comunicativamente al sistema cliente 10.
En algunas realizaciones, cada rutina de código de bytes almacenada en la base de datos 26 comprende un conjunto de instrucciones de código de bytes, que, cuando son ejecutadas por BTVM 34, hacen que BTVM 34 realice una tarea específica relacionada con la seguridad informática. Una rutina de código de bytes ejemplar aplica un conjunto de pruebas heurísticas para determinar si un objeto de software en particular (o grupo de objetos) es malicioso. Otro ejemplo de la rutina de código de bytes verifica la ocurrencia de una secuencia particular de eventos (una firma de comportamiento) en el sistema cliente 10. No todos los eventos de la secuencia deben ser causados por la misma entidad. Sin embargo, la ocurrencia de tal secuencia de eventos puede ser indicativa de malware. En uno de tales ejemplos, las actividades maliciosas se dividen entre un grupo de entidades, llevando a cabo cada miembro del grupo una pequeña parte de las actividades maliciosas. Por lo tanto, una rutina de código de bytes configurada para correlacionar eventos correspondientes a tales actividades distribuidas puede detectar un grupo completo de entidades maliciosas.
Otras rutinas de código de bytes ejemplares realizan tareas de contabilidad y/o estadísticas (por ejemplo, contar eventos, relacionar parámetros de eventos). Otras rutinas de código de bytes pueden alterar la manera en la que el software y/o un usuario del sistema cliente 10 interactúa con el sistema operativo 30 y/o dispositivos de hardware (por ejemplo, una rutina puede evitar que un objeto de software escriba en el disco o acceda a adaptadores 22 de red). Cada rutina de código de bytes puede incorporar un método de detección y/o heurístico distintos. En algunas realizaciones, cada rutina de código de bytes puede configurarse para detectar la presencia de una categoría, familia, tipo o variante particular de agente malicioso. Varias rutinas distintas pueden colaborar en la detección de una sola categoría, familia, tipo o variante de agente malicioso. En algunas realizaciones, una sola rutina puede participar en la detección de varias categorías, tipos, familias o variantes de malware.
La Figura 6 muestra una rutina 70 de código de bytes ejemplar según algunas realizaciones de la presente invención. La rutina 70 comprende un indicador 72 de desencadenante y una sección 74 de código de bytes. En algunas realizaciones, el indicador 72 de desencadenante codifica una o más condiciones para ejecutar la rutina de código de bytes respectiva. La(s) condición(es) respectivas pueden ser evaluadas por el despachador 32 de rutinas y/o BTVM 34 para determinar si la rutina de código de bytes respectiva debería ejecutarse en respuesta a la detección de la ocurrencia de un tipo particular de evento. Una condición ejemplar requiere determinar si una expresión desencadenante particular se evalúa como VERDADERA o FALSA y determinar que la condición se satisface cuando la expresión es VERDADERA. En algunas realizaciones, la expresión desencadenante respectiva comprende un indicador de un tipo de evento (por ejemplo, creación de proceso, una llamada al sistema específica, etc.). La expresión desencadenante puede comprender además parámetros de eventos, tales como una ruta, un nombre de archivo, un ID de proceso, etc. En algunas realizaciones, las expresiones de activación pueden comprender variables utilizadas por BTVM 34 y/o despachador 32 de rutinas (véase el ejemplo a continuación).
El indicador 72 de desencadenante puede comprender además una bandera que indica si la sección respectiva de rutina/código de bytes debería ejecutarse de manera sincrónica o asincrónica. El término sincrónico se utiliza en la presente memoria para indicar una manera de ejecutar una rutina de código de bytes en donde la ejecución del proceso que genera el evento que desencadenó la ejecución de la rutina respectiva (en la presente memoria se considera proceso desencadenante, para simplificar) se suspende mientras se ejecuta la rutina respectiva. Algunas realizaciones utilizan un contexto de ejecución de hilo del proceso desencadenante para ejecutar la rutina de código de bytes respectiva, que suspende implícitamente la ejecución del proceso desencadenante, o al menos de un hilo del proceso respectivo, durante la ejecución de la rutina. La suspensión y/o reanudación de la ejecución del proceso desencadenante puede ser efectuada por el interceptor del evento respectivo. Por ejemplo, el interceptor 28a-c puede secuestrar el hilo del proceso desencadenante y/o reanudar la ejecución del proceso desencadenante solo en respuesta a una señal del despachador 32 de rutinas. A diferencia de la ejecución sincrónica, la ejecución asincrónica se refiere a una forma de ejecutar una rutina de código de bytes en donde se permite que el proceso desencadenante continúe la ejecución, mientras que el evento que desencadenó la notificación se inserta en una cola de eventos para su procesamiento posterior. Tener un indicador de sincronía asociado a cada rutina o sección de código de bytes puede ayudar al despachador 32 de rutinas para determinar cómo manejar las notificaciones de eventos (se dan más detalles a continuación).
En algunas realizaciones, la sección 74 de código de bytes comprende una sucesión de instrucciones 74a-c de código de bytes instruyendo a BTVM 34 para realizar la tarea de seguridad informática asociada con la rutina 70. En algunas realizaciones, cada instrucción de código de bytes es una instrucción nativa de un procesador virtual de BTVM 34. En una realización ejemplar, BTVM 34 es una máquina virtual Java® e instrucciones 74a-c de código de bytes son instrucciones del lenguaje Java®. Para que el procesador 12 de hardware ejecute una instrucción de código de bytes, la instrucción de código de bytes respectiva primero se traduce (interpreta o compila) en una secuencia de instrucciones nativas de procesador, por ejemplo, en instrucciones de una arquitectura de conjunto de instrucciones (ISA) del procesador 12. Dichas traducciones son realizadas, al menos en parte, por BTVM 34.
Cuando la aplicación 40 de seguridad se ejecuta en una plataforma virtual, BTVM 34 puede traducir cada instrucción de código de bytes en una secuencia de instrucciones nativas de procesador del procesador virtual de la plataforma virtual respectiva.
Un conjunto de instrucciones de código de bytes ejemplar puede comprender, entre otras, instrucciones de código de bytes para establecer valores, comparar valores, realizar saltos, instrucciones de bucle e instrucciones para llamar a funciones externas (tales como funciones del módulo auxiliar 36 en la Figura 3). En algunas realizaciones, cada instrucción de código de bytes incluye un campo de código 76 de código de operación indicativo de una operación y un campo 78 de operando indicativo de al menos un operando.
Algunas rutinas de código de bytes pueden tener una pluralidad de secciones, en donde cada sección puede tener un indicador de desencadenante distinto. En tales configuraciones, cada sección de la rutina puede desencadenarse por una condición distinta. En uno de tales ejemplos, la rutina 70 de código de bytes puede tener como objetivo la detección de ransomware (“cibersecuestro de datos”), es decir, software malintencionado que cifra los archivos de un usuario y le pide al usuario que pague un rescate antes de descifrar los archivos respectivos. Ejemplos de ransomware incluyen el malware CryptoWall, CryptoLocker y CTB-Locker, entre otros. Tal malware normalmente llama a una API de cifrado, enumera los archivos del usuario y muestra un mensaje de rescate. Una rutina de código de bytes ejemplar que detecta tal malware puede incluir cuatro secciones:
Sección 1: Desencadenar: EventType = llamada a una función criptográfica
Salida: establecer la variable estática CryptoAPICall = TRUE
Sección 2: Desencadenar: [EventType = enumerar archivos usando FindFirstFile API y CryptoAPICall =
TRUE]
Hacer: Verificar la extensión de archivo de los archivos enumerados
Salida: establecer la variable estática RansomDocSearch = TRUE si los archivos enumerados tienen extensiones PDF, DOCX, JPG, ...
Sección 3: Desencadenar: [EventType = intentar escribir en un archivo de disco y RansomDocSearch =
TRUE]
Hacer: determinar si el archivo está entre los archivos enumerados
Salida: establecer RansomActivity = TRUE y aumentar la puntuación de evaluación en 30 puntos
Sección 4: Desencadenar: [EventType = cambiar de fondo de pantalla y RansomActivity = TRUE]
Salida: aumentar la puntuación de evaluación en 20 puntos
En el ejemplo anterior, la Sección 2 se puede ejecutar solo cuando la Sección 1 se ha ejecutado al menos una vez, la Sección 3 se puede ejecutar solo cuando la Sección 2 se ha ejecutado, etc.
En algunas realizaciones, cada rutina de código de bytes comprende además una sección de inicialización, una sección de limpieza y una sección de error. La sección de inicialización puede comprender inicializaciones variables y puede ejecutarse una vez, cuando la rutina de código de bytes respectiva se carga en la memoria (por ejemplo, en la etapa 108 en la Figura 5). La sección de limpieza se puede ejecutar al finalizar la rutina respectiva. La sección de error puede comprender instrucciones ejecutadas en caso de que ocurra un error durante la ejecución de cualquier otra sección de la rutina de código de bytes respectiva.
En algunas realizaciones, en una etapa 110 (La Figura 5), la aplicación 40 de seguridad puede analizar las rutinas de código de bytes cargadas y crear un indicador de asociación (por ejemplo, una tabla o un índice hash) que indique una asociación entre los tipos de eventos y las rutinas de código de bytes desencadenadas por los tipos de eventos respectivos. Tal asociación permite al despachador 32 de rutinas seleccionar rutinas para su ejecución en respuesta a la detección de la ocurrencia de ciertos eventos.
La Figura 7 muestra una secuencia ejemplar de etapas realizadas por el despachador 32 de rutinas según algunas realizaciones de la presente invención. Una secuencia de etapas 112-114 escucha las notificaciones de eventos de los interceptores 28a-c. En respuesta a la recepción de la notificación 42 de eventos, una etapa 116 determina un conjunto de parámetros 47 de evento del evento notificado respectivo. Tales parámetros pueden ser específicos de un evento. Algunos parámetros de eventos ejemplares incluyen, entre otros, un identificador de un proceso o hilo (por ejemplo, ID de proceso) que realiza la acción notificada, un nombre de archivo, una ruta, una dirección de memoria y un operando de una instrucción de procesador. Los parámetros de evento pueden ser determinados por interceptores 28a-c e incluidos en la notificación 42 de eventos, o pueden ser determinados por el despachador 32 de rutina en respuesta a la recepción de la notificación 42. En un ejemplo en donde el evento notificado es un intento de crear un nuevo archivo de disco, los parámetros de evento pueden incluir el nombre del archivo que se está creando. El interceptor de eventos puede determinar el nombre de archivo respectivo y transmitirlo al despachador 32 de rutinas como parte de la notificación 42. En otro ejemplo, la identidad de un proceso que realiza una acción particular puede ser determinada directamente por el despachador 32 de rutina, por ejemplo, analizando una estructura de datos utilizada por el sistema operativo 30 para gestionar los procesos actualmente en ejecución. En el sistema operativo Windows®, cada proceso se representa como un bloque de proceso ejecutivo (EPROCESS), que comprende, entre otros, cuadritos para cada uno de los hilos del proceso respectivo, y un ID de proceso único que permite al sistema operativo 30 identificar el proceso respectivo de una pluralidad de procesos en ejecución. Hay disponibles representaciones de procesos/hilos similares para otros sistemas operativos, tales como Linux.
La ocurrencia de ciertos eventos puede requerir la ejecución sincrónica de una rutina de código de bytes asociada. Ejemplos de tales eventos incluyen, entre otros, eventos con consecuencias sustanciales y/o irreversibles para el sistema cliente respectivo, tales como la terminación de un proceso, la eliminación de un archivo y la eliminación de una clave de registro. Para gestionar la ejecución sincrónica, algunas realizaciones del despachador 32 de rutinas pueden mantener una lista de tuplas <evento, rutina>, en donde cada tupla indica que la rutina respectiva debería ejecutarse sincrónicamente en respuesta a la ocurrencia del evento respectivo. Tales tuplas pueden ser estáticas, por ejemplo, algunas rutinas (o secciones de una rutina) se ejecutan necesariamente de manera sincrónica cada vez que se produce el desencadenante respectivo. Las tuplas estáticas pueden identificarse, por ejemplo, según un valor de una bandera de sincronía asociada a la rutina/sección respectiva (véase más arriba). Otras tuplas <evento, rutina> pueden ser situacionales, es decir, pueden estar en efecto solo en ciertas circunstancias. Tales tuplas se pueden añadir y/o eliminar dinámicamente de la lista, por ejemplo, en respuesta a la ocurrencia de otros eventos, etc. En algunas realizaciones, la lista de <evento, rutina> tuplas registradas para procesamiento sincrónico puede variar según un conjunto de opciones indicadas por un usuario (por ejemplo, administrador) del sistema cliente respectivo. En general, el procesamiento/ejecución sincrónico de rutinas de código de bytes puede ofrecer una mayor seguridad, pero puede afectar negativamente a la experiencia del usuario al ralentizar algunas tareas. Los diferentes usuarios pueden preferir diferentes configuraciones de seguridad. En algunas realizaciones, cada configuración (por ejemplo, nivel de seguridad deseado) puede corresponder a una composición distinta de la lista de <evento, rutina>.
En una etapa 120, el despachador 32 de rutinas determina si la ocurrencia del evento desencadenante indicado por la notificación de evento actual justifica el procesamiento sincrónico, por ejemplo determinando si hay al menos una tupla de <evento, rutina> que comprende el evento respectivo. La determinación en la etapa 120 puede proceder además según el tipo de evento respectivo, según una bandera de sincronización de la notificación 42, o según un indicador de desencadenante de una rutina de código de bytes.
Cuando la ocurrencia del evento respectivo no requiere procesamiento sincrónico, en una etapa 122, el despachador 32 de rutinas inserta el evento respectivo en la cola 31 de eventos. Otra etapa 124 señala al interceptor(es) 28a-c para reanudar la ejecución del proceso/hilo provocando la notificación del evento respectivo.
Cuando la ocurrencia del evento notificado actualmente requiere procesamiento sincrónico, en una etapa 126, el despachador 32 de rutinas selecciona una rutina de código de bytes según el evento respectivo. La etapa 126 puede incluir identificar un subconjunto de rutinas de código de bytes asociadas con el tipo de evento actual y evaluar las condiciones desencadenantes de cada una de tales rutinas. Una etapa 130 comprende el lanzamiento de una instancia de BTVM 34 instanciado con la rutina de código de bytes respectiva. Algunas realizaciones utilizan el hilo de ejecución del proceso desencadenante para ejecutar la instancia respectiva de BTVM 34. Cuando la etapa 126 identifica más de una rutina de código de bytes desencadenada por la notificación del evento actual, la secuencia de etapas 128-130 se puede volver a ejecutar para cada una de tales rutinas.
En algunas realizaciones, en una etapa 132, el despachador 32 de rutinas espera una respuesta del motor 38 de evaluación del comportamiento y/o BTVM 34 indicando un resultado de una evaluación de seguridad del proceso que provoca la notificación 42. La evaluación puede indicar, por ejemplo, si el proceso respectivo es malicioso. En una realización alternativa, en la etapa 132, el despachador 32 puede esperar hasta que BTVM 34 ha terminado de ejecutar la rutina de código de bytes actual. Cuando la rutina respectiva ha terminado de ejecutarse y/o se completa la evaluación de seguridad, el despachador 32 puede señalar al interceptor(es) 28a-c de eventos para reanudar la ejecución del proceso que provoca la notificación 42 de eventos.
La Figura 8 ilustra una secuencia ejemplar de etapas llevadas a cabo por el despachador 32 de rutinas para procesar la cola 31 de eventos según algunas realizaciones de la presente invención. Una secuencia de etapas 142­ 144 espera hasta que la cola 31 contiene al menos un elemento. Una etapa 146 elimina un evento de la cola. Cuando cola 31 es del tipo FIFO, los eventos se eliminan en el orden en que se insertaron. En una etapa 148, el despachador 32 de rutinas evalúa las condiciones de activación según el tipo y/o los parámetros del evento, para identificar un subconjunto de rutinas de código de bytes desencadenadas por el evento respectivo. En una secuencia de etapas 150-152-154, el despachador 32 selecciona cada una de tales rutinas y las envía para su ejecución a BTVM 34.
La Figura 9 muestra una secuencia ejemplar de etapas realizadas por una máquina virtual 34 de traducción de código de bytes al ejecutar una rutina de código de bytes. En algunas realizaciones, BTVM 34 comprende una emulación de software de un sistema informático, que comprende un procesador virtual, una memoria virtual y un conjunto de registros virtuales. El procesador virtual de BTVM 34 considera las instrucciones de código de bytes como su conjunto de instrucciones nativas. Sin embargo, dado que las instrucciones de código de bytes no son instrucciones nativas de la plataforma, esa aplicación 40 de seguridad se ejecuta, la ejecución de instrucciones de código de bytes incluye traducir cada instrucción de código de bytes en una secuencia de instrucciones nativas de procesador del procesador de la plataforma respectiva. En algunas realizaciones, BTVM 34 comprende un intérprete de código configurado para interpretar y ejecutar instrucciones de código de bytes una por una. En una forma de realización alternativa, BTVM 34 puede incluir un compilador Just-In-Time (JIT) configurado para compilar todas las instrucciones de una rutina de código de bytes juntas en una rutina nativa de código. La rutina nativa de código compilada se ejecuta luego como un todo. En algunas realizaciones, BTVM 34 comprende una biblioteca de funciones (por ejemplo, clases) codificadas en el conjunto de instrucciones nativas del procesador 12, en donde cada tipo de instrucción de código de bytes corresponde a una función distinta de dicha biblioteca. En tales casos, interpretar una instrucción de código de bytes puede comprender identificar la función apropiada según la instrucción de código de bytes y ejecutar la función respectiva. Las máquinas virtuales de traducción de código de bytes ejemplares incluyen las máquinas virtuales Java® y Lua®, entre otras.
En algunas realizaciones, el espacio de memoria virtual de BTVM 34 se divide en varias regiones, almacenando cada región un tipo distinto de variables. Algunas variables pueden ser de tipo LOCAL; los valores de tales variables pueden ser únicos para la instancia actual de la rutina respectiva o sección de código de bytes. Otras variables pueden ser de tipo ESTÁTICO (dedicadas a un tipo de rutina en particular, compartidas en todas las secciones de código de una rutina de ese tipo en particular, manteniendo su valor en múltiples instancias de la misma sección de rutina/código de bytes). Otras variables pueden ser de tipo GLOBAL (compartidas en todas las rutinas e instancias de código de bytes). Algunas realizaciones de BTVM 34 también pueden operar con variables de tipo PROCESO -estas variables pueden estar unidas de manera única a una tupla de proceso de rutina, compartidas en todas las secciones de código de una rutina de ese tipo particular, manteniendo su valor en múltiples instancias de la misma sección de rutina/código de bytes pero diferente de un proceso a otro. Cuando la memoria virtual de BTVM 34 está configurada para almacenar variables del tipo PROCESO, tales variables pueden inicializarse una vez para cada proceso que está siendo monitoreado por interceptores 28a-c de eventos, y borrado al finalizar el proceso respectivo.
En algunas realizaciones, la aplicación 40 de seguridad mantiene un grupo de hilos para uso de BTVM 34. En un ejemplo, el grupo de hilos comprende el mismo número de grupos que el recuento de CPU lógicas del procesador 12. Todos los hilos del grupo de hilos se pueden establecer en el mismo nivel de prioridad. Al despachar rutinas de código de bytes, el despachador 32 puede esperar al siguiente hilo disponible. Instancias distintas de BTVM 34 de este modo, puede ejecutarse de forma independiente y concurrente, en contextos de memoria arbitrarios. En algunas realizaciones, instancias de BTVM 34 pueden ejecutarse fuera de orden, es decir, no necesariamente en el mismo orden en que los eventos que los desencadenaron se insertaron en la cola 31 de eventos.
En respuesta a la recepción del indicador 46 de rutina (por ejemplo, una dirección de memoria de la rutina de código de bytes) del despachador 32 de rutinas, BTVM 34 puede acceder a la sección 74 de código de bytes. Sin pérdida de generalidad, las siguientes etapas ilustradas describen una realización en donde BTVM 34 interpreta y ejecuta cada instrucción de código de bytes por turno. Un experto en la técnica apreciará que la presente descripción se puede adaptar para describir el funcionamiento de una realización que utiliza la compilación justo a tiempo (JIT). En una secuencia de etapas 166-168, BTVM 34 puede interpretar una instrucción de código de bytes y ejecutar un conjunto de operaciones indicadas por la instrucción respectiva.
Algunas instrucciones de código de bytes requieren una funcionalidad compleja, por ejemplo, la funcionalidad ofrecida por una función del sistema operativo 30. Para mantener la complejidad de BTVM 34 al mínimo y para reducir la superficie de ataque de BTVM 34, algunas realizaciones proporcionan tal funcionalidad a BTVM 34 a través de una interfaz de programa de aplicación (API) incorporada como módulo auxiliar 36 (Figura 3). El Módulo 36 puede comprender un conjunto de funciones auxiliares configuradas para ayudar a BTVM 34, realizando tareas tales como verificar la existencia de un archivo, intentar hacer coincidir el contenido de una sección de memoria con una firma indicativa de malware, enumerar archivos y establecer puntuaciones de evaluación, entre otras. Cuando la instrucción de código de bytes actual llama a una función auxiliar, en una etapa 170, la traducción VM 34 de código de bytes emite una llamada API 48 al módulo auxiliar 36. El módulo auxiliar 36 puede interactuar aún más con el sistema operativo 30.
En algunas realizaciones, el módulo auxiliar 36 puede tener la funcionalidad para añadir nuevos eventos a la cola 31 de eventos, en respuesta a una llamada API desde la VM 34 de traducción de códigos de bytes (véase, por ejemplo, la Figura 3). En tal ejemplo, una primera parte de una rutina de código de bytes se procesa sincrónicamente. BTVM 34 luego puede hacer que una segunda parte de la rutina respectiva se ejecute más tarde (de manera asincrónica) llamando al módulo auxiliar 36 para añadir un nuevo evento a la cola 31, el nuevo evento elegido para desencadenar la ejecución de la segunda parte de la rutina. En otro ejemplo, el mecanismo descrito puede usarse para ejecutar una cascada de rutinas de código de bytes, en donde cada rutina determina la ejecución del siguiente miembro de la cascada instruyendo al módulo auxiliar 36 para insertar un nuevo evento en la cola 31 de eventos.
Algunas rutinas de código de bytes generan un indicador 50 de evaluación al motor 38 de evaluación del comportamiento, por ejemplo, a través de una llamada API al motor 38 o al módulo auxiliar 36. El indicador 50 de evaluación puede incluir puntuaciones de evaluación indicativos de la probabilidad de que un objeto monitoreado particular (por ejemplo, un proceso) sea malicioso. Otro indicador 50 de evaluación ejemplar comprende añadir un incremento de puntuación a una puntuación de evaluación mantenida para el objeto respectivo por el motor 38 de evaluación. Otro indicador ejemplar 50 incluye un veredicto (por ejemplo, limpio/malicioso). En algunas realizaciones, una secuencia de etapas 174-176 determina si se cumple una condición de evaluación (por ejemplo, si se ha calculado un incremento de puntuación) y, en caso afirmativo, transmite el indicador 50 al motor 38 de evaluación.
Una etapa 178 puede verificar si se satisface una condición de terminación, y cuando no, BTVM 34 puede avanzar a la siguiente instrucción de código de bytes de la rutina actual (véase la etapa 166 más arriba). En algunas realizaciones, la etapa 178 puede comprender determinar si se ha ejecutado la última instrucción de código de bytes de la sección de rutina/sección de código de bytes actual. Algunas rutinas de código de bytes pueden configurarse para ejecutarse durante un período máximo de tiempo; en tales casos, la etapa 178 puede determinar si el período de tiempo máximo permitido ha transcurrido desde que se lanzó la rutina/sección de código de bytes actual en ejecución. Puede satisfacerse otra condición de terminación ejemplar siempre que se produzca un error durante la ejecución de la rutina/sección de código de bytes respectiva. Cuando se satisface la condición de terminación, una etapa 180 puede terminar la instancia actual de BTVM 34 y liberar el hilo respectivo en el grupo de hilos.
En algunas realizaciones, el motor 38 de evaluación del comportamiento mantiene una base de conocimiento centralizada de entidades de software monitoreadas, tales como procesos e hilos que se ejecutan en el sistema cliente 10. Para cada entidad, el motor 38 puede almacenar un indicador de filiación (por ejemplo, para indicar las relaciones entre padres e hijos, las relaciones entre los procesos que inyectan código y los destinatarios de dichas inyecciones de código, etc.). Algunas realizaciones del motor 38 de evaluación almacenan además un conjunto de puntuaciones de evaluación asociadas a cada entidad monitoreada. Cada una de tales puntuaciones puede determinarse según un criterio distinto (por ejemplo, cada puntuación se actualiza mediante una rutina de código de bytes específica). En algunas realizaciones, el motor 38 de puntuación está configurado para determinar según dichas puntuaciones si cada entidad monitoreada representa una amenaza para la seguridad informática. Cuando se identifica tal amenaza, el motor 38 puede tomar medidas anti-malware contra la entidad maliciosa respectiva, por ejemplo, para detener la ejecución o para incapacitar de otra manera el objeto de software respectivo. El motor 38 puede alertar además a un usuario del sistema cliente 10 y/o un administrador del sistema.
Los sistemas y métodos ejemplares descritos anteriormente permiten proteger un sistema cliente contra amenazas a la seguridad informática, tales como malware y spyware. Para cada una de una pluralidad de entidades ejecutables, tales como procesos e hilos que se ejecutan actualmente en el sistema cliente, una aplicación de seguridad mantiene un conjunto de puntuaciones de evaluación, que pueden indicar la probabilidad de que la entidad respectiva represente una amenaza. En algunas realizaciones, tales puntuaciones se producen en respuesta a la ejecución de una pluralidad de rutinas de detección, cada rutina configurada para evaluar una entidad monitoreada según criterios específicos de cada rutina de detección. Las rutinas de detección pueden implementar diferentes heurísticas de seguridad informática; las rutinas separadas pueden corresponder a distintas heurísticas. Por ejemplo, una rutina puede determinar si una entidad monitoreada realiza una secuencia de acciones indicativa de malware, conocida en la técnica como firma de comportamiento. La ejecución de las rutinas de detección se puede desencadenar de forma selectiva, en respuesta a la detección de la aparición de eventos desencadenantes específicos.
En algunas realizaciones de la presente invención, las rutinas de detección se formulan en código de bytes, es decir, utilizando un conjunto personalizado de instrucciones que no son fácilmente ejecutables por el procesador del sistema cliente respectivo. En cambio, las rutinas de detección se ejecutan dentro de una máquina virtual de traducción de código de bytes, que utiliza técnicas de interpretación o compilación justo a tiempo para traducir cada rutina de código de bytes en un conjunto de instrucciones nativas de procesador del procesador de la plataforma respectiva, antes de ejecutar las instrucciones respectivas.
En los sistemas de seguridad informática convencionales, las rutinas de detección normalmente se compilan previamente en el código nativo de la plataforma objetivo y se empaquetan junto con el resto de los componentes de una aplicación de seguridad. Aunque tales configuraciones permiten una ejecución rápida y optimizada de las rutinas de detección respectivas, pueden ser difíciles de desarrollar, mantener actualizadas y desplegar en los sistemas informáticos de cliente. Por ejemplo, cualquier pequeño cambio en una rutina de detección, o la introducción de una nueva rutina/heurística de detección, puede requerir una nueva compilación de una gran parte del código de la aplicación de seguridad y el despliegue de una actualización de software relativamente grande (por ejemplo, varios megabytes). Además, un error de software en la actualización puede provocar la caída de toda la aplicación de seguridad, por lo que las actualizaciones suelen requerir pruebas exhaustivas antes de entregarse a los clientes.
Por el contrario, el uso de rutinas de detección de códigos de bytes permite que algunas realizaciones de la presente invención acorten sustancialmente el tiempo de comercialización de la solución de seguridad, así como también simplifiquen el proceso de actualización del software. Dado que las rutinas de detección de códigos de bytes se interpretan o compilan sobre la marcha, se pueden desarrollar y entregar a los clientes por separado de los componentes principales de la solución de seguridad. Se pueden desarrollar e implementar nuevas heurísticas de detección de forma completamente independiente de las rutinas existentes. Como se muestra en la Figura 10, una actualización de software puede comprender solo un conjunto de rutinas 70 de código de bytes, que asciende a unos pocos cientos de bytes. Para activar las nuevas capacidades de detección, la(s) respectiva(s) rutina(s) de código de bytes pueden introducirse en la base de datos 26 de rutinas y posteriormente registrarse con el despachador 32 de rutinas. También, dado que cada rutina de detección se ejecuta dentro de una instancia de la máquina virtual de traducción de código de bytes y por separado de otros componentes de la aplicación de seguridad, se contiene un error o un error de software presente dentro de una rutina de código de bytes y es menos probable que afecte al funcionamiento de otro software.
Algunas realizaciones de la presente invención pueden usar una máquina virtual de traducción de código de bytes ampliamente disponible, tal como las máquinas virtuales Java® o Lua®, para lograr la interpretación y/o compilación JIT de rutinas de detección. Sin embargo, para minimizar la complejidad de la arquitectura y reducir la superficie de ataque de la máquina virtual de traducción de códigos de bytes, algunas realizaciones emplean una máquina virtual de traducción personalizada dotada de una funcionalidad mínima. Cuando se requiere una funcionalidad más compleja dentro de una rutina de detección, algunas realizaciones proporcionan la funcionalidad requerida a través de una API auxiliar separada.
Dado que cada instancia de la máquina virtual de traducción de código de bytes puede ejecutarse dentro de un contexto de memoria independiente y separada, algunas realizaciones de la presente invención pueden ofrecer las mismas ventajas de seguridad que proporcionan, por ejemplo, el almacenamiento en contenedores. Otras ventajas de la presente invención incluyen la portabilidad. Si bien es posible que algunos componentes de la solución de seguridad propuesta deban compilarse por separado para cada tipo de dispositivo cliente (por ejemplo, sistema informático, teléfono inteligente, etc.), las rutinas de código de bytes son independientes de la plataforma en el sentido de que las rutinas de detección idénticas, incluyendo las actualizaciones, pueden ser entregadas a todas las plataformas y dispositivos cliente.
Tales ventajas de la presente invención pueden tener un coste de sobrecarga de memoria y velocidad de procesamiento. Si bien las soluciones previamente compiladas están optimizadas para un rendimiento máximo de una plataforma particular, la interpretación y/o compilación JIT de rutinas de detección pueden hacer que algunas realizaciones de la presente invención sean más lentas que las aplicaciones de seguridad previamente compiladas. Será evidente para un experto en la técnica que las realizaciones anteriores pueden modificarse de muchas formas sin apartarse del alcance de la invención. Por consiguiente, el alcance de la invención debería estar determinado por las siguientes reivindicaciones y sus equivalentes legales.

Claims (19)

REIVINDICACIONES
1. Un sistema cliente que comprende al menos un procesador de hardware configurado para ejecutar un despachador [32] de rutinas, una máquina virtual [34] de traducción de código de bytes y un motor [38] de evaluación del comportamiento, en donde :
el despachador [32[ de rutinas está configurado, en respuesta a la detección de la ocurrencia de un evento desencadenante, para seleccionar una rutina de código de bytes anti-malware para su ejecución a partir de una pluralidad de rutinas de código de bytes anti-malware, siendo la rutina de código de bytes anti-malware seleccionada según el evento desencadenante, en donde la ocurrencia del evento desencadenante es causada por un proceso monitoreado que se ejecuta dentro del sistema cliente;
la máquina virtual [34] de traducción de código de bytes está configurada, en respuesta al despachador [32] de rutinas que selecciona la rutina de código de bytes anti-malware, para ejecutar la rutina de código de bytes antimalware para determinar si la ocurrencia del evento desencadenante es indicativa de malware, en donde la ejecución de la rutina de código de bytes anti-malware comprende:
traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador, y
ejecutar la secuencia de instrucciones nativas de procesador; y
el motor [38] de evaluación del comportamiento está configurado para determinar si el sistema cliente comprende malware según un resultado de la máquina virtual [34] de traducción de código de bytes que ejecuta la rutina de código de bytes anti-malware.
2. El sistema cliente de la reivindicación 1, en donde el despachador [32] de rutinas está configurado además, en respuesta a la detección de la ocurrencia del evento desencadenante, para:
determinar si se satisface una condición de sincronía según un tipo de evento desencadenante;
en respuesta a la determinación de si se satisface la condición de sincronía, cuando se satisfaga la condición de sincronía, configurar el procesador de hardware para suspender la ejecución del código que pertenece al proceso monitoreado hasta que la máquina virtual de traducción de código de bytes termine de ejecutar la rutina de código de bytes anti-malware; y
en respuesta a la determinación de si se satisface la condición de sincronía, cuando no se satisfaga la condición de sincronía, instruir al procesador de hardware para que continúe la ejecución del código que pertenece al proceso monitoreado.
3. El sistema cliente de la reivindicación 2, en donde el despachador [32] de rutinas está configurado además, en respuesta a determinar si se satisface la condición de sincronía, cuando no se satisfaga la condición de sincronía, para insertar el evento desencadenante en una cola [31] de eventos para su procesamiento posterior.
4. El sistema cliente de la reivindicación 3, en donde el despachador [32] de rutinas está configurado además para: eliminar un segundo evento desencadenante de la cola [31] de eventos;
en respuesta a la eliminación del segundo evento desencadenante de la cola [31] de eventos, seleccionar una segunda rutina de código de bytes anti-malware para su ejecución, siendo seleccionada la segunda rutina de código de bytes anti-malware de la pluralidad de rutinas de código de bytes según el segundo evento desencadenante; y en respuesta a la selección de la segunda rutina de código de bytes anti-malware, transmitir un indicador de la segunda rutina de código de bytes anti-malware a la máquina virtual [34] de traducción de código de bytes.
5. El sistema cliente de la reivindicación 1, en donde la ejecución de la rutina de código de bytes anti-malware hace que el procesador de hardware determine si el proceso monitoreado realizó un conjunto de acciones.
6. El sistema cliente de la reivindicación 1, en donde la ejecución de la rutina de código de bytes anti-malware hace que el procesador de hardware determine si el evento desencadenante forma parte de una secuencia de eventos indicativa de malware.
7. El sistema cliente de la reivindicación 6, en donde un evento seleccionado de la secuencia de eventos es causado por otro proceso monitoreado que se ejecuta dentro del sistema cliente, siendo el otro proceso monitoreado distinto del proceso monitoreado.
8. El sistema cliente de la reivindicación 1, en donde la rutina de código de bytes anti-malware comprende una codificación de una condición desencadenante, y en donde la selección de la rutina de código de bytes anti-malware para su ejecución comprende determinar si se satisface la condición desencadenante.
9. El sistema cliente de la reivindicación 1, en donde la rutina de código de bytes anti-malware comprende una codificación de una condición desencadenante, y en donde la máquina virtual [34] de traducción de código de bytes está configurada además para seleccionar el conjunto de instrucciones de código de bytes para su traducción según el resultado de determinar si se satisface la condición desencadenante.
10. Un método implementado por ordenador que comprende emplear al menos un procesador de hardware de un sistema cliente para realizar cada una de las etapas de:
en respuesta a la detección de la ocurrencia de un evento desencadenante, seleccionar una rutina de código de bytes anti-malware de una pluralidad de rutinas de código de bytes según el evento desencadenante, siendo configurada la rutina de código de bytes anti-malware para determinar si la ocurrencia del evento desencadenante es indicativa de malware, en donde el evento desencadenante es provocado por un proceso monitoreado que se ejecuta dentro del sistema cliente;
en respuesta a la selección de la rutina de código de bytes anti-malware, traducir un conjunto de instrucciones de código de bytes de la rutina de código de bytes anti-malware en una secuencia de instrucciones nativas de procesador;
ejecutar la secuencia de instrucciones nativas de procesador; y
determinar si el sistema cliente comprende malware según el resultado de la ejecución de la secuencia de instrucciones nativas de procesador.
11. El método de la reivindicación 10, que comprende además, en respuesta a la detección de la ocurrencia del evento desencadenante:
emplear al menos un procesador de hardware para determinar si se satisface una condición de sincronía según un tipo de evento desencadenante;
en respuesta a la determinación de si se satisface la condición de sincronía, cuando se satisface la condición de sincronía, configurar al menos un procesador de hardware para suspender la ejecución del código que pertenece al proceso monitoreado hasta que la secuencia de instrucciones del procesador nativo termine de ejecutarse; y en respuesta a la determinación de si se satisface la condición de sincronía, cuando no se satisface la condición de sincronía, emplear al menos un procesador de hardware para continuar la ejecución del código que pertenece al proceso monitoreado.
12. El método de la reivindicación 11, que comprende además, en respuesta a la determinación de si se satisface la condición de sincronía, cuando no se satisface la condición de sincronía, emplear al menos un procesador de hardware para insertar el evento desencadenante en una cola [31] de eventos para su posterior procesamiento.
13. El método de la reivindicación 12, que comprende además:
emplear al menos un procesador de hardware para eliminar un segundo evento desencadenante de la cola [31] de eventos;
en respuesta a la eliminación del segundo evento desencadenante de la cola [31] de eventos, emplear al menos un procesador de hardware para seleccionar una segunda rutina de código de bytes anti-malware para su ejecución, siendo seleccionada la segunda rutina de código de bytes anti-malware de la pluralidad de rutinas de código de bytes según el segundo evento desencadenante;
en respuesta a la selección de la segunda rutina de código de bytes anti-malware, emplear al menos un procesador de hardware para traducir un conjunto de instrucciones de código de bytes de la segunda rutina de código de bytes anti-malware en una segunda secuencia de instrucciones nativas de procesador; y
emplear al menos un procesador de hardware para ejecutar la segunda secuencia de instrucciones nativas de procesador.
14. El método de la reivindicación 10, en donde la ejecución de la secuencia de instrucciones nativas de procesador hace que al menos un procesador de hardware determine si el proceso monitoreado realizó un conjunto de acciones.
15. El método de la reivindicación 10, en donde la ejecución de la secuencia de instrucciones nativas de procesador hace que al menos un procesador de hardware determine si el evento desencadenante forma parte de una secuencia de eventos indicativa de malware.
16. El método de la reivindicación 15, en donde un evento seleccionado de la secuencia de eventos es causado por otro proceso monitoreado que se ejecuta dentro del sistema cliente, siendo el otro proceso monitoreado distinto del proceso monitoreado.
17. El método de la reivindicación 10, en donde la rutina de código de bytes anti-malware comprende una codificación de una condición desencadenante, y en donde la selección de la rutina de código de bytes anti-malware para su ejecución comprende determinar si se satisface la condición desencadenante.
18. El método de la reivindicación 10, en donde la rutina de código de bytes anti-malware comprende una codificación de una condición desencadenante, comprendiendo el método además:
determinar si se satisface la condición desencadenante; y
en respuesta, seleccionar el conjunto de instrucciones de código de bytes para su traducción según el resultado de determinar si se cumple la condición desencadenante.
19. Un medio legible por ordenador no transitorio que almacena instrucciones que, cuando son ejecutadas por al menos un procesador de hardware de un sistema cliente, hacen que el sistema cliente realice el método de la reivindicación 10.
ES16730294T 2015-06-12 2016-06-07 Detección de comportamiento de malware utilizando una máquina virtual de interpretación Active ES2857102T3 (es)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/738,548 US9460284B1 (en) 2015-06-12 2015-06-12 Behavioral malware detection using an interpreter virtual machine
PCT/EP2016/062882 WO2016198392A1 (en) 2015-06-12 2016-06-07 Behavioral malware detection using an interpreter virtual machine

Publications (1)

Publication Number Publication Date
ES2857102T3 true ES2857102T3 (es) 2021-09-28

Family

ID=56137286

Family Applications (1)

Application Number Title Priority Date Filing Date
ES16730294T Active ES2857102T3 (es) 2015-06-12 2016-06-07 Detección de comportamiento de malware utilizando una máquina virtual de interpretación

Country Status (12)

Country Link
US (1) US9460284B1 (es)
EP (1) EP3308315B1 (es)
JP (1) JP6706273B2 (es)
KR (1) KR102206115B1 (es)
CN (1) CN107690645B (es)
AU (1) AU2016274532B2 (es)
CA (1) CA2986321C (es)
ES (1) ES2857102T3 (es)
HK (1) HK1246905A1 (es)
IL (1) IL255802B (es)
RU (1) RU2679175C1 (es)
WO (1) WO2016198392A1 (es)

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
AU2015279922B2 (en) * 2014-06-24 2018-03-15 Virsec Systems, Inc. Automated code lockdown to reduce attack surface for software
US10614210B2 (en) * 2015-07-31 2020-04-07 Digital Guardian, Inc. Systems and methods of protecting data from injected malware
WO2017023775A1 (en) * 2015-07-31 2017-02-09 Digital Guardian, Inc. Systems and methods of protecting data from malware processes
US11170104B1 (en) * 2015-08-21 2021-11-09 Amazon Technologies, Inc. Identifying attacks on file systems
US10033747B1 (en) * 2015-09-29 2018-07-24 Fireeye, Inc. System and method for detecting interpreter-based exploit attacks
US20210026950A1 (en) * 2016-03-07 2021-01-28 Crowdstrike, Inc. Hypervisor-based redirection of system calls and interrupt-based task offloading
US9734337B1 (en) * 2017-01-24 2017-08-15 Malwarebytes Inc. Behavior-based ransomware detection
US11223649B2 (en) 2018-05-06 2022-01-11 Nec Corporation User-added-value-based ransomware detection and prevention
KR102462128B1 (ko) * 2018-07-18 2022-11-03 비트데펜더 아이피알 매니지먼트 엘티디 컴퓨터 보안 사건을 보고하기 위한 시스템 및 방법
US10846088B2 (en) * 2018-08-21 2020-11-24 Arm Limited Control of instruction execution in a data processor
US10452868B1 (en) 2019-02-04 2019-10-22 S2 Systems Corporation Web browser remoting using network vector rendering
US11880422B2 (en) 2019-02-04 2024-01-23 Cloudflare, Inc. Theft prevention for sensitive information
US11080394B2 (en) * 2019-03-27 2021-08-03 Webroot Inc. Behavioral threat detection virtual machine
US11314863B2 (en) 2019-03-27 2022-04-26 Webroot, Inc. Behavioral threat detection definition and compilation
US11481486B2 (en) * 2019-03-27 2022-10-25 Webroot Inc. Behavioral threat detection engine
US11080391B2 (en) 2019-03-27 2021-08-03 Webroot Inc. Behavioral threat detection definition and compilation
RU2711041C1 (ru) * 2019-05-14 2020-01-14 федеральное государственное казенное военное образовательное учреждение высшего образования "Краснодарское высшее военное училище имени генерала армии С.М. Штеменко" Министерства обороны Российской Федерации Способ анализа программного обеспечения на отсутствие недекларированных функциональных возможностей
CN111061538A (zh) * 2019-11-14 2020-04-24 珠海金山网络游戏科技有限公司 一种多Lua虚拟机内存优化方法及其系统
WO2024034841A1 (ko) * 2022-08-12 2024-02-15 삼성전자주식회사 지정된 이벤트에 기반하여 파일을 컴파일하기 위한 전자 장치 및 그 방법

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6125439A (en) * 1996-01-24 2000-09-26 Sun Microsystems, Inc. Process of executing a method on a stack-based processor
US6295643B1 (en) * 1998-12-10 2001-09-25 International Business Machines Corporation Method and apparatus for improving java virtual machine performance using persistent execution information
WO2004075060A1 (ja) * 2003-02-21 2004-09-02 Tabei, Hikaru コンピュータウィルス検出装置
KR100483700B1 (ko) * 2003-12-03 2005-04-19 주식회사 잉카인터넷 온라인 게임 클라이언트 보안을 위한 실시간 프로세스 불법 접근 및 조작 차단 방법
GB0525902D0 (en) * 2005-12-20 2006-02-01 Nokia Corp Signal message decompressor
US7949848B2 (en) * 2007-03-08 2011-05-24 Arm Limited Data processing apparatus, method and computer program product for reducing memory usage of an object oriented program
CN101373502B (zh) * 2008-05-12 2012-06-20 公安部第三研究所 基于Win32平台下病毒行为的自动化分析系统
US8572740B2 (en) * 2009-10-01 2013-10-29 Kaspersky Lab, Zao Method and system for detection of previously unknown malware
US8566943B2 (en) * 2009-10-01 2013-10-22 Kaspersky Lab, Zao Asynchronous processing of events for malware detection
CA2774728C (en) * 2009-11-13 2019-02-12 Irdeto Canada Corporation System and method to protect java bytecode code against static and dynamic attacks within hostile execution environments
RU2430411C1 (ru) * 2010-03-02 2011-09-27 Закрытое акционерное общество "Лаборатория Касперского" Система и способ обнаружения вредоносного программного обеспечения
US9032526B2 (en) * 2011-05-12 2015-05-12 Microsoft Technology Licensing, Llc Emulating mixed-code programs using a virtual machine instance
US9298910B2 (en) * 2011-06-08 2016-03-29 Mcafee, Inc. System and method for virtual partition monitoring
US20130152200A1 (en) * 2011-12-09 2013-06-13 Christoph Alme Predictive Heap Overflow Protection
US8918881B2 (en) * 2012-02-24 2014-12-23 Appthority, Inc. Off-device anti-malware protection for mobile devices
US8881291B2 (en) * 2012-09-25 2014-11-04 Oracle International Corporation System and method for inhibiting the processing of new code modules by an outdated runtime environment
RU2536664C2 (ru) * 2012-12-25 2014-12-27 Закрытое акционерное общество "Лаборатория Касперского" Система и способ автоматической модификации антивирусной базы данных
WO2014143005A1 (en) 2013-03-15 2014-09-18 Mcafee, Inc. Hypervisor-based buffer overflow detection and prevention
RU2531861C1 (ru) * 2013-04-26 2014-10-27 Закрытое акционерное общество "Лаборатория Касперского" Система и способ оценки вредоносности кода, исполняемого в адресном пространстве доверенного процесса
RU2653985C2 (ru) 2013-06-28 2018-05-15 Закрытое акционерное общество "Лаборатория Касперского" Способ и система обнаружения вредоносного программного обеспечения путем контроля исполнения программного обеспечения запущенного по сценарию

Also Published As

Publication number Publication date
CA2986321C (en) 2021-09-28
CN107690645A (zh) 2018-02-13
EP3308315B1 (en) 2020-12-09
AU2016274532A1 (en) 2017-12-07
KR102206115B1 (ko) 2021-01-22
WO2016198392A1 (en) 2016-12-15
US9460284B1 (en) 2016-10-04
JP2018517985A (ja) 2018-07-05
HK1246905A1 (zh) 2018-09-14
IL255802B (en) 2021-01-31
CA2986321A1 (en) 2016-12-15
EP3308315A1 (en) 2018-04-18
IL255802A (en) 2018-01-31
KR20180018531A (ko) 2018-02-21
AU2016274532B2 (en) 2020-08-20
RU2679175C1 (ru) 2019-02-06
JP6706273B2 (ja) 2020-06-03
CN107690645B (zh) 2021-07-16

Similar Documents

Publication Publication Date Title
ES2857102T3 (es) Detección de comportamiento de malware utilizando una máquina virtual de interpretación
JP6378758B2 (ja) 仮想マシンにおけるマルウェア検出のためのプロセス評価
ES2792912T3 (es) Sistemas y métodos de seguridad informática que utilizan excepciones de introspección asíncronas
ES2794624T3 (es) Sistemas y métodos para rastrear comportamiento malicioso a través de múltiples entidades de software
US9305167B2 (en) Hardware-enabled prevention of code reuse attacks
ES2925891T3 (es) Filtrado de eventos para aplicaciones de seguridad de máquina virtual
US10049211B1 (en) Hardware-accelerated prevention of code reuse attacks
US10140448B2 (en) Systems and methods of asynchronous analysis of event notifications for computer security applications
US9596261B1 (en) Systems and methods for delivering context-specific introspection notifications
US9536084B1 (en) Systems and methods for delivering event-filtered introspection notifications
US9531735B1 (en) Systems and methods for delivering introspection notifications from a virtual machine