MyCouponize is an aggressive adware infection that simultaneously installs itself in Safari, Chrome and Firefox, It hijacks the user’s search and page loads, redirecting them to multiple web sites that advertise scamware and other unwanted junk.
1. Run the search in DetectX.
2. Click on the [X] button.
You’ll find this button just above the results table to the right, between the search count and the tick (whitelist) button. It will turn red when you hover over it. When it does so, click it.
Then hit ‘Delete’ to remove all the associated items.
You’ll need to enter a password as some of the items are outside of your user folder.
esc key or click the ‘Cancel’ button on any pop up dialogs that appear.
3. Go to the Profiler
Here we’ll unload the launchd processes that belong to MyCouponize.
Navigate to the user launchd processes section and move the cursor over the item
Click the ‘Remove x’ button that appears when the line is highlighted.
Wait for the profiler to refresh and then go back to the same section and remove the second process called
4. Quit the mediaDownloader.app
This item has already been deleted in step 1, but its process may still be running in memory. If its icon appears in the Dock, right click on it and choose ‘Quit’ from the menu.
4. Finally, go to Safari Preferences’ Extensions tab
Click the uninstall button to remove the MyCouponize extension.
After that, Safari should be in good working order. If you have Chrome, Firefox or possibly other browsers installed, make sure you remove the extensions or Add Ons from those, too.
Since early November, I’ve been seeing reports of High Sierra users being presented with a dialog box from the Firewall asking whether the user wants to accept incoming network connections to
This is causing some confusion among troubleshooters as there’s a fairly notorious process with the same name associated with IBM’s (badly-performing) Trusteer software. This latter often causes system slow downs and the general recommendation is to remove it unless you absolutely can’t live without it.
rapportd process responsible for the dialog has nothing to do with IBM’s Trusteer and is, in fact, an Apple daemon introduced in 10.12. According to the man page, Apple’s
rapportd is a daemon providing support for the Rapport connectivity framework. Although
rapportd is bundled with 10.12, it appears to have only become active in 10.13.
lsof -i -P | grep -i rapport
at the command line doesn’t return any hits on my 10.12 machine, but High Sierra reveals that Apple’s
rapportd process is listening for network connections on port 49158. Further investigations have found that
rapportd is connected to Apple’s HomeKit framework, a home automation platform for controlling smart home products with iOS apps and Siri voice commands, and is likely related to Airplay 2.
To verify which
rapportd process you’re dealing with, jump into Terminal and paste this command:
ps aux | grep rapportd
Alternatively, if you’re a DetectX Swift user, you can search for it in the Profiler view (Command-F evokes the Find inspector bar):
If the search or find reveals a process address as
/usr/libexec/rapportd, that’s your Apple friend and you can safely allow the connection. Searches for
rapportd also might produce any of the following paths, all of which are legitimate:
On the other hand, if you see a path address for
or searches reveal
that’s the IBM app you’re looking at. Whether you want to allow that or uninstall that will depend on both your mac’s performance and whether you need the software or not.
Hope that helps to clear up some of the confusion!
Given news that some hackers are using websites to mine cryptocurrency even when users apparently close their browser on Windows, I got to wondering whether a similar exploit would work on macOS.
As the video above shows*, a malicious app can easily hide an open Safari window from all desktop workspaces, making it incredibly difficult for users to notice or to make visible again even when they do. This trick can be exploited without elevated privileges, and it doesn’t matter whether the malicious app is code-signed or not.
An invisible Safari window is a problem because it could be running scripts, mining cryptocurrency, redirecting to sites for adware revenue or doing all manner of other things. Note the window could contain multiple tabs that the user may have already been tricked into opening before the window is made invisible.
As can be seen in the video, the Safari window isn’t in another full screen workspace, or minimized in the Dock or hidden by any other window or toolbar (as in the Windows 10 trick).
On the contrary, it can’t actually be found anywhere, and nor will Window > Bring All To Front help. If you open a new window and then try to use Merge All Windows to bring the hidden window out, all that happens is your new window will disappear with the hidden window too.
The only visible indicators that there’s an invisible window open are the window list in the Window menu, and the invisible outline revealed by Expose (four-finger swipe down).
So what if you find there is an invisible window hiding from you, how do you get it back?
To retrieve and kill the hidden window, you need to click View > Enter Full Screen, then click the red close button. Don’t click the green button to take it out of full screen though, as that’ll just cause it to hide again, with a nice animation that you can see on the video!
Another day, another hacker trick to watch out for folks!
* This vulnerability was demonstrated on 10.12.6. It also exists in both 10.11.6 El Capitan and 10.13.2 High Sierra.
Update: There’s a security update available in the App Store now that mitigates this risk. It should be applied by all High Sierra users as a matter of urgency.
Today has been all about a monumental security flaw in High Sierra which allows anyone to log in to a mac and immediately become the root user without a password at all.
If you haven’t yet seen the news, check out the 30-second video above. If you’re not on High Sierra, no need to worry.
Although there are conflicting reports of exactly under what conditions the exploit can be triggered, it seems that in most cases two attempts are required to escalate user privileges. The first time enables the root user with the password that you do or do not put in the password field (i.e., it’ll accept a blank password). The second time is using those credentials to unlock whatever it is you want to unlock (in the video, only 1 attempt is shown as I had already ran the exploit once prior to making the video). There also seems to be conflicting reports about whether the flaw can be exploited remotely. What does seem certain is that malicious 3rd party applications could programmatically use it to escalate privileges for themselves, so it’s important to make sure you take the proper precautions to deal with this flaw until Apple patches it with an update.
Alas, with so much excitement, it seems some people are getting confused about exactly what needs to be done to avoid falling victim to this security flaw. The answer is not, as has been mistakenly suggested in some quarters, to disable the root user, but quite the reverse: you need to enable it.
The one thing that stops the flaw from being exploited is having the root user already enabled and set with a strong password.
By default, macOS ships with the root user disabled, so unless you (or someone who administrates your mac) has enabled it at some point, it won’t be set. If you’re not sure, this AppleScript will quickly tell you the status of the root user:
Update: further testing on 10.13 shows that the root user may be enabled without writing a ShadowHash entry to dscl. In that case, the script would incorrectly indicate root was disabled. Thus, to be certain, the best way to check is to follow the instructions in the apple support article linked to below.
If you find the root user is disabled, then go and enable it by following Apple’s instructions here:
Be sure to use a strong password of at least 14 characters or more. You can save the password if you want, but it doesn’t really matter much if you forget it. There’s really never any need for an admin user to require the root user at all, and there are other ways to get root privileges safely through the Terminal if needs be.
One of the obstacles in becoming a command line guru is actually figuring out not just what’s available (see learning the Terminal: part Three) but how to use it. That just got a whole lot easier thanks to a (relatively) new tool called tldr.
Most command line (CLI) utilities come with either a man page or a help command, invoked either by
man or <
/path/to/tool> --help, respectively. That’s traditionally the way we learn all the ins-and-outs of a given tool. If you’re lucky, there will be some examples at the end of the man page, and if you’re luckier still, there’ll be an example of exactly what you want to do with the tool there, too.
But what if you’re not lucky? Some CLI tools come with very few or no examples, some come even without a help command or man page. When that happens, prior to tldr your best bet was to go on an internet search or ask a friendly CLI expert if you knew one.
Now, tldr provides a third, and perhaps better, option. Unlike traditional man pages, tldr just spits out some basic examples of the CLI tool you specify, and that (more often than not) may be all all you need to get going (see the screenshots for examples).
If you have brew installed, you can get tldr easily with the command
brew install tldr
Using it is simple. Try some of these for fun:
and so on. Here’s the output for
The one thing tldr doesn’t seem to have built in that I can find is a list of the commands it knows about. There is a workaround, though. You can search through the tldr pdf to see what’s available. Alternatively, we can us a bit of command-line magic to do it for us:
find ~/.tldrc -path '*common*' -or -path '*osx*' | cut -d"/" -f8 | cut -d"." -f1 | sort
If you’d like to make that into a nice little function that you can call simply with something like
tldr_list, review the first post in this series on how to make and add functions to your
As tldr is a community-based program, it is likely to be added to quite regularly (I have a few I’m planning to contribute myself), so we can only hope that the pdf is updated regularly and/or that tldr gains a proper introspective list function.
Speaking of updates, if you try tldr on itself, i.e,
you’ll note the ‘update’ command. It’s probably worth remembering to run that from time to time. tldr also comes, of course, with its own man page, too!
Time was this would take a trip to the Terminal, but if you’re running Sierra or above there’s a handy new keyboard shortcut.
Just activate the Finder and hold down shift-command-period. Repeat to toggle invisible files off again.
This works not only in save and open dialog sheets, but in regular Finder windows also.
Spoofing or phishing – presenting a user with fake authentication requests – is a common email tactic, but it’s not the only vector where you need to be on your guard. Every version of macOS is vulnerable to a very simple phishing attack right on your desktop that doesn’t require admin privileges to run, would not be detected by GateKeeper or XProtect, and which could easily be placed on your mac by any of the nefarious malware / adware installer scripts that come with some less reputable software downloads.
This attack isn’t new, but it’s not often talked about. The easiest way to see how it works is in this quick 4-minute demo:
As you can see, it’s easy to grab the icon of any Application and put it in the script; it doesn’t even have to be the icon of an app that’s running. The simple demo I gave above could easily launch iTunes first to increase the coherence of the attack, or it could use a completely different icon, including the icon of security programs you may have running on your mac.
How can you check?
If you were presented with a password request like this and wanted to check whether it’s legitimate or not, an easy way would be to use my free utility DetectX Swift’s Profiler. Click the Profiler function, and search for ‘osascript’ within the Running Processes section. Note how DetectX Swift shows you the text of the script being run, confirming that this dialog is up to no good:
It’s been unusually quiet on Applehelpwriter these past few months, and the reason is that I’ve been devoting all my time and efforts to the new version of DetectX. The new version is called DetectX Swift because (yeah, you guessed it) I wrote it in Swift and because it’s considerably faster than its older sibling.
DetectX Swift’s got a new interface, but there’s far more going on under the hood. The Search uses some fancy heuristics as well as hard-coded and live update search definitions to ensure it provides the very best in security threat scanning.
The new Profile view employs some super cool dynamic highlighting and lets you inspect the contents not only of directories but also of scripts, plists and other files that could execute troublesome code on your mac.
There’s changes in the History view, too, both in the display and functions. One of the coolest things I like about the new History function is that you can run a diff on any previous run against the latest run, immediately seeing how they differ.
There’s tons more to DetectX Swift, but the best way to find out about it is just to try it. The beta version is free to use for both Home and Commercial users, so just head off over to its home page and grab yourself a copy!
Don’t forget to keep us informed of how it goes. The beta is still in an early stage and more features are slated as it develops, but feel free to tell us about anything that you feel could be done better or things that you’d like to see added.
Share and enjoy! 🙂