Feed aggregator

Infocon: green

ISC Stormcast For Sunday, April 14th, 2024 https://isc.sans.edu/podcastdetail/8938
Categories: Security Posts

ISC Stormcast For Sunday, April 14th, 2024 https://isc.sans.edu/podcastdetail/8938, (Sat, Apr 13th)

SANS Internet Storm Center, InfoCON: green - Sat, 2024/04/13 - 21:58
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Security Posts

Critical Palo Alto GlobalProtect Vulnerability Exploited (CVE-2024-3400), (Sat, Apr 13th)

SANS Internet Storm Center, InfoCON: green - Sat, 2024/04/13 - 21:14
On Friday, Palo Alto Networks released an advisory warning users of Palo Alto's Global Protect product of a vulnerability that has been exploited since March [1]. Volexity discovered the vulnerability after one of its customers was compromised [2]. The vulnerability allows for arbitrary code execution. A GitHub repository claimed to include an exploit (it has been removed by now).  But the exploit may have been a fake and not the actual exploit. It appeared a bit too simplistic (hopefully). I had no chance to test it. Assume Compromise According to Volexity, exploit attempts for this vulnerability were observed as early as March 26th. Workarounds GlobalProtect is only vulnerable if telemetry is enabled. Telemetry is enabled by default, but as a "quick fix", you may want to disable telemetry. Palo Alto Threat Prevention subscribers can enable Threat ID 95187 to block the exploit. Patch A patch should be available soon (it is not available as I am writing this). Check with Palo Alto for updates. [1] https://security.paloaltonetworks.com/CVE-2024-3400
[2] https://www.volexity.com/blog/2024/04/12/zero-day-exploitation-of-unauthenticated-remote-code-execution-vulnerability-in-globalprotect-cve-2024-3400 ---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter| (c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Security Posts

Change Healthcare faces another ransomware threat—and it looks credible

ArsTechnica: Security Content - Sat, 2024/04/13 - 20:25
Enlarge (credit: iStock / Getty Images Plus) For months, Change Healthcare has faced an immensely messy ransomware debacle that has left hundreds of pharmacies and medical practices across the United States unable to process claims. Now, thanks to an apparent dispute within the ransomware criminal ecosystem, it may have just become far messier still. In March, the ransomware group AlphV, which had claimed credit for encrypting Change Healthcare’s network and threatened to leak reams of the company’s sensitive health care data, received a $22 million payment—evidence, publicly captured on bitcoin’s blockchain, that Change Healthcare had very likely caved to its tormentors’ ransom demand, though the company has yet to confirm that it paid. But in a new definition of a worst-case ransomware, a different ransomware group claims to be holding Change Healthcare’s stolen data and is demanding a payment of their own. Read 6 remaining paragraphs | Comments
Categories: Security Posts

Space Force Is Planning a Military Exercise in Orbit

Wired: Security - Sat, 2024/04/13 - 13:30
Two satellites will engage in a “realistic threat response scenario” when Victus Haze gets underway.
Categories: Security Posts

On-The-Fly: Cómo hackear MQTT con Network Packet Manipulation en 1 minuto

Un informático en el lado del mal - Sat, 2024/04/13 - 12:39
La pasada MorterueloCON participé junto con Pablo González en las jornadas donde presentamos un nuevo módulo para nuestra herramienta 'on-the-fly' en el que habíamos estado trabajando días atrás.

Figura 1: On-The-Fly - Cómo hackear MQTT con Network Packet Manipulation en 1 minuto
'on-the-fly' es una proyecto del equipo de Ideas Locas que ofrece capacidades para realizar pruebas de pentesting en varios dominios (IoT, ICS & TI). Se trata de una herramienta innovadora al unir diferentes mundos que comparten un factor común: la red. Es Open Source, por lo que te animamos a participar activamente en el proyecto que puedes encontrar en su GitHub.
Figura 2: GitHub de OnTheFly
Si revisas el blog y has trabajado con la herramienta, habrás visto que hay un módulo para ‘on-the-fly’ para hacer Network Packet Manipulation, concretamente para manipular paquetes de MySQL al vuelo. En esta ocasión quisimos hacer lo mismo pero para manipular paquetes del protocolo MQTT, y así ampliar las capacidades que tienes para los proyectos de Ethical Hacking.

Figura 3: Libro de Ethical Hacking 2ª Edición
de Pablo González en 0xWord

Ahora hemos publicado este nuevo módulo y te explico como puedes ponerlo a prueba. El escenario es el siguiente:
  • Un broker MQTT que se encargue de hacer llegar los mensajes entre los diferentes clientes.
  • Dos clientes MQTT, uno que publicará el mensaje (que se manipulará en el aire) y otro cliente que esté suscrito al topic que recibirá el mensaje.
  • Una máquina con Kali Linux y herramienta ‘on-the-fly’ preparada.
  • El módulo de manipulación MQTT preparado y lanzado.
Debes saber que este tipo de módulos necesitan de otro módulo para que proporcione el tráfico, en este caso haciendo uso del módulo arp_spoof.

Montaje del broker

Para poner en marcha el broker de manera rápida puedes hacer uso de Docker con una imagen de mosquitto (puedes encontrarla en el Docker Hub):

$ docker run -it -p 1883:1883 -p 9001:9001 -v mosquitto.conf:/mosquitto/config/mosquitto.conf eclipse-mosquitto
Debes tener en cuenta que tienes que tener un fichero de configuración. En el ejemplo, mosquitto.conf se encuentra en local y se montará sobre la ruta /mosquitto/config/mosquitto.conf del contenedor. En el repositorio de GitHub de mosquitto puedes encontrar un ejemplo de configuración, además de tener la documentación oficial en el sitio web de mosquitto donde se explica con detalle cada uno de los parámetros de configuración posibles.
Figura 4: Libro de Docker:SecDevOps en 0xWord de
Fran RamírezElías Grande y Rafael Troncoso
Para este caso, vamos a habilitar el puerto de escucha 1883 (por defecto para conexiones sin cifrar y sin autenticar) y el puerto 9001 (este se usará para una conexión a través de Web Socket, sin cifrar y sin autenticar). Esto se resume en un archivo de configuración que contenga las siguientes lineas:

listener 1883 listener 9001 protocol websockets
Ahora podemos lanzar el contenedor y hacer una prueba de conexión con el broker. Para ello necesitaremos un cliente, por ejemplo MQTTX. MQTTX es un cliente gráfico MQTT, es Open Source bajo una licencia Apache 2.0, y es multiplataforma, por lo que podemos usarlo con los principales sistemas operativos.

Figura 5: Nueva conexión en MQTTX
Al abrirlo tendremos que configurar una nueva conexión, indicando un nombre con el que se guardará en el listado de conexiones, un ID de cliente (que se auto-genera directamente en el cliente), y la dirección y puerto del host. Como nota, para la realización de la prueba de manipulación de paquetes debemos trabajar con la versión 3.1.1 del protocolo MQTT, que se puede indicar en las opciones avanzadas.

Ahora podemos crear una nueva suscripción para estar pendientes de todos los mensajes que se mandan a dicho "topic". Para este ejemplo vamos a suponer que hay una bombilla a la que se le puede cambiar el color cuando se publica sobre el topic ‘bulb/color’.

Figura 6: Suscripción al topic ‘bulb/color’
Con la suscripción creada, vamos a mandar un mensaje con un color, por ejemplo, blue, suponiendo que el dispositivo que estamos ejemplificando espera recibir este mensaje para cambiar su color.

Figura 7: Publicación de mensaje en el topic ‘bulb/color’
Al mandar y recibir el mensaje en el mismo cliente lo vemos como si fuera una conversación: a la derecha los mensajes enviados y a la izquierda los mensajes que se reciben. En ambos casos aparece el topic donde se ha mandado/recibido.

Figura 8: Ataques en redes de datos IPv4&IPv6 (4ª Edición) deJL. Rambla, ampliado y revisado por Pablo González y Chema Alonso
Como ves, hacer uso del protocolo MQTT para intercambiar mensajes entre dispositivos es algo muy sencillo. Únicamente se debe disponer de un broker y de uno o varios clientes para realizar el intercambio.

MQTT Packet Manipulation PoC

Ahora que ya sabemos como funciona el protocolo MQTT, vamos a hacer uso del nuevo módulo de 'on-the-fly' para manipular estos paquetes en el aire.

Figura 9: Esquema manipulación de paquetes MQTT
Para empezar necesitamos hacer que el tráfico de una máquina víctima pase a través de nosotros, por lo que comenzamos haciendo uso del módulo arp_spoof, o cualquiera de las técnicas que se explican en el libro de Ataques en redes de datos IPv4&IPv6 (4ª Edición).

load modules/spoof/arp_spoof
En el ejemplo, conocemos la dirección IP de la víctima y del su puerta de enlace - "gateway" -, por lo que lo configuramos con el uso del comando set y lo ejecutamos con run.

Figura 10: Ejecución del módulo arp_spoof en Kali Linux
Con el ARP Spoofing en ejecución, cargamos el módulo de manipulación MQTT:

load modules/manipulation/mqtt_manipulation
Para este módulo hay que configurar dos parámetros:
  • mqtt_topic_modify: este valor indica el topic que se quiere escuchar para manipular su mensaje.
  • msg_spoof: este valor representa el nuevo mensaje que se quiere asignar.
De esta manera, en el ejemplo se ha indicado que se quiere escuchar el topic bulb/color y vamos a reemplazar cualquier mensaje por lime, por lo que vamos a cambiar cualquier color a éste.

Figura 11: Ejecución del módulo mqtt_manipulation en Kali Linux 
Por último, realizamos la prueba de funcionamiento. Nos dirigimos a la máquina víctima y realizamos la publicación de un nuevo color.

Figura 12: Manipulación en tiempo real de los paquetes MQTT
Si todo ha ido bien podremos observar que, aunque el mensaje que ha salido del cliente es correcto, la recepción que llega a la suscripción es el modificado por 'on-the-fly', por lo que hemos conseguido manipular el tráfico MQTT en tiempo real. En el siguiente video puedes ver la demostración completa del ejemplo.

Figura 13: PoC de Network Manipulación MQTT con 'on-the-fly'
Como ves, este módulo de manipulación de paquetes MQTT hace muy sencillo poder jugar con este protocolo, y propone otro caso de uso para un entorno IoT donde 'on-the-fly' tiene ya varios módulos disponibles.
Figura 14: Pentesting con Kali Silver Edition
 Esperamos que os haya gustado este artículo, y esperamos que lo utilicéis y nos aportéis ideas de mejoras, o que ayudéis a mejorar nuestro 'on-the-fly' con nuevos módulos.
Happy hacking!
Autor: Álvaro Núñez-Romeroinvestigador en el equipo de Ideas Locas. Autor del libro "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun" y del VBOOK de "Arduino para Hackers (& Makers): PoCs and Hacks Just for Fun"
Contactar con Álvaro Núñez-Romero
Sigue Un informático en el lado del mal RSS 0xWord
- Contacta con Chema Alonso en MyPublicInbox.com
Categories: Security Posts

Roku Breach Hits 567,000 Users

Wired: Security - Sat, 2024/04/13 - 12:30
Plus: Apple warns iPhone users about spyware attacks, CISA issues an emergency directive about a Microsoft breach, and a ransomware hacker tangles with an unimpressed HR manager named Beth.
Categories: Security Posts

3 healthcare organizations that are building cyber resilience

Webroot - Fri, 2024/04/05 - 20:15
From 2018 to 2023, healthcare data breaches have increased by 93 percent. And ransomware attacks have grown by 278 percent over the same period. Healthcare organizations can’t afford to let preventable breaches slip by. Globally, the average cost of a healthcare data breach has reached $10.93 million. The situation for healthcare organizations may seem bleak. But there is hope. Focus on layering your security posture to focus on threat prevention, protection, and recovery. Check out three healthcare organizations that are strengthening their cyber resilience with layered security tools. 1. Memorial Hermann balances user experience with encryption Email encryption keeps sensitive medical data safe and organizations compliant. Unfortunately, providers will skip it if the encryption tool is difficult to use. Memorial Hermann ran into this exact issue. Juggling compliance requirements with productivity needs, the organization worried about the user experience for email encryption. Webroot Email Encryption powered by Zix provides the solution. Nearly 75 percent of Memorial Hermann’s encrypted emails go to customers who share Webroot. Now more than 1,750 outside organizations can access encrypted email right from their inbox, with no extra steps or passwords. Read the full case study. 2. Allergy, Asthma and Sinus Center safeguards email The center needed to protect electronic medical records (EMR). But its old software solution required technical oversight that was difficult to manage. Webroot Email Threat Protection by OpenText gives the healthcare organization an easy way to keep EMR secure. OpenText’s in-house research team is continually monitoring new and emerging threats to ensure the center’s threat protection is always up to date. With high-quality protection and a low-maintenance design, the IT team can focus on other projects. When patient data is at stake, the center knows it can trust Webroot. Read the full case study. 3. Radiology Associates avoid downtime with fast recovery Radiologists need to read and interpret patient reports so they can quickly share them with doctors. Their patients’ health can’t afford for them to have downtime. After an unexpected server crash corrupted its database, Radiology Associates needed a way to avoid workflow interruptions. Carbonite Recover by OpenText helps the organization get back to business quickly in the event of a data breach or natural disaster. Plus, the price of the solution and ease of use gave Radiology Associates good reasons to choose our solution. Read the full case study. Conclusion As ransomware becomes more sophisticated and data breaches occur more frequently, healthcare organizations must stay vigilant. Strong cyber resilience should be a priority so that you can protect patient privacy and maintain trust within the healthcare industry. And you don’t have to do it alone. We’re ready to help out as your trusted cybersecurity partner. Together, we can prevent data breaches, protect sensitive data, and help you recover when disaster strikes. Contact us to learn more about our cybersecurity solutions. The post 3 healthcare organizations that are building cyber resilience appeared first on Webroot Blog.
Categories: Security Posts

5 ways to strengthen healthcare cybersecurity

Webroot - Fri, 2024/04/05 - 19:44
Ransomware attacks are targeting healthcare organizations more frequently. The number of costly cyberattacks on US hospitals has doubled. So how do you prevent these attacks? Keep reading to learn five ways you can strengthen security at your organization. But first, let’s find out what’s at stake. Why healthcare needs better cybersecurity Healthcare organizations are especially vulnerable to data breaches because of how much data they hold. And when a breach happens, it creates financial burdens and affects regulatory compliance. On average, the cost of a healthcare data breach globally is $10.93 million. Noncompliance not only incurs more costs but also hurts patient trust. Once that trust is lost, it’s difficult to regain it, which can impact your business and standing within the industry. Adopting a layered security approach will help your organization prevent these attacks. Here are five ways to strengthen your cybersecurity: 1. Use preventive security technology Prevention, as the saying goes, prevention is better than the cure. With the right systems and the right methodology, it’s possible to detect and intercept most cyberthreats before they lead to a data breach, a loss of service, or a deterioration in patient care.
Examples of prevention-layer technologies include: 2. Provide cybersecurity training According to Verizon, 82 percent of all breaches involve a human element. Sometimes malicious insiders create security vulnerabilities. Other times, well-intentioned employees fall victim to attacks like phishing, legitimate-looking emails that trick employees into giving attackers their credentials or other sensitive information—like patient data. In fact, 16 percent of breaches start with phishing. When your employees receive basic cybersecurity training, they are more likely to recognize bad actors, report suspicious activity, and avoid risky behavior. You can outsource cybersecurity training or find an automated security training solution that you manage. 3. Ensure regulatory compliance Healthcare providers are subject to strict data privacy regulations like HIPPA and GDPR. If an avoidable data breach occurs, organizations face hefty fines from state and federal authorities. The email and endpoint protection tools described above help you stay compliant with these regulations. But sometimes a breach is out of your control. So regulators have provided guidelines for how to respond, including investigation, notification, and recovery. 4. Build business recovery plans Adding a recovery plan to your multilayered security approach is crucial to achieving and maintaining cyber resilient healthcare. Ideally, you’ll catch most incoming threats before they become an issue. However, the recovery layer is critical when threats do get through or disasters occur. You might think that your cloud-based applications back up and secure your data. But SaaS vendors explicitly state that data protection and backup is the customer’s responsibility of the customer. Some SaaS applications have recovery options, but they’re limited and ineffective. A separate backup system is necessary to ensure business continuity. Reasons for implementing a solid recovery strategy include:
  • Re-establishing patient trust.
  • Avoiding disruptions to patient care.
  • Remaining compliant with HIPPA and GDPR requirements.
Remember, lives depend on getting your systems back up quickly. That’s why your healthcare organization needs a secure, continuously updated backup and recovery solution for local and cloud servers. 5. Monitor and improve continuously Once you have your multilayered security approach in place, you’ll need a centralized management console to help you monitor and control all your security services. This single-pane-of-glass gives you real-time cyber intelligence and all the tools you need to protect your healthcare organization, your reputation, and your investment in digital transformation. You can also spot gaps in your approach and find ways to improve. Conclusion Cybersecurity can seem daunting at times. Just remember that every step you take toward cyber resilience helps you protect patient privacy and maintain your credibility within the healthcare industry.
So when you’re feeling overwhelmed or stuck, remember the five ways you can strengthen your layered cybersecurity approach:
  1. Use preventive technology like endpoint protection and email encryption.
  2. Train your employees to recognize malicious activities like phishing.
  3. Ensure that you’re compliant with HIPPA, GDPR, and any other regulation standards.
  4. Retrieve your data from breaches with backup and recovery tools.
  5. Monitor your data and improve your approach when necessary.
The post 5 ways to strengthen healthcare cybersecurity appeared first on Webroot Blog.
Categories: Security Posts

Introducing Ruzzy, a coverage-guided Ruby fuzzer

By Matt Schwager Trail of Bits is excited to introduce Ruzzy, a coverage-guided fuzzer for pure Ruby code and Ruby C extensions. Fuzzing helps find bugs in software that processes untrusted input. In pure Ruby, these bugs may result in unexpected exceptions that could lead to denial of service, and in Ruby C extensions, they may result in memory corruption. Notably, the Ruby community has been missing a tool it can use to fuzz code for such bugs. We decided to fill that gap by building Ruzzy. Ruzzy is heavily inspired by Google’s Atheris, a Python fuzzer. Like Atheris, Ruzzy uses libFuzzer for its coverage instrumentation and fuzzing engine. Ruzzy also supports AddressSanitizer and UndefinedBehaviorSanitizer when fuzzing C extensions. This post will go over our motivation behind building Ruzzy, provide a brief overview of installing and running the tool, and discuss some of its interesting implementation details. Ruby revelers rejoice, Ruzzy* is here to reveal a new era of resilient Ruby repositories. * If you’re curious, Ruzzy is simply a portmanteau of Ruby and fuzz, or fuzzer. Bringing fuzz testing to Ruby The Trail of Bits Testing Handbook provides the following definition of fuzzing: Fuzzing represents a dynamic testing method that inputs malformed or unpredictable data to a system to detect security issues, bugs, or system failures. We consider it an essential tool to include in your testing suite. Fuzzing is an important testing methodology when developing high-assurance software, even in Ruby. Consider AFL’s extensive trophy case, rust-fuzz’s trophy case, and OSS-Fuzz’s claim that it’s helped find and fix over 10,000 security vulnerabilities and 36,000 bugs with fuzzing. As mentioned previously, Python has Atheris. Java has Jazzer. The Ruby community deserves a high-quality, modern fuzzing tool too. This isn’t to say that Ruby fuzzers haven’t been built before. They have: kisaten, afl-ruby, FuzzBert, and perhaps some we’ve missed. However, all these tools appear to be either unmaintained, difficult to use, lacking features, or all of the above. To address these challenges, Ruzzy is built on three principles:
  1. Fuzz pure Ruby code and Ruby C extensions
  2. Make fuzzing easy by providing a RubyGems installation process and simple interface
  3. Integrate with the extensive libFuzzer ecosystem
With that, let’s give this thing a test drive. Installing and running Ruzzy The Ruzzy repository is well documented, so this post will provide an abridged version of installing and running the tool. The goal here is to provide a quick overview of what using Ruzzy looks like. For more information, check out the repository. First things first, Ruzzy requires a Linux environment and a recent version of Clang (we’ve tested back to version 14.0.0). Releases of Clang can be found on its GitHub releases page. If you’re on a Mac or Windows computer, then you can use Docker Desktop on Mac or Windows as your Linux environment. You can then use Ruzzy’s Docker development environment to run the tool. With that out of the way, let’s get started. Run the following command to install Ruzzy from RubyGems: MAKE="make --environment-overrides V=1" \ CC="/path/to/clang" \ CXX="/path/to/clang++" \ LDSHARED="/path/to/clang -shared" \ LDSHAREDXX="/path/to/clang++ -shared" \ gem install ruzzy These environment variables ensure the tool is compiled and installed correctly. They will be explored in greater detail later in this post. Make sure to update the /path/to portions to point to your clang installation. Fuzzing Ruby C extensions To facilitate testing the tool, Ruzzy includes a “dummy” C extension with a heap-use-after-free bug. This section will demonstrate using Ruzzy to fuzz this vulnerable C extension. First, we need to configure Ruzzy’s required sanitizer options: export ASAN_OPTIONS="allocator_may_return_null=1:detect_leaks=0:use_sigaltstack=0" (See the Ruzzy README for why these options are necessary in this context.) Next, start fuzzing: LD_PRELOAD=$(ruby -e 'require "ruzzy"; print Ruzzy::ASAN_PATH') \ ruby -e 'require "ruzzy"; Ruzzy.dummy' LD_PRELOAD is required for the same reason that Atheris requires it. That is, it uses a special shared object that provides access to libFuzzer’s sanitizers. Now that Ruzzy is fuzzing, it should quickly produce a crash like the following: INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 2527961537 ... ==45==ERROR: AddressSanitizer: heap-use-after-free on address 0x50c0009bab80 at pc 0xffff99ea1b44 bp 0xffffce8a67d0 sp 0xffffce8a67c8 ... SUMMARY: AddressSanitizer: heap-use-after-free /var/lib/gems/3.1.0/gems/ruzzy-0.7.0/ext/dummy/dummy.c:18:24 in _c_dummy_test_one_input ... ==45==ABORTING MS: 4 EraseBytes-CopyPart-CopyPart-ChangeBit-; base unit: 410e5346bca8ee150ffd507311dd85789f2e171e 0x48,0x49, HI artifact_prefix='./'; Test unit written to ./crash-253420c1158bc6382093d409ce2e9cff5806e980 Base64: SEk= Fuzzing pure Ruby code Fuzzing pure Ruby code requires two Ruby scripts: a tracer script and a fuzzing harness. The tracer script is required due to an implementation detail of the Ruby interpreter. Every tracer script will look nearly identical. The only difference will be the name of the Ruby script you’re tracing. First, the tracer script. Let’s call it test_tracer.rb: require 'ruzzy' Ruzzy.trace('test_harness.rb') Next, the fuzzing harness. A fuzzing harness wraps a fuzzing target and passes it to the fuzzing engine. In this case, we have a simple fuzzing target that crashes when it receives the input “FUZZ.” It’s a contrived example, but it demonstrates Ruzzy’s ability to find inputs that maximize code coverage and produce crashes. Let’s call this harness test_harness.rb: require 'ruzzy' def fuzzing_target(input) if input.length == 4 if input[0] == 'F' if input[1] == 'U' if input[2] == 'Z' if input[3] == 'Z' raise end end end end end end test_one_input = lambda do |data| fuzzing_target(data) # Your fuzzing target would go here return 0 end Ruzzy.fuzz(test_one_input) You can start the fuzzing process with the following command: LD_PRELOAD=$(ruby -e 'require "ruzzy"; print Ruzzy::ASAN_PATH') \ ruby test_tracer.rb This should quickly produce a crash like the following: INFO: Running with entropic power schedule (0xFF, 100). INFO: Seed: 2311041000 ... /app/ruzzy/bin/test_harness.rb:12:in `block in ': unhandled exception from /var/lib/gems/3.1.0/gems/ruzzy-0.7.0/lib/ruzzy.rb:15:in `c_fuzz' from /var/lib/gems/3.1.0/gems/ruzzy-0.7.0/lib/ruzzy.rb:15:in `fuzz' from /app/ruzzy/bin/test_harness.rb:35:in `' from bin/test_tracer.rb:7:in `require_relative' from bin/test_tracer.rb:7:in `' ... SUMMARY: libFuzzer: fuzz target exited MS: 1 CopyPart-; base unit: 24b4b428cf94c21616893d6f94b30398a49d27cc 0x46,0x55,0x5a,0x5a, FUZZ artifact_prefix='./'; Test unit written to ./crash-aea2e3923af219a8956f626558ef32f30a914ebc Base64: RlVaWg== Ruzzy used libFuzzer’s coverage-guided instrumentation to discover the input (“FUZZ”) that produces a crash. This is one of Ruzzy’s key contributions: coverage-guided support for pure Ruby code. We will discuss coverage support and more in the next section. Interesting implementation details You don’t need to understand this section to use Ruzzy, but fuzzing can often be more art than science, so we wanted to share some details to help demystify this dark art. We certainly learned a lot from the blog posts describing Atheris and Jazzer, so we figured we’d pay it forward. Of course, there are many interesting details that go into creating a tool like this but we’ll focus on three: creating a Ruby fuzzing harness, compiling Ruby C extensions with libFuzzer, and adding coverage support for pure Ruby code. Creating a Ruby fuzzing harness One of the first things you need when embarking on a fuzzing campaign is a fuzzing harness. The Trail of Bits Testing Handbook defines a fuzzing harness as follows: A harness handles the test setup for a given target. The harness wraps the software and initializes it such that it is ready for executing test cases. A harness integrates a target into a testing environment. When fuzzing Ruby code, naturally we want to write our fuzzing harness in Ruby, too. This speaks to goal number 2 from the beginning of this post: make fuzzing Ruby simple and easy. However, a problem arises when we consider that libFuzzer is written in C/C++. When using libFuzzer as a library, we need to pass a C function pointer to LLVMFuzzerRunDriver to initiate the fuzzing process. How can we pass arbitrary Ruby code to a C/C++ library? Using a foreign function interface (FFI) like Ruby-FFI is one possibility. However, FFIs are generally used to go the other direction: calling C/C++ code from Ruby. Ruby C extensions seem like another possibility, but we still need to figure out a way to pass arbitrary Ruby code to a C extension. After much digging around in the Ruby C extension API, we discovered the rb_proc_call function. This function allowed us to use Ruby C extensions to bridge the gap between Ruby code and the libFuzzer C/C++ implementation. In Ruby, a Proc is “an encapsulation of a block of code, which can be stored in a local variable, passed to a method or another Proc, and can be called. Proc is an essential concept in Ruby and a core of its functional programming features.” Perfect, this is exactly what we needed. In Ruby, all lambda functions are also Procs, so we can write fuzzing harnesses like the following: require 'json' require 'ruzzy' json_target = lambda do |data| JSON.parse(data) return 0 end Ruzzy.fuzz(json_target) In this example, the json_target lambda function is passed to Ruzzy.fuzz. Behind the scenes Ruzzy uses two language features to bridge the gap between Ruby code and a C interface: Ruby Procs and C function pointers. First, Ruzzy calls LLVMFuzzerRunDriver with a function pointer. Then, every time that function pointer is invoked, it calls rb_proc_call to execute the Ruby target. This allows the C/C++ fuzzing engine to repeatedly call the Ruby target with fuzzed data. Considering the example above, since all lambda functions are Procs, this accomplishes the goal of calling arbitrary Ruby code from a C/C++ library. As with all good, high-level overviews, this is an oversimplification of how Ruzzy works. You can see the exact implementation in cruzzy.c. Compiling Ruby C extensions with libFuzzer Before we proceed, it’s important to understand that there are two Ruby C extensions we are considering: the Ruzzy C extension that hooks into the libFuzzer fuzzing engine and the Ruby C extensions that become our fuzzing targets. The previous section discussed the Ruzzy C extension implementation. This section discusses Ruby C extension targets. These are third-party libraries that use Ruby C extensions that we’d like to fuzz. To fuzz a Ruby C extension, we need a way to compile the extension with libFuzzer and its associated sanitizers. Compiling C/C++ code for fuzzing requires special compile-time flags, so we need a way to inject these flags into the C extension compilation process. Dynamically adding these flags is important because we’d like to install and fuzz Ruby gems without having to modify the underlying code. The mkmf, or MakeMakefile, module is the primary interface for compiling Ruby C extensions. The gem install process calls a gem-specific Ruby script, typically named extconf.rb, which calls the mkmf module. The process looks roughly like this: gem install -> extconf.rb -> mkmf -> Makefile -> gcc/clang/CC -> extension.so Unfortunately, by default mkmf does not respect common C/C++ compilation environment variables like CC, CXX, and CFLAGS. However, we can force this behavior by setting the following environment variable: MAKE="make --environment-overrides". This tells make that environment variables override Makefile variables. With that, we can use the following command to install Ruby gems containing C extensions with the appropriate fuzzing flags: MAKE="make --environment-overrides V=1" \ CC="/path/to/clang" \ CXX="/path/to/clang++" \ LDSHARED="/path/to/clang -shared" \ LDSHAREDXX="/path/to/clang++ -shared" \ CFLAGS="-fsanitize=address,fuzzer-no-link -fno-omit-frame-pointer -fno-common -fPIC -g" \ CXXFLAGS="-fsanitize=address,fuzzer-no-link -fno-omit-frame-pointer -fno-common -fPIC -g" \ gem install msgpack The gem we’re installing is msgpack, an example of a gem containing a C extension component. Since it deserializes binary data, it makes a great fuzzing target. From here, if we wanted to fuzz msgpack, we would create an msgpack fuzzing harness and initiate the fuzzing process. If you’d like to find more fuzzing targets, searching GitHub for extconf.rb files is one of the best ways we’ve found to identify good C extension candidates. Adding coverage support for pure Ruby code Instead of Ruby C extensions, what if we want to fuzz pure Ruby code? That is, Ruby projects that do not contain a C extension component. If modifying install-time functionality via lengthy, not-officially-supported environment variables is a hacky solution, then what follows is not for the faint of heart. But, hey, a working solution with a little artistic freedom is better than no solution at all. First, we need to cover the motivation for coverage support. Fuzzers derive some of their “smarts” from analyzing coverage information. This is a lot like code coverage information provided by unit and integration tests. While fuzzing, most fuzzers prioritize inputs that unlock new code branches. This increases the likelihood that they will find crashes and bugs. When fuzzing Ruby C extensions, Ruzzy can punt coverage instrumentation for C code to Clang. With pure Ruby code, we have no such luxury. While implementing Ruzzy, we discovered one supremely useful piece of functionality: the Ruby Coverage module. The problem is that it cannot easily be called in real time by C extensions. If you recall, Ruzzy uses its own C extension to pass fuzz harness code to LLVMFuzzerRunDriver. To implement our pure Ruby coverage “smarts,” we need to pass in Ruby coverage information to libFuzzer in real time as the fuzzing engine executes. The Coverage module is great if you have a known start and stop point of execution, but not if you need to continuously gather coverage information and pass it to libFuzzer. However, we know the Coverage module must be implemented somehow, so we dug into the Ruby interpreter’s C implementation to learn more. Enter Ruby event hooking. The TracePoint module is the official Ruby API for listening for certain types of events like calling a function, returning from a routine, executing a line of code, and many more. When these events fire, you can execute a callback function to handle the event however you’d like. So, this sounds great, and exactly like what we need. When we’re trying to track coverage information, what we’d really like to do is listen for branching events. This is what the Coverage module is doing, so we know it must exist under the hood somewhere. Fortunately, the public Ruby C API provides access to this event hooking functionality via the rb_add_event_hook2 function. This function takes a list of events to hook and a callback function to execute whenever one of those events fires. By digging around in the source code a bit, we find that the list of possible events looks very similar to the list in the TracePoint module: 37 #define RUBY_EVENT_NONE 0x0000 /**< No events. */ 38 #define RUBY_EVENT_LINE 0x0001 /**< Encountered a new line. */ 39 #define RUBY_EVENT_CLASS 0x0002 /**< Encountered a new class. */ 40 #define RUBY_EVENT_END 0x0004 /**< Encountered an end of a class clause. */ ... Ruby event hook types If you keep digging, you’ll notice a distinct lack of one type of event: coverage events. But why? The Coverage module appears to be handling these events. If you continue digging, you’ll find that there are in fact coverage events, and that is how the Coverage module works, but you don’t have access to them. They’re defined as part of a private, internal-only portion of the Ruby C API: 2182 /* #define RUBY_EVENT_RESERVED_FOR_INTERNAL_USE 0x030000 */ /* from vm_core.h */ 2183 #define RUBY_EVENT_COVERAGE_LINE 0x010000 2184 #define RUBY_EVENT_COVERAGE_BRANCH 0x020000 Private coverage event hook types That’s the bad news. The good news is that we can define the RUBY_EVENT_COVERAGE_BRANCH event hook ourselves and set it to the correct, constant value in our code, and rb_add_event_hook2 will still respect it. So we can use Ruby’s built-in coverage tracking after all! We can feed this data into libFuzzer in real time and it will fuzz accordingly. Discussing how to feed this data into libFuzzer is beyond the scope of this post, but if you’d like to learn more, we use SanitizerCoverage’s inline 8-bit counters, PC-Table, and data flow tracing. There’s just one more thing. During our testing, even though we added the correct event hook, we still weren’t successfully hooking coverage events. The Coverage module must be doing something we’re not seeing. If we call Coverage.start(branches: true), per the Coverage documentation, then things work as expected. The details here involve a lot of sleuthing in the Ruby interpreter source code, so we’ll cut to the chase. As best we can tell, it appears that calling Coverage.start, which effectively calls Coverage.setup, initializes some global state in the Ruby interpreter that allows for hooking coverage events. This initialization functionality is also part of a private, internal-only API. The easiest solution we could come up with was calling Coverage.setup(branches: true) before we start fuzzing. With that, we began successfully hooking coverage events as expected. Having coverage events included in the standard library made our lives a lot easier. Without it, we may have had to resort to much more invasive and cumbersome solutions like modifying the Ruby code the interpreter sees in real time. However, it would have made our lives even easier if hooking coverage events were part of the official, public Ruby C API. We’re currently tracking this request at trailofbits/ruzzy#9. Again, the information presented here is a slight oversimplification of the implementation details; if you’d like to learn more, then cruzzy.c and ruzzy.rb are great places to start. Find more Ruby bugs with Ruzzy We faced some interesting challenges while building this tool and attempted to hide much of the complexity behind a simple, easy to use interface. When using the tool, the implementation details should not become a hindrance or an annoyance. However, discussing them here in detail may spur the next fuzzer implementation or step forward in the fuzzing community. As mentioned previously, the Atheris and Jazzer posts were a great inspiration to us, so we figured we’d pay it forward. Building the tool is just the beginning. The real value comes when we start using the tool to find bugs. Like Atheris for Python, and Jazzer for Java before it, Ruzzy is an attempt to bring a higher level of software assurance to the Ruby community. If you find a bug using Ruzzy, feel free to open a PR against our trophy case with a link to the issue. If you’d like to read more about our work on fuzzing, check out the following posts: Contact us if you’re interested in custom fuzzing for your project.
Categories: Security Posts

Android Malware Vultur Expands Its Wingspan

Fox-IT - Thu, 2024/03/28 - 12:00
Authored by Joshua Kamp Executive summary The authors behind Android banking malware Vultur have been spotted adding new technical features, which allow the malware operator to further remotely interact with the victim’s mobile device. Vultur has also started masquerading more of its malicious activity by encrypting its C2 communication, using multiple encrypted payloads that are decrypted on the fly, and using the guise of legitimate applications to carry out its malicious actions. Key takeaways
  • The authors behind Vultur, an Android banker that was first discovered in March 2021, have been spotted adding new technical features.
  • New technical features include the ability to:
    • Download, upload, delete, install, and find files;
    • Control the infected device using Android Accessibility Services (sending commands to perform scrolls, swipe gestures, clicks, mute/unmute audio, and more);
    • Prevent apps from running;
    • Display a custom notification in the status bar;
    • Disable Keyguard in order to bypass lock screen security measures.
  • While the new features are mostly related to remotely interact with the victim’s device in a more flexible way, Vultur still contains the remote access functionality using AlphaVNC and ngrok that it had back in 2021.
  • Vultur has improved upon its anti-analysis and detection evasion techniques by:
    • Modifying legitimate apps (use of McAfee Security and Android Accessibility Suite package name);
    • Using native code in order to decrypt payloads;
    • Spreading malicious code over multiple payloads;
    • Using AES encryption and Base64 encoding for its C2 communication.
Introduction Vultur is one of the first Android banking malware families to include screen recording capabilities. It contains features such as keylogging and interacting with the victim’s device screen. Vultur mainly targets banking apps for keylogging and remote control. Vultur was first discovered by ThreatFabric in late March 2021. Back then, Vultur (ab)used the legitimate software products AlphaVNC and ngrok for remote access to the VNC server running on the victim’s device. Vultur was distributed through a dropper-framework called Brunhilda, responsible for hosting malicious applications on the Google Play Store [1]. The initial blog on Vultur uncovered that there is a notable connection between these two malware families, as they are both developed by the same threat actors [2]. In a recent campaign, the Brunhilda dropper is spread in a hybrid attack using both SMS and a phone call. The first SMS message guides the victim to a phone call. When the victim calls the number, the fraudster provides the victim with a second SMS that includes the link to the dropper: a modified version of the McAfee Security app. The dropper deploys an updated version of Vultur banking malware through 3 payloads, where the final 2 Vultur payloads effectively work together by invoking each other’s functionality. The payloads are installed when the infected device has successfully registered with the Brunhilda Command-and-Control (C2) server. In the latest version of Vultur, the threat actors have added a total of 7 new C2 methods and 41 new Firebase Cloud Messaging (FCM) commands. Most of the added commands are related to remote access functionality using Android’s Accessibility Services, allowing the malware operator to remotely interact with the victim’s screen in a way that is more flexible compared to the use of AlphaVNC and ngrok. In this blog we provide a comprehensive analysis of Vultur, beginning with an overview of its infection chain. We then delve into its new features, uncover its obfuscation techniques and evasion methods, and examine its execution flow. Following that, we dissect its C2 communication, discuss detection based on YARA, and draw conclusions. Let’s soar alongside Vultur’s smarter mobile malware strategies! Infection chain In order to deceive unsuspecting individuals into installing malware, the threat actors employ a hybrid attack using two SMS messages and a phone call. First, the victim receives an SMS message that instructs them to call a number if they did not authorise a transaction involving a large amount of money. In reality, this transaction never occurred, but it creates a false sense of urgency to trick the victim into acting quickly. A second SMS is sent during the phone call, where the victim is instructed into installing a trojanised version of the McAfee Security app from a link. This application is actually Brunhilda dropper, which looks benign to the victim as it contains functionality that the original McAfee Security app would have. As illustrated below, this dropper decrypts and executes a total of 3 Vultur-related payloads, giving the threat actors total control over the victim’s mobile device. Figure 1: Visualisation of the complete infection chain. Note: communication with the C2 server occurs during every malware stage. New features in Vultur The latest updates to Vultur bring some interesting changes worth discussing. The most intriguing addition is the malware’s ability to remotely interact with the infected device through the use of Android’s Accessibility Services. The malware operator can now send commands in order to perform clicks, scrolls, swipe gestures, and more. Firebase Cloud Messaging (FCM), a messaging service provided by Google, is used for sending messages from the C2 server to the infected device. The message sent by the malware operator through FCM can contain a command, which, upon receipt, triggers the execution of corresponding functionality within the malware. This eliminates the need for an ongoing connection with the device, as can be seen from the code snippet below. Figure 2: Decompiled code snippet showing Vultur’s ability to perform clicks and scrolls using Accessibility Services. Note for this (and upcoming) screenshot(s): some variables, classes and method names were renamed by the analyst. Pink strings indicate that they were decrypted. While Vultur can still maintain an ongoing remote connection with the device through the use of AlphaVNC and ngrok, the new Accessibility Services related FCM commands provide the actor with more flexibility. In addition to its more advanced remote control capabilities, Vultur introduced file manager functionality in the latest version. The file manager feature includes the ability to download, upload, delete, install, and find files. This effectively grants the actor(s) with even more control over the infected device. Figure 3: Decompiled code snippet showing part of the file manager related functionality. Another interesting new feature is the ability to block the victim from interacting with apps on the device. Regarding this functionality, the malware operator can specify a list of apps to press back on when detected as running on the device. The actor can include custom HTML code as a “template” for blocked apps. The list of apps to block and the corresponding HTML code to be displayed is retrieved through the vnc.blocked.packages C2 method. This is then stored in the app’s SharedPreferences. If available, the HTML code related to the blocked app will be displayed in a WebView after it presses back. If no HTML code is set for the app to block, it shows a default “Temporarily Unavailable” message after pressing back. For this feature, payload #3 interacts with code defined in payload #2. Figure 4: Decompiled code snippet showing part of Vultur’s implementation for blocking apps. The use of Android’s Accessibility Services to perform RAT related functionality (such as pressing back, performing clicks and swipe gestures) is something that is not new in Android malware. In fact, it is present in most Android bankers today. The latest features in Vultur show that its actors are catching up with this trend, and are even including functionality that is less common in Android RATs and bankers, such as controlling the device volume. A full list of Vultur’s updated and new C2 methods / FCM commands can be found in the “C2 Communication” section of this blog. Obfuscation techniques & detection evasion Like a crafty bird camouflaging its nest, Vultur now employs a set of new obfuscation and detection evasion techniques when compared to its previous versions. Let’s look into some of the notable updates that set apart the latest variant from older editions of Vultur. AES encrypted and Base64 encoded HTTPS traffic In October 2022, ThreatFabric mentioned that Brunhilda started using string obfuscation using AES with a varying key in the malware samples themselves [3]. At this point in time, both Brunhilda and Vultur did not encrypt its HTTP requests. That has changed now, however, with the malware developer’s adoption of AES encryption and Base64 encoding requests in the latest variants. Figure 5: Example AES encrypted and Base64 encoded request for bot registration. By encrypting its communications, malware can evade detection of security solutions that rely on inspecting network traffic for known patterns of malicious activity. The decrypted content of the request can be seen below. Note that the list of installed apps is shown as Base64 encoded text, as this list is encoded before encryption. {"id":"6500","method":"application.register","params":{"package":"com.wsandroid.suite","device":"Android/10","model":"samsung GT-I900","country":"sv-SE","apps":"cHQubm92b2JhbmNvLm5iYXBwO3B0LnNhbnRhbmRlcnRvdHRhLm1vYmlsZXBhcnRpY3VsYXJlcztzYS5hbHJhamhpYmFuay50YWh3ZWVsYXBwO3NhLmNvbS5zZS5hbGthaHJhYmE7c2EuY29tLnN0Y3BheTtzYW1zdW5nLnNldHRpbmdzLnBhc3M7c2Ftc3VuZy5zZXR0aW5ncy5waW47c29mdGF4LnBla2FvLnBvd2VycGF5O3RzYi5tb2JpbGViYW5raW5nO3VrLmNvLmhzYmMuaHNiY3VrbW9iaWxlYmFua2luZzt1ay5jby5tYm5hLmNhcmRzZXJ2aWNlcy5hbmRyb2lkO3VrLmNvLm1ldHJvYmFua29ubGluZS5tb2JpbGUuYW5kcm9pZC5wcm9kdWN0aW9uO3VrLmNvLnNhbnRhbmRlci5zYW50YW5kZXJVSzt1ay5jby50ZXNjb21vYmlsZS5hbmRyb2lkO3VrLmNvLnRzYi5uZXdtb2JpbGViYW5rO3VzLnpvb20udmlkZW9tZWV0aW5nczt3aXQuYW5kcm9pZC5iY3BCYW5raW5nQXBwLm1pbGxlbm5pdW07d2l0LmFuZHJvaWQuYmNwQmFua2luZ0FwcC5taWxsZW5uaXVtUEw7d3d3LmluZ2RpcmVjdC5uYXRpdmVmcmFtZTtzZS5zd2VkYmFuay5tb2JpbA==","tag":"dropper2"} Utilisation of legitimate package names The dropper is a modified version of the legitimate McAfee Security app. In order to masquerade malicious actions, it contains functionality that the official McAfee Security app would have. This has proven to be effective for the threat actors, as the dropper currently has a very low detection rate when analysed on VirusTotal. Figure 6: Brunhilda dropper’s detection rate on VirusTotal. Next to modding the legitimate McAfee Security app, Vultur uses the official Android Accessibility Suite package name for its Accessibility Service. This will be further discussed in the execution flow section of this blog. Figure 7: Snippet of Vultur’s AndroidManifest.xml file, where its Accessibility Service is defined with the Android Accessibility Suite package name. Leveraging native code for payload decryption Native code is typically written in languages like C or C++, which are lower-level than Java or Kotlin, the most popular languages used for Android application development. This means that the code is closer to the machine language of the processor, thus requiring a deeper understanding of lower-level programming concepts. Brunhilda and Vultur have started using native code for decryption of payloads, likely in order to make the samples harder to reverse engineer. Distributing malicious code across multiple payloads In this blog post we show how Brunhilda drops a total of 3 Vultur-related payloads: two APK files and one DEX file. We also showcase how payload #2 and #3 can effectively work together. This fragmentation can complicate the analysis process, as multiple components must be assembled to reveal the malware’s complete functionality. Execution flow: A three-headed… bird? While previous versions of Brunhilda delivered Vultur through a single payload, the latest variant now drops Vultur in three layers. The Brunhilda dropper in this campaign is a modified version of the legitimate McAfee Security app, which makes it seem harmless to the victim upon execution as it includes functionality that the official McAfee Security app would have. Figure 8: The modded version of the McAfee Security app is launched. In the background, the infected device registers with its C2 server through the /ejr/ endpoint and the application.register method. In the related HTTP POST request, the C2 is provided with the following information:
  • Malware package name (as the dropper is a modified version of the McAfee Security app, it sends the official com.wsandroid.suite package name);
  • Android version;
  • Device model;
  • Language and country code (example: sv-SE);
  • Base64 encoded list of installed applications;
  • Tag (dropper campaign name, example: dropper2).
The server response is decrypted and stored in a SharedPreference key named 9bd25f13-c3f8-4503-ab34-4bbd63004b6e, where the value indicates whether the registration was successful or not. After successfully registering the bot with the dropper C2, the first Vultur payload is eventually decrypted and installed from an onClick() method. Figure 9: Decryption and installation of the first Vultur payload. In this sample, the encrypted data is hidden in a file named 78a01b34-2439-41c2-8ab7-d97f3ec158c6 that is stored within the app’s “assets” directory. When decrypted, this will reveal an APK file to be installed. The decryption algorithm is implemented in native code, and reveals that it uses AES/ECB/PKCS5Padding to decrypt the first embedded file. The Lib.d() function grabs a substring from index 6 to 22 of the second argument (IPIjf4QWNMWkVQN21ucmNiUDZaVw==) to get the decryption key. The key used in this sample is: QWNMWkVQN21ucmNi (key varies across samples). With this information we can decrypt the 78a01b34-2439-41c2-8ab7-d97f3ec158c6 file, which brings us another APK file to examine: the first Vultur payload. Layer 1: Vultur unveils itself The first Vultur payload also contains the application.register method. The bot registers itself again with the C2 server as observed in the dropper sample. This time, it sends the package name of the current payload (se.accessibility.app in this example), which is not a modded application. The “tag” that was related to the dropper campaign is also removed in this second registration request. The server response contains an encrypted token for further communication with the C2 server and is stored in the SharedPreference key f9078181-3126-4ff5-906e-a38051505098. Figure 10: Decompiled code snippet that shows the data to be sent to the C2 server during bot registration. The main purpose of this first payload is to obtain Accessibility Service privileges and install the next Vultur APK file. Apps with Accessibility Service permissions can have full visibility over UI events, both from the system and from 3rd party apps. They can receive notifications, list UI elements, extract text, and more. While these services are meant to assist users, they can also be abused by malicious apps for activities, such as keylogging, automatically granting itself additional permissions, monitoring foreground apps and overlaying them with phishing windows. In order to gain further control over the infected device, this payload displays custom HTML code that contains instructions to enable Accessibility Services permissions. The HTML code to be displayed in a WebView is retrieved from the installer.config C2 method, where the HTML code is stored in the SharedPreference key bbd1e64e-eba3-463c-95f3-c3bbb35b5907. Figure 11: HTML code is loaded in a WebView, where the APP_NAME variable is replaced with the text “McAfee Master Protection”. In addition to the HTML content, an extra warning message is displayed to further convince the victim into enabling Accessibility Service permissions for the app. This message contains the text “Your system not safe, service McAfee Master Protection turned off. For using full device protection turn it on.” When the warning is displayed, it also sets the value of the SharedPreference key 1590d3a3-1d8e-4ee9-afde-fcc174964db4 to true. This value is later checked in the onAccessibilityEvent() method and the onServiceConnected() method of the malicious app’s Accessibility Service. ANALYST COMMENT
An important observation here, is that the malicious app is using the com.google.android.marvin.talkback package name for its Accessibility Service. This is the package name of the official Android Accessibility Suite, as can be seen from the following link: https://play.google.com/store/apps/details?id=com.google.android.marvin.talkback.
The implementation is of course different from the official Android Accessibility Suite and contains malicious code. When the Accessibility Service privileges have been enabled for the payload, it automatically grants itself additional permissions to install apps from unknown sources, and installs the next payload through the UpdateActivity. Figure 12: Decryption and installation of the second Vultur payload. The second encrypted APK is hidden in a file named data that is stored within the app’s “assets” directory. The decryption algorithm is again implemented in native code, and is the same as in the dropper. This time, it uses a different decryption key that is derived from the DXMgKBY29QYnRPR1k1STRBNTZNUw== string. The substring reveals the actual key used in this sample: Y29QYnRPR1k1STRB (key varies across samples). After decrypting, we are presented with the next layer of Vultur. Layer 2: Vultur descends The second Vultur APK contains more important functionality, such as AlphaVNC and ngrok setup, displaying of custom HTML code in WebViews, screen recording, and more. Just like the previous versions of Vultur, the latest edition still includes the ability to remotely access the infected device through AlphaVNC and ngrok. This second Vultur payload also uses the com.google.android.marvin.talkback (Android Accessibility Suite) package name for the malicious Accessibility Service. From here, there are multiple references to methods invoked from another file: the final Vultur payload. This time, the payload is not decrypted from native code. In this sample, an encrypted file named a.int is decrypted using AES/CFB/NoPadding with the decryption key SBhXcwoAiLTNIyLK (stored in SharedPreference key dffa98fe-8bf6-4ed7-8d80-bb1a83c91fbb). We have observed the same decryption key being used in multiple samples for decrypting payload #3. Figure 13: Decryption of the third Vultur payload. Furthermore, from payload #2 onwards, Vultur uses encrypted SharedPreferences for further hiding of malicious configuration related key-value pairs. Layer 3: Vultur strikes The final payload is a Dalvik Executable (DEX) file. This decrypted DEX file holds Vultur’s core functionality. It contains the references to all of the C2 methods (used in communication from bot to C2 server, in order to send or retrieve information) and FCM commands (used in communication from C2 server to bot, in order to perform actions on the infected device). An important observation here, is that code defined in payload #3 can be invoked from payload #2 and vice versa. This means that these final two files effectively work together. Figure 14: Decompiled code snippet showing some of the FCM commands implemented in Vultur payload #3. The last Vultur payload does not contain its own Accessibility Service, but it can interact with the Accessibility Service that is implemented in payload #2. C2 Communication: Vultur finds its voice When Vultur infects a device, it initiates a series of communications with its designated C2 server. Communications related to C2 methods such as application.register and vnc.blocked.packages occur using JSON-RPC 2.0 over HTTPS. These requests are sent from the infected device to the C2 server to either provide or receive information. Actual vultures lack a voice box; their vocalisations include rasping hisses and grunts [4]. While the communication in older variants of Vultur may have sounded somewhat similar to that, you could say that the threat actors have developed a voice box for the latest version of Vultur. The content of the aforementioned requests are now AES encrypted and Base64 encoded, just like the server response. Next to encrypted communication over HTTPS, the bot can receive commands via Firebase Cloud Messaging (FCM). FCM is a cross-platform messaging solution provided by Google. The FCM related commands are sent from the C2 server to the infected device to perform actions on it. During our investigation of the latest Vultur variant, we identified the C2 endpoints mentioned below. EndpointDescription/ejr/Endpoint for C2 communication using JSON-RPC 2.0.
Note: in older versions of Vultur the /rpc/ endpoint was used for similar communication./upload/Endpoint for uploading files (such as screen recording results)./version/app/?filename=ngrok&arch={DEVICE_ARCH}Endpoint for downloading the relevant version of ngrok./version/app/?filename={FILENAME}Endpoint for downloading a file specified by the payload (related to the new file manager functionality). C2 methods in Brunhilda dropper The commands below are sent from the infected device to the C2 server to either provide or receive information. MethodDescriptionapplication.registerRegisters the bot by providing the malware package name and information about the device: model, country, installed apps, Android version. It also sends a tag that is used for identifying the dropper campaign name.
Note: this method is also used once in Vultur payload #1, but without sending a tag. This method then returns a token to be used in further communication with the C2 server.application.stateSends a token value that was set as a response to the application.register command, together with a status code of “3”. C2 methods in Vultur The commands below are sent from the infected device to the C2 server to either provide or receive information. MethodDescriptionvnc.register (UPDATED)Registers the bot by providing the FCM token, malware package name and information about the device, model, country, Android version. This method has been updated in the latest version of Vultur to also include information on whether the infected device is rooted and if it is detected as an emulator.vnc.status (UPDATED)Sends the following status information about the device: if the Accessibility Service is enabled, if the Device Admin permissions are enabled, if the screen is locked, what the VNC address is. This method has been updated in the latest version of Vultur to also send information related to: active fingerprints on the device, screen resolution, time, battery percentage, network operator, location.vnc.appsSends the list of apps that are installed on the victim’s device.vnc.keylogSends the keystrokes that were obtained via keylogging.vnc.config (UPDATED)Obtains the config of the malware, such as the list of targeted applications by the keylogger and VNC. This method has been updated in the latest version of Vultur to also obtain values related to the following new keys: “packages2”, “rurl”, “recording”, “main_content”, “tvmq”.vnc.overlayObtains the HTML code for overlay injections of a specified package name using the pkg parameter. It is still unclear whether support for overlay injections is fully implemented in Vultur.vnc.overlay.logsSends the stolen credentials that were obtained via HTML overlay injections. It is still unclear whether support for overlay injections is fully implemented in Vultur.vnc.pattern (NEW)Informs the C2 server whether a PIN pattern was successfully extracted and stored in the application’s Shared Preferences.vnc.snapshot (NEW)Sends JSON data to the C2 server, which can contain:

1. Information about the accessibility event’s class, bounds, child nodes, UUID, event type, package name, text content, screen dimensions, time of the event, and if the screen is locked.
2. Recently copied text, and SharedPreferences values related to “overlay” and “keyboard”.
3. X and Y coordinates related to a click.vnc.submit (NEW)Informs the C2 server whether the bot registration was successfully submitted or if it failed.vnc.urls (NEW)Informs the C2 server about the URL bar related element IDs of either the Google Chrome or Firefox webbrowser (depending on which application triggered the accessibility event).vnc.blocked.packages (NEW)Retrieves a list of “blocked packages” from the C2 server and stores them together with custom HTML code in the application’s Shared Preferences. When one of these package names is detected as running on the victim device, the malware will automatically press the back button and display custom HTML content if available. If unavailable, a default “Temporarily Unavailable” message is displayed.vnc.fm (NEW)Sends file related information to the C2 server. File manager functionality includes downloading, uploading, installing, deleting, and finding of files.vnc.syslogSends logs.crash.logsSends logs of all content on the screen.installer.config (NEW)Retrieves the HTML code that is displayed in a WebView of the first Vultur payload. This HTML code contains instructions to enable Accessibility Services permissions. FCM commands in Vultur The commands below are sent from the C2 server to the infected device via Firebase Cloud Messaging in order to perform actions on the infected device. The new commands use IDs instead of names that describe their functionality. These command IDs are the same in different samples. CommandDescriptionregisteredReceived when the bot has been successfully registered.startStarts the VNC connection using ngrok.stopStops the VNC connection by killing the ngrok process and stopping the VNC service.unlockUnlocks the screen.deleteUninstalls the malware package.patternProvides a gesture/stroke pattern to interact with the device’s screen.109b0e16 (NEW)Presses the back button.18cb31d4 (NEW)Presses the home button.811c5170 (NEW)Shows the overview of recently opened apps.d6f665bf (NEW)Starts an app specified by the payload.1b05d6ee (NEW)Shows a black view.1b05d6da (NEW)Shows a black view that is obtained from the layout resources in Vultur payload #2.7f289af9 (NEW)Shows a WebView with HTML code loaded from SharedPreference key “946b7e8e”.dc55afc8 (NEW)Removes the active black view / WebView that was added from previous commands (after sleeping for 15 seconds).cbd534b9 (NEW)Removes the active black view / WebView that was added from previous commands (without sleeping).4bacb3d6 (NEW)Deletes an app specified by the payload.b9f92adb (NEW)Navigates to the settings of an app specified by the payload.77b58a53 (NEW)Ensures that the device stays on by acquiring a wake lock, disables keyguard, sleeps for 0,1 second, and then swipes up to unlock the device without requiring a PIN.ed346347 (NEW)Performs a click.5c900684 (NEW)Scrolls forward.d98179a8 (NEW)Scrolls backward.7994ceca (NEW)Sets the text of a specified element ID to the payload text.feba1943 (NEW)Swipes up.d403ad43 (NEW)Swipes down.4510a904 (NEW)Swipes left.753c4fa0 (NEW)Swipes right.b183a400 (NEW)Performs a stroke pattern on an element across a 3×3 grid.81d9d725 (NEW)Performs a stroke pattern based on x+y coordinates and time duration.b79c4b56 (NEW)Press-and-hold 3 times near bottom middle of the screen.1a7493e7 (NEW)Starts capturing (recording) the screen.6fa8a395 (NEW)Sets the “ShowMode” of the keyboard to 0. This allows the system to control when the soft keyboard is displayed.9b22cbb1 (NEW)Sets the “ShowMode” of the keyboard to 1. This means the soft keyboard will never be displayed (until it is turned back on).98c97da9 (NEW)Requests permissions for reading and writing external storage.7b230a3b (NEW)Request permissions to install apps from unknown sources.cc8397d4 (NEW)Opens the long-press power menu.3263f7d4 (NEW)Sets a SharedPreference value for the key “c0ee5ba1-83dd-49c8-8212-4cfd79e479c0” to the specified payload. This value is later checked for in other to determine whether the long-press power menu should be displayed (SharedPref value 1), or whether the back button must be pressed (SharedPref value 2).request_accessibility (UPDATED)Prompts the infected device with either a notification or a custom WebView that instructs the user to enable accessibility services for the malicious app. The related WebView component was not present in older versions of Vultur.announcement (NEW)Updates the value for the C2 domain in the SharedPreferences.5283d36d-e3aa-45ed-a6fb-2abacf43d29c (NEW)Sends a POST with the vnc.config C2 method and stores the malware config in SharedPreferences.09defc05-701a-4aa3-bdd2-e74684a61624 (NEW)Hides / disables the keyboard, obtains a wake lock, disables keyguard (lock screen security), mutes the audio, stops the “TransparentActivity” from payload #2, and displays a black view.fc7a0ee7-6604-495d-ba6c-f9c2b55de688 (NEW)Hides / disables the keyboard, obtains a wake lock, disables keyguard (lock screen security), mutes the audio, stops the “TransparentActivity” from payload #2, and displays a custom WebView with HTML code loaded from SharedPreference key “946b7e8e” (“tvmq” value from malware config).8eac269d-2e7e-4f0d-b9ab-6559d401308d (NEW)Hides / disables the keyboard, obtains a wake lock, disables keyguard (lock screen security), mutes the audio, stops the “TransparentActivity” from payload #2.e7289335-7b80-4d83-863a-5b881fd0543d (NEW)Enables the keyboard and unmutes audio. Then, sends the vnc.snapshot method with empty JSON data.544a9f82-c267-44f8-bff5-0726068f349d (NEW)Retrieves the C2 command, payload and UUID, and executes the command in a thread.a7bfcfaf-de77-4f88-8bc8-da634dfb1d5a (NEW)Creates a custom notification to be shown in the status bar.444c0a8a-6041-4264-959b-1a97d6a92b86 (NEW)Retrieves the list of apps to block and corresponding HTML code through the vnc.blocked.packages C2 method and stores them in the blocked_package_template SharedPreference key.a1f2e3c6-9cf8-4a7e-b1e0-2c5a342f92d6 (NEW)Executes a file manager related command. Commands are:

1. 91b4a535-1a78-4655-90d1-a3dcb0f6388a – Downloads a file
2. cf2f3a6e-31fc-4479-bb70-78ceeec0a9f8 – Uploads a file
3. 1ce26f13-fba4-48b6-be24-ddc683910da3 – Deletes a file
4. 952c83bd-5dfb-44f6-a034-167901990824 – Installs a file
5. 787e662d-cb6a-4e64-a76a-ccaf29b9d7ac – Finds files containing a specified pattern Detection Writing YARA rules to detect Android malware can be challenging, as APK files are ZIP archives. This means that extracting all of the information about the Android application would involve decompressing the ZIP, parsing the XML, and so on. Thus, most analysts build YARA rules for the DEX file. However, DEX files, such as Vultur payload #3, are less frequently submitted to VirusTotal as they are uncovered at a later stage in the infection chain. To maximise our sample pool, we decided to develop a YARA rule for the Brunhilda dropper. We discovered some unique hex patterns in the dropper APK, which allowed us to create the YARA rule below. rule brunhilda_dropper
{
meta:
author = "Fox-IT, part of NCC Group"
description = "Detects unique hex patterns observed in Brunhilda dropper samples."
target_entity = "file"
strings:
$zip_head = "PK"
$manifest = "AndroidManifest.xml"
$hex1 = {63 59 5c 28 4b 5f}
$hex2 = {32 4a 66 48 66 76 64 6f 49 36}
$hex3 = {63 59 5c 28 4b 5f}
$hex4 = {30 34 7b 24 24 4b}
$hex5 = {22 69 4f 5a 6f 3a}
condition:
$zip_head at 0 and $manifest and #manifest >= 2 and 2 of ($hex*)
} Wrap-up Vultur’s recent developments have shown a shift in focus towards maximising remote control over infected devices. With the capability to issue commands for scrolling, swipe gestures, clicks, volume control, blocking apps from running, and even incorporating file manager functionality, it is clear that the primary objective is to gain total control over compromised devices. Vultur has a strong correlation to Brunhilda, with its C2 communication and payload decryption having the same implementation in the latest variants. This indicates that both the dropper and Vultur are being developed by the same threat actors, as has also been uncovered in the past. Furthermore, masquerading malicious activity through the modification of legitimate applications, encryption of traffic, and the distribution of functions across multiple payloads decrypted from native code, shows that the actors put more effort into evading detection and complicating analysis. During our investigation of recently submitted Vultur samples, we observed the addition of new functionality occurring shortly after one another. This suggests ongoing and active development to enhance the malware’s capabilities. In light of these observations, we expect more functionality being added to Vultur in the near future. Indicators of Compromise Analysed samples Package nameFile hash (SHA-256)Descriptioncom.wsandroid.suiteedef007f1ca60fdf75a7d5c5ffe09f1fc3fb560153633ec18c5ddb46cc75ea21Brunhilda Droppercom.medical.balance89625cf2caed9028b41121c4589d9e35fa7981a2381aa293d4979b36cf5c8ff2Vultur payload #1com.medical.balance1fc81b03703d64339d1417a079720bf0480fece3d017c303d88d18c70c7aabc3Vultur payload #2com.medical.balance4fed4a42aadea8b3e937856318f9fbd056e2f46c19a6316df0660921dd5ba6c5Vultur payload #3com.wsandroid.suite001fd4af41df8883957c515703e9b6b08e36fde3fd1d127b283ee75a32d575fcBrunhilda Dropperse.accessibility.appfc8c69bddd40a24d6d28fbf0c0d43a1a57067b19e6c3cc07e2664ef4879c221bVultur payload #1se.accessibility.app7337a79d832a57531b20b09c2fc17b4257a6d4e93fcaeb961eb7c6a95b071a06Vultur payload #2se.accessibility.app7f1a344d8141e75c69a3c5cf61197f1d4b5038053fd777a68589ecdb29168e0cVultur payload #3com.wsandroid.suite26f9e19c2a82d2ed4d940c2ec535ff2aba8583ae3867502899a7790fe3628400Brunhilda Droppercom.exvpn.fastvpn2a97ed20f1ae2ea5ef2b162d61279b2f9b68eba7cf27920e2a82a115fd68e31fVultur payload #1com.exvpn.fastvpnc0f3cb3d837d39aa3abccada0b4ecdb840621a8539519c104b27e2a646d7d50dVultur payload #2com.wsandroid.suite92af567452ecd02e48a2ebc762a318ce526ab28e192e89407cac9df3c317e78dBrunhilda Dropperjk.powder.tendencefa6111216966a98561a2af9e4ac97db036bcd551635be5b230995faad40b7607Vultur payload #1jk.powder.tendencedc4f24f07d99e4e34d1f50de0535f88ea52cc62bfb520452bdd730b94d6d8c0eVultur payload #2jk.powder.tendence627529bb010b98511cfa1ad1aaa08760b158f4733e2bbccfd54050838c7b7fa3Vultur payload #3com.wsandroid.suitef5ce27a49eaf59292f11af07851383e7d721a4d60019f3aceb8ca914259056afBrunhilda Dropperse.talkback.app5d86c9afd1d33e4affa9ba61225aded26ecaeb01755eeb861bb4db9bbb39191cVultur payload #1se.talkback.app5724589c46f3e469dc9f048e1e2601b8d7d1bafcc54e3d9460bc0adeeada022dVultur payload #2se.talkback.app7f1a344d8141e75c69a3c5cf61197f1d4b5038053fd777a68589ecdb29168e0cVultur payload #3com.wsandroid.suitefd3b36455e58ba3531e8cce0326cce782723cc5d1cc0998b775e07e6c2622160Brunhilda Droppercom.adajio.storm819044d01e8726a47fc5970efc80ceddea0ac9bf7c1c5d08b293f0ae571369a9Vultur payload #1com.adajio.storm0f2f8adce0f1e1971cba5851e383846b68e5504679d916d7dad10133cc965851Vultur payload #2com.adajio.stormfb1e68ee3509993d0fe767b0372752d2fec8f5b0bf03d5c10a30b042a830ae1aVultur payload #3com.protectionguard.appd3dc4e22611ed20d700b6dd292ffddbc595c42453f18879f2ae4693a4d4d925aBrunhilda Dropper (old variant)com.appsmastersafeyf4d7e9ec4eda034c29b8d73d479084658858f56e67909c2ffedf9223d7ca9bd2Vultur (old variant)com.datasafeaccountsanddata.club7ca6989ccfb0ad0571aef7b263125410a5037976f41e17ee7c022097f827bd74Vultur (old variant)com.app.freeguarding.twofactorc646c8e6a632e23a9c2e60590f012c7b5cb40340194cb0a597161676961b4de0Vultur (old variant) Note: Vultur payloads #1 and #2 related to Brunhilda dropper 26f9e19c2a82d2ed4d940c2ec535ff2aba8583ae3867502899a7790fe3628400 are the same as Vultur payloads #2 and #3 in the latest variants. The dropper in this case only drops two payloads, where the latest versions deploy a total of three payloads. C2 servers
  • safetyfactor[.]online
  • cloudmiracle[.]store
  • flandria171[.]appspot[.]com (FCM)
  • newyan-1e09d[.]appspot[.]com (FCM)
Dropper distribution URLs
  • mcafee[.]960232[.]com
  • mcafee[.]353934[.]com
  • mcafee[.]908713[.]com
  • mcafee[.]784503[.]com
  • mcafee[.]053105[.]com
  • mcafee[.]092877[.]com
  • mcafee[.]582630[.]com
  • mcafee[.]581574[.]com
  • mcafee[.]582342[.]com
  • mcafee[.]593942[.]com
  • mcafee[.]930204[.]com
References
  1. https://resources.prodaft.com/brunhilda-daas-malware-report
  2. https://www.threatfabric.com/blogs/vultur-v-for-vnc
  3. https://www.threatfabric.com/blogs/the-attack-of-the-droppers
  4. https://www.wildlifecenter.org/vulture-facts
Categories: Security Posts

Cybersecurity Concerns for Ancillary Strength Control Subsystems

BreakingPoint Labs Blog - Thu, 2023/10/19 - 19:08
Additive manufacturing (AM) engineers have been incredibly creative in developing ancillary systems that modify a printed parts mechanical properties.  These systems mostly focus on the issue of anisotropic properties of additively built components.  This blog post is a good reference if you are unfamiliar with isotropic vs anisotropic properties and how they impact 3d printing.  […] The post Cybersecurity Concerns for Ancillary Strength Control Subsystems appeared first on BreakPoint Labs - Blog.
Categories: Security Posts

Update on Naked Security

Naked Security Sophos - Tue, 2023/09/26 - 12:00
To consolidate all of our security intelligence and news in one location, we have migrated Naked Security to the Sophos News platform.
Categories: Security Posts
Syndicate content