Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The EICAR test file was used to functionally test an antivirus system. As it stands today almost every AV system will flag EICAR as being a "test" virus. For more information on this historic test virus please click here.

Currently the EICAR test file is only good for testing the presence of an AV solution, but it doesn't check for engine file or DAT file up-to-dateness. In other words, why do a functional test of a system that could have DAT files that are more than 10 years old. With the quantity of viruses released daily, over time, the EICAR signature loses value as a testing tool.

That being said, I think EICAR needs to be updated/modified to be effective test that works in conjunction with an AV management solution.

Some people on serverfault responded to an earlier revision of this question.

To answerers: Please focus on the point:

This revised question is about testing the functionality of an AV system.

Please don't respond with management solutions since they don't test what's deployed and in the field. Management solutions report and that may be flawed in one way or another for example: sometimes a machine may not be included in routine AV administration by operator error. Sometimes AV is managed by a different company or group. No matter what your stance is on 'management', this does not count at a post-deployment "test" IMHO. This question is about real world testing, without using live viruses... which is the intent of the original EICAR.

I'm proposing a new EICAR file format with the appendage of an XML blob that will conditionally cause the Antivirus engine to respond.

<?xml version="1.0"?>

In this sample, the antivirus engine would only alert on the EICAR file if both the signature or engine file is equal to or newer than the valid-from date. Also there is a passcode that will protect the usage of EICAR to the system administrator.

If you have a backgound in "Test Driven Design" TDD for software you may get that all I'm doing is applying the principals of TDD to my infrastructure.

Based on your experience and contacts how can I make this idea happen?

share|improve this question

closed as not a real question by RobM, GregD, ThatGraemeGuy, Zypher, Izzy Sep 9 '10 at 21:31

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

I think you misunderstand why the eicar signature exists. – Sirex Sep 9 '10 at 14:15
@Sirex - Please explain. The alternative is to test using a near-zero day virus. That is exactly why EICAR was created. – LamonteCristo Sep 9 '10 at 14:20
As several answers here explain (better), eicar was created with the view to test if virus catching was present in an enviroment using a safe definition with no payload. It has nothing to do with the up-to-dateness of any virus solution, which is completely dependant upon the correct management of the solution once deployed. The solution you seek is already in existance, but if your rly on a third party which isnt keeping its definitions up to date, run your own or ditch them – Sirex Sep 9 '10 at 14:49
If your AV deployment is not giving you the visibility you need, then you need a different deployment or a different vendor. – Joe Sep 9 '10 at 16:02
@Sirex - I understand why the EICAR signature exists. It exists to safely test the presence of an AV solution. Some people erroneously think that also means they are safe. There is almost no safety in an out of date AV product. That is the reason of my proposal. – LamonteCristo Sep 9 '10 at 17:07

What you are after (in the context of a system not under your control) is unlikely to ever become viable simply because it would open yet another vulnerability against the AV software itself. i.e. It would become possible to probe a system to determine whether or not it is capable of detecting the latest virus. If the test fails the virus could be sent through undetected without arousing undue suspicion.

As for the EICAR test, it's high time that was abandoned. Most AV software I've seen is either hard coded to detect it or has a signature for it, making the "test" absolutely worthless.

share|improve this answer
I agree that EICAR is currently mostly worthless, unless you want to prove the lack of AV scanning. If my proposed idea was implemented there would have to be a means to protect against "snooping". – LamonteCristo Sep 8 '10 at 22:10
+1, Additionally if you use any sort of pattern for the newly updated files, AV makes will catch on and simply "detect" anything that matches the pattern; making the newer test files detectably by old software. – Chris S Sep 9 '10 at 17:07
-1 There is no case of probing since a password is in the EICAR file. Also old AV won't catch on to this nonsense string that does nothing. To those engines, this should be a string no different than your email signature... just an ASCII blob – LamonteCristo Sep 9 '10 at 17:17
John, there's nothing "worthless" about the EICAR test, if you understand what it is supposed to do. It isn't supposed to be an up-to-date test of how good AV software is, but simply whether or not it is deployed and configured correctly. This is explained clearly enough on the website. – RobM Sep 9 '10 at 18:47

I doubt the industry is going to make a new EICAR file monthly for you. Its a waste of time and resources. The solution to your problem is buying a centralized AV like Symantec or Sophos so you can run a report and see which clients need updating.

share|improve this answer
My external vendor will not allow me to see these reports. – LamonteCristo Sep 8 '10 at 20:20
Have you thought about changing external vendors? – Mitch Miller Sep 8 '10 at 23:04
@Mitch Miller - We already did.. to Proofpoint. We still want functional tests though as I proposed... – LamonteCristo Sep 8 '10 at 23:13

The EICAR file itself doesn't test for the presence of anti-virus. It is simple used as a tool for testing purposes (so you're not you know testing against live viruses).

There are plenty of ways to monitor and manage engine and definition updates (I'm assuming you are using McAfee since you are using the DAT terminology)

Every enterprise anti-virus has a central management console available. For McAffee check out ePolicy Orchestrator (or whatever the current SMB software is called).

share|improve this answer
I updated my need. I need to audit an external system I don't manage. – LamonteCristo Sep 8 '10 at 20:20

The EICAR file only tests for the presence of AV, it isn't used for currentness. I believe the EICAR file itself is over a decade old at this point and is therefore 'supported' by everything.

Solving the currentness problem is one that all enterprise grade AV products have solutions for. McAfee has the ePolicy Orchestrator. Symantec has System Center. Microsoft ForeFront also has a reporting console. They all rely on the AV engines themselves to report back to homebase about what they're currently running in regards to both definitions and engines. The more sophisticated Desktop Inventory products out there can also provide this kind of service.

share|improve this answer
I understand that EICAR only tests for the existance of AV, not it's currentness and therefore it not a good choice for my test. My real issue is that I rely on an external system that I don't manage, and viruses come through because of out of date DAT files – LamonteCristo Sep 8 '10 at 20:21

The answers above are pointing you towards a centralized management console. That's usually the best answer. I take your point about passive monitoring, but I think you're slightly off-base. The central solutions I've worked with don't assume that the client got the update; they update the information in the console with what the client says its definition date/version is. That's exactly as accurate as you asking the client machine yourself in some other way. In fact, the worst that can happen is a breakdown in the console, still sending updated DATs but losing return communication from a client, and showing an older definition date in the console than the client actually has.

However, if you can't do that (machines aren't going to stay under your control after deployment, etc) then you can try to find out where the AV software you use keeps that information.

When I had to do this for SAV CE, you could query the registry of the client machine to find the current AV definition version, and I think the date as well. For McAfee DAT files, you might be able to find out where the directory the DATs are kept, and have a script that looks for the created or last-modified date of the newest DAT file in that directory.

share|improve this answer
Thank you but this does not help me in a hosted / cloud solution... where functional testing is my only choice. – LamonteCristo Sep 8 '10 at 22:42
Then put the onus on the people managing your systems, for crap's sake. Your not managing them, you're paying someone else to do it. Say that you want a daily report from the managed hosting company of the AV definitions on the servers you rent. – mfinni Sep 9 '10 at 1:08
From a management perspective you have a point, however, I edited this question and content. EICAR needs updating in order to be relevant. If you agree please upvote. – LamonteCristo Sep 9 '10 at 11:41

Consider submitting this idea to

share|improve this answer
Already did.. just hoping to get more support from people in-the-know @serverfault. Let's see how it goes. – LamonteCristo Sep 9 '10 at 14:09

If I understand what you're asking for is a third party tool to test whether or not a third party tool is doing what they say they're doing? If so, why would you propose relying on a third party tool when you haven't been able to rely on third parties thus far? o_O

I'm not sure we can help you "make it happen". I can't "make" eicar do anything anymore than I can "make" you do something for me. I've found that when I can't get something accomplished through a reliable third party, I do it myself or not at all.

If you wish to test email security, you could try GFIs email security test, although I believe it's a bit out-dated.

Edited to add:

You keep arguing that "EICAR needs updating in order to be relevant." No, it doesn't. Their AV test file only has one purpose and that is "produce a file that their (and many other) products "detect" as if it were a virus. " That's it. In that respect, they remain relevant.

If you have a third-party vendor that isn't performing to your expectations, then you fall back on an SLA. Your SLA should state what they're doing to maintain current AV and how they're going to prove that to you to your satisfaction. Nothing you have another party "do" (in this case you're asking for EICAR to make another test file to test whether your AV is up-to-date) is going to make up for the fact that you don't have this spelled out in an SLA.

share|improve this answer
I'm well aware of GFI's email test. They use EICAR as well and I'm addressing that test's issues here. To address your other point... aren't we all 3rd parties when you think of it? It takes one person to "do" something to make change happen. Often it requires working with other people. That's what I'm trying to do, first on Serverfault, and in other venues. I'd appreciate your support if you want to effect change. – LamonteCristo Sep 9 '10 at 14:06
We both agree that the EICAR test today is pretty much inconclusive. I also feel pretty unpopular now, but I stand by my idea. It seem rational, logical, and an effective test. I do not understand why no-one is focusing on the testing aspect, which is what I want to do. Just test. All the other points are valid, but I only care about testing in this specific case and no-one is paying attention to that. – LamonteCristo Sep 9 '10 at 17:38
..what is the point of detecting a virus if the engine is too old. You might as well not have any AV at all. EICAR is irrelevant today, since a positive test result means you have AV software.. but it could be from 1996. Which is a useless test result. – LamonteCristo Sep 9 '10 at 17:42
I'm sorry MakerOfThings, but you keep insisting that EICAR is "irrelevant" and needs to be updated because it doesn't solve your problem. This is, with all due respect, either rude or ignorant. It doesn't do a good job of testing what you want to test because it isn't supposed to test that. A chainsaw doesn't make a very good toothpick either and for much the same reason. – RobM Sep 9 '10 at 18:45
I believe it's true to say (1) EICAR tests for the presence of AV software, (2) perhaps to the advantage of malicious hackers, (3) where the AV software could be functionally ineffective or out-of-date... therefore making the test useless. The combination of points 1,2, and 3 is not self-focused. I've already fixed my issue and migrated to another vendor. However EICAR is at most ineffective, at at worst a tool for hackers since the help text for quarantined messages can be used for social engineering and SMTP header tracing. – LamonteCristo Sep 9 '10 at 19:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.