Shlayer malware is on one out of ten Mac computers. And it has been like that for two years. It is malware that mainly attacks the advertising system. Given this overwhelming statement (10% of infected operating systems and a campaign that has been going on for two years now) we considered one question: what is the operating system doing to defend itself? We are aware that XProtect, the built-in anti-malware software, detects poorly and badly. But how has it responded to an epidemic of such dimensions?
We won’t well on its functioning because already provides all the details. It is interesting to know that it usually pretends to be a Flash update that downloads an encrypted file. This, once decrypted, downloads the real Trojan with curl.
Code from the image will deobfuscate a file that will end up doing something like this:
This in turn will lead to the installation of the most aggressive adware. This simple behavior has given users more than a headache for two years now. By the way, that curl -F0L is their “trademark”, because they are not usual curl parameters.
What is XProtect
XProtect is a basic signature-based malware detection system that was introduced in September 2009. It constitutes a first approach to an antivirus integrated into MacOS. Currently, XProtect has some more signatures that may be clearly found (malware name and detection pattern) in this path:
XProtect contains signatures on the one hand, and Yara rules on the other hand (it is defined by XProtect.plist and Xprotect.yara on that directory), and with both systems malware is detected and defined. GateKeeper is supported by both; it monitors and sends it to them. The list XProtect.plist is public. Number 3 from the URL refers to Mountain Lion. When 2 is modified, Lion signature file may be viewed, and 1 corresponds to Snow Leopard. Apple does not seem keen to talk too much about it. Let’s go forward with the initial question.
Has Apple taken the matter into their own hands?
Yes, but only recently, when they introduced several Yara rules to detect these signatures (which in principle are a mystery and no details are offered about the rules). For example, on January 22nd the following 4 rules were introduced: MACOS.8283b86, MACOS.b264ff6, MACOS.f3edc61 and MACOS.60a3d68.
A few days before, on January 7th, 3 additional signatures or Yara rules were introduced: MACOS_5af1486, MACOS_03b5cbe and MACOS_ce3281e.
And in December, 7 more were introduced: MACOS_9bdf6ec, MACOS_e79dc35, MACOS_d92d83c, MACOS.0e62876, MACOS.de444f2, MACOS.b70290c and MACOS.22d71e9.
This results in a total of 14 signatures in two months. Considering that in 10 years they accumulate a little more than 100 signatures, it may be concluded that they have worked hard in the last months. It is not usual to have so many signatures in such a short space of time, so yes, it seems that they are lately worried about malware on Mac. Now we ask ourselves another question:
Are these rules effective?
With these Yara rules of XProtect we have performed a retrohunting in VirusTotal to see since when malware of this type exists. This is an investigation that involves searching back in time for files that meet certain Yara rules. VirusTotal will give back as many samples that meet these rules and will give us an idea of how many have appeared over time.
Over 1,000 samples were found in less than three months. The interesting point is that there are samples since well before December 2019 (when they began to introduce detection rules in XProtect). This suggests that in some way these protection rules added by Mac during these months are late.
Exploring the results of the retrohunt, we located samples that were not hunted by antiviruses. In principle, we thought that these were false positives, but a subsequent analysis showed that they are rules for detecting browser plugins and specific adware, such as: Wharkike, EngineFiles, ContentBenefits, ForwardOpen-extension… This leads us to an interesting conclusion: XProtect detects adware (search engines mainly) not detected by any antivirus. However, it seems that some false positives have crept into (we believe that the mdworker_share module is sometimes detected as a false positive).
Again as a curiosity, a thousand samples in about 70 days gives us an average of almost 15 samples uploaded to VirusTotal per day. Most samples are detected because they are the decryption script showed in the image above. This is an early stage of the attack, which may be positive.
Indeed, it seems that XProtect (in a totally opaque way) has moved up a gear and in a few days has created more detection rules than ever. These rules are hunting a lot of malware at their earliest stage, and even do a better job than antiviruses.
Nevertheless, we have a big “but”. The rules are late and, in addition, open to the attacker. They will be tempted to go unnoticed just by looking at what XProtect detects and modifying when necessary. This doesn’t mean they are bad, but easily bypassable.
For example, if we analyze some of the strings on which they rely to detect malware, we see how it does it:
Whose strings may be translated into this:
They in turn are commands usually used by malware, and by simply modifying one byte the rules could be bypassed.