Blog Archives

let’s bury the myth of the safe Mac

image for do macs get malware

Do Macs get malware? Can my Mac get infected by a virus? Do I need AV software for my Mac? These are questions I hear a lot, but the answers that come from many so-called Apple Mac gurus are often wrong or misleading.

In this post, we’ll take a look at some of the reasons why people think Macs are safe from malware and the confusions that are often bandied around concerning “AV” (“anti virus software”), “viruses” and genuine malware. Then we’ll look at the actual security situation on macOS and make some suggestions as to how you can stay safe without turning yourself into a paranoid security conspiracist or downloading useless software that just eats up your system resources while providing no real protection.

“It’s All Security Theatre” theatrics

There’s an unfortunate and dangerous misconception perpetrated by certain people in the macOS community. These people variously claim that there is no malware threat to Macs, or if there is then Macs are immune from it, and no matter what the case, Macs are inherently safer than other kinds of computer, specifically Windows computers.

The purveyors of such arguments typically make a big deal of trying to undermine any argument that security is an issue on macOS by claiming that malware on Macs is all a myth made up by AV vendors to drum up business for their own products. In many Mac user forums, people worried about hacking and malware are often treated to dismissive replies of this sort:

“you are at much greater risk from a concussion due to a fish falling from the sky. The Mac AV industry and security researchers have worked very hard to make you believe this is something to be afraid of.”

The claim that emanates from such people often begins with “there are no known viruses for macOS” and, therefore, you don’t need anti-virus software. This is a laughable confusion of terminology.

image of do Macs get malware

AV software is inappropriately named. There actually aren’t any known viruses on macOS, it’s true (these days, there are very few for Windows either and most AV software isn’t primarily looking for them). That’s because viruses are a specific kind of threat that went out of fashion long ago. Viruses were the product of vandals; the modern security threats facing macOS users are the products of profiteers. It’s a different ball game.

These days, criminals are more interested in pushing macOS adware, backdoors, keyloggers, RATS, trojans and spyware. Ransomware has also been known on the platform, though thankfully to date that’s an isolated incident.

The conspiracy theorists like to point out that security vendors have a vested interest in making people fearful. It’s rather like saying insurance companies or law enforcement have an interest in higher crime rates. I’m all for healthy cynicism. The reality is that there are, indeed, commercial interests involved in fighting malware just as there are in fighting other kinds of crime. And where there’s commerce, you’ll also find cheats and unscrupulous dealers. There are plenty of dodgy AV products around; some are even on the Apple App Store. Some of those proclaiming that the security industry is all fraud are pushing their own software as an alternative. Unscrupulous, indeed.

Be wary of any software that offers to “find” threats but then insists you pay up in order to remove them or which tries to lock you in after minimal use where you cannot fully determine the value of the offering.

image of mackeeper fake search

However, unlike the one shown above and others like it, there are genuine security products out there developed by genuinely-good people serving the community.

But the real point is that the existence of commercial interests in the anti-malware industry is, on its own, no more an indicator of duplicity than it is in any other industry. While amplification of threat intelligence through news stories, tweets and other social media serves the security industry just as amplification of relevant issues serves any business sector, to claim that all vendors are unscrupulous or that the threat is entirely fictional is disingenuous and worse, it’s dangerous.

As we’ll see below, the threats are real, but the conspiracy theorists threaten to lead macOS users into a false sense of security.

Burying the Myth of the Safe Mac

It’s not just the conspiracy theorists you have to watch out for. It’s also the “wisdom of the wise”. Far and wide, you’ll hear Mac gurus arguing from their own personal experience that, since they’ve never encountered macOS malware and they’ve been using the platform for x, y, z amount of years, there are, consequently, no malware threats to macOS and that it’s inherently safer than other platforms.

The logical fallacy in that should be clear. Arguing from a sample of one to a conclusion for all is just bad thinking. It also should perhaps come as no surprise if a “power user” hasn’t come across threats to their own Mac. They typically have limited and specialised interests that don’t take them to many of the far corners of the internet. Power users also tend to write scripts or even their own software to do things on their Mac, whereas other users would instead go looking for a tool to download from adware-infested mass distribution sites, torrent sites and who-knows-where, with all the risks that that involves.

When the self-professed gurus tell you they have never encountered a security issue on a Mac, they aren’t testifying to the safety of the platform; they are in fact revealing only that they know nothing about macOS security.

Will Gatekeeper Protect You From Malware?

Some people are more realistic and acknowledge the existence of the threat, just as Apple themselves have done by building anti-malware protections into macOS itself, namely, Gatekeeper, XProtect and MRT (Malware Removal Tool).

Because Apple have taken these measures and have been pretty vocal in their marketing about it, too, many think that Apple’s built-in security technologies will keep them safe. Here’s a typical example of this kind of thinking, where a forum poster suggests Apple may not be sharing information about malware threats because they can just kill them by revoking the malware developer’s code signature.

image of post about apple gatekeeper

Of course, there is no such setting as “Run only signed apps”, but seasoned Mac users would understand that the poster is referring to Gatekeeper, which is the first check the system makes on application code signatures.

Unfortunately, the poster is just flat-out wrong. Even when set to App-Store only, it’s a simple matter for even a standard user to run apps with invalid signatures or no codesigning at all. Both Gatekeeper and XProtect are easily bypassed. Not only can standard users override Gatekeeper’s “App Store only” settings, so can other processes. None of this needs admin privileges. As for Apple’s Malware Removal Tool, it is useful to the extent of its signature database, but it has the major limitation that it only runs when you reboot your Mac.

Malware Campaigns That Target macOS Users

A typical day for me hunting macOS threats on VirusTotal looks something like this, with several hundred new samples to inspect:

image of a threat found on virus total

So, yes, macOS malware is a thing and it’s out there. From nation state actors to sneaky hackers on Discord, if you’re using a Mac to interact widely with other people, visit websites, read email – in other words, doing the things that make your Mac useful – then there is a non-negligible chance of you encountering someone trying to infect your Mac.

In 2018 alone, we saw the emergence of malware families such as OSX.MaMi, CrossRAT, OSX.AppleJeus, WindTail, OSX.Dummy, CoinTicker, OSX.DarthMiner and OSX.LamePyre. On top of that, we’ve seen the appearance of a number of adware installers acting as trojans for cryptominers, such as PPMiner, CreativeUpdate and SearchPageInstaller. Old favourites like OSX.Fruitfly remain viable threats that can be repurposed by other actors as neither XProtect nor Gatekeeper is equipped to tackle script-based and fileless attacks.

Adware and PPI (pay-per-install) PUPs (potentially unwanted programs) like MacKeeper and Advanced Mac Cleaner, MyShopcoupon and chill tab are rampant. Adware in general is an increasing concern as we see adware developers expand their range of techniques and begin to cross the line into malware-like behaviour. Browser extensions are still a widely unappreciated threat, built-in browser anti-phishing protections are easily defeated, and if you haven’t had a phishing email in your Inbox then you are likely one of an increasingly diminishing global minority.

Finally, let’s note that for criminal types, it’s never been easier to get into the macOS malware business with the proliferation of dedicated exploit kits like empyre, EvilOSX, Pupy, Bella, EggShell and others.

How To Stay Safe on macOS

The evidence provided above is conclusive: the threats are real, so don’t let anyone try to kid you otherwise.

That said, the most widespread, “in the wild” problems affecting Macs today come from adware and PUPs. It might not be the end-of-the-world if your Mac gets infected with some nuisance adware and scam virus alerts keep popping up in your browser, but neither is it a particularly pleasant experience that you should have to put up with.

Fortunately, dealing with them is fairly straightforward, so let common-sense prevail. Most home users don’t need the expense or resource-impact of a full-on AV Suite. Reboot your Mac often to take advantage of what protection the built-in MRT tool offers, and use a lightweight, troubleshooting tool like my DetectX Swift to help diagnose and remove problems if your Mac starts behaving oddly.

image of detectx swift search results

While the technically-proficient may be able to deal with a lot of adware from the Terminal, DetectX is light enough to be run on a regular or scheduled basis (like after you install any new software) and can look for and remove adware, malware, keyloggers and more.

You can use DetectX Swift indefinitely and without paying a cent. It won’t burden your finances with a monthly subscription bill or demand that you pay money to remove suspicious or unwanted files, or insist that you pay up after a few uses. While there is an optional registration for home use which also provides a few bonus features, it’s not necessary to register in order to use the app’s core functionality. You can even script it with AppleScript and enjoy almost all the troubleshooting functions it offers as an unregistered, unpaid user. I also offer free, personal triage to both registered and unregistered users if you have an issue that DetectX does not resolve.

If you have a fleet of Macs in an organisational setting you might want to consider the low-cost, DetectX Swift Management license in order to access the command line search tool and integrate with platforms like Jamf or Munki. For more in-depth coverage and cross-platform support, enterprises should look at next-gen AV software that uses behavioural AI like SentinelOne.

Picture Credit: Mikayla Mallek


how to reverse malware on macOS

Resources for learning malware analysis and reverse engineering abound for the Windows platform and PE files, but by comparison there’s very little literature or tutorials for those who want to learn specifically about how to reverse macOS malware and macOS malware analysis techniques.

In this series of posts, you’ll take a sample file and use native tools and techniques to understand what a file does and to build a list of IoCs (Indicators of Compromise) that can be used in detection.

image of reverse engineering malware on macos

As there’s a lot of ground to cover, the tutorial is split over several parts. In Part 1, you’ll learn how to set up a safe environment to test malware on macOS. You’ll install all the tools you need (bonus: doesn’t cost a cent!) and learn where you can source samples of macOS malware from. You’ll examine an application bundle and its contents to understand how it works and find an interesting encrypted text file. In Part 2, you’ll learn the fundamentals of static analysis of Mach-O binaries, the native executable file type for macOS. In Part 3, you’ll use dynamic analysis techniques to execute a malware file in a controlled manner and read code from memory.

If you have ever wanted to learn how to reverse malware on macOS, this is the place to start! Continue reading…

browsers’ anti-phishing protections easily defeated


While troubleshooting a user’s mac the other day, I happened to come across a curious line in one of the logs:

Screen Shot 2018-06-11 at 16.28.05

After a bit of digging, it occurred to me that this and the other flags being sent in the process command were possibly Preferences or Settings in the Looking at chrome://settings/privacy revealed, of course, Google’s phishing and malware protection setting, ‘Protect you and your device from dangerous sites’.

Here it is set to ‘On’, which is the default setting:

Screen Shot 2018-06-11 at 16.31.28

A quick test proved that setting it to ‘Off’ produced the `—disable-client-side-phishing-detection’ flag in the browser’s process output. Setting it back to ’On’ and relaunching the browser produced no output, confirming my theory. 

Screen Shot 2018-06-11 at 16.40.39

A quick message to my user also confirmed that he wasn’t aware that phishing protection had been disabled, and to the best of his memory, had not been disabled by himself. 

A simple preference setting
That got me to wondering whether that setting could be turned off programmatically by another, possibly malicious, process. To my surprise, it turns out that it’s trivial to do so. 

All Chromium browsers have a Preferences file located in their Application Support folder. Usually this is within another folder called ‘Default’, but not always. Chrome and Vivaldi, for example, have it there, but Opera (and Opera Developer) store the Preferences file at the root level of their respective support folders. 

The file contains the setting for whether the Phishing protection should be enabled or not. To determine how the preference was encoded in the file, I made a copy of the current Preferences file, toggled the setting, then made another copy. BBEdit’s ‘Find Differences’ function quickly told me the name of the key (if you don’t have BBEdit, you can also use Xcode’s FileMerge to run diffs, though it isn’t as pretty or as full-featured):

Screen Shot 2018-06-11 at 16.56.36

Again, there are differences among browsers. As shown above, Opera uses the key “fraud_protection_enabled” which takes a boolean. Chrome and Vivaldi, on the other hand, use a “safebrowsing” key which takes an array of key-value pairs, with the first item of the array being the key “enabled:”, and taking a bool for its value, like this:





With this information, it’s a pretty simple thing for another process running under your username to write to the Preferences file and turn off the built-in protections. 

What about Safari?
Safari isn’t vulnerable to quite the same tactic as it doesn’t store its preferences in the same way. However, it’s even easier to defeat Safari’s ‘Warn when visiting a fraudulent website’ setting:

Screen Shot 2018-06-11 at 17.44.08

Apple hardened some of Safari’s preferences (like setting the Home page) some time ago to stop adware from making unauthorised changes, but this one is still unprotected in the current public release of macOS High Sierra. A one-liner in Terminal removes the preference:

defaults write WarnAboutFraudulentWebsites 0

Screen Shot 2018-06-11 at 18.04.48

What can you do?
The ease with which these protections can be surreptitiously turned off in all major browsers is a worry. And let’s face it, who would notice if this setting was quietly turned off? In both Chrome and Safari, the change takes effect immediately and does not even require a restart of the browser.

Fortunately, my shareware app DetectX Swift will warn you if browsing protection is off when you run a search and prompt you to turn it back on. To ensure that all insecure pages have been removed after turning the setting back on, DetectX Swift will continue to show the warning until you restart the browser and execute another search.

Screen Shot 2018-06-14 at 12.24.44

The protection covers all the browsers mentioned above. If you’re running some other browser and would like to know if it’s similarly vulnerable, drop a line in the Comments or contact Sqwarq Support and request support for your browser to be added.

Stay safe, folks! 😀


Featured pic: Nature by PichieArt

defending against EvilOSX, a python RAT with a twist in its tail

EvilOSX is a malware project hosted on GitHub that offers attackers a highly customisable and extensible attack tool that will work on both past and present versions of macOS. The project can be downloaded by anyone and, should that person choose, be used to compromise the Macs of others.

What particularly interested me about this project was how the customisation afforded to the attacker (i.e., anyone who downloads and builds the project, then deploys it against someone else) makes it difficult for security software like my own DetectX Swift to accurately track it down when it’s installed on a victim’s machine.

In this post we’ll explore EvilOSX’s capabilities, customisations, and detection signatures. We’ll see that our ability to effectively detect EvilOSX will depend very much on the skill of the attacker and the determination of the defender.

For low-skilled attackers, we can predict a reasonably high success rate. However, attacker’s with more advanced programming skills that are able to customise EvilOSX’s source code to avoid detection are going to present a bigger problem. Specifically, they’re going to put defenders in an awkward position where they will have to balance successful detection rates against the risk of increasing false positives.

We’ll conclude the discussion by looking at ways that individuals can choose for themselves how to balance that particular scale.

What is it?
EvilOSX is best described as a RAT. The appropriately named acronym stands for remote access trojan, which in human language means a program that can be used to spy on a computer user by accessing things like the computer’s webcam, microphone, and screenshot utility, and by downloading personal files without the victim’s knowledge. It may or may not have the ability to acquire the user’s password, but in general it can be assumed that a RAT will have at least the same access to files on the machine as the login user that has been compromised.

Whether EvilOSX is intentionally malicious or ‘an educational tool’ is very much a matter of perspective. Genuine malware authors are primarily in the business of making money, and the fact that EvilOSX (the name is a bit of a giveaway) is there for anyone to use (or abuse) without obvious financial benefit to the author is arguably a strong argument for the latter. What isn’t in doubt, however, is that the software can be readily used for malicious purposes. Irresponsible to publish such code? Maybe. Malicious? Like all weapons, that depends on who’s wielding it. And as I intimated in the opening section, exactly how damaging this software can be will very much depend on the intentions and skills of the person ‘behind the wheel’.

How does it work?
When an attacker decides to use EvilOSX, they basically build a new executable on their own system from the downloaded project, and then find a way – through social engineering or exploiting some other vulnerability – to run that executable on the target’s system.

There is no ‘zero-day’ here, and out of the box EvilOSX doesn’t provide a dropper to infect a user’s machine. That means everybody already has a first line of defence against a malicious attacker with this tool: Prudent browsing and careful analysis of anything you download, especially in terms of investigating what a downloaded item installs when you run it (DetectX’s History function is specifically designed to help you with this).

EvilOSX doesn’t need to be run with elevated privileges, however, nor does the attacker need to compromise the user’s password. As intimated earlier, it’ll run with whatever privileges the current user has (but, alas, that is often Admin for many Mac users). All the attacker needs to do is to convince the victim to download something that looks innocuous and run it.

Once run, the malicious file will set up the malware’s persistence mechanism (by default, a user Launch Agent) and executable (the default is in the user’s ~/Library/Containers folder) and then delete itself, thus making it harder to discover after the fact how the infection occurred.

After successful installation, the attacker can now remotely connect to the infected machine whenever both the client (i.e., victim) and server (i.e., attacker) are online.

Once the attacker has surreptitiously connected to the client, there are a number of options, including webcam, screenshots, and downloading and exfiltrating browser history.

In my tests, some of the modules shown in the above image didn’t work, but the webcam, screenshots, browser history and the ability to download files from the victim’s machine were all fully functional.

Customisation options
By default, EvilOSX will offer the attacker the option of making a LaunchAgent with a custom name – literally, anything the attacker wants to invent, or to use the default

That in itself isn’t a problem for DetectX Swift, which examines all Launch Agents and their program arguments regardless of the actual filename. The malware also offers the option to not install a Launch Agent at all. Again, DetectX Swift will still look for the malware even if there’s no Launch Agent, but more on this in the final sections below.

If configured, the malware installs the Launch Agent and, by default, points it to run a binary located at ~/Library/Containers/.EvilOSX. There’s no option for changing this in the set up routine itself, but the path to the program argument is easily modified if the attacker is willing to do some basic editing of the source code.

Making matters even more difficult is that with a little know-how, the attacker could easily adapt EvilOSX to not use a Launch Agent at all and to use one of a variety of other persistence methods available on OSX like cron jobs, at jobs and one or two others that are not widely known. I’ll forego giving a complete rundown of them all here, but for those interested in learning more about it, try Jason Bradley’s OS X Incident Response: Scripting and Analysis for a good intro.

String pattern detection
Faced with unknown file names in unknown locations, how does an on-demand security tool like DetectX Swift go about ensuring this kind of threat doesn’t get past its detector search? Let’s start to answer that by looking at the attack code that runs on the victim’s machine.

We can see what the attack code is going to look like before it’s built from examining this part of the source code:

As the image above shows, the structure and contents of the file are determined by the output_file.write commands. Before exploring those, lets just take a look at what the finished file looks like. Here’s the start of the file:

and here’s the final lines:

Notice how the first four lines of the executable match up with the first four output_file.write commands. There’s a little leeway here for an attacker to make some customisations. The first line is required because, as noted by the developer, changing that will effectively nullify the ability of the Launch Agent to run the attack code. Line 4, or some version of it, is also pretty indispensable, as the malware is going to need functions from Python’s os module in order to run a lot of its own commands. Line 3, however, is more easily customised. Note in particular that the output_file.write instruction defines how long the random key shall be: between 10 and 69 (inclusive) characters long. One doesn’t have to be much of an expert to see how easy it would be to change those values.

Line 5 in the executable is where things get really interesting, both for attacker and defender. As it is, that line contains the entire attack code, encrypted into gibberish by first encoding the raw python code in base64 and then encrypting it with AES256. That will be random for each build, based on the random key written at Line 3. We can see this in the next image, which shows the encrypted code from three different builds. Everything from the highlighted box onwards to the last 100 or so characters of the script are random.

However, as one of my favourite 80s pop songs goes, some things change, some stay the same. The first thing that we can note, as defenders, is that when this code is running on a victim’s machine, we’re going to see it in the output of ps. If you want to try it on your own machine, run this from the command line (aka in the

ps -axo ppid,pid,command | grep python | grep -v python

That will return anything running on your Mac with python in the command or command arguments.

Of course, the victim (and yourself!) may well have legitimate Python programs running. To limit our hits, we can run the file command on each result from ps and see what it returns. Our attack code, being a single, heavily encrypted and extremely long line in the region of 30,000 characters, will return this indicator:

file: Python script text executable, ASCII text, with very long lines

That still isn’t going to be unique, but the test will futher narrow down our list of candidates. We can then use string pattern detection on the remaining suspects to see which contain the following plain text items,

  • import os
  • exec("".join(os.popen("echo
  • -md sha256 | base64 --decode")
  • readlines()))
  • We could arguably even include this:

  • U2FsdGVkX1
  • which occurs immediately after echo, but for reasons I’m about to explain, that might not be a good idea. Still, from the default source code provided by the developer, if we find all of those indicators in the same file, we can be reasonably certain of a match (in truth, there’s a couple of other indicators that I haven’t mentioned here in order to keep DetectX Swift one-step ahead of the attackers).

    Unfortunately for defenders, the attacker has a few workarounds available to them for defeating string pattern detection. To begin with, the attacker could adapt the code to use something other than base64, or indeed nothing at all. Similary, AES256 isn’t the only option for encryption. For these reasons,we can’t assume that we’ll find something like U2FsdGVkX1 in the malicious file. Then, there’s the original source code’s use of the long-deprecated os.popen. That is an odd choice to start with, and someone with a bit of experience in Python would be able to rewrite that line to avoid the telling indicators.

    Skill level and customisation options

    Advanced detection options
    At this point you may be feeling that the attacker holds all the cards, and to a certain extent that is true, but there are some positive takeaways. First, we can be fairly sure of catching the neophyte hackers (aka “script kiddies”) with little to no programming experience who are trying to hack their friends, school or random strangers on the internet. The motivation to adapt the code is probably not going to be there for a large number of people just doing it 4 the lulz.

    Secondly, depending on your tolerance for investigating false positives, and as I’ll explain how below, if you needed to be super vigilant, you could simply check on every python executable running on your Mac which file identifies as having ‘very long lines’. For sure, there are legitimate programs doing that, but the number still isn’t going to be that high on any given machine, and the paths to those legit programs are going to be readily identifiable. If security is of overriding importance, then it’s not much inconvenience, and time well spent.

    By default, DetectX Swift will find instances of EvilOSX running on a mac when it’s used out of the box, and when its used with a modified launch agent and executable path. It will also still find it when the attacker has made certain alterations to the source code. However, a determined attacker who chooses to rewrite the source code specifically to avoid string pattern detection is always going to be one-step ahead of our heuristics.

    We are not out of options though. You can still use DetectX Swift combined with the as a means to making custom detections as mentioned above. Here’s how:

    1. Launch DetectX Swift and allow it to search for the variations of EvilOSX it knows about. If nothing is returned, go into the Profile view.
    2. Click inside the dynamic profiler view, and press Command-F and type python into the search field.
    3. If there are no hits in the Running Processes section, you don’t have EvilOSX running on your machine.
    4. If there are any hits within the Running Processes section, make a note of each one’s command file path by selecting it in the view and pressing Command-C to copy it.
    5. Switch to the Terminal app, type file (with a space) and Command-V to paste. If the path has any spaces in it, surround it in single quotes. Then press return.
    6. If the path doesn’t come back with ‘very long lines’, the file isn’t EvilOSX.
    7. If it does, hit the up arrow on the keyboard to put the previous command back at the prompt, use Control-A to move the cursor to the beginning of the line, and replace the word file with cat (if you’re familiar with Vi or similar command line text editors use one of those instead). Hit return.
    8. Inspect the output from cat with the following in mind:

    9. Does the file end with readlines()))?
    10. Use command and the up arrow to go back up to the beginning of the file. How close does the file look to matching what you’ve seen here? Look for variations like import * from os and import subprocess.
    11. Consider the path that you pasted in. Is it something that looks like it belongs to a genuine program, or is it a completely unfamiliar? Anything that points to ~/Library and isn’t contained within a recognized application named folder should warrant further investigation.

    You’ll need to consider carefully the answers to 8, 9, & 10, with an emphasis on the latter, for each python file you tested to make an assessment. If you’re in any doubt, contact us here at Sqwarq and we’ll be glad to take a look at it and confirm one way or the other.

    EvilOSX is just one of an increasing number of Python RAT projects that are appearing on the internet. It’s not particularly sophisticated, and this is both a strength and a weakness. With modest programming skills, an attacker can modify the source code to increase the chances of evading automated detections. However, vigilant users can still identify EvilOSX if they know what to look for, as explained in the preceding sections of this post, or by contacting Sqwarq support for free advice.

    Stay safe, folks! 🙂

    What’s the difference between DetectX and DetectX Swift?

    Since releasing DetectX Swift back in January, a lot of people have been asking me how the new ‘Swift’ version differs from the older one, aside from requiring 10.11 or higher (the original will run on 10.7 or higher).

    Well sure, it’s written in Swift — and it’s much swifter, literally, but of course there’s a lot more to it than that.

    I’ve finally had a spare moment to enumerate the feature list and create a comparison chart. Although the image above is essentially the same as the one you’ll see at the link address at the moment, there’s still a bunch of features to be added as we go through development of version 1. Thus, be sure to check the latest version of the chart to get the most up-to-date info.

    Of course, if you have any questions drop me a comment below, or email me either at Sqwarq or here at Applehelpwriter.

    Enjoy 🙂

    scan for malware on the command line

    Screen Shot 2017-12-20 at 19.23.50

    DetectX Swift now has the ability to do command line searches for issues on your mac like malware, keyloggers, browser hijacks and potentially dangerous software, and there’s a number of extra options that are not available when using the user interface. In this post, I’m going to give you a quick tour of the CLI (Command Line Interface) tool with some examples of how to use it (if you haven’t yet grabbed a free copy of DetectX Swift you might want to do that first to play along).

    1. Basic scan
    Let’s start with a basic scan. To use the CLI search, you need to specify the full path to the app executable. In this example, let’s suppose that the app is in /Applications folder. In that case, you’d need to execute this on the command line:

    /Applications/DetectX\\ Swift search

    Since that’s a bit of a handful, even using tab completion, you might want to edit your .bash_profile to include a shortcut alias. Here’s mine:

    sphil@sphils-iMac-5:~$ cat .bash_profile

    alias sudo='sudo '

    alias detectx='/Applications/DetectX\\ Swift'

    Note the sudo line (and note the extra space in the value). We’re going to need that so that we can pass the alias to sudo when we want to pass certain options to the search. Like…

    2. Scan other users
    Probably the most important benefit you gain with scanning on the command line rather than from the app’s interface is the ability to scan all, or selected, other users. You can search all users by using sudo and the -a option:

    sudo detectx search -a

    If you want to restrict the search to one or more users, the -u option allows you to specify a list of shortuser names (comma-delimited):

    sudo detectx search -u alice,bob

    3. Go deep
    If you’d like more verbose output, including how long the search took, try either the vsearch or vvvv commands:

    sudo detectx vvvv -a

    4. Save the results
    You can specify a path to output the results, either in regular text:

    sudo detectx vvvv -a ~/Desktop/searchtest.txt

    or, by passing the extra -j option, in JSON format:

    sudo detectx search -aj ~/Desktop/searchtest.json

    Here’s an example of what the formatted JSON file looks like:

    Screen Shot 2017-12-20 at 18.05.26

    5. Anything else?
    There’s a help command that will output the documentation to the command line, and also if you get into the habit of regularly running command line checks, don’t forget to launch the app from time to time in the Finder. Like its predecessor, DetectX, DetectX Swift does a lot of other stuff besides searching that can help track down and remediate problems with your mac, and a large part of that revolves around the way it tracks changes to your system every time you launch it. The CLI tool runs independently of that and won’t give you that kind of feedback or record those changes.

    Finally, note that in the release version of DetectX Swift, the CLI tool is only available for a limited period to Home and Unregistered users. Unlimited acccess to the CLI tool requires a Pro or Management license.

    Enjoy! 🙂

    DetectX Swift History

    DetectX Swift beta has arrived

    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! 🙂

    how to reveal hidden users

    With malware big in the news again, and evidence that at least one malware variant that targets macOS creates hidden users on the victim’s system, here’s a timely tip on how to check for unwelcome guests.

    For this tip, we’re going to use the Terminal, which you can find in the /Applications/Utilities folder. If you’re not a frequent visitor to the land of the command line, you might want to see my 3-part series “Learning the Terminal”.

    Regardless, the first thing we’re going to do in Terminal is about the simplest command you’ll ever type: w. Yep, type a single ‘w’ at the prompt and press return.

    The w utility is a very quick way to see who’s currently logged on to your system and to ensure that there’s no surprises. You should see a couple of entries for yourself: one as ‘console’ and one as ‘s***’. The first represents a login through the usual Desktop GUI login window; the second is there because you just logged into Terminal. Anybody else logged in either via the command line (like a potential remote user) or the GUI will show up here. Notice that on my machine, there’s another user called ‘Developer’ who hasn’t logged in using the GUI, but is logged in via a command line interface. Note that ‘w’ returns the full user name, not the short one.

    While the w utility will tell you if a hidden user is currently logged on, what if there’s a hidden user that isn’t active at the particular time you check? To look for those, we have a couple of options. First, we can use the dscl utility to list all users, and you might be surprised at how many there are:

    dscl . -list /Users

    Look to the end of that list where the names that don’t begin with an underscore start. ‘Daemon’, ‘Nobody’, ‘Root’ and ‘Guest’ are all standard system accounts, as are all those entries that begin with an underscore. Don’t worry about those. However, aside from those, you should only see names that you recognise. To make things a little easier, we can add another command to the dscl command to filter that list. Try this

    dscl . -list /Users | grep -vE ‘_|root|nobody|daemon|Guest’

    That should now only return the names of real users. There shouldn’t be any names in there you don’t recognise. In my example, I know the last three, but the first one ‘dev’ isn’t familiar to me. Note that unlike ‘w’, this command returns short user names, and that ‘dev’ looks very much like it’s the same account as ‘Developer’ that I saw earlier.

    However, what we have so far is a list of users, not a list of hidden users. To see specifically if any accounts are hidden, we need a longer command:

    defaults read /Library/Preferences/

    Normally, when there are no hidden users, this will return the contents of a property list file that may look something like this:

    GuestEnabled = 1;
    OptimizerLastRunForBuild = 31898816;
    OptimizerLastRunForSystem = 168494592;
    lastUser = loggedIn;
    lastUserName = imackim;

    That tells us that there’s no hidden users on this mac. How so? Because if there were it would return something very different, like this:

    We can see not only the list of hidden users, but also that the preference for hiding users has been set to ‘1’ (in plist syntax, ‘1’ means true and ‘0’ means false). Note again that unlike the dscl command above, this returns the account’s full name, not the short user name.

    If we’d like to ‘unhide’ that user, so the account appears in the login window GUI and in System Preferences’ ‘Users & Groups’ pane, we’ll need admin privileges. To do that, cut and paste the following into Terminal:

    sudo defaults write /Library/Preferences/ Hide500Users -bool NO

    Supply an admin user password at the prompt and hit ‘return’, but type slowly as the display doesn’t register your key presses, which makes it easy to fat finger your password.

    Next, we need to change the IsHidden key in dscl for that user, so

    sudo dscl . -change /Users/dev IsHidden 1 0

    In the above command, substitute my user’s shortname dev for the shortname of the user on your machine. The 1 0 is the old value (hidden) followed by the new value (unhidden). The line can be read as “change User dev’s IsHidden value from hidden to unhidden.”

    For the more advanced
    We can save ourselves some typing by putting much of this into a script so that we can run it whenever we want. If you’re not familiar with how to create and use bash scripts, take a look here.

    Our script will basically do the same as all the commands we listed above (except changing the prefs for Hide500Users) in one fell swoop, and there’s a couple of little twists that I’ll leave as an exercise for the reader to figure out. To save on the typing, you can copy the whole script from my pastebin here.

    The script’s output is illustrated in the shot at the top of this post.

    Enjoy! 🙂

    %d bloggers like this: