Eicar was meant to test legacy AV software. Modern security tools now work differently, but when compliance comes calling, can a tool afford to fail an eicar test?

In this post, I want to explain how a recent change to DetectX Swift (DTXS) came about. The story started with a request from a Mac admin who wanted to know if DTXS could be updated to recognize eicar files in order to meet an external accreditation test. Because of the way DTXS works, I knew that would present quite a challenge, and one I wasn’t even sure I could meet while remaining true to DTXS’s core philosophy of being a fast, lightweight, on-demand security and troubleshooting tool.

Eicar actually presents a more difficult challenge to DTXS precisely because eicar is harmless and because DTXS doesn’t work like the AV scanners that eicar was designed to test. Below, I explain those challenges, and in so doing cover some of the inner workings of DTXS: how it detects threats and issues, why it is so fast, what its capabilities are, and how it’s different from traditional AV scanners (aka “legacy Anti Virus”).

Snakeoil or Essential Tool?
Back in the day when AV software only had to look for actual viruses (as in a self-replicating computer programs) and later trojans and worms - we’re talking early 2000s - it occurred to a number of people paying big money for AV software that they couldn’t actually tell whether their software was protecting them if there were no threats currently in their environment.

It’s a bit like buying expensive medicine to prevent a disease that you haven’t been exposed to. How do you know the pill will actually work in the event you come into contact with a pathogen? How do you know you’re not just being sold snakeoil? Replace the appropriate terms in this Victorian advertisement with those used in a lot of contemporary AV marketing material, and the patter sounds hauntingly familiar:

HALL’S VEGETABLE SICILIAN HAIR RENEWER
If your hair is grey or faded, or weak or thin, give the RENEWER a trial,
and you will be astonished! Your grey locks will soon become the same color
as in youth, the weak hair will be strengthened, and new healthy hair
will start and grow. It stops the falling of the hair, and thus prevents baldness.
It eradicates dandruff, cures eruptions and itching, and leaves the hair soft and silken, and much to be admired.

What is Eicar?
Eicar was essentially an attempt to answer the question of efficacy insofar as it’s designed to test that an AV scanner is actually scanning and checking files against its database of signatures. The equivalent for Hall’s Hair Renewer would be some test that showed that it at least contained one recognised, active ingredient of hair renewal. That wouldn’t prove that the product lived up to all or even any of its claims. It would, though, at least prove that the product was doing something, and that’s exactly what the eicar test is supposed to establish for AV scanners.

Eicar is itself a harmless file. It’s literally just a text file that you can - but don’t have to - turn into an executable. If you do turn it into an executable and run it, it will do nothing more harmful than print out the string “EICAR-STANDARD-ANTIVIRUS-TEST-FILE!”

The eicar file should be detected by any AV scanner because AV scanners include a signature (more on this below) specifically for the eicar file. So if you want to verify that your AV protection is up and running and alert to threats, you download the eicar file. Good old-fashioned AV scanners should detect it on write to disk, but if not, they should definitely detect it if you execute the file. Why? Because all AV vendors have included the eicar signature, so if they don’t detect it, they’re clearly not working. It’s also detected by macOS’s XProtect feature, so long as you don’t bypass it.

A successful test, of course, says nothing about the reliability or accuracy of a scanner’s other signatures, but that’s another issue that eicar was not designed or intended to solve.

How Do AV Scanners Work?
Legacy Anti Virus scanners work by searching every file - or at least every binary - on the system and scanning for tell-tale signs of malware. There’s two ways they usually do that: they can either produce a SHA or MD5 hash of the binary and see if that hash matches a list of known malware hashes, or they can scan the binary for specific strings and again see if those match any collections in the AV scanner’s database.

That all takes time - it’s why AV scanners have such a poor reputation for hogging system resources - and it’s also not very practical with modern malware. Commodity adware and malware nowadays often employ techniques to produce a slightly different binary from one download to the next, a technique security researchers call polymorphism. Sometimes these are tailored to the target system by the intial infection, which fingerprints the victim’s machine before requesting a custom payload. This can result in a unique hash that is unknown to the AV scanner’s database and/or strings that are obfuscated and unreadable to scanners.

Given the modern threatscape, binary scanning an entire system is not particularly effective, and not particularly efficient. That’s why DTXS does very little binary scanning (there are certain circumstances when DTXS does a binary scan on a specific file that has been flagged by its other heuristics). And yet, DTXS produces comparably good if not better results than traditional scanners, and in just a few seconds. How so?

How DetectX Works
The eicar test is a great idea for AV scanners, but it doesn’t work for something like DetectX. DTXS is an on-demand search tool - it’s not constantly monitoring your file system - and as you’ll know if you’ve spent even the briefest of time with DetectX Swift, the search function is incredibly quick. Probably faster than any other similar tool on the market, and streets ahead of legacy Anti Virus scanners. DetectX Swift’s speed isn’t really anything to do with the language it’s programmed in (a common misconception), which is just a happy namesake coincidence, but rather down to the way that it searches for threats and issues.

Part of the secret is that DTXS leverages Apple APIs to identify items that get downloaded and to match those identifiers against a constantly updated database of “badware”. The Finder doesn’t churn through your whole hard disk every time you search for something like an AV scanner does, and neither does DTXS.

In fact, for user searching, the Finder uses the same technology that underpins Spotlight. DetectX (DTX), the older version of DetectX Swift, used to rely heavily on that also, but that can still be slow during times when the OS is busy or re-indexing the file system. In the worst case scenario, some users actively turn off Spotlight indexing, and that really hammered the older DTX’s ability to search. To avoid these problems, DTXS consults (amongst other things) macOS’s own internal database of registered applications (known as ‘LaunchServices’) and checks them against its own database of badware. DTXS updates this database every time you search if you have an internet connection; if not, it relies on the definitions from the last time that you did, and failing that on those that are bundled within the application itself.

This is incomparably faster, as the difference in search times between the older DetectX (DTX) and the newer DetectX Swift amply demonstrates, and it works great for things that are distributed as applications, packages and extensions (“bundles” in Apple-speak). That includes the majority of commodity adware installers and quite a bit of known malware - a lot more than is known to either XProtect or Gatekeeper, too.

Not Everything is a Bundle!
However, for exploit kits utilizing Python (hello Bella, EvilOSX, Empyre and friends!), perl (FruitFly, you cheeky script you!) and Bash (come on, bashark!) among other things, DTXS needs a different approach. In these cases, DTXS uses heuristics to identify the intruder by its behaviour. There’s a number of behaviours that DTXS can hit on, including location of dropped files, commands passed during execution, and child processes spawned. There’s also one or two others that are probably best kept under the hood (sorry bad guys!), but you get the general idea: DTXS’ second-layer of heuristics rely on observing something that is currently happening or that has happened in a persistent way.

Eicar, however, presents a different - and difficult - challenge for DTXS. That’s because eicar has neither bundle nor developer identifiers, so it isn’t registered with LaunchServices. It also doesn’t leave behind any persistent behaviour or process that we can detect when DTXS launches and searches, since eicar runs for a mere fraction of a second - just long enough to print out its message - and exits, the chances of it being active when DTXS is looking for it are next to zero.

DetectX Sits in Userland, For a Reason!
There may be some trace of eicar at a deeper level in records like fsevents, but by design DTXS runs on a policy of least privileges. The whole premise of DTXS is that threats come into the system via “userland” or user space, not the kernel, so that’s where DTXS sits: looking for interactions with the user either on infection or execution.

Running on least privileges means DTXS can’t inspect “deep” file databases that require root privileges to scrutinise. That also means that, unlike most security solutions on the market today, DTXS also doesn’t run as a rootkit that can potentially be hijacked by malicious processes to compromise your system, or which can equally be used as spyware. DTXS runs with no more privileges than the user needs to launch any program. 

Supporting Eicar Detection
Since eicar was meant to test scanners, and DTXS isn’t a scanner, you may wonder why I would want to support the eicar test. To be frank, I didn’t. It was my view for at least the last 4 years or so, since I wrote the original DetectX app, that it was unnecessary as DetectX isn’t a scanner, so why worry about tests designed for scanners?

While both DTX and DTXS were conceived of as tools for home users, DTXS has evolved into a tool that is now capable of supporting enterprise and organisational integrations with endpoint management software like Jamf and Munki. And of course what that means is that some of those organisations that want to take advantage of DTXS abilities (not to mention its market-beating low price!) face the challenge of accreditation. So it was that when an institutional user indicated that without eicar detection, DetectX Swift simply couldn’t be used on their Macs, I knew that this was not going to be an isolated case. Something had to be done.

In order to put in some support for eicar detection, I had to consider the pros and cons of adding another heuristic for a file that is known to be harmless. Detecting eicar is kind of easy if you don’t care about search times or system resources (you could just run find on the root folder!), but of course DTXS cares very much about speed and resource use. A good security tool should not affect productivity because if it does, users will either not use it or find ways to circumvent it. That’s why DetectX Swift is made to be both fast and light.

So what I wanted to do with the eicar detection was ensure that DTXS would detect a file that was intended to be detected - that is, after all, the original purpose of eicar’s ‘catch me if you’re awake’ purpose - while at the same time be certain not to catch any false positives. And I needed to do that without increasing search times, since it’s unfair to users to expend unnecessary resources for something that is only pretending to be a threat, rather than something which could be or actually is a threat.

A First Try…
Since eicar is typically downloaded through a browser, that gave me an idea. On macOS, all the major browsers will attach a “quarantine bit” to any file they download, so that that file can be passed to Gatekeeper and XProtect for examination. A record of these quarantined downloads is available without elevating privileges, so DTXS can check whether there’s any record of eicar being downloaded.

That doesn’t quite solve the problem, however, for a few reasons. First, that record doesn’t tell us the location of the file on disk, so we might be able to determine that the file was downloaded, but not if it’s still present and worse, not where it is. Second, the record of quarantined downloads is cleared at different and unpredictable times - one being when the user hits the Clear button in Safari’s Downloads toolbar. That means that we could easily miss a download between runs of DTXS.

NSMetadataQuery Lends a Hand
While checking for existence of eicar from the quarantine database could provide a useful hint, I needed something more reliable. As already mentioned, DTXS doesn’t rely on Spotlight to the degree that the older DTX did, but it is still employed in certain limited cases. Though rarely used, the code for doing a metadata query had been brought over to DTXS from DTX. Could Spotlight do the work we needed? Keeping the number of metadata queries down to the bare minimum is essential to reduce the impact on search times, but DTXS has so few uses of this method that adding the eicar search to it should have negligible impact. And luckily, tests using Apple’s NSMetadataQuery API to spot files with ‘eicar’ in the name indicated no adverse effect on search times as expected. All I needed to do then was parse any results for the eicar string in the file to rule out false positives.

After sufficient testing, I was delighted to release DetectX v1.085, which now recognises a file if it contains both the string “eicar” in its name and contains the unique eicar string in the file’s contents. If either one of those conditions are not met, then DTXS will not flag the file. Thus, it’ll detect “eicar2.txt” and “another_eicar.bin” if they contain the eicar content string. If they do not, DTXS will ignore them. Similarly, a file that does contain the eicar content string but is called, say, “hello_car” will not trigger a detection. Independently of this mechanism, a note is made in the Activity log if DTXS observes that an eicar file has been downloaded via a browser.

Keeping It Real!
It’s far from comprehensive, but in making this choice I had to balance the value of increasing DTXS search time (something I’m philosophically opposed to unless it improves user safety) for the sake of a ‘fake’ test with the needs of customers who have to pass accreditation tests that use a simple measure like eicar (apparently, still fairly prevalent) to determine compliance.

The implementation isn’t perfect - Spotlight-style queries are blind to certain locations - but it should satisfy the requirement that eicar was originally created for: is this tool’s search engine actually doing anything?

Although it’s easy to intentionally avoid DTXS’s eicar detection, as I hope this post has made clear that’s primarily because eicar isn’t malware and doesn’t have malware behaviour. The real bad guys, who have to engage with the user’s assets in far more detectable ways than merely printing out a string to the console, have much harder tests to pass if they want to go unnoticed by DetectX Swift.

Picture Credit: Cyber Hallway by paradevik