James Kilner contributed to the technical editing of this blog. Nethanella Messer, Segev Fogel, Or Ben Nun and Liran Tiebloom contributed to the blog.

Although in the PC realm it is common to see financial malware used in web attacks to commit fraud, in Android-based financial malware this is a new trend. Traditionally, financial malware in Android uses overlay techniques to steal victims’ credentials.

In 2022, IBM Security Trusteer researchers discovered a new trend in financial mobile malware that targets Android and is replacing the classic overlay M.O. (Modus Operandi). These new attacks use the good-old web attack tactics with adjustments made for Android. IBM Trusteer has dubbed these attack tactics Mobile Web(View) attacks because the attack vector is the Android WebView component, and not the browser application (for reasons that will be explained in the following sections).

In this blog, two extremely effective attack techniques are discussed: Web(View) injection attack (based on web injects in the browser) and mobile cookie stealing.

What is a web injection attack?

A web injection attack is a technique used by malware to exfiltrate and manipulate the content of a website from the client side as it is being presented by the browser. During a web injection attack, the malware injects HTML or JavaScript code into the website by running code in the scope of the web browser process that is installed on the victim’s device.

In a web injection attack, what the victim sees in the browser might be different from what is intended by the web server. In addition, every private detail entered by the victim on the website is exposed to the malware.

For example, the JavaScript code that is injected by the malware can extract data from an HTML form that the user has filled in. Using this method, the malware can steal login credentials, credit card numbers, CVVs and so on. That data can then be sent to the command-and-control server (C2C) of the malware operator.

Another common example of a web injection attack is to manipulate the visuals of a website. This type of web injection attack can be used to insert new fields to steal additional personal identifiable information (also known as PII) that is not requested by the legitimate service or even to remove existing fields, which can prevent the user from seeing security warnings. This attack is also used by malware to perform on-device fraud (ODF) by changing the payee of a transaction initiated by the victim to the fraudster mule account.

Figure 1 — An example of injected JavaScript code. The injection creates a fake login form of an e-commerce company instead of the original content of the legitime website (left) versus the original HTML of the legitime website (right).

Figure 2 — The result of the injected JavaScript code: a fake login form of an e-commerce company (left) versus the original legitime website (right).

Due to all of these capabilities, the web injection technique is especially common among desktop financial malware, such as the Zeus Sphinx variant, IcedID and TrickBot.

Why are there no web injection attacks on mobile?

Although the use of web injection attacks has become the standard for desktop financial malware, this is not the case for mobile. Instead, financial malware on Android mostly uses the overlay technique, and more recently RAT techniques to steal victims’ credentials.

The reason web injection is not used in mobile is that on a non-rooted Android phone (and without using exploits), code injection to the browser application process (or to any other application on the device) is not possible. The Android operation system enforces these restrictions with the implementation of Android sandboxing.

Android Sandbox

In general, in Android OS, a distinct Linux user ID (UID) is assigned to each installed application. Android uses this UID to set up a kernel-level Application Sandbox. The kernel-enforced process isolation prevents applications from injecting code into each other, accessing each other’s files and resources, and manipulation of their code. Due to the sandbox protections, mobile malware cannot inject code into other browser applications such as Google Chrome and cannot inject code into the real banking application. As a result, Android malware cannot perform classic web injection attacks on Android.

Figure 3 — An example showing the UID of three processes running on a device: a banking application, a malware application, and the Chrome browser application.

Challenge accepted: Introducing the Web(View) inject attack

Android WebView

WebView is an embeddable browser inside an app that is used to load a URL. The WebView element is a part of the application it is running within; therefore, it is not protected by the Android Sandbox. In fact, Android allows an application to inject JavaScript code into its own WebView.

According to the malware analyzed by IBM Trusteer, to manipulate a banking website, the malware impersonates the banking application and runs a WebView that loads a legitimate URL of the bank. The malware injects JavaScript code that is required for the attack into its own WebView and uses that code to intercept text entered by the victim into the HTML fields such as the victim’s username and password.

The overall attack flow is shown in the following figure:

Figure 4 — Web(View) Inject attack flow.

*Smishing, also known as SMS-phishing, is a mobile text message containing a link to download malware or visit a malicious site via phishing.

How can malware inject its own code into a WebView element?

Introducing Android JavaScript interface

Android provides developers with an interface that allows them to bind JavaScript code into an Android app that uses a WebView. Android developers who build a web application using WebView can create interfaces between the JavaScript code and native Android code.

The application must know the exact names of the fields within the HTML of the legitimate site to use this technique. In turn, the JavaScript code must know the exact names of the Android functions within the interface to interact with them.

In the malware that Trusteer analyzed, the names of the Android JavaScript interface functions can be seen: “sendCerd,” “closeFrom,” and “sendBalance.” When the user enters their username and password, the malware extracts the values using the val() jQuery function and sends the information to the C2C. The script can get values from text fields in the HTML that the user filled in, including special fields with type=”Password”.

To mark potentially interesting targets, the attacker is specifically interested in the balance of the victim’s account. The code to retrieve the balance has a timeout of 3 seconds.

Figure 5 — The malware JavaScript code.

Figure 6 — The malware corresponding JavaScript interface from the Android side.

After the malware exfiltrates the victim’s PII, the victim continues through the following web pages on the legitimate website without raising their suspicions.

WebView settings

To inject the JavaScript code, the malware sets the WebView settings “setJavaScriptEnabled” and “setDomStorageEnabled” to “true”.

Figure 7 — The malware’s WebView settings. Note the use of a constant user-agent of a Samsung device (SM-A205U).

Injecting JavaScript

After setting up the Android JavaScript and the WebView, the malware can inject the JavaScript code into its own WebView with the loadUrl() function. In the malware analyzed by Trusteer, the JavaScript was Base64 encoded. Looking at the source of the injected page, the injection code is not human readable; however, since it is only Base64 encoded, it can be easily decoded.

Figure 8 — The malware’s Base64 encoded JavaScript injected code.

Web(View) attack versus overlay attack

In this attack dubbed Web(View) Injection by IBM Security Trusteer, the malware loads a legitime URL of the bank rather than a fake activity or a fake phishing site. In an overlay attack, the malware shows the victim a fake overlay screen mimicking the bank’s login page on top of the real banking app.

One advantage of the Web(View) Inject method is that the malware doesn’t need to change the design of the overlay screen every time the bank changes its UI since it is injecting straight into the legitimate banking site.

Another advantage is that this attack requires fewer permissions than an overlay attack, which usually requires at least the “android.permission.SYSTEM_ALERT_WINDOW” permission. In fact, Web(View) attack requires only the “android.permission.INTERNET” permission to be declared in the manifest. This permission is extremely common and therefore much less suspicious.

This is not the first time mobile malware has used the Web(View) inject technique, but this is the first time that IBM Trusteer researchers have identified it being used by mobile financial malware.

Web(View) Injection is not the only web attack technique IBM Trusteer detected that financial malware used in Android.

The next attack discussed in this blog is a Mobile Cookie Stealing attack that, much like the Web(View) Injection attack, targets the Android WebView component.

What is a cookie stealing attack?

Cookies are strings of text and numbers that websites store in the browser to save the login state or track the user’s activity on the website.

Cookies are used as session identifiers. Various websites including banks and cryptocurrency sites use cookies as session identifiers for their login pages. If a fraudster steals a cookie from the browser after the user logged in, the fraudster might be able to use the cookie to steal the victim’s session (as long as the cookie hasn’t expired) without even having to know the victim’s credentials.

This attack has recently gained popularity among financial mobile malware, such as SOVA’s remake malware MailBot, FluBot, SharkBot, and Hydra, the newer version of BianLian.

Who stole the cookie from the Android jar?

As stated in the Android Sandbox section, an Android application cannot manipulate the browser application directly and, as a result, can’t steal cookies from it without the victim’s knowledge. However, cookie stealing can be done from its own WebView.

BianLian is a piece of financial malware that has overlay capabilities as well as RAT capabilities. IBM Trusteer researchers have analyzed the BianLian malware, aka Hydra, and here BianLian’s implementation of the cookie stealing attack is unpacked. The overall attack flow is shown in the following figure:

Figure 9 — Cookie stealing attack flow

The malware creates an instance of CookieManager and then the “getCookie()” method is used with the legitimate URL loaded to get the cookie.

Figure 10 — BianLian’s cookie theft function.

BianLian steals cookies from e-mail, social networking and financial applications, using the real application’s URLs:

Figure 11 — BianLian’s cookie theft configuration list.

BianLian detects when the user opens one of the targeted apps using the accessibility service. It then overlays the legitimate application with its own WebView loaded with the real login URL of the targeted application. This way, from the victim’s perspective, everything seems to be as expected. However, any interaction the victim has from this point on is with the malware screen and not the actual application.

The malware WebView has the “setMixedContentMode” property set to load content from any other origin, even if that origin is insecure. It also has the “setCacheMode” property set to load no cache, which means loading from the network.

The malware then waits for the user to log in to the service. It makes sure the victim is successfully logged into their account by checking the loaded URL with the “onPageFinished” method and then grabs the session cookie using the Cookie manager.

Once it steals the cookie, BianLian sends the cookie to its C2C (at the time of writing, the malware sends requests to the server unencrypted via HTTP). Finally, the fraudster uses the stolen cookie to hijack the victim’s session.

Fewer permissions, fewer suspicions

Similar to the Web(View) injection attack, the cookie stealing attack requires only the “android.permission.INTERNET” permission.

Note that even if the website uses HTTPS, the malware can still intercept the cookie value with the described technique.

Conclusion

Although it took more than a decade, web attack techniques have finally made their move to mobile. In this blog, we have detailed two such attack techniques translated from PC to Android in the form of WebView abuse attacks: the Web(View) injection attack and Mobile Cookie grabbing.

Every Android application is exposed to these attacks because malware can use a WebView to load any service URL that has an online login page and inject it with its own JavaScript, which effectively gains full control of the website (from the client perspective).

The biggest risk from the Web(View) Inject attack is the fact this attack might allow an attacker to perform ODF, where transactions are initiated from the same device that the victim uses daily. This is a known M.O. used by PC financial malware, where the attacker replaces the payee of each money transaction with their own account. The fraudulent transaction is initiated by the victim from the legitimate device, making it look less suspicious.

Because this technique requires only a few permissions and is relatively easy to implement for anyone familiar with Web attack in PC, IBM Trusteer expects WebView attacks in Android to be seen more frequently in financial malware in the future.

Malware IOCs

The post A view into Web(View) attacks in Android appeared first on Security Intelligence.

Nethanella Messer and James Kilner contributed to the technical editing of this blog.

IBM Trusteer researchers continually analyze financial fraud attacks in the online realms. In recent research into mobile banking malware, we delved into the BrazKing malware’s inner workings following a sample found by MalwareHunterTeam. BrazKing is an Android banking Trojan from the RAT category. It mostly targets mobile banking users in Brazil and is likely operated by a local threat group.

This post provides our findings about BrazKing’s new version with insights about its dynamic mechanisms and the features that help cyber criminals use it in mobile banking fraud. As this post is written, we are seeing that BrazKing is an ongoing development and believe there will be more to come in the near future.

New BrazKing With Added Agility

With a new version in the wild, we set out to look at what changed for BrazKing since the last version. It turns out that its developers have been working on making the malware more agile than before, moving its core overlay mechanism to pull fake overlay screens from the command and control (C2) server in real time.

In the previous version, BrazKing abused the accessibility service to detect which app the user opened. When the malware detected the launch of a targeted banking app, it used to pull an overlay screen from a hardcoded URL and present it on top of the legitimate app. Now, it automates a call to the attacker’s server, requesting those matches on the fly. The detection of which app is being opened, is now done server side, and the malware regularly sends on-screen content to the C2. Credential grabbing is then activated from the C2 server, and not by an automatic command from the malware.

The agility that’s added here is that the attacker can choose the next action or avoid one according to information on the victim’s IP (Brazilian/other), or whether the malware is being run on an emulator. They can modify what’s sent back. They can adjust the target list at all times without modifying the malware itself.

This is a tactic that we have seen when desktop banking Trojans started delivering their configurations and web injections in the same manner. Android Trojans do that as well, and BrazKing’s developer has implemented that change in the version we analyzed.

Figure 1: BrazKing targets have a matching overlay the C2 can send and display on over legitimate apps

Same Overlay, but Different

Another point we observed in BrazKing is the way the same overlay concept from other malware is being implemented with a twist.

Classic overlay malware on Android devices overlays a fake screen on top of the original banking apps. To display that fake overlay on another running app, the malware must have the user approve a permission ‘android.permission.SYSTEM_ALERT_WINDOW’. Malware can also approve that permission without user interaction by abusing the Android accessibility service.

We noted that while BrazKing now works without the SYSTEM_ALERT_WINDOW permission, which allows BrazKing to be more elusive and arouse less suspicion, it remains in its manifest.

When BrazKing displays its overlay screen it loads the fake screen’s URL from the C2 to a webview in a window. Android System webview allows users to open links within apps they are using without having to leave the app. BrazKing uses TYPE_ACCESSIBILITY_OVERLAY as the type of window when adding the webview from within the accessibility service. This overlay window is then shown on screen—covering the original app and even screens like the ‘Settings’ menu window.

Figure 2: BrazKing overlay techniques keep it stealthier – 0x7F0 is hex code for TYPE_ACCESSIBLITY_OVERLAY flag

Behind the scenes, when displaying the overlay screen to the user, BrazKing can intercept the views in the background, tap buttons and even enter text in Android textviews while the legitimate app is covered with a fake overlay.

No Permissions, No Problem

Asking for very few permissions might make BrazKing look less harmful, and the small number of permissions that it does ask for are not categorized as dangerous to approve. BrazKing manages to work with a rather limited list of permissions, but what it lacks in permissions, it makes up for in Accessibility Service abuse. It utilizes all the capabilities of the accessibility service.

Let’s examine what it can do with only the accessibility service:

• Dissect the screen programmatically instead of taking screenshots in picture format. This can be done programmatically but on a non-rooted device that would require explicit approval of the user.
• Keylogger capabilities by reading the views on the screen.
• RAT capabilities—BrazKing can manipulate the target banking application by tapping buttons or keying text in.
• Read SMS without the ‘android.permission.READ_SMS’ permission by reading text messages that appear on screen.
• Read contact lists without ‘android.permission.READ_CONTACTS’ permission by reading the contacts on the “Contacts” screen.

There are also permissions that were dropped since the previous version. For example, ‘android.permission.BIND_DEVICE_ADMIN’ is no longer used in the new version. That permission was previously used to allow the attacker to lock the device and hide malicious activity from the user. With the overlay covering the entire screen, this suspicious permission is no longer required.

Dropping risky permissions is an advantage to the malware as it is less likely to be flagged by automated controls.

BrazKing’s Infection Routine

The following sections give a technical rundown of BrazKing’s infections routine per our analysis of the current version of this malware.

Initial Download

The initial infection vector is a phishing message with a URL that leads to a website claiming the device is about to be blocked due to a supposed lack of security. It requires the user to ‘update’ the operating system by tapping a button on the page. The site uses HTTPS, making it appear more credible.

Figure 3: BrazKing starts off with a social engineering message

Tapping the button launches the download of BrazKing. The app is downloaded via the browser, and then installed by the package manager. To make that happen, the user does have to approve the download of apps from unknown sources. After the initial download, the malware attempts to have the user approve permissions under the guise of a Google requirement.

Requesting Access to the Accessibility Service

Accessibility Services are what allows malware like BrazKing to forego permissions. It requests access to this service in order to activate the ability to capture the screen and keystrokes that it will later send to the C2. It also uses it to detect running banking apps that would be of interest to its operators.

The request for access takes place during the first run of BrazKing on a newly infected device. To trick the user to approve the request, the malware impersonates a Google update, or a service as shown below.

Figure 4: BrazKing asking for Accessibility Service access

First Run – New Bot Registration

Once the user accepts the accessibility service request, the malware starts running in the background. Most users would see that as going back to normal. In versions of Android 10 and below, the malware’s app icon disappears from the screen.

BrazKing’s activity commences as it sends a request to the C2 server, registering a new infected bot to the botnet. It sends over the following details:

• Device data:
  • BUILD version
  • Device name
  • OS version
  • Device manufacturer
  • Android ID. This ID is used as a bot identifier dubbed ‘hwid’. Android IDs are a 64-bit number (expressed as a hexadecimal string), unique to each combination of app-signing key, user and device.
• List of apps installed on the device (removed in some versions, added in others).
• Display properties: height, width.

Figure 5: BrazKing sends new bot info to C2 server

Once the bot has been registered, BrazKing is ready and listening for commands from the C2 server.

Trusteer researchers often encounter malware that tests whether it is running in a testing environment, such as an emulator, and if so, stops running. We have not observed such checks in BrazKing’s code, but we did notice that the list of device details it sends to the C2 will differ when it’s run in an emulator as compared to running on a physical device. We conclude that blocking research devices might be possible via BrazKing’s server-side code.

Remove-Me-Not

Persistence is a malware must-have, and BrazKing’s developers do not want to see it easily removed. To prevent deletion, the malware takes over when the user attempts to remove it. With accessibility service monitoring, BrazKing is programmed to notice when the user is opening the uninstall screen. Should the user attempt to restore the device to manufactory settings, BrazKing would quickly tap the ‘Back’ and ‘Home’ buttons faster than a human could, preventing them from removing the malware in that manner.

The same tactic is used when users attempt to interact with antivirus apps, returning them to the home screen if they attempt to launch an app to run a scan or quarantine malware.

BrazKing’s New Obfuscation Techniques

BrazKing uses string obfuscation to keep its resources protected. It applies a XOR operation with a constant key that’s hardcoded into the malware binary. Then it also encodes with Base64. By using a constant key inside the sample, the obfuscation can be easily reversed.

Figure 6: BrazKing’s obfuscated strings

After de-obfuscating the strings, we were able to see their content, which matches with device information BrazKing sends over to its operators.

Figure 7: BrazKing’s strings – De-obfuscated

Ongoing C2 Communications

To communicate with the attacker’s server during its ongoing operations, BrazKing uses the WebSocket protocol. WebSocket differs from the more typical HTTP, which is often used by financial malware. Rather than looking at a series of requests and responses, like HTTP requires, WebSocket works as a bidirectional messaging protocol. The WebSocket handshake uses the HTTP upgrade header to switch from the HTTP protocol to the WebSocket protocol and BrazKing queues task threads. Each thread executes a different task sent from the C2.

We have seen the WebSocket protocol choice previously used by other malware operators in Brazil.

BrazKing’s list of commands appears below:

BrazKing’s Fraud Enabling Features

BrazKing’s goal is to help its operators initiate and complete fraudulent transactions from infected user devices. To do that, it leverages a few core capabilities:

• Input injection – allowing the fraudster to interact with running apps on the device.
• Screen dissection – providing the attacker with insights as to what the user sees on their screen.
• Keylogging – helping attackers grab credentials from the device.
• Fake overlay screens – allowing BrazKing to trick users into sharing credentials, and also blocking them from interacting with the legitimate app they intended to use.

Each of these features is described in more detail below. We will follow the technical details with an explanation of BrazKing’s fraud modus operandi.

Input Injection

As its name suggests, this feature allows BrazKing to interact with apps as if they were the device’s owner. Abusing Android’s Accessibility Service, the malware can tap buttons, select options, enter text and perform other actions on behalf of the user. This process is assisted by the attacker from the C2 server, enabling them to choose which views BrazKing will click on or what text it might tap, thereby controlling what information is sent through to the bank’s server during a transaction.

Figure 8: BrazKing’s text injection function

Screen Dissection

Via the C2, the attacker can send a command to the malware asking to see what the user is viewing at the time. In response, BrazKing will send the following details:

• Bot ID
• View type: is it a text box? Are there buttons?
• Is there clickable content that’s visible to the user?
• Width and height of the view?
• What’s the text shown on the view?
• The package name of the application that’s currently running on screen.

In previous versions, this command was pushed manually. In the new version, the malware sends the details to the C2 on repeat.

Using the information from BrazKing, the fraudster can understand what the victim is viewing on screen and use this insight to plan a fraudulent transaction.

Keylogging

Abusing the Android Accessibility Service again, BrazKing is able to captures all user keystrokes.

When text on a text box is modified/entered by the user, the event triggers the Accessibility Service, which in turn triggers BrazKing. This allows the malware to obtain the text in the textbox and send it to the C2. Examples of such text can be a URL in the web browser, a text message or a password field.

Figure 9: Looking for on-screen text and grabbing passwords

The ‘Kly’ string indicates that the data sent to C2 was collected by the keylogger module.

If BrazKing detects that a password is being entered by the user, the malware captures each letter of the password separately, since on a text field only the last entered character is visible to the user and all other characters are displayed as asterisks. The malware saves each letter and ignores the asterisk characters. All the keystrokes are sent to the C2 from the configuration file.

Figure 10: BrazKing saves passwords by character, then sends them to a C2 server alongside device data

Fake Overlay Screens

BrazKing uses two typical fake overlay images. One interacts with the infected user, asking for their payment card’s PIN number. The other image keeps them waiting, unable to continue to interact with the app they originally opened.

Figure 11: BrazKing’s social engineering overlays

App List No Longer Required

Most banking Trojans that target Android users ask to have the list of installed apps sent to their operators. BrazKing used to also fetch that list by using the ‘getinstalledpackages’ API. This is a common malware request, but as of Android version 11 (SKD 30) Google views the app list as sensitive information. They now require apps to query what they need from the overall list, and the complete list is thus filtered.

To get the entire list, the malware would have to declare android.permission.QUERY_ALL_PACKAGES or ‘Query’ element in the manifest.

BrazKing avoids hoarding permissions, so it has removed this ask, and instead relies on the screen dissection feature to view what apps the user might be looking at.

Figure 12: BrazKing’s target list exposed in some of the versions we analyzed

BrazKing’s Fraud Techniques

BrazKing does not automate fraud on infected devices; that activity is controlled through the C2 server. The malware’s operators are likely tailoring the attack to each bank. Therefore, according to our analysis, there can be several attack scenarios that BrazKing operators can tailor according to security controls used by different banks. Those can be altered with relative ease.

Opening the Banking App

Scenario A

The C2 sends a command to the malware to show a message on screen and lure the user to open the banking application.

Scenario B

The C2 sends a command to the malware to open the banking app.

Fraud M.O.

After the banking app opens, the malware subsequently allows the attacker to log keystrokes, extract the password, take over, initiate a transaction, and grab other transaction authorization details to complete it.

Lock & Delay

The malware is capable of locking the phone’s screen and presenting the user with a delay screen.

Stealing 2FA Codes

Scenario A

When the user receives an SMS-based transaction authorization challenge from the bank, BrazKing can display a fake PIN code on screen to the user, all while the attacker can use the stolen code to complete the fraudulent transaction.

Scenario B

BrazKing can use its keylogging feature to steal SMS-based two-factor authentication (2FA).

Mobile Banking Malware Prevalent in the Fraud Arena

Major desktop banking Trojans have long abandoned the consumer banking realms for bigger bounties in BEC fraud, ransomware attacks and high-value individual heists. This, together with the ongoing trend of online banking transitioning to mobile, caused a void in the underground cybercrime arena to be filled by mobile banking malware.

These one-stop-shop codes are simpler to operate, easier to obtain and can facilitate the complete fraud cycle by being resident on what was previously an out-of-band device — the smartphone. The access to 2FA codes at the same place where credentials are obtained is pivotal, and helps fraudsters continue to profit from mobile malware, mostly on Android devices.

Indicators of compromise from the BrazKing versions we analyzed appear below. If you would like to keep up to date on IBM Trusteer research, please check out: securityintelligence.com/category/x-force. For more about IBM Trusteer and the ways we help customers mitigate the risk and losses of fraud, please visit: www.ibm.com/security/fraud-protection/trusteer

IOCs

The post BrazKing Android Malware Upgraded and Targeting Brazilian Banks appeared first on Security Intelligence.

Cryptomining has become a lucrative industry, growing more and more mainstream. Now, attackers are trying to grab a bit of that cash with apps that claim to automate it. But when downloaded, the apps don’t do anything except take your money.

Lookout found that a total of 172 apps, including 25 on Google Play, promised users cloud-based cryptomining services for a fee. In truth, those apps never delivered those services.

Take a look at how these apps succeeded in stealing over $350,000 from nearly 100,000 victims.

Inside the BitScam and CloudScam Apps

Lookout did a deep dive into two types of apps, which they sorted into the BitScam and CloudScam families. All of these used a similar code base and design as one another despite advertising different cryptomining operations.

“They are simply shells to collect money for services that don’t exist,” Lookout reported.

Lookout’s researchers observed that whoever had created the BitScam apps had done so using a framework that didn’t require programming experience. Both apps asked users to use Google Play’s in-app billing system to purchase cryptomining subscriptions and services. BitScam also allowed users to pay using bitcoin and Ethereum.

Once installed, the apps loaded a dashboard that displayed a fake hash mining rate as well as the amount of coins that the users had supposedly earned. They also informed users that they could increase their hash mining rate by purchasing other services or subscription upgrades.

It was all a ruse, of course. The in-app updates did nothing to change the mining ‘rate’ either.

What’s more, the apps prevented users from withdrawing any of their mined ‘coins’. The programs displayed a message saying that the withdrawal was pending, but in the background, the apps reset the user’s coin balance to zero.

Other Fake Cryptomining Apps

While cryptocurrency is in the public eye more now than when it began, this kind of app has been around for years. Back in 2018, for instance, security researcher Lukas Stefanko discovered four apps that all impersonated cryptocurrency services. They leveraged that guise to steal users’ cryptocurrency wallet credentials and/or to trick them into sending money to the attackers.

Several years later, Intezer Labs came across an operation targeting users with fake cryptocurrency-related apps. Once installed, those apps dropped ElectroRAT, a Golang-based malware strain which targeted Windows-, macOS- and Linux-based systems.

How to Defend Against Cryptomining Scam Apps

Security teams can help their organizations to protect their employees against threats like BitScam and CloudScam using ongoing awareness training. They can use it to educate their employees about mobile security best practices, such as downloading apps from trusted developers only and installing apps from only an official app store. They can also draw on threat intelligence to keep their users up to date on some of the newest mobile threats.

The post Fake Cryptomining Apps Stole Over $350K From Android Users appeared first on Security Intelligence.

Who stalks the stalkers? When it comes to Android security, stalkerware presents a double risk.

It’s common knowledge that mobile stalkerware undermines a target’s privacy. That’s kind of the point. A stalkerware incident often involves someone, such as a spouse, gaining physical access to someone’s smartphone and installing a monitoring app. They then use that software to remotely track what another person is doing on the device or spy on where they’re going.

What’s not so widely known is that stalkerware vendors don’t always code their apps correctly.

For instance, ESET found over 150 errors in 58 stalkerware Android apps. Those issues not only further compromised targets’ Android security and privacy, they also put the snoopers themselves at risk.

Read on to learn which weaknesses appeared most frequently in the apps surveyed.

Android Security Stalkerware Problems at a Glance

Out of the 158 issues ESET found, the most common type was insecure transmission of users’ personally identifiable information. This category accounted for 22 vulnerabilities, ranking higher than storing sensitive information on external media and exposing sensitive user information to unauthorized access, which account for 19 and 17 weaknesses, respectively.

The fourth most prevalent problem, at 17 weaknesses, was server leak of stalker information. ESET found that several stalkerware apps kept information about those using the app to track someone. It also stored a victim’s data on a server — even after the stalker requested that the service delete their information. That data might have included more information about the tracker in the event that they had an existing connection with the target.

Sometimes, victims’ information remained on a stalkerware service’s servers even after the snooper removed their account.

ESET reported the Android security and privacy issues to the stalkerware vendors as part of its 90-day responsible disclosure policy. As of reporting, only six responded by fixing the issues, while seven said that they were working on a fix. One vendor decided not to fix the reported issues; the rest didn’t respond.

The Growth of Stalkerware

ESET’s researchers also found that Android stalkerware detection increased by 48% between 2019 and 2020. This growth has continued into 2021. For example, Avast observed a 93% increase in the volume of spyware and stalkerware app detection over the first two months of the year. That’s compared to the same time period in 2020.

In response, some digital defense groups took action. For instance, the Coalition Against Stalkerware developed a standard definition of stalkerware, which encouraged research into the way it spreads. They also created TinyCheck for the purpose of detecting stalkerware apps, which can pose threats to Android security as well as to other brands of smart phones, in a more efficient manner.

How to Defend Against Stalkerware

The issues discussed above highlight the need for organizations to defend themselves against stalkerware. One of the ways they can do that is to educate their employees about what to look for. For example, smart phone users should delete unused apps and look for strange changes on their devices. In addition, never leave your devices unattended.

In the event organizations discover stalkerware installed on a connected device, they need to approach removal carefully. The best thing to do is to not notify the victim in a way that could be discovered on the compromised device. Instead, they should speak to the victim in person and proceed from there.

The post Android Security: Over 150 Security and Privacy Issues Found on Stalkerware appeared first on Security Intelligence.

Last week in security news, researchers revealed that the average ransomware demand grew 14 times over a one-year period from 2018 to 2019. Ransomware wasn’t the only malware category that made headlines this past week. A strain of Android malware caught researchers’ attention by limiting its malicious activity to a single capability. Yet another threat received some attention for its growing interest in creating backdoor functionality on infected Windows machines.

Top Story of the Week: A Leap in Ransomware Demand Amounts

Citing industry researchers, Group-IB revealed that the average ransom demanded from a victim increased 14 times, from $6,000 to $84,000, in the span of one year. And this observation didn’t even capture some of the largest ransomware demands of 2019.

Out of all the ransomware families, Ryuk was the worst, according to researchers. In one attack, the crypto-malware coerced two cities in Florida into handing over a combined ransom payment of $1 million. In another attack, threat actors demanded $5 million — the largest demand ever recorded, noted Group-IB — from a town in Massachusetts.

Source: iStock

Also in Security News

• Portuguese Banks Caught in the Crosshairs of New Grandoreiro Variant: Segurança Informática revealed that it spotted a new variant of the Grandoreiro malware family targeting Portuguese banks. This variant operated similarly to previous versions, but it also improved the way in which it communicated with its command-and-control (C&C) server.
• Malicious Functionality of DEFENSOR ID Limited to Single Action: Researchers at ESET learned that an Android malware strain called “DEFENSOR ID” had succeeded in bypassing Google Play’s security checks. It did so by limiting its malicious functionality to a single action: requesting access to Accessibility Services for the purpose of emptying victims’ financial accounts.
• New Flaw Allows Malicious Apps to Masquerade as Legitimate: Promon researchers detected a critical severity vulnerability that enabled malicious Android applications to camouflage themselves as legitimate programs in order to remain hidden. They named the flaw “StrandHogg 2.0” due to its similarities with the original StrandHogg flaw discovered in 2019.
• Phishers Target Office 365 Details With Fake Supreme Court Subpoenas: A phishing campaign detected by Armorblox sent out attack emails that used “Supreme Court” as the sender identity and used authoritative language to coerce recipients into clicking a “View Subpoena” button. Those who complied found themselves redirected to a fake Office 365 login page.
• Continued Interest in Backdoor Functionality Held by Sarwent Malware: SentinelOne came across a new sample of the Sarwent malware family that demonstrated sustained interest in using PowerShell commands and other techniques to perform backdoor functionality. Updates to the threat also provided evidence of a preference for abusing Remote Desktop Protocol (RDP).
• Plaintext Passwords Targeted by Modified Discord Client: According to Bleeping Computer, attackers released a new version of the AnarchyGrabber malware family called “AnarchyGrabber3.” This threat abused a modified Discord client to steal users’ plaintext passwords and relied on commands to spread to victims’ friends on Discord.
• New Versions of Valak Malware Deployed in U.S., German Campaigns: In April 2020, Cybereason identified multiple attack campaigns leveraging new variants of the Valak malware family to prey on targets in the United States and Germany. Researchers found over 30 versions of the malware, a discovery that suggests that Valak’s authors made many improvements to their creation over a short period of time.
• Brute-Force Attacks Employed by PonyFinal Ransomware for Gaining Initial Access: Microsoft Security Intelligence revealed that a PonyFinal ransomware campaign leveraged brute-force attacks against a target organization’s systems management server as a means of gaining initial access. The campaign ultimately spread to endpoints with Java Runtime Environment (JRE) enabled to install its payload.

Security Tip of the Week: Strengthen Your Anti-Ransomware Defenses

Security professionals can help their organizations defend against a ransomware attack by making sure they have access to the latest threat intelligence. They can then use that information to stay on top of the latest ransomware attacks and techniques. Additionally, companies should leverage an endpoint management solution to monitor their endpoints for suspicious activity that could be indicative of a ransomware attack.

The post Weekly Security News Roundup: Average Ransomware Demand Grew 14 Times in One Year appeared first on Security Intelligence.

Security researchers uncovered a new Android malware strain called “DEFENSOR ID” that channels its malicious activity through a device’s Accessibility Services.

In its analysis, ESET observed DEFENSOR ID had succeeded in infiltrating the Google Play store, sneaking past mobile security checks by reducing its malicious functionality to a single action: requesting access to a device’s Accessibility Services. This privilege enabled the malware to perform 17 commands received from the attacker, including launching an app and performing a click action remotely instructed by its handlers.

By controlling a device’s Accessibility Services, DEFENSOR ID gave attackers the ability to steal access to and subsequently empty a victim’s cryptocurrency wallet or banking account. This privilege also gave malicious actors the ability to read SMS text messages for the purpose of intercepting a victim’s two-step verification (2SV) code in the event that they had enabled this security feature on their account.

Android Malware Abusing Accessibility Services

DEFENSOR ID isn’t the first Android malware to abuse Accessibility Services in 2020. In March, for instance, McAfee witnessed the Android/LeifAccess.A Trojan exploiting this Android feature to infect a device and post fake reviews on Google Play.

In April 2020, Check Point Research observed the Black Rose Lucy malware family using a fake streaming video optimization (SVO) prompt to trick a victim into granting access to their device’s Accessibility Services. Just a couple of days later, Cybereason detailed the efforts of EventBot to steal user data from financial apps by leveraging Accessibility Services.

Defend Against DEFENSOR ID

Security professionals can help defend their organizations against Android malware such as DEFENSOR ID by creating security policies around the use of mobile devices. Those policies should limit the marketplaces and developers from which employees can download apps onto their corporate devices. Teams should also consider leveraging tools powered by artificial intelligence (AI) to help detect the latest threat behaviors circulating in the wild.

The post New Android Malware Channels Malicious Activity Through Accessibility Services appeared first on Security Intelligence.

Last week in security news, researchers observed digital criminals selling a new malware strain based on the ZeuS family called “Silent Night.” This Trojan wasn’t the only new threat that made headlines last week. Security analysts also uncovered a new strain based on a leak of the DenDroid malware family along with a new backdoor employed by the Winnti Group.

Top Story of the Week: Introducing Silent Night

In May 2020, Malwarebytes observed a new malware strain whose design was reminiscent of the ZeuS banking Trojan family. Researchers also noticed that malware authors had compiled version 1.0 of the threat in November 2019, which indicated that the threat was new.

The security firm investigated the malware and found it being offered for sale on underground web forums. Named “Silent Night,” the threat arrived as a downloader that fetched its core malicious module and injected it into numerous running processes. This infection chain made use of legitimate components to achieve its nefarious ends.

Source: iStock

Also in Security News

• Reflective DLL Loading Employed by Attackers to Deploy Netwalker: Trend Micro observed malicious actors using a technique known as reflective dynamic-link library (DLL) loading to deploy samples of Netwalker ransomware. These attacks began with a PowerShell script and allowed malicious actors to load a DLL from memory instead of from a disk.
• E-Skimming Attacks Enabled by Magento Plugin Vulnerability: The FBI warned in an alert that it had witnessed malicious actors abusing a cross-site scripting bug in the Magento Mass Import plugin. This exploit granted digital attackers the ability to conduct e-skimming attacks without raising any red flags.
• New “WolfRAT” Malware Linked to DenDroid Family: Cisco Talos discovered that the Android-based “WolfRAT” threat shared command-and-control (C&C) infrastructure with the DenDroid malware family. Researchers also observed some links with Wolf Research, an organization known for developing espionage-based software.
• Multiple Phishing Campaigns Spoof New Azure AD Sign-In Page: In mid-May, Microsoft Security Intelligence detected numerous phishing operations that spoofed the new Azure AD sign-in page. One of those campaigns leveraged a PDF document disguised as a OneDrive document to redirect victims to a phishing website disguised as Microsoft’s sign-in page.
• Source Code for GhostDNS Exploit Kit Leaked Online: Avast’s Web Shield analyzed a .RAR archive and found that it contained the complete source code of the GhostDNS exploit kit. In effect, this linked file contained everything that an attacker needs to conduct a DNS hijack campaign and steal sensitive information inputted by victims.
• Android Devices Carefully Targeted by Mandrake Espionage Platform: In early 2020, Bitdefender came across the Mandrake platform while it was engaged in conducting phishing attacks against cryptocurrency wallets and other targets. Closer analysis revealed that Mandrake selected just a handful of Android devices for exploitation so as to avoid detection.
• New PipeMon Backdoor Employed by Winnti Group: In early February, ESET observed the Winnti Group employing a new modular backdoor called “PipeMon” to target video game developers located in Asia. In one of those attacks, the threat group used the backdoor to compromise its target’s build system; in another, it infected a company’s game servers.

Security Tip of the Week: Strengthen Your Anti-Malware Defenses

Security professionals can strengthen organizational anti-malware defenses by investing in solutions that leverage artificial intelligence (AI) to spot sophisticated threat behaviors indicative of malicious software. Companies should also make sure they have an incident response (IR) plan in place for the purpose of addressing a malware infection.

The post Weekly Security News Roundup: ‘Silent Night’ Malware Reminiscent of ZeuS appeared first on Security Intelligence.

Security researchers observed the newly documented Mandrake espionage platform carefully selecting Android devices for further exploitation.

Bitdefender discovered Mandrake in early 2020 while the espionage platform was in the process of conducting phishing attacks against cryptocurrency wallet applications, mobile banking programs and other financial software on Android devices. The security firm subsequently analyzed the threat and found that it had been in circulation since 2016.

In its analysis, Bitdefender found that the espionage platform selected just a handful of Android devices for further exploitation. It then used manipulation tactics, including disguising a series of powerful permission requests as an end-user license agreement, to infect those selected devices. Those rights gave the threat the ability to steal credentials, exfiltrate data and conduct secondary phishing attacks on compromised devices.

Not the Only Threat to Target Android Devices in Recent Years

Mandrake is not the only sophisticated threat that has targeted Android users. Back in 2018, for instance, Wandera spotted an Android malware family called “RedDrop” using sophisticated techniques to collect a vast amount of information from an infected device.

In March 2019, Security Without Borders uncovered “Exodus,” an Android spyware platform that targeted primarily Italian users with extensive surveillance and data-collection capabilities. More recently in April 2020, Kaspersky Lab discovered several overlaps between the “PhantomLance” operation and other attack campaigns conducted by the OceanLotus group.

How to Defend Against Mandrake

Security professionals can help defend their organizations against espionage platforms such as Mandrake by enforcing security policies that limit the types of apps that users can install on their work devices. Those policies should specifically restrict allowable installations to apps from trusted developers on official app marketplaces that have been vetted by the security team. Additionally, infosec personnel should invest in a mobile device management (MDM) solution that leverages artificial intelligence (AI) and other tools to scan for sophisticated threat behaviors.

The post Mandrake Espionage Platform Selects Android Devices for Exploitation appeared first on Security Intelligence.

More than 200 personal finance apps are at risk of a mobile banking Trojan dubbed EventBot, which is designed to steal user data, security researchers warn.

First spotted in the wild by Cybereason, EventBot is focused on Android devices and attempts to take advantage of its accessibility features.

The range of targets EventBot could potentially infect represent some of the best-known financial service mobile apps on the market. The mobile banking Trojan can even infiltrate cryptocurrency wallets such as Coinbase, researchers said.

How EventBot Makes Its Entrance

Like similar cyberthreats, EventBot makes its way onto smartphones through malicious apps designed to resemble legitimate tools, such as Microsoft Word or Adobe Flash. These programs operate as a keylogger upon installation by sending a request to the mobile OS’s accessibility services.

The Trojan runs in the background of the device and begins tracking everything typed into the smartphone once those permissions have been granted. Even notifications and text messages can be read by hackers once the malware has gained a foothold, researchers said.

The investigation suggested EventBot is a serious cybersecurity issue, given its focus on financial service apps and the fact that its approach is based on services that are critical to Android’s functionality.

The data stolen via the Trojan ranges from banking passwords to two-factor authentication (2FA) codes. The information can then be used for a variety of purposes, researchers added. This includes everything from hijacking financial transactions to identity theft and, of course, taking funds from a victim’s account.

EventBot is likely to evolve considerably over time. Already, researchers noted that there have been changes in the way it encrypts communication with a command-and-control (C&C) server. The threat’s authors have also added capabilities, such as a way to steal a victim’s lock code or gain access to settings that could give cybercriminals greater privileges.

Put an End to EventBot Before It Begins

IT security teams managing a fleet of Android devices for a company can defend themselves against the likes of EventBot with a robust security information and event management (SIEM) solution. Teams should also use threat intelligence to keep abreast of major variations and evolutions in the overall threat landscape.

Individual consumers, meanwhile, should always be wary of downloading apps from sources other than the official app stores: Google Play and the Apple App Store.

The post EventBot Mobile Banking Trojan Could Infect Over 200 Financial Services Apps appeared first on Security Intelligence.

Last week in security news, the authors of Shade ransomware announced that they were releasing 750,000 decryption keys to help their remaining victims recover their files for free. Speaking of ransomware, a notorious malware-as-a-service (MaaS) botnet added crypto-ransomware capabilities, thereby augmenting its ability to target Android users. Several other botnets also attracted the attention of security researchers.

Top Story of the Week: The End of Shade Ransomware

In a GitHub post, the authors of Shade ransomware announced the publication of 750,000 decryption keys along with their own custom decryption software. The malicious actors noted that some victims might have trouble using these resources to recover their files for free. In response, those nefarious individuals vocalized their hope that security firms would use the published keys and software to create commercial decryption tools that would be easier to use.

This announcement marked the last stage of Shade ransomware’s retirement. After ceasing all distribution of their creation in late 2019, those responsible for the ransomware said that they had deleted all data and source codes relating to their activity.

Source: iStock

Also in Security News

• Return of Black Rose Lucy Marked by Addition of Ransomware Features: Check Point Research discovered that the Black Rose Lucy botnet had returned from a two-year hiatus by masquerading as a video player application. The digital threat leveraged this disguise to use its new ransomware features and encrypt all files identified in the device’s directories.
• BEC Scam Launched by Florentine Banker Steals £600K: Also from Check Point Research, a threat group known as the Florentine Banker attracted security professionals’ attention by targeting at least three large financial organizations with sophisticated business email compromise (BEC) scams. In one of these attacks, the group successfully stole £600,000.
• New Shellbot Linux Malware Launched by Outlaw Hacking Group: Yoroi Security came across a new Linux malware called Shellbot that originated from the Outlaw hacking group. Early versions of this threat arrived with a module for conducting distributed denial-of-service (DDoS) attacks, but later versions used a Monero miner and Perl backdoor as its main elements.
• LeetHozer Botnet Samples Share Attack Resources With Moobot: The Network Research Lab at 360 observed that the new LeetHozer botnet used the same downloader and the same unique string in its vulnerability exploitation routine as Moobot. Acknowledging those similarities, the research team posited that Moobot and LeetHozer originated from the same group of attackers.
• Inquiry Discovered Multi-Year PhantomLance Campaign: Kaspersky launched an inquiry into a backdoor Trojan identified by another security firm back in July 2019. This effort revealed that the campaign, dubbed PhantomLance, had been active since at least 2016 and had infiltrated several app marketplaces including the Google Play store.
• Zero-Day Flaw in Sophos Firewalls Exploited by Information Stealer: Researchers at Sophos revealed that malicious actors had exploited a zero-day flaw to achieve remote code execution on some of the security firm’s firewall products. That malicious activity enabled those actors to install the Asnarök Trojan for the purpose of stealing data from their victims.
• High-Severity Code Injection Vulnerability Plugged in WP Plugin: In late April, Wordfence discovered a vulnerability in the Real-Time Find and Replace WordPress plugin that could enable a malicious actor to inject malicious Javascript into an exposed site by tricking the site admin. The security firm notified the plugin’s developer who responded by issuing a patch a few hours later.
• Department of Labor’s FMLA Used as Lure to Target Users: IBM X-Force detected a phishing campaign in which digital attackers used the U.S. Department of Labor’s Family and Medical Leave Act (FMLA) to convince recipients to open an email attachment. Once opened, that file infected recipients with Trickbot.

Security Tip of the Week: Review Your Organization’s Ransomware Defenses

Security professionals can strengthen defenses against ransomware threats such as Shade by using an ongoing security awareness training program to build up a positive security culture in the workplace. This effort will cultivate employees’ familiarity with phishing campaigns and other social engineering attacks, thereby reducing the number of available distribution channels for attackers. In addition, infosec personnel should leverage the latest threat intelligence to stay on top of evolving ransomware campaigns.

The post Weekly Security News Roundup: Shade Ransomware Authors Release 750K Decryption Keys appeared first on Security Intelligence.