The Android banking trojan known as Vultur has resurfaced with a suite of new features and improved anti-analysis and detection evasion techniques, enabling its operators to remotely interact with a mobile device and harvest sensitive data.

“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,” NCC Group researcher Joshua Kamp said in a report published last week.

Vultur was first disclosed in early 2021, with the malware capable of leveraging Android’s accessibility services APIs to execute its malicious actions.

The malware has been observed to be distributed via trojanized dropper apps on the Google Play Store, masquerading as authenticator and productivity apps to trick unwitting users into installing them. These dropper apps are offered as part of a dropper-as-a-service (DaaS) operation called Brunhilda.

Other attack chains, as observed by NCC Group, involve the droppers being spread using a combination of SMS messages and phone calls – a technique called telephone-oriented attack delivery (TOAD) – to ultimately serve an updated version of the malware.

“The first SMS message guides the victim to a phone call,” Kamp said. 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 [legitimate] McAfee Security app.”

The initial SMS message aims to induce a false sense of urgency by instructing the recipients to call a number to authorize a non-existent transaction that involves a large sum of money.

Upon installation, the malicious dropper executes three related payloads (two APKs and one DEX file) that register the bot with the C2 server, obtain accessibility services permissions for remote access via AlphaVNC and ngrok, and run commands fetched from the C2 server.

One of the prominent additions to Vultur is the ability to remotely interact with the infected device, including carrying out clicks, scrolls, and swipes, through Android’s accessibility services, as well as download, upload, delete, install, and find files.

In addition, the malware is equipped to prevent the victims from interacting with a predefined list of apps, display custom notifications in the status bar, and even disable Keyguard to bypass lock screen security measures.

“Vultur’s recent developments have shown a shift in focus towards maximizing remote control over infected devices,” Kamp said.

“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.”

The development comes as Team Cymru revealed the Octo (aka Coper) Android banking trojan’s transition to a malware-as-a-service operation, offering its services to other threat actors for conducting information theft.

“The malware offers a variety of advanced features, including keylogging, interception of SMS messages and push notifications, and control over the device’s screen,” the company said.

“It employs various injects to steal sensitive information, such as passwords and login credentials, by displaying fake screens or overlays. Additionally, it utilizes VNC (Virtual Network Computing) for remote access to devices, enhancing its surveillance capabilities.”

Octo campaigns are estimated to have compromised 45,000 devices, primarily spanning Portugal, Spain, Turkey, and the U.S. Some of the other victims are located in France, the Netherlands, Canada, India, and Japan.

The findings also follow the emergence of a new campaign targeting Android users in India that distributes malicious APK packages posing as online booking, billing, and courier services via a malware-as-a-service (MaaS) offering.

The malware “targets theft of banking information, SMS messages, and other confidential information from victims’ devices,” Broadcom-owned Symantec said in a bulletin.

Jan 24, 2024NewsroomCloud Security / Kubernetes

Cybersecurity researchers have discovered a loophole impacting Google Kubernetes Engine (GKE) that could be potentially exploited by threat actors with a Google account to take control of a Kubernetes cluster.

The critical shortcoming has been codenamed Sys:All by cloud security firm Orca. As many as 250,000 active GKE clusters in the wild are estimated to be susceptible to the attack vector.

In a report shared with The Hacker News, security researcher Ofir Yakobi said it “stems from a likely widespread misconception that the system:authenticated group in Google Kubernetes Engine includes only verified and deterministic identities, whereas in fact, it includes any Google authenticated account (even outside the organization).”

The system:authenticated group is a special group that includes all authenticated entities, counting human users and service accounts. As a result, this could have serious consequences when administrators inadvertently bestow it with overly permissive roles.

Specifically, an external threat actor in possession of a Google account could misuse this misconfiguration by using their own Google OAuth 2.0 bearer token to seize control of the cluster for follow-on exploitation such as lateral movement, cryptomining, denial-of-service, and sensitive data theft.

To make matters worse, this approach does not leave a trail in a manner that can be linked back to the actual Gmail or Google Workspace account that obtained the OAuth bearer token.

Sys:All has been found to impact numerous organizations, leading to the exposure of various sensitive data, such as JWT tokens, GCP API keys, AWS keys, Google OAuth credentials, private keys, and credentials to container registries, the last of which could then be used to trojanize container images.

Following responsible disclosure to Google, the company has taken steps to block the binding of the system:authenticated group to the cluster-admin role in GKE versions 1.28 and later.

“To help secure your clusters against mass malware attacks that exploit cluster-admin access misconfigurations, GKE clusters running version 1.28 and later won’t allow you to bind the cluster-admin ClusterRole to the system:anonymous user or to the system:unauthenticated or system:authenticated groups,” Google now notes in its documentation.

Google is also recommending users to not bind the system:authenticated group to any RBAC roles, as well as assess whether the clusters have been bound to the group using both ClusterRoleBindings and RoleBindings and remove unsafe bindings.

Orca has also warned that while there is no public record of a large-scale attack utilizing this method, it could be only a matter of time, necessitating that users take appropriate steps to secure their cluster access controls.

“Even though this is an improvement, it is important to note that this still leaves many other roles and permissions that can be assigned to the group,” the company said.

Dec 19, 2023The Hacker NewsSoftware Security / Threat intelligence

Threat actors are increasingly making use of GitHub for malicious purposes through novel methods, including abusing secret Gists and issuing malicious commands via git commit messages.

“Malware authors occasionally place their samples in services like Dropbox, Google Drive, OneDrive, and Discord to host second stage malware and sidestep detection tools,” ReversingLabs researcher Karlo Zanki said in a report shared with The Hacker News.

“But lately, we have observed the increasing use of the GitHub open-source development platform for hosting malware.”

Legitimate public services are known to be used by threat actors for hosting malware and acting as dead drop resolvers to fetch the actual command-and-control (C2) address.

While using public sources for C2 does not make them immune to takedowns, they do offer the benefit of allowing threat actors to easily create attack infrastructure that’s both inexpensive and reliable.

This technique is sneaky as it allows threat actors to blend their malicious network traffic with genuine communications within a compromised network, making it challenging to detect and respond to threats in an effective manner. As a result, the chances that an infected endpoint communicating with a GitHub repository will be flagged as suspicious is less likely.

The abuse of GitHub gists points to an evolution of this trend. Gists, which are nothing but repositories themselves, offer an easy way for developers to share code snippets with others.

It’s worth noting at this stage that public gists show up in GitHub’s Discover feed, while secret gists, although not accessible via Discover, can be shared with others by sharing their URL.

“However, if someone you don’t know discovers the URL, they’ll also be able to see your gist,” GitHub notes in its documentation. “If you need to keep your code away from prying eyes, you may want to create a private repository instead.”

Another interesting aspect of secret gists is that they are not displayed in the GitHub profile page of the author, enabling threat actors to leverage them as some sort of a pastebin service.

ReversingLabs said it identified several PyPI packages – namely, httprequesthub, pyhttpproxifier, libsock, libproxy, and libsocks5 – that masqueraded as libraries for handling network proxying, but contained a Base64-encoded URL pointing to a secret gist hosted in a throwaway GitHub account without any public-facing projects.

The gist, for its part, features Base64-encoded commands that are parsed and executed in a new process through malicious code present in the setup.py file of the counterfeit packages.

The use of secret gists to deliver malicious commands to compromised hosts was previously highlighted by Trend Micro in 2019 as part of a campaign distributing a backdoor called SLUB (short for SLack and githUB).

A second technique observed by the software supply chain security firm entails the exploitation of version control system features, relying on git commit messages to extract commands for execution on the system.

The PyPI package, named easyhttprequest, incorporates malicious code that “clones a specific git repository from GitHub and checks if the ‘head’ commit of this repository contains a commit message that starts with a specific string,” Zanki said.

“If it does, it strips that magic string and decodes the rest of the Base64-encoded commit message, executing it as a Python command in a new process.” The GitHub repository that gets cloned is a fork of a seemingly legitimate PySocks project, and it does not have any malicious git commit messages.

All the fraudulent packages have now been taken down from the Python Package Index (PyPI) repository.

“Using GitHub as C2 infrastructure isn’t new on its own, but abuse of features like Git Gists and commit messages for command delivery are novel approaches used by malicious actors,” Zanki said.