By Deeba Ahmed
From Banking Apps to Crypto Wallets: SpyNote Malware Evolves for Financial Gain.
This is a post from HackRead.com Read the original post: SpyNote Android Spyware Poses as Legit Crypto Wallets, Steals Funds

The notorious SpyNote Android spyware returns, exploiting Accessibility APIs to target crypto wallets and unsuspecting users, ultimately stealing their cryptocurrency.

The Android spyware SpyNote developers are now considering cryptocurrencies, extending beyond mere credentials spying to initiate cryptocurrency transfers, revealed the latest research report from FortiGuard Labs.

Researchers noted that Spynote, a notorious Remote Access Trojan (**RAT**), is now targeting “famous crypto wallets” by abusing the Accessibility API. The API’s job is to automatically perform UI actions, such as recording device unlocking gestures and is mainly helpful for people with disabilities.

The malicious code abuses the Accessibility API to automatically fill out a form and transfer cryptocurrency to cyber criminals. It reads and memorizes the destination wallet address and amount, and replaces it with the attacker’s crypto wallet address.

The information is sent to a remote server with which the malware has established a connection already to complete the action. It is worth noting that the entire act is completed automatically, without alerting the user.

According to Fortinet’s **blog post**, on 1st February, a malicious sample was found posing as a legitimate crypto wallet, incorporating SpyNote RAT and anti-analysis features. They also observed that threat actors are mainly targeting users with mobile crypto wallets or banking applications in this financially motivated, medium-severity hacking saga.

Researchers showed screenshots in which SpyNote malware can be seen requesting Accessibility Service and the user granting access with the Android OS displaying additional warnings. It is evident that clicking on “Allow” signals the malware to perform its nefarious action whereas clicking “Deny” prevents it from gaining access.

Screenshot: FortiGuard Labs

Hackread has been following the evolution of SpyNote ever since it made its first appearance **back in 2016** when Palo Alto’s Unit 42 discovered this RAT on a dark net forum mainly targeting users who install APK apps. Researchers noted that SpyNote helped attackers gain remote control of infected devices, and enabled sideloading on Android devices.

In 2017, Zscaler IT security researchers **discovered** fake apps infected with the SpyNote RAT, allowing attackers to gain remote administrative control on Android devices. Researchers identified various apps, including fake Netflix, WhatsApp, YouTube, Facebook, Photoshop, SkyTV, Hotstar, Trump Dash PokemonGo, etc., infected with a new variant of SpyNote RAT.

Over the years, SpyNote has become a common family of Android malware, with over 10,000 samples and multiple variants, noted FortiGuard researchers.

Last year, the malware authors shifted focus to banking fraud, as the Cleafy Threat Intelligence Team **reported** SpyNote targeting European financial institutions with social engineering tactics and abusing Accessibility services. The attack started with deceptive smishing campaigns, directing victims to install a “new certified banking app” and granting remote access to their devices.

It is worth noting that malware often lures victims into giving them the necessary rights to access the Accessibility API through different lures, posing a threat to users, especially people with disabilities.

Android users are advised to pay attention to applications requesting the Accessibility API. End-users should treat these requests as suspicious, especially from alleged crypto wallets, PDF readers, and video players.

****RELATED ARTICLES****

1.  **Watch out: New Android spyware records your calls covertly**
2.  **LetMeSpy Android Spyware Service Shuts Down After Data Breach**
3.  **Confucius Android spyware hits military, nuclear entities in Pakistan**
4.  **Xamalicious Backdoor Infects 25 Android Apps, Affects 327K Devices**
5.  **Hackers spread Android spyware through Facebook using Fake profiles**

SpyNote Android Spyware Poses as Legit Crypto Wallets, Steals Funds

By Waqas
The latest report from Swedish telecom security firm Enea sheds light on security vulnerabilities within the widely used messaging platform, WhatsApp.
This is a post from HackRead.com Read the original post: Israeli NSO Group Suspected of “MMS Fingerprint” Attack on WhatsApp

NSO Group, an Israeli spyware firm, is suspected of exploiting a novel “MMS Fingerprint” attack to target unsuspected users on WhatsApp, exposing their device information without needing user interaction.

Swedish telecom security firm Enea reports that the Israeli NSO Group, targeted journalists, human rights activists, lawyers, and government officials with a novel MMS Fingerprint attack by exploiting a **vulnerability in WhatsApp**.

The report that the company shared with Hackread.com on Thursday 15, 2023, WhatsApp discovered a vulnerability in its system in May 2019, allowing attackers to install Pegasus spyware on users’ devices. The flaw was then exploited to target government officials and activists globally. WhatsApp sued **NSO Group** for this exploitation, but appeals failed in the US appeal court and Supreme Court.

The attack, reportedly used by NSO Group, was discovered in a contract between the Israeli agency’s reseller and the telecom regulator of Ghana, which can be viewed in lawsuit documents **here** (PDF).

Enea launched an investigation to find out how an MMS fingerprint attack occurs. They discovered that it could reveal the target device and OS version without user interaction by sending an MMS.

The MMS UserAgent, a string that identifies the OS and device (such as a Samsung phone running Android), can be used by malicious actors to exploit vulnerabilities, tailor malicious payloads, or craft phishing campaigns.

**Surveillance companies** often request device information, but UserAgent may be more useful than IMEI. It’s important to note that MMS UserAgent is different from browser UserAgent, which has privacy concerns and changes.

The problem, according to Enea’s **report**, was not in the Android, Blackberry, or iOS devices but in the complex, multi-stage MMS flow process. The MMS flow examination suggested this was launched possibly through another method involving binary SMS.

For your information, MMS standards designers worked on a way to notify recipient devices of an MMS waiting for them without requiring them to be connected to the data channel. MM1\_notification.REQ uses SMS, a binary SMS (WSP Push), to notify the recipient MMS device’s user agent that an MMS message is waiting for retrieval.

The subsequent MM1\_retrieve.REQ is an HTTP GET to the URL address, including user device information, suspected to be leaked and potentially lifted the MMS fingerprint.

Researchers obtained sample SIM cards from a randomly selected Western European operator and successfully sent MM1\_notification.REQs (binary SMSs), setting the content location to a URL controlled by their web server.

The target device automatically accessed the URL, exposing its UserAgent and x-wap-profile fields. A Wireshark decode of the MMS notification and GET revealed how an attacker would execute an “MMS Fingerprint” attack, demonstrating it was possible in real life.

Enea’s report outlines the stages in an MMS flow and provides insight into the initial attack notification sent to the target. (Screenshot: ENEA)

The attack highlights the **ongoing threat to the mobile ecosystem**. Binary SMS attacks have been steadily reported over the last 20 years, highlighting the need for mobile operators to evaluate their protection against such threats.

For detailed insights into the report, we reached out to **Javvad Malik**, lead security awareness advocate at **KnowBe4** who warned that, Unlike previous methods, this attack doesn’t require user interaction, posing a significant concern for users’ security. The targeting of journalists, activists, and officials highlights the misuse of technology for surveillance and oppression. Platforms like WhatsApp must prioritize security as the foundation of their services.

> _“The saga of the NSO Group and its controversial exploits offers another chapter with the revelation of the “MMS Fingerprint” attack. At the heart of this revelation is a stark reminder of the ever-evolving cybersecurity threats, demonstrating not just the sophistication of threat actors, but their relentless pursuit to leverage vulnerabilities._
> 
> _The tactical evolution from requiring user interaction to achieve compromise—such as the unfortunate click on a malicious link—to now being able to extract valuable information through seemingly benign MMSs, underlines a significant shift. It’s concerning, to say the least, that users can be targeted without any user interaction._
> 
> _The targeting of journalists, activists, and officials is particularly egregious, highlighting a dark side of technological advancements where tools designed to connect and empower can also be twisted into instruments of surveillance and oppression. For organisations like WhatsApp and entities involved in digital communication, the imperative is clear: Security cannot merely be a feature; it must be the very foundation upon which platforms are built and maintained._
> 
> _In the broader context, incidents like the “MMS Fingerprint” attack are reminders that security cannot remain static and needs to continually evolve and build more resilient and secure systems.”_
> 
> Javvad Malik – KnowBe4

To prevent the attack, disabling MMS auto-retrieval on mobile devices can help, but some devices may not allow modification. On the network side, filtering Binary SMS/MM1\_notification messages can be effective. If a malicious binary SMS message is received, it is essential to prevent messages from connecting to attacker-controlled IP addresses.

1.  **Israeli spyware hacked phones of journalists globally**
2.  **iShutdown Tool Detects Pegasus Spyware on iOS Devices**
3.  **Fake WhatsApp clone aim at crypto on Android and Windows**
4.  **WhatsApp OTP Scam Allows Scammers to Hijack Your Account**
5.  **iPhones of State Dept officials hacked by NSO Pegasus spyware**

Israeli NSO Group Suspected of “MMS Fingerprint” Attack on WhatsApp

There was about a 24-hour period where many news outlets reported on a reported DDoS attack that involved a botnet made up of thousands of internet-connected toothbrushes.

Thursday, February 15, 2024 14:00

I’ll be the first to admit that, like many people on the internet last week, I got caught up in the toothbrush distributed denial-of-service attack that wasn’t.  

I had a whole section on it written up in last week’s newsletter, and then I came across Graham Cluley’s blog post debunking the whole thing, and I had to delete it about an hour before the newsletter went live.  

There was about a 24-hour period where many news outlets reported on a reported DDoS attack that involved a botnet made up of thousands of internet-connected toothbrushes, it all started with one international newspaper report, and then was aggregated to death and spread quickly on social media.  

This attack was only a _hypothetical_ that a security researcher posed in an interview but was reported or translated as an attack that happened. 

To me, I think we can all learn from a few major takeaways from this entire saga — myself included.  

It’s easy to see why this was a ready-made story to go viral: It involved a silly device that probably doesn’t need to be connected to the internet anyway, it involved a large number that would grab headlines and it was a DDoS attack, which have suddenly come back in vogue over the past year. 

But, I’ll admit, the aggregated stories seemed a little fishy to me at first, because all the reports didn’t include any specifics about which company was targeted, how long the attack lasted, or the name of the device that was reportedly compromised. 

That last part should be a red flag going forward for any of us wanting to share a meme about something the next time a cybersecurity story goes viral — in my opinion, responsible disclosure of an attack or compromise should always include information about whatever vulnerability it was that was exploited. In this hypothetical scenario, I don’t think an adversary would have been able to compromise an internet-connected toothbrush without first exploiting some sort of vulnerability, which if it’s being reported on in public, should at least include information on patches or mitigations. 

I also think we all need to be asking the fundamental question: Why? In this case, I should have asked myself why an attacker would want to go through the trouble of compromising smart toothbrushes. And what would be the end goal of targeting a private company with a DDoS attack? Likely, it would be to demand a ransom in exchange for the attacker stopping the attack, but without knowing what sector the targeted company was in, it’s tough to guess how profitable that might even be. (For example, a health care agency may be looking to do anything to get back to operating asap, as lives could literally be at stake.) 

And once the attacker compromised a toothbrush, what information can they glean from the user besides their dental hygiene habits? Usually, they’d be looking to steal some sort of personal information, login credentials or financial data that they could then turn around and sell on the dark web. 

Needless to say, there were multiple red flags we all ignored when this story started to spread. And I’m not here to blame anyone in this case; it was all honest mistakes that, all things considered, ended up not being that serious. But the toothbrush botnet that wasn’t does serve as a reminder to all of us to be a bit more mindful before clicking share or posting a story on social media.  

**The one big thing **

Cisco Talos has identified a new backdoor authored and operated by the Turla APT group, a Russian cyber espionage threat group. This new backdoor we’re calling “TinyTurla-NG” (TTNG) is similar to Turla’s previously disclosed implant, TinyTurla, in coding style and functionality implementation. Talos assesses with high confidence that TinyTurla-NG, just like TinyTurla, is a small “last chance” backdoor that is left behind to be used when all other unauthorized access/backdoor mechanisms have failed or been detected on the infected systems. 

**Why do I care? **

Turla has been widely known to target entities across the world using a huge set of offensive tools in geographies including the U.S., European Union, Ukraine and Asia. They’ve previously used malware families such as CAPIBAR and KAZUAR to target Ukrainian defense forces. After Crutch and TinyTurla, Turla has now expanded their arsenal to include the TinyTurla-NG and TurlaPower-NG malware families, while also widening its net of targets to NGOs. 

**So now what? **

Talos has released new ClamAV signatures and Snort rules to protect against TinyTurla and the actors’ actions. We don’t know what the initial access vector is, so it’s tough to give targeted advice on how to avoid this malware, but having any endpoint detection in place will block this “last chance” backdoor.  

**Top security headlines of the week **

**Chinese state-sponsored actor Volt Typhoon may have silently sat on U.S. critical infrastructure networks for more than five years,** according to a new report from American intelligence agencies. According to the advisory, the infamous hacking group has been exploiting vulnerabilities in routers, firewalls and VPNs to target water, transportation, energy and communications systems across the country. Volt Typhoon has been able to control some victims’ surveillance camera systems, and the access could have allowed them to disrupt critical energy and water controls. The actor is known for using living-off-the-land binaries (LoLBins) to remain undetected once they gain an initial foothold. Authorities in Canada, Australia and New Zealand also contributed to last week’s advisory, citing their concern for similar activity in their countries. The FBI’s director recently said in testimony to U.S. Congress that authorities had dismantled a bot network of hundreds of compromised devices that was connected to VoltTyphoon. (Axios, The Guardian) 

**A new spyware network called TheTruthSpy may have compromised hundreds of Android devices using silent tracking apps that users download thinking they’re legitimate.** Security researchers uncovered the information of thousands of devices that have already been compromised, including their IMEI numbers and advertising IDs. TheTruthSpy appears to actively spy on large clusters of victims across Europe, India, Indonesia, the U.S. and U.K. The operators behind TheTruthSpy also did not address a security vulnerability in the software, identified as CVE-2022-0732, which left the victim data they stole potentially vulnerable to other bad actors. These types of stalkerware tools are often used by family members, spouses or peers of victims who want to track their physical locations and spy on messages and phone calls. The spyware is downloaded via an app, which doesn’t appear on the victim’s home screen and operates quietly in the background. (TechCrunch, maia blog) 

**Apple removed a fake LastPass app called “LassPass” after the popular password management service reported it.** The phony LassPass used a similar logo to that of the legitimate LastPass and was up on the App Store for an unknown amount of time. Apple also said it was removing the creator of the app from its Developer Program. This is a very rare case for the Apple App Store, as it has a strict review policy. LastPass released a warning to all users last week of the fake app’s existence, including a link to the legitimate LastPass app. LassPass only had one review on the store, and multiple reviews warning it was fake. However, it’s safe to assume that the app was likely set up as some sort of phishing scam meant to get users to enter their legitimate LastPass login information to be stolen by the fake app’s creator. (Ars Technica, Bleeping Computer) 

**Can’t get enough Talos? **

*   Beers with Talos Ep. #143: The Reddit security diaries 
*   The Need to Know: How are attackers using QR codes in phishing emails and lure documents? 
*   First Microsoft Patch Tuesday zero-day of 2024 disclosed as part of group of 75 vulnerabilities 

**Upcoming events where you can find Talos **

**S4x24** **(March 4 - 27)** 

Miami Beach, Florida 

_To protect themselves during Russian aggression, the Ukrainian military utilizes electronic warfare to blanket critical infrastructure to defeat radar and GPS-guided smart munitions. This has the unintended consequence of disrupting GPS synchrophasor clock measurements and creating service outages on an already beleaguered and damaged transmission electric grid. Joe Marshall from Talos’ Strategic Communications team will tell an incredible story of how a group of engineers and security professionals from a diverse coalition of organizations came together to solve this electronic warfare GPS problem in an unconventional technical way, and helped stabilize parts of the transmission grid of Ukraine._ 

**RSA** **(May 6 - 9)** 

_San Francisco, California_ 

**Most prevalent malware files from Talos telemetry over the past week **

**SHA 256:** a31f222fc283227f5e7988d1ad9c0aecd66d58bb7b4d8518ae23e110308dbf91    
**MD5:** 7bdbd180c081fa63ca94f9c22c457376   
**Typical Filename:** c0dwjdi6a.dll   
**Claimed Product:** N/A    
**Detection Name:** Trojan.GenericKD.33515991 

**SHA 256:** 5616b94f1a40b49096e2f8f78d646891b45c649473a5b67b8beddac46ad398e1      
**MD5:** 3e10a74a7613d1cae4b9749d7ec93515      
**Typical Filename:** IMG001.exe      
**Claimed Product:** N/A      
**Detection Name:** Win.Dropper.Coinminer::1201 

**SHA 256:** 59f1e69b68de4839c65b6e6d39ac7a272e2611ec1ed1bf73a4f455e2ca20eeaa     
**MD5:** df11b3105df8d7c70e7b501e210e3cc3     
**Typical Filename:** DOC001.exe     
**Claimed Product:** N/A     
**Detection Name:** Win.Worm.Coinminer::1201 

**SHA 256:** 5e537dee6d7478cba56ebbcc7a695cae2609010a897d766ff578a4260c2ac9cf   
**MD5:** 2cfc15cb15acc1ff2b2da65c790d7551   
**Typical Filename:** rcx4d83.tmp   
**Claimed Product:** N/A     
**Detection Name:** Win.Dropper.Pykspa::tpd 

**SHA 256:** 77c2372364b6dd56bc787fda46e6f4240aaa0353ead1e3071224d454038a545e   
**MD5:** 040cd888e971f2872d6d5dafd52e6194   
**Typical Filename:** tmp000c3787   
**Claimed Product:** Ultra Virus Killer   
**Detection Name:** PUA.Win.Virus.Ultra::95.sbx.tg

Why the toothbrush DDoS story fooled us all

The Google Passkey Manager on Android appears to have inconsistent messaging for deletion of data along with other varying issues that lead us to believe it's not ready for prime time.

*INTRODUCTION*  
Passkeys on Android are stored in Google Password Manager by default. The user cannot make their own backups of them.

Note: although the user can export a CSV file with both passkeys and passwords, the lines representing passkeys will not contain any secrets, rendering them useless.

Also note that Google Passkey Manager appears to primarily be a CLOUD-based password manager (with copies of passwords and passkeys usually cached on devices).

*PROBLEM*  
The user may have chosen to configure a "sync passphrase" in Chrome.  
Instructions on what to do, in case the user wishes to change or remove their sync passphrase, can be found in [1] under "Reset your passphrase".

Effectively the user is sent to [2] and should press the button "Clear Data" at the bottom of that page.  
Until mid June 2023, the text near that button used to read (emphasis in CAPS added by me):

   "This will clear your Chrome data from your Google Account.  
   THIS WON'T CLEAR ANY DATA FROM YOUR DEVICES."

However, tapping the "Clear Data" button would unrecoverably DELETE ALL YOUR PASSKEYS (not your passwords).

*ISSUE REPORTED TO GOOGLE*  
I reported this "passkeys gone" problem to Google as a security issue on June 11, 2023.  
Please see the Timeline below for details.

*"FIX"*  
The issue was "fixed" around June 15, 2023, apparently by changing the text at the bottom of [2] into (emphasis in CAPS added by me):

   "This will clear your Chrome data that has been saved in your Google Account.  
   THIS MIGHT CLEAR SOME DATA FROM YOUR DEVICES."

However, tapping the "Clear Data" button will still DELETE ALL OF YOUR PASSKEYS without any other warnings.

In my opinion this is unacceptable, as is the handling of my bug report. Therefore I have not yet reported the issues mentioned below to Google nor to the Chromium team.

*POTENTIAL SYNC ISSUES*  
Apparently Google decided to use a DEVICE based encryption key (instead of a Google ACCOUNT based key) to encrypt the passkey's private keys.  
The idea is that, if you start using an second Android device, the encryption key from the first device is transferred  to your second device.

Note that this requires you to enter your Google cloud password PLUS the screen unlock code of your first device on your second device.

However, transfer of the encryption key will fail if the second device ALREADY HAS an encryption key.

Note: I actually ran into this condition accidentally during tests.  
Although this may not be a typical situation, it is possible to reproduce (which I will not (yet) describe).

Consequently, if you you brick or loose your old Android device, and somehow you managed to already have a DIFFERENT encryption key on your new Android device, passkeys and passwords will sync from the cloud, but the synced passkeys will be UNUSABLE on your new device.

Tip: whatever you do on a new replacement device: don't start by creating a passkey as a test!  
Wait until your old passkeys have synchronized to your new device and you've confirmed that they work, before you add any new passkeys.

*BUG IN PASSWORDS.GOOGLE.COM*  
Editing a passkey's (user) name in [3] renders all passkeys for the domain unusable, with the following error message when attempting to use them:

   "No Passkeys Available  
   There aren't any passkeys for [domain] on this device"

That particular passkey will be unusable forever.  
However, any other passkeys for the same domain become usable again after you delete the -now corrupt and unusable- passkey.

*OTHER ISSUES*  
During my tests I found a lot of other issues (mostly minor compared to those mentioned above).  
Such as the following worrisome messages I repeatedly saw:

   "An unknown error occurred while talking to the credential manager."

   "For security, you can no longer access your encrypted data on this device."

Also, in Chrome settings, after enabling sync, tapping on "Password Manager" would usually open Google Password Manager (implemented as a part of Google Play Services), but sometimes the Chrome built-in password manager instead.

I may reveal other issues at a later stage.

*CONCLUSION*  
In my opinion the reliability of Android's passkey implementation insufficient (immature, not production ready).

There is no way for the user to back up their passkey secrets themselves, while cloud storage of passkeys can obviously not be relied upon (Google owns your passkeys, not you).

The partial integration of Google Password Manager with Chrome's builtin password manager complicates things - in particular when combined with a "sync passphrase" and/or "on device encryption".  
The apparent confusion which party (Google or the Chromium team) is responsible for fixing bugs in Google Password Manager seems amateuristic annd chaotic.

Account lockout is a serious risk. If fallbacks to passwords or recovery codes remains a necessity because of easily lost passkeys, the advantage of "phishing resistance" is mostly moot.

*DISCLOSURE TIMELINE* (format: yyyy-mm-dd)  
2023-06-06 I published a Dutch article "Passkeys voor leken" (Passkeys for beginners) [4].

2023-06-08 After enabling encryption (using a sync passphrase) for all synced data, and then following Google's instructions [1] on how to change that passphrase, I noticed that all passkeys on my Google Pixel 6 Pro Android phone had disappeared.

I wrote about this in [5], but initially thought that I made a mistake myself.  
After thid incident I started to further investigate this issue, which appeared to reproduce.

2023-06-11 I uploaded a vulnerability report to Google titled "Passkeys gone from device after clearing Chrome data from Google Account" [6].

2023-06-12 Google acknowledges receiving my report.

2023-06-14 Google forwards my report to the Chromium team [7] and sets the status of the Google issue to "Won't Fix (Infeasible)".

2023-06-14 Im am notified that my vulnerability report was registered by the Chromium team.  
In [7] I see that the issue was assigned to a specific person (the "assignee" from now on).

2023-06-15 On the bug tracking website [7] I uploaded a zip-file with screenshots to further clarify things.

2023-06-15 The assignee wrote in [7]:

   "This is as expected, but you're right that we should clarify that on the page and that it's unexpected that Android's implementation of Sync differs r.e. the clearing of data from devices."

2023-06-15 The assignee adds a comment:

   "> it's unexpected that Android's implementation of Sync differs r.e. the clearing of data from devices.  
   (Sorry, that was poorly worded. It's potentially _surprising_ that Android differs given the wording.)"

At that time I did not understand what the assignee meant. Later I discovered by accident that the text at the bottom of [2] had been changed, and the assignee was apparently referring to that text.

2023-08-10 After 60 days since my initial report, I addded a comment in [7] that I am able to reproduce the vulnerability using the latest (August) Android update. I added:

   "I don't know whether this is a Chromium or an Android issue, but losing passkeys is unacceptible.  
   What gives?"

2023-09-10 (after 90 days) On [6] I reported that I had not heard back from the Chromium team since June 15 and that I do not understand what they wrote that day, and that there was no response to my August 8 comment.

2023-09-11 My latest comment in [6] is acknowledged by Google and under review.

2023-09-15 Google states that they won't do anything as this vulnerability is tracked by [7].

2024-02-07 No updates on [6] and [7].  
Publication.

*REFERENCES*  
[1] https://support.google.com/chrome/answer/165139

[2] https://chrome.google.com/sync

[3] https://passwords.google.com/

[4] https://security.nl/posting/798699/Passkeys+voor+leken

[5] https://security.nl/posting/798932

[6] https://issuetracker.google.com/issues/286730198

[7] https://bugs.chromium.org/p/chromium/issues/detail?id=1454857

Google Android Passkey Deletion / Confusion

Microsoft has issued patches for 73 security vulnerabilities in its February 2024 Patch Tuesday.

Microsoft has issued patches for 73 security vulnerabilities in its February 2024 Patch Tuesday. Among these vulnerabilities are two zero-days that are reportedly being used in the wild.

The two zero-day vulnerabilities have already been added to the Cybersecurity & Infrastructure Security Agency’s catalog of  Known Exploited Vulnerabilities, based on evidence of active exploitation. This means that Federal Civilian Executive Branch (FCEB) agencies need to remediate these vulnerabilities by March 5, 2024, in order to protect their devices.

The Common Vulnerabilities and Exposures (CVE) database lists publicly disclosed computer security flaws. The zero-days patched in this round of updates are:

CVE-2024-21351 (CVSS score 7.6 out of 10): a Windows SmartScreen security feature bypass vulnerability. The vulnerability allows a malicious actor to inject code into SmartScreen and potentially gain code execution, which could potentially lead to some data exposure, lack of system availability, or both. An authorized attacker must send the user a malicious file and convince the user to open it.

CVE-2024-21412 (CVSS score 8.1 out of 10): an Internet Shortcut Files security feature bypass vulnerability. An unauthenticated attacker could send the targeted user a specially crafted file that is designed to bypass displayed security checks. However, the attacker would have no way to force a user to view the attacker-controlled content. Instead, the attacker would have to convince them to take action by clicking on the file link.

The bypassed security feature in both cases is the Mark of the Web (MOTW), the technology that ensures Windows pops a warning message when trying to open a file downloaded from the Internet. When a file is downloaded, Windows adds a ZoneId in the form of an Alternate Data Stream to the file which is responsible for the warning message(s).

Another vulnerability worth keeping an eye on is CVE-2024-21413 (CVSS score 9.8 out of 10): a Microsoft Outlook remote code execution (RCE) vulnerability. Successful exploitation of this vulnerability would allow an attacker to bypass the Office Protected View and to gain high privileges, which include read, write, and delete functionality. Microsoft notes that the Preview Pane is an attack vector. The update guide for this vulnerability lists a number of required updates before protection is achieved.

**Other vendors**

Other vendors have synchronized their periodic updates with Microsoft. Here are few major ones that you may find in your environment.

**Adobe** has released security updates to address vulnerabilities in several products:

*   Adobe Commerce and Magento
*   Adobe Substance 3D Painter
*   Adobe Acrobat and Reader
*   Adobe FrameMaker Publishing Server
*   Adobe Audition 
*   Adobe Substance 3D Designer

The **Android** Security Bulletin for February contains details of security vulnerabilities for patch level 2024-02-05 or later.

**Ivanti** has urged customers to patch yet another critical vulnerability.

**SAP** has released its February 2024 Patch Day updates.

**We don’t just report on vulnerabilities—we identify them, and prioritize action.**

Cybersecurity risks should never spread beyond a headline. Keep vulnerabilities in tow by using ThreatDown Vulnerability and Patch Management.

 Update now! Microsoft fixes two zero-days on February Patch Tuesday 

By Deeba Ahmed
QNAP has released fixes for the zero-day vulnerability, so it's important to install them immediately.
This is a post from HackRead.com Read the original post: Zero-Day in QNAP QTS Affects NAS Devices Globally

Unit 42 researchers discovered a new vulnerability in QNAP devices on 7 November 2023, which was confirmed by the vendor on 19 December 2023, and a security advisory was released subsequently to provide guidance and recommendations.

Palo Alto Networks Unit 42’s Advanced Threat Prevention (ATP) and telemetry systems identified a new zero-day vulnerability in QNAP QTS and QuTS hero firmware from the vendor QNAP. The vulnerability is tracked as **CVE-2023-50358** and affects QNAP Network Attached Storage (NAS) devices.

For your information, QNAP, a company specializing in NAS devices, is known for its QNAP Turbo NAS System (QTS) operating system, which is often embedded in the firmware of QNAP NAS devices.

In its **report** published on 13 February 2024, authors Chao Lei, Jeff Luo, and Zhibin Zhang explained that CVE-2023-50358 is a command injection vulnerability found in the quick.cgi component of QNAP QTS firmware that is accessible without authentication. The vulnerability occurs when the HTTP request parameter todo=set\_timeinfo is set, and the parameter SPECIFIC\_SERVER is saved into a configuration file /tmp/quick/quick\_tmp.conf with the entry name NTP Address.

The component then starts time synchronization using the ntpdate utility, and the command-line execution is ensured by reading the NTP Address in quick\_tmp.conf and system(). Untrusted data from the SPECIFIC\_SERVER parameter helps build a command line, which is executed in the shell, leading to arbitrary command execution.

It is worth noting that this vulnerability affects 289,665 separate IP addresses. The top five countries affected by the vulnerability are Germany, the United States, China, Italy, and Japan.

Proof of command-line execution and heatmap shows the most impacted countries. (Screenshot: Unit 42)

According to Unit 42 researchers threat actors constantly search for vulnerabilities in network-connected hosts, such as NAS devices because these can be exploited quickly. This is why ensuring foolproof security of these devices is necessary.

IoT devices are vulnerable to remote code execution vulnerabilities due to their low attack complexity and critical impact. To protect against these threats, QNAP recommends updating to the latest version of QTS or QuTScloud hero- QTS 5.1.5 or QuTS hero h5.1.5.

****List of Affected Devices****

*   QTS 5.1.x
*   QTS 5.0.1
*   QTS 5.0.0
*   QTS 4.5.x
*   QTS 4.3.6
*   QTS 4.3.4
*   QTS 4.3.x
*   QTS 4.2.x
*   QuTS hero h5.1.x
*   QuTS hero h5.0.1
*   QuTS hero h5.0.0
*   QuTS hero h4.x

QNAP has **released** a security advisory, advising affected organizations to follow mitigation instructions or apply firmware updates. 

“Multiple vulnerabilities have been reported to affect several QNAP operating system versions. If exploited, the OS command injection vulnerabilities could allow users to execute commands via a network.”

In its advisory, the vendor noted fixing two vulnerabilities, CVE-2023-47218 and CVE-2023-50358 and explained how to implement the fixes.

“If you do not want to install a fully fixed version for your device, you can still mitigate the vulnerabilities by installing a partially fixed version. However, note that the vulnerabilities still exist during the installation process of a partially fixed version. The vulnerabilities only disappear after installation is complete.”

1.  **CISA and Fortinet Warns of New FortiOS Zero-Day Flaws**
2.  **Ivanti VPN Flaws Exploited by DSLog Backdoor and Crypto Miners**
3.  **Hackers Uncover Airbus EFB App Vulnerability, Risking Aircraft Data**
4.  **Ethical Hackers Reported 835 Vulnerabilities, Earned $450K in 2023**
5.  **Smart Helmets Flaw Exposed Millions to Risk of Hacking and Surveillance**

Zero-Day in QNAP QTS Affects NAS Devices Globally

Stalkerware app TheTruthSpy has been hacked for the fourth time, once again leaking the sensitive data it captures.

In 2022, we published an article about how photographs of children taken by a stalkerware-type app were found exposed on the internet because of poor cybersecurity practices by the app vendor.

The stalkerware-type app involved, TheTruthSpy, has shown once again that the way in which it handles captured data shows no respect to its customers. And even less for the victims it’s monitoring.

TheTruthSpy markets itself as a tool that can be placed in the hands of employers who want to keep tabs on employees in the workplace, or in the hands of parents who want to look after their kids. But it can just as easily be placed in the hands of stalkers, abusive partners, or someone who just wants to get a leg up in their divorce proceedings.

Stalkerware-type applications like TheTruthSpy typically get installed secretly, by a person with access to the victim’s phone. For that reason, by design, the apps stay hidden from the device owner, while giving the attacker complete access.

Boasting “more than 15 spying features,” it can track a target’s location; reveal their browser history; record their calls; read their SMS messages; spy on their WhatsApp, Facebook, SnapChat and Viber messages; log what they type; and record what they say.

That alone is bad enough, but the app seems to have a persistent problem with security. In 2022, tech publication TechCrunch discovered that TheTruthSpy and other spyware apps share a common Insecure Direct Object Reference (IDOR) vulnerability, CVE-2022-0732. The publications described the bug as “extremely easy to exploit, and grants unfettered remote access to all of the data collected from a victim’s Android device.”

The bug was never fixed, and yesterday, stalkerware researcher maia arson crimew, revealed that it was stumbled upon again by two different hacking groups.

> When members of the two hacking groups looked into TruthSpy last december while searching for stalkerware to hack, they independently stumbled upon the same IDOR vulnerability

The good news is that both groups, SiegedSec and ByteMeCrew, said in a Telegram post that they are not publicly releasing the breached data, given its highly sensitive nature. They provided enough data to enable TechCrunch to verify that it is authentic though, by matching IMEI numbers (numbers that uniquely identify phones) and advertising IDs against a list of previous known-to-be compromised devices.

Which means that by installing TheTruthSpy—and a whole fleet of clone apps including Copy9, MxSpy, iSpyoo, SecondClone, TheSpyApp, ExactSpy, FoneTracker and GuestSpy—you are not just spying on someone, you are also potentially exposing their data for anyone to find.

The data reportedly shows that TheTruthSpy continues to actively spy on large clusters of victims across Europe, India, Indonesia, the United States, the United Kingdom and elsewhere.

Sadly, this is no surprise. According to 2023 research from Malwarebytes, 62 percent of people in the United States and Canada admitted to monitoring their romantic partners online in one form or another, from looking through a spouse’s or significant other’s text messages, to tracking their location, to rifling through their search history, to even installing monitoring software onto their devices.

**Removing stalkerware**

If you want to know if your phone is or was infected with TheTruthSpy, you can use the lookup tool provided by TechCrunch, which has been updated to include information about the most recent leak.

Malwarebytes, as one of the founding members of the Coalition Against Stalkerware, makes it a priority to detect and remove stalkerware-type apps from your device. It is good to keep in mind however that by removing the stalkerware-type app you will alert the person spying on you that you know the app is there.

Because the apps install under a different name and hide themselves from the user, it can be hard to find and remove them. That is where Malwarebytes for Android can help you.

1.  Open Malwarebytes for Android.
2.  Open the app’s dashboard
3.  Tap **Scan** **now**
4.  It may take a few minutes to scan your device.

 If malware is detected you can act on it in the following ways:

*   **Uninstall**. The threat will be deleted from your device.
*   **Ignore Always**. The file detection will be added to the Allow List, and excluded from future scans. Legitimate files are sometimes detected as malware. We recommend reviewing scan results and adding files to Ignore Always that you know are safe and want to keep.
*   **Ignore Once**: A file has been detected as a threat, but you are not sure whether to add it to your Allow List or delete. This option will ignore the detection this time only. It will be detected as malware on your next scan.

**We don’t just report on phone security—we provide it**

Cybersecurity risks should never spread beyond a headline. Keep threats off your iOS devices by downloading Malwarebytes for iOS today.

 TheTruthSpy stalkerware, still insecure, still leaking data 

Red Hat Security Advisory 2024-0773-03 - An update for the squid:4 module is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions. Issues addressed include buffer over-read, denial of service, and null pointer vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_0773.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

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

Synopsis:           Important: squid:4 security update  
Advisory ID:        RHSA-2024:0773-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:0773  
Issue date:         2024-02-12  
Revision:           03  
CVE Names:          CVE-2023-5824  
====================================================================

Summary: 

An update for the squid:4 module is now available for Red Hat Enterprise Linux 8.4 Advanced Mission Critical Update Support, Red Hat Enterprise Linux 8.4 Telecommunications Update Service, and Red Hat Enterprise Linux 8.4 Update Services for SAP Solutions.

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.

Description:

Squid is a high-performance proxy caching server for web clients, supporting FTP, and HTTP data objects.

Security Fix(es):

* squid: DoS against HTTP and HTTPS (CVE-2023-5824)

* squid: Denial of Service in SSL Certificate validation (CVE-2023-46724)

* squid: NULL pointer dereference in the gopher protocol code (CVE-2023-46728)

* squid: Buffer over-read in the HTTP Message processing feature (CVE-2023-49285)

* squid: Incorrect Check of Function Return Value In Helper Process management (CVE-2023-49286)

* squid: denial of service in HTTP request parsing (CVE-2023-50269)

Bug Fix(es):

* squid crashes in assertion when a parent peer exists (RHEL-18254)

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.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-5824

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2245914  
https://bugzilla.redhat.com/show_bug.cgi?id=2247567  
https://bugzilla.redhat.com/show_bug.cgi?id=2248521  
https://bugzilla.redhat.com/show_bug.cgi?id=2252923  
https://bugzilla.redhat.com/show_bug.cgi?id=2252926  
https://bugzilla.redhat.com/show_bug.cgi?id=2254663

Red Hat Security Advisory 2024-0773-03

Red Hat Security Advisory 2024-0772-03 - An update for the squid:4 module is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions. Issues addressed include buffer over-read, denial of service, and null pointer vulnerabilities.

The following advisory data is extracted from:

https://access.redhat.com/security/data/csaf/v2/advisories/2024/rhsa-2024_0772.json

Red Hat officially shut down their mailing list notifications October 10, 2023.  Due to this, Packet Storm has recreated the below data as a reference point to raise awareness.  It must be noted that due to an inability to easily track revision updates without crawling Red Hat's archive, these advisories are single notifications and we strongly suggest that you visit the Red Hat provided links to ensure you have the latest information available if the subject matter listed pertains to your environment.

- Packet Storm Staff

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

Synopsis:           Important: squid:4 security update  
Advisory ID:        RHSA-2024:0772-03  
Product:            Red Hat Enterprise Linux  
Advisory URL:       https://access.redhat.com/errata/RHSA-2024:0772  
Issue date:         2024-02-12  
Revision:           03  
CVE Names:          CVE-2023-5824  
====================================================================

Summary: 

An update for the squid:4 module is now available for Red Hat Enterprise Linux 8.2 Advanced Update Support, Red Hat Enterprise Linux 8.2 Telecommunications Update Service, and Red Hat Enterprise Linux 8.2 Update Services for SAP Solutions.

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.

Description:

Squid is a high-performance proxy caching server for web clients, supporting FTP, and HTTP data objects.

Security Fix(es):

* squid: DoS against HTTP and HTTPS (CVE-2023-5824)

* squid: Denial of Service in SSL Certificate validation (CVE-2023-46724)

* squid: NULL pointer dereference in the gopher protocol code (CVE-2023-46728)

* squid: Buffer over-read in the HTTP Message processing feature (CVE-2023-49285)

* squid: Incorrect Check of Function Return Value In Helper Process management (CVE-2023-49286)

* squid: denial of service in HTTP request parsing (CVE-2023-50269)

Bug Fix(es):

* squid crashes in assertion when a parent peer exists (RHEL-18253)

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.

Solution:

https://access.redhat.com/articles/11258

CVEs:

CVE-2023-5824

References:

https://access.redhat.com/security/updates/classification/#important  
https://bugzilla.redhat.com/show_bug.cgi?id=2245914  
https://bugzilla.redhat.com/show_bug.cgi?id=2247567  
https://bugzilla.redhat.com/show_bug.cgi?id=2248521  
https://bugzilla.redhat.com/show_bug.cgi?id=2252923  
https://bugzilla.redhat.com/show_bug.cgi?id=2252926  
https://bugzilla.redhat.com/show_bug.cgi?id=2254663

Red Hat Security Advisory 2024-0772-03

“This eruption of violence had been brewing for years, through successive economic collapses, pandemics, and the utter dysfunction that had become American life.” An exclusive excerpt from 2054: A Novel.

Tag

#sap