La seguridad del sistema operativo es una de las prioridades de Microsoft. Los desarrolladores de la nueva generación de Windows han dado una respuesta oportuna y adecuada a las amenazas más actuales para las plataformas Windows, implementando una serie de tecnologías de protección que antes sólo estaban disponibles en soluciones de otras compañías. El sistema ahora está más protegido, y la tarea se les ha hecho más difícil a los delincuentes cibernéticos.
No obstante, en ciertos casos los recursos del sistema operativo resultan insuficientes, ya que los desarrolladores tienen que hacer concesiones en muchos aspectos, lo que tiene un efecto negativo en la seguridad del sistema y hace que sean necesarias herramientas externas de seguridad informática.
Debido a su prevalencia, Windows ha sido y sigue siendo el blanco favorito de los delincuentes cibernéticos de todo tipo. Los hackers de “sombrero negro” estudian escrupulosamente cada nueva versión, tratando de encontrar nuevas oportunidades de lucrar. También la estudian los hackers de “sombrero blanco”, para quienes Windows es el principal campo de batalla contra sus homólogos criminales. Como es natural, Kaspersky Lab examina minuciosamente todos los cambios de seguridad introducidos por Microsoft, con el fin de proporcionar a sus usuarios la máxima protección contra amenazas informáticas.
Nuestro informe consta de tres partes dedicadas a las innovaciones más notables de Windows 10 en lo que a seguridad se refiere. A saber: el navegador Microsoft Edge, la tecnología de seguridad basada en la virtualización y el nuevo Windows Defender, que es la solución antivirus integrada en el sistema operativo. Todos ellos han añadido nuevas funciones al sistema de seguridad de Windows, pero por desgracia, tienen ciertos puntos débiles. En este artículo usaremos ejemplos prácticos para mostrar cómo funcionan las tecnologías de protección de Windows 10 y cómo se las puede complementar con soluciones de terceros para fortalecer la seguridad del sistema.
Microsoft Edge
La última versión del navegador Microsoft Edge está llamada a reemplazar a Internet Explorer y viene incluida en Windows 10 como navegador predeterminado. La compañía ha trabajado duro y agregado muchas innovaciones, entre ellas algunas relacionadas con la seguridad.
Para mitigar los ataques cross-site, en Edge aparecieron las tecnologías Content Security y HTTP Strict Transport Security. No sólo están diseñadas para reducir la probabilidad de éxito de los ataques, sino también para informar al propietario del servicio web de los intentos de ataque.
Microsoft también ha pensado cómo proteger a Edge contra los exploits, cuyos ataques afectaron tanto a Internet Explorer. Ahora, gracias a la utilización de contenedores y a que las operaciones de procesamiento de contenidos se hacen en diferentes procesos, se ha vuelto mucho más difícil explotar las vulnerabilidades. Por último, la integración con SmartScreen tiene como objetivo evitar que se visiten sitios web de contenido nocivo.
Aparte de las nuevas tecnologías que Edge admite, su seguridad también se ve fortalecida por haber abandonado las antiguas tecnologías vulnerables. Ya no se admiten VML, BHOy ActiveX, en las que se basaban la mayor parte de las aplicaciones publicitarias y los complementos maliciosos para el navegador.
Sin embargo, la seguridad del navegador está determinada por su capacidad de neutralizar ataques reales. La mayoría de los programas maliciosos diseñados para robar dinero de la banca en línea funciona correctamente en navegadores como Internet Explorer, Chrome, Firefox, Opera. Con esto nos referimos al viejo Zeus (Zbot), que sigue siendo usado por los delincuentes, el sensacional Dyreza (Dyre) y el bot P2P Cridex (Dridex).
La funcionalidad del troyano bancario se reduce a la realización de ataques MITB (Man-in-the-Browser). La mayoría los llevan a cabo introduciendo su código en el proceso del navegador e interceptando las funciones de red. Sin embargo, en cada navegador estas funciones están implementadas de forma diferente, lo que obliga a los autores de virus a introducir constantemente modificaciones y actualizaciones en el software malicioso para que pueda funcionar en todos los navegadores y versiones posibles.
En noviembre de 2015 llegó la noticia de que el troyano Dyreza había adquirido funciones suficientes para atacar a Microsoft Edge. Sin embargo, la actividad de esta botnet pronto se redujo a cero, debido a que se dejaron de publicar actualizaciones y se apagaron los servidores de comando y control.
Otro famoso troyano bancario, Kronos, aprendió a atacar a Edge en 2016. Nosotros pusimos a prueba sus posibilidades en una máquina virtual con Windows 10. En el código de la nueva versión de Kronos encontramos una función que verifica el nombre del proceso y la suma de comprobación, además del hash de las funciones interceptadas.
Función que detecta el navegador por la suma de comprobación de su proceso
Kronos verifica el nombre del proceso, pone la cadena en minúsculas para calcular la suma de comprobación, y la eleva al cuadrado. A continuación, se busca el hash resultante en una tabla y si se lo encuentra, el troyano intenta interceptar las funciones que necesita en el proceso.
Nombres de procesos de navegador que el troyano conoce:
Nombre del proceso | Suma de comprobación |
iexplore.exe | 0x64302d39 |
chrome.exe | 0x05d66cc4 |
firefox.exe | 0x39ace100 |
opera.exe | 0x9420a4a1 |
microsoftedge.exe | 0x9b6d5990 |
microsoftedgecp.exe | 0x949b93d9 |
Para realizar acciones maliciosas que resulten en ganancias para sus propietarios, Kronos intercepta los procesos de creación y envío de solicitudes HTTP en la biblioteca WinInet.
Lista de funciones de WinInet.dll que Kronos intercepta:
Función API | Hash |
HttpOpenRequestA | Y7D4D7E3T2T2A4U3 |
HttpQueryInfoA | C8C0U1A2G4G5Y2B5 |
HttpSendRequestA | Y4U1P2F2G7T2A4U3 |
InternetCloseHandle | A7S3H3X3D5Y7T7F7 |
InternetConnectA | H0S6D5Q7E8P3P6U5 |
InternetCrackUrlA | E6F2A3S8Y4C7D5A5 |
InternetOpenA | B7P8P7T4E3U2H5A5 |
InternetQueryOptionA | C1Y0B7E2B0P2P3T7 |
InternetReadFile | D6X2S6E3Q3C5B5X2 |
InternetSetOptionA | X3Y6Q2T7Q5Q2A5X6 |
Kronos intercepta las funciones usando un método de slicing, estableciendo una instrucción de transición incondicional JMP al principio del código. El código malicioso incrustado en el navegador no se carga como una biblioteca, sino como un código shell, por lo que el componente Mitigation Policy instalado en el navegador no impide que se ejecute.
Intercepción de la InternetReadFile en MicrosoftEdgeCP.exe
Procesador de la función interceptada
La interceptación exitosa de estas funciones permite que el troyano incruste datos en una página web. Además, Kronos obtiene información sobre el usuario, su nombre de usuario y contraseña, su saldos de cuentas bancarias, redirige al usuario a sitios de phishing, agrega a la página legítima del banco campos de entrada adicionales (lo que le permite averiguar la respuesta a la pregunta secreta, el número de tarjeta de crédito, la fecha de cumpleaños de la víctima y su número de teléfono).
Ejemplo de inyección web en la página de un banco
Vale decir que Kronos es capaz de atacar a Edge sólo en las versiones de 32 bits de Windows 10. Sin embargo, esto no es una limitación fundamental, porque ya existen otros troyanos bancarios que funcionan con la versión de 64 bits de Edge.
A principios de este año apareció una nueva modificación del famoso bancario Gozi, que entre otras cosas, puede llevar a cabo ataques MITB contra la versión Edge de 64 bits de Windows 10. El troyano inyecta su código en el proceso RuntimeBroker.exe, inicia el navegador en su nombre y se incrusta en el proceso del navegador.
Parte de la función de comprobación de los nombres de los procesos en los que se incrusta
El código incrustado intercepta funciones de creación y envío de solicitudes HTTP, de la misma manera que Kronos. Pero para hacerlo, no usa el slicing, sino la sustitución de los indicadores IAT y la suplantación de direcciones de funciones en la tabla de exportación (Export Table).
Parte de la función de comprobación del nombre del proceso para establecer intercepciones a cada navegador
Intercepción de HttpSendRequestW realizada por el troyano bancario Gozi en el navegador MS Edge
Destacamos que Windows Defender bloquea correctamente las versiones actuales de Kronos y Gozi. No obstante, es probable que aparezcan nuevas aplicaciones de malware y adware capaces de utilizar Edge para sus propios fines.
Protección a través de la virtualización
En la versión corporativa de Windows 10, Microsoft ha implementado un nuevo enfoque de seguridad basado en la tecnología de virtualización de hardware, Microsoft Hyper-V. El nuevo paradigma, denominado Virtualization Based Security (VBS), se fundamenta en el mecanismo de listas de admitidos, cuando en el equipo sólo se ejecutan aplicaciones de la lista de confianza, y en el aislamiento de los servicios y datos más importantes de los demás componentes del sistema operativo.
VBS depende de la plataforma y las funciones del CPU, de modo que para el funcionamiento de esta tecnología se requiere:
- Windows 10 Enterprise.
- Firmware UEFI v2.3.1 y posteriores con soporte de Secure Boot.
- Procesador central con soporte de las funciones de virtualización Intel VT-x / AMD-V.
- Arquitectura de 64 bits.
- La presencia del mecanismo Second Level Addres (DUELAS) en el procesador.
- Intel VT-d / AMD-Vi IOMMU (opcional).
- Capacidad de bloquear algunas funciones del firmware UEFI y actualizarlo de forma segura.
- TPM (opcional).
Microsoft utiliza el hipervisor Hyper-V como plataforma de virtualización. Mientras menor sea el código que contiene el hipervisor, habrá menos vectores de ataque contra el mismo. En este aspecto el pequeño tamaño de Hyper-V resulta muy beneficioso. A diferencia de las versiones anteriores de Windows, el hipervisor no se inicia como un controlador en modo kernel, sino durante el inicio de UEFI, al principio del arranque del equipo.
La rutina de inicialización de Hyper-V
En VBS, con el hipervisor activo, a cada procesador virtual se le asigna el atributo virtual Virtual Trust Level (VTL). Por el momento, existen dos niveles: 1 VTL (“mundo protegido”) y VTL 0 ( “mundo normal”). VTL 1 cuenta con más privilegios que VTL 0.
El modo de núcleo protegido (Secure Kernel Mode o SKM, Ring 0, 1 VTL) incluye un núcleo mínimo (SK), un módulo de comprobación de integridad de código (Code Integrity o CI) y un módulo de cifrado. El modo de usuario aislado (Isolated User Mode o IUM, Ring 3, VTL 1) incluye una serie de servicios aislados, llamados Trustlets, y no solo están aislados del mundo exterior, sino también entre sí. En el “mundo normal” (VTL 0) opera el núcleo tradicional, los controladores del modo kernel, los procesos y servicios que se ejecutan con las reglas anteriores.
Descripción esquemática de los dos mundos
Con el hipervisor activo, solo el kernel protegido y aislado protege las páginas físicas de la memoria y sus atributos. Puede manipular los atributos de las páginas y prohibirles o permitirles la lectura, escritura y ejecución de código en una página determinada. Esto le permite evitar el lanzamiento de código no confiable, la modificación maliciosa del código de aplicaciones de confianza y la fuga de datos protegidos.
En esta arquitectura, el único componente que controla la ejecución de cualquier código en el sistema está protegido por un módulo aislado de verificación de la autenticidad de código (CI). El núcleo del “mundo normal” no puede asignar los atributos de una página física en modo kernel.
Credential Guard
Uno de los principales bloques funcionales VBS es Credential Guard, que aísla los secretos de tal modo que solo el código confiable tenga acceso a ellos. Esto le permite resistir los ataques de acceso directo a la memoria (DMA), y los ataques de tipo pass-the-hash y pass-the-ticket.
Información del sistema. Credential Guard y HVCI
Pusimos a prueba la tecnología tratando de obtener datos secretos mediante el acceso directo a la memoria. Para ello, utilizamos las herramientas de hackeo Mimikatz e Inception. No lo logramos. Credencial Guard resultó demasiado difícil para ellas.
Ataque DMA mediante la herramienta de Inception
Device Guard
La tecnología Device Guard incluida en VBS es el sucesor de Microsoft AppLocker. Controla la puesta en marcha y ejecución de cualquier código: archivos ejecutables y bibliotecas dinámicas, driver de modo kernel, scripts (por ejemplo, PowerShell), etc. Con este fin, usa una directiva de integridad de código diseñada por un administrador, que determina qué software considerar de confianza.
La principal dificultad del uso de Device Guard es la elaboración correcta de las directivas, que puede resultar complicada incluso para un administrador de sistemas experimentado. En condiciones ideales, el procedimiento es el siguiente:
- Incluir los mecanismos necesarios de VBS de Windows 10 en un equipo de prueba aparte.
- Crear una imagen del sistema operativo Windows.
- Instalar todo el software necesario.
- Crear una directiva de integridad de código según determinadas reglas y dejarla funcionar durante un tiempo en modo de auditoría. Durante este tiempo se puede añadir o modificar el software.
- Revisar el registro de eventos en busca de eventos de IC.
- Perfeccionar la directiva, por ejemplo, firmar el software que carece de firma digital.
- Combinar la versión original de la directiva con la versión que se creó durante el funcionamiento del modo de auditoría.
- Transferir el modo de auditoría al modo de prohibición e incluirlo en la directiva de integridad de código.
- Difundir las directivas creadas a los usuarios finales.
La directiva de integridad de código define las condiciones de ejecución del código, tanto en el modo de usuario (User Mode Code Integrity o UMCI), como en el modo de kernel (Kernel Mode Code Integrity o KMCI). La tecnología Secure Boot garantiza el arranque seguro del núcleo de Windows. La directiva de integridad debe ser mantenida y actualizada de acuerdo con los requisitos de software de la organización.
Además de la política de integridad, se aplican otras restricciones a la ejecución de código. Así, una página de memoria física recibirá el atributo “ejecución” sólo en el caso de que pase la verificación de autenticidad con el certificado. Además, una página en modo de núcleo no puede tener simultáneamente los atributos de “escritura” y “ejecución” (restricción W ^ X), para evitar que la mayoría de los exploits e interceptores funciones en modo de núcleo. Si se intenta cambiar el contenido de la página del modo de núcleo con los atributos de “lectura” y “ejecución”, se produce un error de excepción. Si no se lo procesa, Windows se detiene y muestra la “pantalla azul de la muerte” o BSOD.
Como resultado, cuando el hipervisor y todos los atributos de seguridad, tales como arranque seguro, TPM, IOMMU, LAMA, están activos, no se pueden ejecutar drivers, aplicaciones, bibliotecas dinámicas, algunos tipos de scripts y módulos de UEFI que carezcan de firma digital. Dependiendo de la configuración de la directiva, también se puede prohibir la ejecución de código firmado, pero que no es de confianza.
Para proteger la directiva contra los cambios no autorizados o evitar que se la sustituya, Microsoft propone firmarla con un certificado que el administrador debe generar por su propia cuenta. Para eliminar una directiva o cambiar su configuración, se requiere otra directiva, firmada con el mismo certificado. Si se intenta eliminar la directiva o “introducir” al sistema una directiva sin firma, el sistema operativo no arrancará.
Pero a pesar de todo, no se puede afirmar que Device Guard sea un sistema impecable. El precio que hay que pagar por la alta seguridad es la reducción de la potencia, algo que es inevitable con la presencia de un hipervisor. El punto débil de la tecnología es que el proceso de crear, configurar y soportar la directiva de integridad de código es sumamente complejo. Las opciones necesarias se encuentran dispersas en diferentes lugares del sistema operativo, no tienen un panel de control común, y en consecuencia, es fácil cometer errores, y con ellos, debilitar la defensa.
Debido a que Secure Boot juega un papel clave en esta tecnología, el nivel de protección depende mucho de la calidad del código de UEFI escrita por terceros, que no está bajo el control de Microsoft. Por último, nos parece sorprendente la falta de protección contra los exploits en modo de usuario.
Ponemos a prueba VBS
Si un código malicioso penetra en un equipo con VBS a través de una vulnerabilidad, tendrá que elevar sus privilegios al modo kernel para atacar el hipervisor, al “mundo protegido” o a UEFI. Nosotros tratamos de hacer algo similar con la ayuda de un driver de régimen de kernel firmado y de confianza.
Resultados de la prueba de penetración desde el modo de kernel:
Prueba | Resultado | Prueba | Resultado |
W+X PE section .INIT | + (by design) | Allocate NP/P MEM, hack PTE manually | + (BSOD) |
W^X PE section .INIT | + (as is) | R+X section, remove WP in CR0 | + (BSOD) |
W+X PE section | + (no start) | Stack code execution | + (BSOD) |
Allocate MEM, execute | + (BSOD) | Allocate MEM, hack MDL manually | + (BSOD) |
R PE section, write, execute | + (BSOD) |
Ninguno de los métodos que probamos funcionó. Tampoco tuvo éxito el ataque mediante registros de control (Control Registers, CR0-CR8, EFER, etc.) y registros específicos de modelos (Model-Specific Registers или MSR), ya que se producía una excepción Privileged Instruction (0xC0000096).
También llevamos a cabo una serie de pruebas en modo de usuario, en un intento de eludir la política de integridad de código en modo de restricción. La tarea consistía en ejecutar una aplicación sin firma o cargar una librería de enlace dinámico sin firma en un proceso de confianza. Esto no funcionó al intentarlo de forma directa, pero en la versión preliminar de Windows 10 (10154) encontramos un curioso error.
La naturaleza del error consiste en que, a pesar de que Device Guard verifica la presencia de la firma en la aplicación, controlador o bibliotecas, no constata si la firma es válida para la aplicación que la lleva. Esto permite recortar una firma válida de cualquier aplicación de confianza y pegarla en cualquiera que no sea de confianza, con lo que el sistema comenzará a considerar que es de confianza. De esta manera, al poner una firma que pertenece a otra aplicación, logramos ejecutar la aplicación no confiable, así como cargar una biblioteca dinámica no confiable.
Informamos de inmediato a Microsoft del error encontrado y lo solucionaron a los pocos días. Windows 10 RTM (10240) ya no lo contiene.
También encontramos un error de denegación de servicio, que permite detener el hipervisor y causar una BSOD desde el espacio del usuario con solo un comando en idioma de ensamblador. El error fue corregido en Windows 10 TH2 (10586).
BSOD del hipervisor
En general, Microsoft ha hecho un excelente trabajo al desarrollar nuevos mecanismos de protección. Sin embargo, al igual que en las versiones anteriores, siguen existiendo posibilidades de ataques a través del firmware. Otro problema son los altos requisitos de cualificación exigidos al administrador del sistema. Si la configuración es incorrecta o se perdió el certificado privado, toda la protección resulta inútil. Además, no hay ninguna protección contra las vulnerabilidades en el modo de usuario. Asimismo, no hay que olvidar que VBS sólo está disponible para los usuarios de la versión corporativa de Windows 10.
Hemos notificado a Microsoft sobre todas las vulnerabilidades encontradas durante las pruebas.
Protección antivirus integrada en Windows
Analicemos también el componente de Windows que protege al sistema contra software malicioso en tiempo real. Está activada por defecto y es, para los usuarios que no instalaron ningún antivirus de terceros, el principal medio de seguridad informática en Windows.
La principal tarea de la protección integrada es impedir la instalación y ejecución de software malicioso. Debe analizar en tiempo real los archivos y procesos en ejecución, identificando los nocivos según una base de datos de firmas actualizada periódicamente. En la mayoría de los casos esta protección es suficiente.
Pero si usted es un usuario activo de Internet, y ejecuta con frecuencia operaciones de importancia crítica en su equipo, por ejemplo, la gestión de sus cuentas bancarias por Internet, necesita una protección multinivel. Incluso los antivirus más avanzados pueden dejar pasar un nuevo malware, todavía desconocido. Y en este caso, solo pueden salvar la situación los niveles adicionales de protección que impidan que el troyano realice actividades maliciosas en el sistema.
Hicimos una breve investigación y encontramos algunos ejemplos de la vida real, cuando la protección incorporada puede ser insuficiente.
Intercepción de datos desde el teclado
Algunos troyanos bancarios interceptan los datos ingresados mediante el teclado para robar la cuenta del usuario en el sistema de banca en línea. En particular, así lo hacen Qadars, Zbot y Cridex. Muchas de las soluciones antivirus, entre ellas Kaspersky Internet Security, tienen un componente que detecta y bloquea los intentos que hacen ciertos programas de interceptar las secuencias de pulsaciones de teclado del usuario. En algunos casos, esto puede ser suficiente para evitar que los atacantes se enriquezcan a expensas de la víctima, incluso si lograron infectar su equipo.
Hemos usado una aplicación que usa la función WinAPI GetAsyncKeyState (método similar al usado en la última prueba de la empresa MRG) para averiguar si la protección de Windows puede evitar que se intercepten las pulsaciones de teclado. Nos fue posible interceptar el nombre de usuario y la contraseña de inicio de sesión en PayPal mientras Windows Defender estaba activo.
Registro de la contraseña al iniciar sesión en la cuenta personal de PayPal
Acceso no autorizado a la cámara web
En la siguiente prueba tratamos de obtener acceso no autorizado a la cámara web. En los últimos años esta función aparece con cada vez mayor frecuencia en troyanos y otras herramientas de hackers. Uno de los ejemplos más claros de la popularidad de esta función entre los atacantes es la presencia del módulo de seguimiento de video en el troyano AdWind.
Observar a la víctima a través de su propia cámara web permite recoger una gran cantidad de información sobre ella, que más adelante se puede utilizar para obtener ganancias criminales, por ejemplo haciendo chantaje con las grabaciones de video de carácter íntimo.
Algunas soluciones antivirus son capaces de controlar el acceso de las aplicaciones a la cámara. En la vida real, prácticamente no hay situaciones en las que las aplicaciones legítimas necesiten usar la cámara sin notificar al usuario, por lo tanto, informalo si lo hace es una práctica conveniente y aceptada. El usuario puede decidir en cada caso si la aplicación realmente necesita utilizar la cámara, o se trata de una actividad sospechosa que hay que prohibir.
Nuestra aplicación de prueba utilizó la biblioteca pública OpenCV (de la misma manera que el troyano activo Rover). Un simple script en Python interceptaba las imágenes de la cámara web y las mostraba en una ventana separada. Como resultado, en un equipo con Windows 10 con la seguridad habilitada, nada impedía a la aplicación interceptar el vídeo y el usuario no recibía ninguna notificación al respecto.
Captura de pantalla del script
El control de las descargas drive-by
Otro de los problemas más acuciantes para los usuarios de Windows son los numerosos exploits que permiten infectar un sistema a través de vulnerabilidades en diversas aplicaciones. Pusimos a prueba la protección integrada con uno de los últimos exploits para la vulnerabilidad CVE-2016-1019 en Adobe Flash Player.
El archivo del exploit es un objeto SWF comprimido con el algoritmo ZLIB.
Exploit flash
Windows Defender detecta el archivo comprimido durante la operación de copia y lo pone en cuarentena.
Detección exitosa de un exploit comprimido
Sin embargo, si se descomprime el archivo SWF inicial, la protección lo deja pasar.
Por otra parte, el mismo archivo comprimido malicioso que el sistema detecta en el disco, puede descargarse de Internet mediante un ataque drive-by y ejecutarse correctamente desde el contexto del navegador. Si una versión vulnerable de Adobe Flash Player está instalada en el sistema, es posible el contagio, ya que Windows Defender carece de un componente capaz de controlar las descargas drive-by.
Descarga exitosa en el navegador de un exploit para Flash detectado en el disco
Además, queremos mencionar que Microsoft Windows tiene un componente integrado (SmartScreen) que puede neutralizar correctamente ataques drive-by mediante el uso del análisis de reputación, pero en algunos casos, sobre todo si se trata de ataques selectivos, es necesario hacer un análisis heurístico adicional del contenido para detectar los procesos iniciados por los exploits. Hemos usado este caso de prueba, que el componente SmartScreen no puede neutralizar, para mostrar que si los atacantes usan un exploit Flash con técnicas que evadan el mecanismo de seguridad de Edge, el usuario puede resultar infectado. Hasta el momento no hemos registrado el uso de estas técnicas de evasión por parte de los delincuentes.
Conclusión
Hoy en día, para proporcionar una protección confiable al sistema del usuario, se requiere un enfoque integral que combine los métodos convencionales de detección (análisis de firmas, análisis de comportamiento, etc.) con módulos adicionales que se centren en la identificación de las técnicas comunes de ataques lanzados por los delincuentes.
Como lo demuestra nuestro pequeño estudio, en algunos casos las tecnologías de seguridad integradas en Windows 10 no son suficientes para proporcionar una protección completa contra los ataques maliciosos. Al igual que en las versiones anteriores de Windows, es imprescindible cerrar todos los posibles vectores de ataque usando soluciones especializadas de seguridad del tipo Internet Security.
Windows 10: ¿Qué hay de nuevo en su sistema de seguridad?