Long-time Slashdot reader b0s0z0ku quotes Ars Technica: A previously undetected piece of malware found on almost 30,000 Macs worldwide is generating intrigue in security circles, which are still trying to understand precisely what it does and what purpose its self-destruct capability serves.

Once an hour, infected Macs check a control server to see if there are any new commands the malware should run or binaries to execute. So far, however, researchers have yet to observe delivery of any payload on any of the infected 30,000 machines, leaving the malware's ultimate goal unknown. The lack of a final payload suggests that the malware may spring into action once an unknown condition is met.

Also curious, the malware comes with a mechanism to completely remove itself, a capability that's typically reserved for high-stealth operations. So far, though, there are no signs the self-destruct feature has been used, raising the question why the mechanism exists. Besides those questions, the malware is notable for a version that runs natively on the M1 chip that Apple introduced in November, making it only the second known piece of macOS malware to do so...

The malware has been found in 153 countries with detections concentrated in the US, UK, Canada, France, and Germany.
Red Canary, the security firm that discovered the malware, has named it "Silver Sparrow." Long-time Slashdot reader Nihilist_CE writes: First detected in August of 2020, the Silver Sparrow malware is interesting in several unsettling ways. It uses the macOS Installer Javascript API to launch a bash process to gain a foothold into the user's system, a hitherto-unobserved method for bypassing malware detection. This bash shell is then used to invoke macOS's built-in PlistBuddy tool to create a LaunchAgent which executes a bash script every hour. This is the command and control process, which downloads a JSON file containing (potentially) new instructions.

Besides the novel installation method, Silver Sparrow is also mysterious in its payload: a single, tiny binary that does nothing but open a window reading "Hello, World!" (in v1, which targets Intel Macs) or "You did it!" (in v2, which is an M1-compatible fat binary). These "bystander binaries" are never executed and appear to be proofs-of-concept or placeholders for future functionality.

An anonymous reader quotes a report from Ars Technica: Homebrew now supports Apple Silicon natively, albeit not with every package. The volunteer Homebrew team made the announcement on the Homebrew blog alongside today's release. While the native support is not yet comprehensive, it bridges the gap significantly, and users can still run Terminal via Rosetta 2 to do what they can't yet while running natively on Apple Silicon. The Homebrew blog post says "we welcome your help" in providing bottles for all packages moving forward.

Here's the full bullet point on Apple Silicon in the Homebrew 3.0.0 release notes: "Apple Silicon is now officially supported for installations in /opt/homebrew. formulae.brew.sh formula pages indicate for which platforms bottles (binary packages) are provided and therefore whether they are supported by Homebrew. Homebrew doesn't (yet) provide bottles for all packages on Apple Silicon that we do on Intel x86_64 but we welcome your help in doing so. Rosetta 2 on Apple Silicon still provides support for Intel x86_64 in /usr/local."

Last week, Apple released macOS Big Sur and the rollout was anything but smooth. The mass upgrade caused the Apple servers responsible for checking if a user opens an app not downloaded from the App Store to slow to a crawl. Apple eventually fixed the problem, "but concerns about paralyzed Macs were soon replaced by an even bigger worry -- the vast amount of personal data Apple, and possibly others, can glean from Macs performing certificate checks each time a user opens an app that didn't come from the App Store," writes Dan Goodin via Ars Technica. From the report: Before Apple allows an app into the App Store, it must first pass a review that vets its security. Users can configure the macOS feature known as Gatekeeper to allow only these approved apps, or they can choose a setting that also allows the installation of third-party apps, as long as these apps are signed with a developer certificate issued by Apple. To make sure the certificate hasn't been revoked, macOS uses OCSP -- short for the industry standard Online Certificate Status Protocol -- to check its validity. [...] Somehow, the mass number of people upgrading to Big Sur on Thursday seems to have caused the servers at ocsp.apple.com to become overloaded but not fall over completely. The server couldn't provide the all clear, but it also didn't return an error that would trigger the soft fail. The result was huge numbers of Mac users left in limbo.

The post Your Computer Isn't Yours was one of the catalysts for the mass concern. It noted that the simple HTML get-requests performed by OCSP were unencrypted. That meant that not only was Apple able to build profiles based on our minute-by-minute Mac usage, but so could ISPs or anyone else who could view traffic passing over the network. (To prevent falling into an infinite authentication loop, virtually all OCSP traffic is unencrypted, although responses are digitally signed.) Fortunately, less alarmist posts like this one provided more helpful background. The hashes being transmitted weren't unique to the app itself but rather the Apple-issued developer certificate. That still allowed people to infer when an app such as Tor, Signal, Firefox, or Thunderbird was being used, but it was still less granular than many people first assumed. The larger point was that, in most respects, the data collection by ocsp.apple.com wasn't much different from the information that already gets transmitted in real time through OCSP every time we visit a website. [...] In short, though, the takeaway was the same: the potential loss of privacy from OCSP is a trade-off we make in an effort to check the validity of the certificate authenticating a website we want to visit or a piece of software we want to install.

In an attempt to further assure Mac users, Apple on Monday published this post. It explains what the company does and doesn't do with the information collected through Gatekeeper and a separate feature known as notarization, which checks the security even of non-App Store apps. The post went on to say that in the next year, Apple will provide a new protocol to check if developer certificates have been revoked, provide "strong protections against server failure," and present a new OS setting for users who want to opt out of all of this. [...] People who don't trust OCSP checks for Mac apps can turn them off by editing the Mac hosts file. Everyone else can move along.

Yesterday, Apple released the latest version of macOS: macOS Big Sur (also known as macOS 11.0) and the rollout was anything but smooth. Many users have complained about Apple services such as iMessage, or even Apple Pay, not working for them. Personally, my 5K iMac (2013), which isn't even compatible with Big Sur, ground to a halt yesterday, as I was unable to open up Google Chrome or any of my Adobe Creative Cloud apps. Even navigating my system preferences was painfully slow.

According to developer Jeff Johnson, the reason apps were failing to launch was because a process called "trustd" failed to attempt to connect to Apple's Online Certificate Status Protocol website (oscp.apple.com). "[D]enying the connection between "trustd" and oscp.apple.com fixes the issue, as does disabling a Mac's connection to the internet," notes Apple Insider. Slashdot reader shanen shares their experience: The story is about different problems, so I'll just start with my own anecdote. The 12GB download was amazingly slow. I'm being charitable and willing to attribute that to high demand. Eventually it did finish. The installation process didn't seem to be too bad. Then I did something with the Mac and it immediately wanted another upgrade. Turned out to be a double upgrade of two slightly different versions of some tools, but another (slow) GB bites the dust. Meanwhile, it decided to do that double-upgrade again? One of those two must have succeeded, because the third attempt failed with the appropriate notice that it had succeeded.

Bottom line? Not reassuring, but it seems to be okay now. I should have made a note about what triggered the extra GB, but I don't think I did anything unusual that should have required an OS-level extension of the system. Ergo, whatever was going on, I think it belonged in the original 12 GB download... Disclaimer needed: I just had an extremely negative interaction with Apple about the battery swelling problem in the course of attempting to consider whether or not I should upgrade my old MacBook Pro. It started on the Apple website, which was amazingly unhelpful even after it dangled a trade-in offer of some kind. Then it continued with a long phone call to a very kind and friendly person who seemed to know not so much, though he eventually led me to the search that revealed "Optimized Battery Charging" as an option that my old Mac cannot use. By the way, new iPhones apparently have it, too. So right now I think Apple finally figured out how to stop the battery swelling, but I am still screwed. I regard the Mac as a sunk cost, and the second rule of sunk cost is to NOT throw good money after bad. The first rule is that no one wants to talk about their mistakes, eh?

So did your upgrade to Big Sur go better than mine? I really hope so. Why share the misery? We have plenty of that with "He whose name need not be mentioned" anymore.

A sizeable number of Mac users are experiencing occasional system crashes after updating to macOS Catalina version 10.15.4, released a few weeks ago. From a report: The crashing issue appears to be most prominent when users attempt to make large file transfers. In a forum post, SoftRAID described the issue as a bug and said that it is working with Apple engineers on a fix for macOS 10.15.5, or a workaround. "SoftRAID said the issue extends to Apple-formatted disks: There is a serious issue with 10.15.4. It shows up in different scenarios, even on Apple disks but is more likely when there are lots of IO threads. We think it is a threading issue. So while SoftRAID volumes are hit the hardest (it's now hard to copy more than 30GB of data at a time), all systems are impacted by this. In our bug report to Apple, we used a method to reproduce the problem with ONLY Apple formatted disks. Takes longer to reproduce, but that is more likely to get a faster fix to the user base."

David Shayer, who worked as a software engineer at Apple for 18 years across iPod, the Apple Watch, and Apple's bug-tracking system Radar, among other projects, looks at the current iOS and macOS releases and tries to work out why they are so buggy. He writes: 1. Overloaded Feature Lists Lead to Schedule Chicken: Apple is aggressive about including significant features in upcoming products. Tight schedules and ambitious feature sets mean software engineers and quality assurance (QA) engineers routinely work nights and weekends as deadlines approach. Inevitably some features are postponed for a future release, as we saw with iCloud Drive Folder Sharing. In a well-run project, features that are lagging behind are cut early, so engineers can devote their time to polishing the features that will actually ship. But sometimes managers play "schedule chicken" since no one wants to admit in the departmental meeting that their part of the project is behind. Instead, they hope someone else working on another aspect of that feature is running even later, so they reap the benefit of the feature being delayed without taking the hit of being the one who delayed it. But if no one blinks, engineers continue to work on a feature that can't possibly be completed in time and that eventually gets pushed off to a future release.

2. Crash Reports Don't Identify Non-Crashing Bugs: If you have reporting turned on (which I recommend), Apple's built-in crash reporter automatically reports application crashes, and even kernel crashes, back to the company. A crash report includes a lot of data. Especially useful is the stack trace, which shows exactly where the code crashed, and more importantly, how it got to that point. A stack trace often enables an engineer to track down the crash and fix it. Crash reports are uniquely identified by the stack trace. The same stack trace on multiple crash reports means all those users are seeing the same crash. The crash reporter backend sorts crash reports by matching the stack traces, and those that occur most often get the highest priority. Apple takes crash reports seriously and tries hard to fix them. As a result, Apple software crashes a lot less than it used to. Unfortunately, the crash reporter can't catch non-crashing bugs. It's blind to the photos that never upload to iCloud, the contact card that just won't sync from my Mac to my iPhone, the Time Capsule backups that get corrupted and have to be restarted every few months, and the setup app on my new iPhone 11 that got caught in a loop repeatedly asking me to sign in to my iCloud account, until I had to call Apple support. (These are all real problems I've experienced.) Shayer has offered several more possible explanations in the original post.

itwbennett shares a report from CSO: iTerm2 users: It's time to upgrade. A security audit sponsored by the Mozilla Open Source Support Program uncovered a critical remote code execution (RCE) vulnerability in the popular open-source terminal app for macOS. ITerm2 is an open-source alternative to the built-in macOS Terminal app, which allows users to interact with the command-line shell. Terminal apps are commonly used by system administrators, developers and IT staff in general, including security teams, for a variety of tasks and day-to-day operations.

The iTerm2 app is a popular choice on macOS because it has features and allows customizations that the built-in Terminal doesn't, which is why the Mozilla Open Source Support Program (MOSS) decided to sponsor a code audit for it. The MOSS was created in the wake of the critical and wide-impact Heartbleed vulnerability in OpenSSL with the goal of sponsoring security audits for widely used open-source technologies. The flaw, which is now tracked as CVE-2019-9535, has existed in iTerm2 for the past seven years and is located in the tmux integration. Tmux is a terminal multiplexer that allows running multiple sessions in the same terminal window by splitting the terminal screen. The flaw was fixed in iTerm2 version 3.3.6, which was released today.

It's happening a little later in the season than usual, but Apple's latest version of macOS is available to download today. From a report: Catalina arrives on the heels of iOS 13, which saw several back-to-back updates after an initially rough launch. For what it's worth, I've been using successive versions of the Catalina beta as my daily driver for months now and can assure you that the latest build is stable enough to safely install. [...] Speaking of games, today also marks the first time that Catalina beta users will have been able to play Apple Arcade games. If you're wondering how the heck you'll play those titles from your Mac, it's worth a reminder that many Arcade games support Xbox and PlayStation controllers.

Also new in this release: As you browse episodes in the podcast app, you'll see avatars for guests and hosts. Apple also says it's made some small usability tweaks to Sidecar, the feature that allows you to use an iPad as a secondary Mac display. You'll also notice more promotional Apple TV+ material in the new TV app, which makes sense -- the streaming service launches November 1st. It'll cost $4.99 a month, but Apple is offering a free year with the purchase of a new Mac, iPhone, iPad or Apple TV. Further reading: Apple's MacOS Catalina Opens Up To iPad Apps; Apple Will Permanently Remove Dashboard In macOS Catalina; Apple Replaces Bash With Zsh as the Default Shell in macOS Catalina; and Apple Finally Kills iTunes.

An anonymous reader writes: "DDoS-for-hire services, also known as DDoS booters, or DDoS stressors, are abusing macOS systems to launch DDoS attacks," reports ZDNet. "These attacks are leveraging macOS systems where the Apple Remote Desktop feature has been enabled, and the computer is accessible from the internet, without being located inside a local network, or protected by a firewall. More specifically, the attackers are leveraging the Apple Remote Management Service (ARMS) that is a part of the Apple Remote Desktop (ARD) feature. When users enable the Remote Desktop capability on their macOS systems, the ARMS service starts on port 3283 and listens for incoming commands meant for the remote Mac." Hackers have figured out a way to bounce traffic off these ports and carry out DDoS attacks with the help of internet connected Macs. Nearly 40,000 macOS systems are currently connected online and can be used to send out DDoS attacks.

Apple Wireless Direct Link (AWDL), a protocol installed on over 1.2 billion Apple devices, contains vulnerabilities that enable attackers to track users, crash devices, or intercept files transferred between devices via man-in-the-middle (MitM) attacks. From a report: These are the findings of a research project that started last year at the Technical University of Darmstadt, in Germany, and has recently concluded, and whose findings researchers will be presenting later this month at a security conference in the US. The project sought to analyze the Apple Wireless Direct Link (AWDL), a protocol that Apple rolled out in 2014 and which also plays a key role in enabling device-to-device communications in the Apple ecosystem. While most Apple end users might not be aware of the protocol's existence, AWDL is at the core of Apple services like AirPlay and AirDrop, and Apple has been including AWDL by default on all devices the company has been selling, such as Macs, iPhones, iPads, Apple watches, Apple TVs, and HomePods. But in the past five years, Apple has never published any in-depth technical details about how AWDL works. This, in turn, has resulted in very few security researchers looking at AWDL for bugs or implementation errors.

puddingebola writes: In May, security researcher Filippo Cavallarin made public a vulnerability in macOS's Gatekeeper. The vulnerability can allow an attacker to use a symlink and an NFS server to bypass Gatekeepers authentication and run malicious code. The malware has been named OSX/Linker and has been tied to the same group that operates the OSX/Surfbuyer adware. All macOS versions are affected, including the latest 10.14.5, and Apple has yet to release a patch to this day, a full month after Cavallarin's public disclosure.

Microsoft is bringing its Windows Defender anti-malware application to macOS -- and more platforms in the future -- as it expands the reach of its Defender Advanced Threat Protection (ATP) platform. From a report: To reflect the new cross-platform nature, the suite is also being renamed to Microsoft Defender ATP, with the individual clients being labelled "for Mac" or "for Windows." macOS malware is still something of a rarity, but it's not completely unheard of. Ransomware for the platform was found in 2016, and in-the-wild outbreaks of other malicious software continue to be found. Apple has integrated some malware protection into macOS, but we've heard from developers on the platform that Mac users aren't always very good at keeping their systems on the latest point release. Further reading: Microsoft launches previews of Windows Virtual Desktop and Defender ATP for Mac.

Google's bug-hunting researchers known as Project Zero have revealed a fresh zero-day vulnerability in macOS called "BuggyCow." "The attack takes advantage of an obscure oversight in Apple's protections on its machines' memory to enable so-called privilege escalation, allowing a piece of malware with limited privileges to, in some cases, pierce into deeper, far more trusted parts of a victim's Mac," reports Wired. "The trick's name is based on a loophole the hackers found in the so-called copy-on-write, or CoW, protection built into how MacOS manages a computer's memory." From the report: Some programs, when dealing with large quantities of data, use an efficiency trick that leaves data on a computer's hard drive rather than potentially clog up resources by pulling it into memory. That data, like any data in a computer's memory, can sometimes be used by multiple processes at once. The MacOS memory manager keeps a map of its physical location to help coordinate, but if one of those processes tries to change the data, the memory manager's copy-on-write safeguard requires it to make its own copy. Which is to say, a program can't simply change the data shared by all the other processes -- some of which could be more highly privileged, sensitive programs than the one requesting the change.

Google's BuggyCow trick, however, takes advantage of the fact that when a program mounts a new file system on a hard drive -- basically loading a whole collection of files rather than altering just one -- the memory manager isn't warned. So a hacker can unmount a file system, remount it with new data, and in doing so silently replace the information that some sensitive, highly privileged code is using. Technically, as a zero-day vulnerability with no patch in sight, BuggyCow applies to anyone with an Apple laptop or desktop. But given the technical skill and access needed to pull it off, you shouldn't lose much sleep over it. To even start carrying out this Rube Goldberg -- style attack, a hacker would need a victim to already have some form of malware running on their computer. And while BuggyCow would allow that malware to potentially mess with the inner workings of higher-privileged parts of the computer, it could do so only if it found a highly privileged program that kept its sensitive data on the hard drive rather than memory. Project Zero says it warned Apple about BuggyCow back in November, but Apple hadn't acted to patch it ahead of last week's public reveal.

A new variant of the multi-stage Shlayer malware known to target macOS users has been observed in the wild, now being capable to escalate privileges using a two-year-old technique and to disable the Gatekeeper protection mechanism to run unsigned second stage payloads. Bleeping Computer reports: This new Shlayer variant unearthed by Carbon Black's Threat Analysis Unit (TAU) targets all macOS releases up to the latest 10.14.3 Mojave, and will arrive on the targets' machines as a DMG, PKG, ISO, or ZIP files, some of them also signed with a valid Apple developer ID to make them look legitimate. Shlayer samples found by TAU also use malicious shell scripts to download additional payloads just like older installments did, and, in the case of samples distributed as DMG images, will surreptitiously launch a .command script in the background after the user launches the fake Flash installer. The malicious script included in the DMG is encoded using base64 and will decrypt a second AES encrypted script which will be executed automatically after being decrypted.

One it successfully downloads the second stage malware payload, Shlayer will "to escalate privileges with sudo using a technique invoking /usr/libexec/security_authtrampoline," presented by Patrick Wardle in his Death by 1000 Installers talk at DEFCON 2017. The next step is to download extra payloads which all contain adware according to TAU and it makes sure they'll be able to run on the compromised Mac by disabling the Gatekeeper protection mechanism. After this is accomplished, all extra payloads downloaded and launched by Shlayer will be seen as whitelisted software because the OS will no longer check if they are signed with an Apple developer ID. Also, just in case the malware is not able to disable Gatekeeper on the infected Mac, some of the second stage payloads are also signed with valid developer IDs.

An anonymous reader quotes a report from Ars Technica, written by Sean Gallagher: Want to be able to run classic Mac OS applications compiled for the Motorola 68000 series of processors on your ever-so-modern Mac OS X machine? Or maybe you'd rather run them on a Raspberry Pi, or an Android device for that matter? There's an emulation project that's trying to achieve just that: Advanced Mac Substitute (AMS). Advanced Mac Substitute is an effort by long-time Mac hacker Josh Juran to make it possible to run old Mac OS software (up to Mac OS 6) without a need for an Apple ROM or system software. Other emulators out there for 64000 Mac applications such as Basilisk II require a copy of MacOS installation media -- such as install CDs from Mac OS 7.5 or Mac OS 8. But AMS uses a set of software libraries that allow old Mac applications to launch right within the operating environment of the host device, without needing to have a full virtual hardware and operating system instance behind them. And it's all open source.

I got a demo of AMS from Juran at Shmoocon in Washington, DC, this past weekend. He showed me an early attempt at getting the game LoadRunner to work with the emulator -- it's not yet interactive. A version of the project, downloadable from Github, includes a "Welcome" screen application (a sort of Mac OS "hello world"), Mac Tic-Tac-Toe, and an animation of NyanCat. Applications are launched from the command line for now and are executed by the emulation software, which interprets the system and firmware calls. Unfortunately, there's still a lot of work to be done. While AMS works on Mac OS X up to version 10.12 -- both on Intel and PowerPC versions of the operating system -- the code currently won't compile on MacOS Mojave. And the Linux implementation of AMS does not yet support keyboard input. I was unable to get the front end to execute at all on Debian 9 on Intel.

Apple today pushed software updates for a range of its computing platforms. They are all minor releases that simply offer a few bug fixes and security updates, with no new features -- and there are no new features in any of the beta releases for these versions of the operating systems, either. From a report: iOS 12.1.3 fixes a scrolling bug in Messages, an iPad Pro-specific audio bug, and a graphical error in some photos, and it addresses some CarPlay disconnects experienced by owners of the three new iPhone models released in late 2018. It also fixes two minor bugs related to the company's HomePod smart speaker.

Four months after a mysterious group was outed for a digital espionage operation that used novel techniques to target Mac users, its macOS malware samples continued to go undetected by most antivirus providers, a security researcher reported on Thursday. Ars Technica reports: Windshift is what researchers refer to as an APT -- short for "advanced persistent threat" -- that surveils individuals in the Middle East. The group operated in the shadows for two years until August, when Taha Karim, a researcher at security firm DarkMatter, profiled it at the Hack in the Box conference in Singapore. Slides, a brief description, and a report from Forbes are here, here and here, respectively.

On Thursday, Mac security expert Patrick Wardle published an analysis of Meeting_Agenda.zip, a file Karim had said installed the rare Mac malware. To Wardle's surprise, results from VirusTotal at the time showed that only two antivirus providers -- Kaspersky and ZoneAlarm -- detected the file as malicious. Wardle then used a feature that searched VirusTotal for related malicious files and found four more. Three of them weren't detected by any AV providers, while one was detected by only two providers. The reason the findings were so surprising is that Apple had already revoked the cryptographic certificate the developers used to digitally sign their malware. That meant Apple knew of the malware. In fairness, the control servers the malware contacts are no longer available on the Internet. That means any infected computers aren't in danger of being surveilled. Also in fairness, the number of detections has slowly risen in the day since Wardle published his analysis.

A North Korea-linked hacking group, dubbed Lazarus, deployed malware for macOS in an effort to infiltrate cryptocurrency exchanges. "In one of the attacks, which Kaspersky refers to as Operation AppleJeus, the group tricked an unsuspecting employee to download a trojanized cryptocurrency trading application that covertly downloaded and installed the Fallchill malware," reports SecurityWeek. Their malware was designed to target macOS in addition to Windows, marking the first time Lazarus has been observed using malware for Apple's OS, according to Kaspersky. The malware was reportedly pushed via an update. Slashdot reader asjk writes: The legitimate-looking application is called Celas Trade Pro and comes from Celas Limited. It's an all-in-one style cryptocurrency trading program which installs malicious code via an update. "... [the program] was seen running the Updater.exe module, which would collect system information and send it back to the server in the form of a GIF image," reports SecurityWeek. "Based on the server's response, the updater either keeps quiet or extracts a payload with base64 and decrypts it using RC4 with another hardcoded key to retrieve an executable file."

"Autodesk has published a support document announcing that it is stopping development of its Alias and VRED vertical market packages, and that older versions will not work on Mojave due to Apple's OpenGL deprecation," writes Stephen Silver for Apple Insider. Alias is software predominantly used in automotive design and industrial design, while VRED is 3D visualization software. From the report: According to a note posted on Autodesk's support website, while older Alias versions can run on High Sierra or earlier, "no versions of VRED will run on that operating system due to the OpenGL deprecation." The change, according to the Autodesk note, "allows Autodesk development teams to focus on bringing innovations to market faster, and allows for more frequent software updates." "In the end, the entire Alias and VRED community will benefit from this streamlined approach," wrote the company.

This follows the announcement by Apple in June at WWDC that Mojave will require graphics hardware to support Metal, and that active development has ceased for OpenGL and OpenCL on the Mac. It isn't clear why Autodesk made the declaration that OpenGL's deprecation was responsible for the applications not working in Mojave. Deprecation does not mean removed, and the existing OpenGL implementation in High Sierra remains in Mojave. The move at present does not appear to affect the core AutoDesk product.

Apple's macOS surreptitiously creates and caches thumbnails for images and other file types stored on password-protected / encrypted containers (hard drives, partitions), according to macOS security experts Wojciech Regula and Patrick Wardle. From a report: The problem is that these cached thumbnails are stored on non-encrypted hard drives, in a known location and can be easily retrieved by malware or forensics tools, revealing some of the content stored on encrypted containers. On macOS, these thumbnails are created by Finder and QuickLook. Finder is the default macOS file explorer app, similar to Windows Explorer. Whenever a user navigates to a new folder, Finder automatically loads icons for the files located in those folders. For images, these icons are gradually replaced by thumbnails that show a preview of the image at a small scale.