Noticias de seguridad

En 2012, una coalición de fabricantes de hardware y software de todo el sector adoptó el Secure Boot para protegerse contra una amenaza de seguridad que se venía gestando desde hacía tiempo. La amenaza era el espectro de un malware que podía infectar el BIOS, el firmware que cargaba el sistema operativo cada vez que se iniciaba una computadora. A partir de ahí, podría permanecer inmune a la detección y eliminación y podría cargarse incluso antes que el sistema operativo y las aplicaciones de seguridad. La amenaza de este malware alojado en el BIOS era en gran medida teórica y se alimentó en gran parte por la creación de ICLord Bioskit por un investigador chino en 2007. ICLord era un rootkit, una clase de malware que obtiene y mantiene un acceso oculto subvirtiendo las protecciones clave integradas en el sistema operativo. La prueba de concepto demostró que estos rootkits de BIOS no solo eran factibles, sino que también eran poderosos. En 2011, la amenaza se convirtió en realidad con el descubrimiento de Mebromi, el primer rootkit de BIOS (ahora denominados Bootkit) conocido que se utilizó en la práctica. Los arquitectos de Secure Boot, muy conscientes de Mebromi y de su potencial para una nueva clase de ataque devastador, idearon una nueva y compleja forma de reforzar la seguridad en el entorno previo al arranque. Integrado en UEFI (Unified Extensible Firmware Interface), que se convertiría en la sucesora de BIOS, Secure Boot utiliza criptografía de clave pública para bloquear la carga de cualquier código que esté firmado con una firma digital aprobada previamente. Hasta el día de hoy, los actores clave en seguridad (entre ellos Microsoft y la Agencia de Seguridad Nacional de los EE.UU.) consideran que Secure Boot es una base importante, si no esencial, de confianza para proteger los dispositivos en algunos de los entornos más críticos, incluidos los de control industrial y redes empresariales. Una evasión ilimitada de Secure Boot El jueves, los investigadores de la empresa de seguridad Binarly revelaron que Secure Boot está completamente comprometido en más de 200 modelos de dispositivos vendidos por Acer, Dell, Gigabyte, Intel y Supermicro. La causa: una clave criptográfica que sustentaba el arranque seguro en esos modelos que se vio comprometida en 2022. En un repositorio público de GitHub publicado en diciembre de ese año, alguien que trabajaba para varios fabricantes de dispositivos con sede en EE.UU. publicó lo que se conoce como "clave de plataforma PK", la clave criptográfica que forma el ancla de raíz de confianza entre el dispositivo de hardware y el firmware que se ejecuta en él. El repositorio estaba ubicado en https://github.com/raywu-aaeon/Ryzen2000_4000.git, y no está claro cuándo fue eliminado. El repositorio incluía la parte privada de la clave de la plataforma en forma cifrada. Sin embargo, el archivo cifrado estaba protegido por una contraseña de cuatro caracteres, una decisión que hizo que fuera trivial para Binarly, y cualquier otra persona con una mínima curiosidad, descifrar el código de acceso y recuperar el texto sin formato correspondiente. La divulgación de la clave pasó en gran medida desapercibida hasta enero de 2023, cuando los investigadores de Binarly la encontraron mientras investigaban un incidente en la cadena de suministro. Ahora que la filtración ha salido a la luz, los expertos en seguridad afirman que torpedea de manera efectiva las garantías de seguridad ofrecidas por Secure Boot. "Es un gran problema", dijo Martin Smolár, un analista de malware especializado en rootkits que revisó la investigación de Binarly. "Básicamente, se trata de una evasión ilimitada de Secure Boot para estos dispositivos que utilizan esta clave de plataforma. Por lo tanto, hasta que los fabricantes de dispositivos o los OEM proporcionen actualizaciones de firmware, cualquiera puede básicamente… ejecutar cualquier malware o código no confiable durante el arranque del sistema. Por supuesto, se requiere acceso privilegiado, pero eso no es un problema en muchos casos". Los investigadores de Binarly dijeron que sus escaneos de imágenes de firmware descubrieron 215 dispositivos que utilizan la clave comprometida, que se puede identificar por el número de serie del certificado 55:fb:ef:87:81:23:00:84:47:17:0b:b3:cd:87:3a:f4. Una tabla de afectados aparece en este artículo. Los investigadores pronto descubrieron que el compromiso de la clave era solo el comienzo de una falla mucho mayor en la cadena de suministro que plantea serias dudas sobre la integridad del arranque seguro en más de 300 modelos de dispositivos adicionales de prácticamente todos los principales fabricantes de dispositivos. Como es el caso de la clave de plataforma comprometida en la filtración de GitHub de 2022, otras 21 claves de plataforma contienen las cadenas "DO NOT SHIP" o "DO NO TRUST". Estas claves fueron creadas por AMI, uno de los tres principales proveedores de kits de desarrollo de software que los fabricantes de dispositivos utilizan para personalizar su firmware UEFI para que funcione en sus configuraciones de hardware específicas. Como sugieren las cadenas, las claves nunca estuvieron pensadas para ser utilizadas en sistemas de producción. En cambio, AMI las proporcionó a los clientes o posibles clientes para que las probaran. Por razones que no están claras, las claves de prueba llegaron a los dispositivos de una lista casi inagotable de fabricantes. Además de los cinco fabricantes mencionados anteriormente, se incluyen Aopen, Foremelife, Fujitsu, HP, Lenovo y Supermicro. PKfail Binarly ha llamado a su descubrimiento PKfail en reconocimiento al enorme error en la cadena de suministro resultante de la falla en toda la industria para administrar adecuadamente las claves de la plataforma. El informe está disponible aquí. Los videos de prueba de concepto están aquí y aquí. Binarly ha proporcionado una herramienta de escaneo aquí. Los cuatro recursos clave para que funcione el Arranque seguro son: La clave de plataforma o PK: proporciona el ancla root-of-trust en forma de una clave criptográfica integrada en el firmware del sistema. Establece la confianza entre el hardware de la plataforma y todo el firmware que se ejecuta en él. La clave de intercambio de claves o KEK: es la clave que establece la confianza entre el sistema operativo y el firmware de la plataforma. La base de datos de firmas o DB: una base de datos que contiene firmas y certificados de confianza para los componentes UEFI de terceros y los cargadores de arranque aprobados por el fabricante del hardware. La base de datos de firmas prohibidas o DBX: una base de datos de firmas y certificados que se utiliza para revocar los componentes de arranque que antes eran de confianza para que ya no puedan ejecutarse durante el arranque. Las actualizaciones tanto de la base de datos como de la DBX deben estar firmadas por una KEK en la base de datos KEK de Arranque seguro. Fuente: Arstechnica

Varios países europeos apuestan por el software de código abierto. Suiza ha dado un gran paso adelante con su "Ley federal sobre el uso de medios electrónicos para el cumplimiento de las tareas gubernamentales" (EMBAG). Esta legislación pionera obliga a utilizar software de código abierto (OSS) en el sector público. Esta nueva ley exige que todos los organismos públicos revelen el código fuente del software desarrollado por ellos o para ellos, a menos que los derechos de terceros o las preocupaciones de seguridad lo impidan. Este enfoque de "dinero público, código público" tiene como objetivo mejorar la transparencia, la seguridad y la eficiencia de las operaciones gubernamentales. Dar este paso no fue fácil. Comenzó en 2011, cuando el Tribunal Supremo Federal suizo publicó su solicitud judicial, Open Justitia, bajo una licencia OSS. Ahora, la ley no solo permite la publicación de OSS por parte del gobierno suizo o sus contratistas, sino que también exige que el código se publique bajo una licencia de código abierto "a menos que los derechos de terceros o razones relacionadas con la seguridad lo excluyan o restrinjan". El profesor Dr. Matthias Stürmer, director del Instituto de Transformación del Sector Público de la Universidad de Ciencias Aplicadas de Berna, lideró la lucha por esta ley. Stürmer cree que todos se beneficiarán de esta regulación, ya que reduce la dependencia de proveedores para el sector público, permite a las empresas expandir sus soluciones comerciales digitales y potencialmente conduce a una reducción de los costos de TI y a una mejora de los servicios para los contribuyentes. Además de exigir el OSS, la EMBAG también requiere la publicación de datos gubernamentales no personales y no sensibles a la seguridad como Datos Gubernamentales Abiertos (OGD). Este enfoque dual "abierto por defecto" marca un cambio de paradigma significativo hacia una mayor apertura y reutilización práctica de software y datos. Se espera que la implementación de la EMBAG sirva como modelo para otros países que estén considerando medidas similares. Su objetivo es promover la soberanía digital y alentar la innovación y la colaboración dentro del sector público. Otros países de Europa han apoyado durante mucho tiempo el código abierto. Por ejemplo, en 2023, el presidente francés Macron declaró: "Nos encanta el código abierto", y la Gendarmería Nacional de Francia (piensa en el FBI si eres estadounidense) usa Linux en sus PC. La Unión Europea (UE) ha trabajado durante mucho tiempo para proteger el OSS a través del proyecto de Auditoría de Software Libre y de Código Abierto (FOSSA) de la UE. En los EE.UU., hay cierto apoyo al código abierto, pero no tanto como en Europa. Por ejemplo, la Política Federal de Código Fuente exige que las agencias federales publiquen al menos el 20% del nuevo código desarrollado a medida como software de código abierto. Sin embargo, no obliga a utilizar código abierto. De manera similar, la Administración de Servicios Generales (GSA) tiene una Política de OSS que exige que las organizaciones de la GSA rindan cuentas y publiquen su código de código abierto. Esta política promueve un enfoque de "primero abierto" para el desarrollo de nuevo código personalizado. Por lo tanto, si bien esta medida legislativa coloca a Suiza a la vanguardia del movimiento global de código abierto, es necesario hacer más trabajo tanto en Europa como en los EE.UU. Fuente: ZDNet

Los actores de amenazas están encadenando fallas de ServiceNow utilizando exploits disponibles públicamente para violar agencias gubernamentales y empresas privadas en ataques de robo de datos. Aunque el proveedor publicó actualizaciones de seguridad para las fallas el 10 de julio de 2024, decenas de miles de sistemas siguen siendo potencialmente vulnerables a los ataques. Según la información publicada por The Stack, "un atacante no autenticado podría encadenar un trío de vulnerabilidades críticas de ServiceNow para lograr una ejecución remota completa de código (RCE), con casi 42.000 instancias de ServiceNow expuestas en el momento de la divulgación en mayo". Las vulnerabilidades encontradas inicialmente por los especialistas de Assetnote ya están parcheadas. La actividad maliciosa fue reportada por Resecurity, que, después de monitorearla durante una semana, identificó múltiples víctimas, incluidas agencias gubernamentales, centros de datos, proveedores de energía y empresas de desarrollo de software. El investigador independiente de ciberseguridad Chirag Artani detalló una de las posibles formas de detección. Otros investigadores también compartieron algunos consejos que aprovechan las plantillas personalizadas de Nuclei y Python, lo que permite a los actores automatizar este proceso. Según Imperva, "se han observado intentos de explotación que aprovechan estas vulnerabilidades en más de 6.000 sitios de diversas industrias, especialmente en la industria de servicios financieros". Detalles de explotación ServiceNow es una plataforma basada en la nube que ayuda a las organizaciones a gestionar flujos de trabajo digitales para operaciones empresariales. Se adopta ampliamente en diversas industrias, incluidas organizaciones del sector público, atención médica, instituciones financieras y grandes empresas. Los escaneos de Internet arrojan casi 300.000 instancias expuestas a Internet, lo que refleja la popularidad del producto: FOFA: https://en.fofa.info/result?qbase64=U2VydmVyOiBTZXJ2aWNlTm93 SHODAN: https://beta.shodan.io/search?query=Server%3A+ServiceNow HUNTERS: https://hunter.how/list?searchValue=web.title%3D%3D%22ServiceNow El 10 de julio de 2024, ServiceNow puso a disposición revisiones para CVE-2024-4879, una falla de validación de entrada crítica (puntaje CVSS: 9.3) que permite a usuarios no autenticados realizar la ejecución remota de código en múltiples versiones de Now Platform. Al día siguiente, el 11 de julio, los investigadores de Assetnote que descubrieron la falla publicaron un artículo detallado sobre CVE-2024-4879 y dos fallas más (CVE-2024-5178 y CVE-2024-5217) en ServiceNow que se pueden encadenar por acceso completo a la base de datos. Pronto, GitHub se vio inundado de exploits funcionales basados ​​en la redacción y escáneres de red masivos para CVE-2024-4879, que los actores de amenazas aprovecharon casi de inmediato para encontrar instancias vulnerables, informa Resecurity. La explotación vista por Resecurity utiliza una inyección para verificar un resultado específico en la respuesta del servidor, seguida de una carga útil de segunda etapa que verifica el contenido de la base de datos. Si tiene éxito, el atacante descarga la listas de usuarios y credenciales de las cuentas habilitadas. Resecurity dice que en la mayoría de los casos, las credenciales fueron hashes, pero algunas de las instancias violadas expusieron credenciales de texto sin formato. Resecurity ha visto una gran cantidad de conversaciones sobre las fallas de ServiceNow en foros clandestinos, especialmente por parte de usuarios que buscan acceso a mesas de servicio de TI y portales corporativos, lo que indica un gran interés por parte de la comunidad de delitos cibernéticos. ServiceNow puso a disposición correcciones para las tres vulnerabilidades a principios de este mes en boletines separados para CVE-2024-4879 (CVSS 9.8), CVE-2024-5178 (CVSS 7.5), CVE-2024-5217 (9.2) respectivamente. Se recomienda a los usuarios verificar la versión indicada en los avisos y asegurarse de haber aplicado el parche en todas las instancias o hacerlo lo antes posible si no lo han hecho. Fuente: BC

Mientras Meta "juega" con su IA, el 14 de julio de 2024, un analista de malware @0x6rss descubrió y compartió en X un problema de seguridad en WhatsApp Messenger para Android. Este problema permite a un atacante disfrazar una aplicación maliciosa de Android como un archivo PDF compartido en el chat. Por ahora la vulnerabilidad NO ha sido solucionada. El error no se puede utilizar indebidamente para compartir aplicaciones maliciosas como archivos adjuntos directamente mediante el uso regular de WhatsApp Messenger. En cambio, para aprovechar este problema, un atacante tendría que enviar una solicitud especial a través de la interfaz de programación de WhatsApp. El 25 de junio de 2024, @0x6rss informó este error de manipulación de extensión al equipo de seguridad de Facebook, que administra la recompensa por errores de WhatsApp. Sin embargo, el equipo no lo consideró una vulnerabilidad de seguridad sino más bien un tipo de engaño de ingeniería social, que no entra en la categoría de vulnerabilidades de seguridad dentro del alcance. A pesar de no estar reconocida oficialmente como una vulnerabilidad (ni haber sido solucionada), es crucial que los usuarios conozcan este "truco" simple pero efectivo. Con este método, se puede engañar a personas que no están muy familiarizadas con la tecnología para que descarguen e instalen una aplicación dañina. Telegram descubrió y solucionó recientemente un problema similar, donde las aplicaciones maliciosas de Android podían disfrazarse de videos compartidos en el chat en la aplicación Telegram para Android. @0x6rss compartió algunos detalles y el error se puede replicar, aunque la prueba de concepto aún no está disponible públicamente. Se puede ver una demostración en este video. Este error se puede explotar únicamente utilizando la API de WhatsApp y no directamente enviando una carga útil diseñada dentro de la aplicación. Este sencillo truco consiste en cambiar la extensión del archivo del documento mostrado. WhatsApp sigue mostrando la extensión original del archivo. Para los usuarios TI, lo más probable es que sea una señal de alerta; sin embargo, es posible que el usuario común no sepa qué significa "APK" o qué extensión de archivo usa la aplicación de Android cuando el nombre del archivo indica que es un formato PDF. Cuando el usuario hace clic en el archivo (APK disfrazado de PDF), aparece la segunda bandera roja, que es una advertencia de WhatsApp de que este documento puede contener contenido no seguro. Esta advertencia es razonable; sin embargo, dice explícitamente un documento, no una aplicación. Existe una pequeña diferencia de texto entre compartir un archivo APK con extensión manipulada y el método normal de compartir un archivo APK real, que efectivamente corresponde a un aplicación de Android. Cuando se hace clic en Abrir, WhatsApp solicita al usuario que permita a WhatsApp Messenger instalar aplicaciones de fuentes desconocidas y, incluso, si esto ya ha sido permitido anteriormente, se omite este paso. Para quienes usan WhatsApp en sus computadoras, este error no afecta a WhatsApp Web ni a la aplicación de escritorio. Fuente: MobileHacker

En junio de 2024, se descubrió un grupo de amenazas que utilizaba el ransomware Akira dirigido a una aerolínea latinoamericana. El actor de amenazas accedió inicialmente a la red a través del protocolo Secure Shell (SSH) y logró extraer datos críticos antes de implementar una variante del ransomware Akira al día siguiente. A lo largo de este compromiso, se abusó de una serie de herramientas legítimas junto con Living off-the-Land Binaries and Scripts (LOLBAS). Esto permitió a los agresores realizar reconocimientos y persistir en el entorno de la víctima recientemente comprometida. Una vez que el atacante logró su objetivo de extraer datos, se implementó el ransomware para cifrar e incapacitar los sistemas de la víctima. Akira es un ransomware como servicio (RaaS) que ha sido un arma central de Storm-1567 (también conocido como Punk Spider y GOLD SAHARA), un destacado grupo de ransomware observado por primera vez en 2023. Debido a los indicadores que incluyen consultas DNS enviadas a un dominio asociado con Remmina (un cliente de escritorio remoto de código abierto), podemos decir con un alto grado de confianza que el actor de amenazas detrás de este compromiso probablemente sea un usuario basado en Linux. ¿Qué es el ransomware Akira? Akira, que se detectó inicialmente en estado salvaje en marzo de 2023, es el ransomware asociado con el grupo RaaS conocido como Storm-1567. El grupo es responsable de desarrollar y mantener el ransomware Akira y los Dedicated Leak Sites (DLS) asociados a él. El grupo suele emplear una táctica de doble extorsión en la que se filtran datos críticos antes de que el ransomware destruya los sistemas de las víctimas comprometidas. Esta estratagema ejerce presión adicional sobre las víctimas para que paguen el rescate, ya que los operadores de ransomware amenazarán con la exposición pública de los datos confidenciales robados si el pago no se realiza rápidamente. Las Tácticas, Técnicas y Procedimientos (TTP) asociados con el ransomware Akira incluyen el abuso frecuente de software legítimo, incluidas herramientas de código abierto como diversas herramientas de pruebas de penetración. El grupo también es conocido por explotar vulnerabilidades en la infraestructura de una organización objetivo, como sistemas sin parches o desactualizados y software de VPN vulnerable. El grupo de amenazas Akira ha atacado numerosos sectores industriales en todo el mundo en los últimos años. Hasta enero de 2024, el grupo había recibido más de 42 millones de dólares en pagos de rescate y se había dirigido a más de 250 organizaciones diferentes. Si bien el grupo se dirige principalmente a sistemas Windows, también tienen variantes de Linux de sus herramientas, incluida una variante dirigida a máquinas virtuales VMware ESXi. Cadena de ataque de Akira Aquí hay una descripción general de la cadena de ataques de dos días del grupo Akira a la aerolínea comprometida, como se muestra a continuación: Vector de ataque Durante este ataque a la aerolínea latinoamericana, obtuvimos datos de detección y respuesta de terminales (EDR) para ayudar en nuestra investigación. No existían registros del compromiso inicial, pero observamos que el primer acceso visible del atacante al "Paciente Cero" fue a través de SSH desde la dirección IP de un router. El Paciente Cero era un servidor de respaldo de Veeam sin parches. Creemos que se utilizó el CVE-2023-27532 disponible públicamente para el acceso inicial, que es una vulnerabilidad en el componente Veeam Backup & Replication. El ataque cumple con todas las características y TTP de Akira proporcionados por el FBI y CISA en su asesoramiento conjunto de ciberseguridad de abril de 2024 sobre el ransomware Akira. Los operadores de Akira anteriormente obtuvieron acceso a objetivos utilizando CVE-2020-3259 y CVE-2023-20269. Recopilación y exfiltración de datos Una vez dentro de la red, el actor de amenazas creó un usuario llamado "backup" y se agregó al grupo de administradores para afianzarse en el entorno. A continuación, el atacante procedió a instalar la herramienta legítima de administración de red Advanced IP Scanner antes de escanear las subredes locales descubiertas mediante el comando "route print". Advanced IP Scanner a menudo se considera una herramienta de doble uso; aunque su funcionamiento puede ser fundamental para los administradores de redes y los profesionales de seguridad, la presencia inesperada de la herramienta en un sistema podría ser una señal de negligencia interna o una señal de alerta para otras activaciones maliciosas. Durante este ataque en particular, la propiedad de los datos de respaldo de Veeam se tomó a través de la carpeta de respaldo de Veeam, mientras que el actor de la amenaza comprimió y cargó datos desde otros sistemas. En esta copia de seguridad se incluyeron tipos de archivos comunes como documentos, imágenes y hojas de cálculo, con la esperanza de que el actor malintencionado pudiera recopilar y aprovechar datos confidenciales y potencialmente valiosos para su propio beneficio financiero. Finalmente, los datos se extrajeron a través de WinSCP, un administrador de archivos gratuito para Windows. El tiempo total desde el inicio de sesión inicial hasta la filtración de datos fue de solo 133 minutos, y el último comando se ejecutó a las 4:55 p.m. UTC. Camino hacia el cifrado Temprano a la mañana siguiente, a las 8:40 UTC, el trabajo del actor de amenazas comenzó de nuevo. Los registros que parecen idénticos al smbexec de Impacket muestran que el atacante realizó comprobaciones de usuario en un puñado de máquinas antes de iniciar sesión en el servidor de respaldo principal de Veeam. Se descargó Netscan como "netscan.zip" usando Google Chrome y se usó WinRAR para descomprimirlo. Luego se identificaron las máquinas conectadas al Active Directory y se dejaron en un archivo llamado "AdComputers.csv". Mientras NetScan se ejecutaba en el servidor de respaldo principal de Veeam, la protección antivirus (AV) se deshabilitó en el host de la máquina virtual, tanto a través de las interfaces de usuario (UI) del antivirus como a través de la línea de comandos. De vuelta en el servidor de respaldo principal de Veeam, se descargó el archivo "win.zip" a través de Google Chrome y se descomprimió con WinRAR. Contenía "w.exe", que es el ransomware Akira. Ese archivo se copió en el host de la VM. Los usuarios se enumeraron utilizando "net group" y posteriormente se manipularon con el siguiente comando: Luego, se descargó el software legítimo de escritorio remoto AnyDesk y se ejecutó en cinco sistemas diferentes. AnyDesk proporciona acceso remoto a otros dispositivos que ejecutan la aplicación. Ahora que la persistencia estaba completamente implementada, los actores de amenazas intentaron implementar ransomware en toda la red utilizando el servidor de respaldo de Veeam como punto de control. Vimos que el archivo "w.exe" (ransomware Akira) se implementaba en varios hosts desde el servidor Veeam comprometido. Al mismo tiempo, se eliminaron las instantáneas (Shadow Copy) a través de PowerShell para hacer imposible la recuperación desde la copia de seguridad: powershell.exe -Command "Get-WmiObject Win32_Shadowcopy | Remove-WmiObject" Esta eliminación ejerce más presión sobre la víctima para que "pague", ya que las copias de seguridad y los volúmenes a los que potencialmente se podría revertir ya no son una opción viable. Infraestructura de red Para este ataque en particular, los registros de los puntos finales no capturaron la dirección IP pública de la conexión SSH entrante. Sin embargo, capturó parte del tráfico saliente. Las consultas de DNS al dominio legítimo "plugins.remmina[.]org". Remmina es un cliente de escritorio remoto de código abierto que no se puede utilizar en Windows a menos que se utilice el subsistema de Windows para Linux. Esto sugiere con un alto grado de confianza que el actor de amenazas detrás de este compromiso y ataque es probablemente un usuario de Linux. La dirección IP 77[.]247[.]126[.]158 se utilizó para la exfiltración de datos y todavía estaba activa al momento de escribir este informe. Conclusiones Como la mayoría de los grupos de ransomware, Akira es una banda maliciosa motivada y con impulso financiero que vende y aprovecha su malware únicamente con fines de lucro. Como el grupo Akira opera como un RaaS, la victimología del grupo varía, siendo sus principales víctimas las pequeñas y medianas empresas (PyMES). También han atacado a algunas organizaciones más grandes con sede en América del Norte y Europa. El incidente detallado en este informe ocurrió durante un período de dos días, pero ocurrió dentro del horario laboral UTC, y el trabajo del actor de la amenaza se detuvo justo antes de las 17:00 UTC del primer día y se reanudó a las 8:40 UTC del segundo día. Existe una confianza baja a moderada de que los actores detrás de este ataque residen actualmente en una zona horaria UTC o cerca de ella. Europa occidental ha sido sede de muchos actores de amenazas notorios este año, como lo demuestra el reciente arresto de un miembro del infame grupo de atacantes de Scattered Spider. Dado que este ataque tuvo como objetivo una víctima en América Latina (LATAM), destaca la voluntad del grupo de apuntar a otras regiones, si alguna organización no repara las vulnerabilidades utilizadas por el actor. Vale la pena señalar que en este incidente, el software interno también estaba críticamente desactualizado, lo que dejó importantes vulnerabilidades que fueron explotadas por el actor de la amenaza una vez que se traspasó el perímetro. Fuente: BlackBerry