Imagine This Scenario
One of your trusted network administrators reaches out on a public Slack, Discord or other chat workgroup for advice on a performance problem he’s seeing on some part of your network. Of course, your admin is a savvy user and knows which people in the forum are reliable contributors. In this scenario, a few of those reliable users post some “yeah, seen this but don’t know the answer” type responses.
Just when it seems like your admin is out of luck, he gets a DM (direct message) from one of the group’s team admins with a solution:
We’ve been aware of this issue for a while and developed a way around it. You’ll need to download and execute this tool with privileges to solve the problem. We’d welcome your feedback on how it goes, or if there’s anything we need to do to improve the fix.
This is what support communities are for, and your admin is now equipped with a tool – and more importantly, a reason to run that tool with privileges – that he believes may solve the problem. Perfect, save for one problem: the team “admin” in the chat group was an impostor, and the “tool” is actually malware.
The scenario described above isn’t all fiction: it’s based on a true story that hit the macOS community last week. The scam convinced users to knowingly run a tool with elevated privileges because they believed it was from a trusted source and that it was the answer to a problem they had themselves sought help for:
Admins are Vulnerable, not ‘Dumb’
Putting safeguards in place like restricting who has admin privileges on your network and who can download and execute software are fine when the attackers are phishing for the low-hanging fruit: standard users who are typically not security-conscious. But when administrators themselves are successfully phished, those tools are obviously inadequate.
In last week’s attack, the fake team administrator had to convince the user to complete a number of distinct steps in order to achieve a compromise. First, the attacker needed the victim to download the executable via curl. For any malware that isn’t signed like this one, curl is a favoured choice as it is one of the means by which Apple’s Gatekeeper and quarantine protections can be sidestepped. Second, the attacker needed to convince the victim to change permissions on the downloaded file to make it executable. And third, of course, the attacker needed the victim to actually run the malware.
Taken individually, those three steps look like a pretty tall order, and when viewed analytically in this way, it’s not hard to understand why some in the security arena have dubbed this malware OSX Dummy. However, there’s nothing “dumb” about the attacker’s method; indeed, quite the reverse. Looked at in context, it’s a very clever sleight-of-hand.
As the image above shows, the malware author made it easy for the victim to comply by providing a one-liner made for a quick copy/paste action. Executing that command produces a single authorization request, at which point the malware captures the admin’s password for reuse. This means there’s very little opportunity for the victim to back out once they’ve committed.
Moreover, it’s clear the attacker understands the ‘art of the confidence trick‘. In all good con-tricks, the trick is to get the mark to override their natural caution by appearing to give them something they themselves have asked for. As in our introductory scenario, the victims mark themselves out for exploitation by asking for help. All the attacker had to do then was appear to meet their needs and to look like a trusted source; the second demand easily pulled off if the support group doesn’t display bonafide admin badges for team admins and also allows non-admins to send direct messages to all users.
We know our admin users are technically gifted and good at their job, but there’s nothing “dumb” about falling for a confidence trick. As this advice page points out:
If you’ve ever been scammed (and most of us have, in one way or another) it doesn’t mean you’re stupid—it only means you were vulnerable. That’s because scam artists play to emotions, not intelligence.
As the advice goes on to say, the most successful cons hinge on desire – only in this case it’s the desire of our admins to do a good job. Of course, it’s easy to criticize in hindsight, but the real issue is: what can we do to protect our network administrators from becoming vulnerable in the first place?
Read more about macOS security:
We Nailed it! Calisto Detected installing Backdoor on macOS
Sentinelone macOS Agent Receives Perfect Score (6/6/6) in Latest AV-Test Evaluation
OSX.CPUMEANER: New Cryptocurrency Mining Trojan Targets macOS
Autonomous Protection
Protecting administrators from themselves is the sort of use-case that SentinelOne’s Deep Visibility module is ideal for. We can’t expect our admins to do their jobs while restricting them from executing processes and functions essential to their work, but we can provide them with the support they need to recognize behaviour that is out of the ordinary.
The malware in last week’s attack had some red flags that are invisible to the user but not to SentinelOne’s behavioral AI. Note the -S flag in this command, executed shortly after the malware launches:
/usr/bin/sudo -S -p #node-sudo-passwd# chown root /tmp/script.sh
While your admins may often need to use sudo, it’s rare that they’ll be using it with the -S flag, which is a way of passing a password on the command line, and something most security-conscious users know is bad practice. While there may be some use-cases for doing that, those are going to be the sort of edge case that it’s worth being reminded of even when legitimate (perhaps an annual security audit might review those with an eye to recommending better procedures).
Using SentinelOne, you could have all uses of ‘sudo -S’ flagged and automatically notified to your security analysts by setting up a Watchlist:
Setting up Watchlists is straightforward. Choose ‘Visibility’ in the SentinelOne Management Console and click inside the search field to bring up the Suggestions pane. For this example, we’ll click first on ‘Name’ under the Process tree and add ‘sudo’ to the search field. Next, click ‘Command Line Arguments’ and add the argument ‘-S’. It’s then simply a matter of hitting the return key to run the search.
To set up notifications, click the ‘Save new set’ button, located on the right underneath the search field, and give your set a name. Slide the notifications button to ‘on’, and you’ll now be able to choose the notification frequency and the email recipients.
After clicking ‘Save’, your recipients will receive an email for any events matching your rule set that occur during the chosen time frame. The email offers the recipient a simple one-click link to the search results in the SentinelOne Management Console. After reviewing the results, your security team can then decide whether to mark the behaviour as a threat and push detection to all your endpoints immediately.
Taking the next step
Of course, a rule set for ‘sudo -S’ is just an example of one kind of Watchlist you could deploy. Having your security team or network administrators draw up a range of rule sets for other kinds of behaviour that they might want to be alerted about is a great idea. Some good examples are offered in this SentinelOne video, which should help to get your team started on the process.
Setting up Watchlists that reflect the kinds of threats your organization faces is a flexible way to deepen the protection SentinelOne provides while at the same time allowing your staff the freedom to do their jobs with confidence. It’s human to err, particularly when our trusted employees are striving to maximize performance and deliver on their goals. However, SentinelOne’s Deep Visibility can ensure human errors don’t become costly security breaches for your organization.
Notes
The “OSX.Dummy” malware referenced in this post is detected automatically starting in Agent version 2.6.1.2509.
