EICAR Is Just the Beginning — Test What Your AV Actually Misses

Your antivirus catches the EICAR test string. Congratulations — that proves signature scanning is on. Now test the other 90% of your threat detection stack.
February 14, 2026·8 min read·Threat

The Problem with Stopping at EICAR

What most tools do

Download the standard EICAR file, confirm it gets caught by the signature engine, check the box, and move on. This tells you nothing about heuristic malware patterns, ransomware behaviors, or zero-day exploits.

What ITSecTools does differently

Provides 5 distinct threat categories. It tests signature scanning (EICAR), heuristic analysis (Mimikatz patterns), behavioral detection (ransomware scripts), and format exploit defenses (OLE/ANI).

Modern threats don't look like EICAR. They look like PowerShell scripts downloading payloads. They look like VBScript files encrypting directories. They look like OLE documents triggering buffer overflows. If you're only testing with EICAR, you're testing 1% of your detection capabilities and assuming the other 99% works.

EICAR in 3 Formats — Each Tests a Different Path

ITSecTools serves the EICAR Standard Anti-Virus Test File in three formats. Each one validates a different layer of your scanning pipeline — a complete pass means your gateway and endpoint cover executable, text, and archive inspection paths.

1. EICAR .com (native executable) — Tests how your AV handles small DOS/COM executable files. This is the canonical EICAR delivery format. Endpoint AV should quarantine this on download; gateway AV with SSL inspection should block it at the network edge.

2. EICAR .txt (plain text) — Tests content-inspection paths used for email attachments, paste-bin downloads, and text exports. Many gateway proxies skip text/plain inspection by default. If your gateway misses the .txt EICAR but catches the .com, you have a MIME-type whitelist gap.

3. EICAR .zip (archive) — Tests archive scanning depth and gateway unpack capability. Many gateways are configured with a max-archive-depth setting (commonly 3 or 4). If your gateway misses this one but catches the .com, your archive inspection policy needs review.

ITSecTools Threat Protection page

What EICAR Actually Validates

EICAR is a signature-detection test. A pass tells you exactly one thing: your AV/EDR engine is online, the signature database is loaded, and content inspection is reaching the file in question. Those are non-trivial things to confirm — many real-world misconfigurations cause one of those layers to silently fail.

EICAR does not exercise heuristic detection, behavioral analysis, or sandboxing. For those layers, validate using the dedicated tests on this platform:

  • NGFW Tests — Validates IPS signature detection, Shellshock response-side patterns, Log4j JNDI, C2 beacon detection.
  • MITRE ATT&CK Simulator — Multi-stage kill-chain (T1190, T1059.001, T1003.001, T1048.003) for layered post-exploitation visibility.
  • DLP Validator — Tests data-loss-prevention coverage including nested-JSON exfiltration that most DLP engines miss.

Use EICAR as the smoke test before you dive into the deeper coverage gaps. If EICAR fails, none of the other tests are meaningful — fix that first.

Gateway vs Endpoint — Test Both

The threat tests in ITSecTools are served over HTTPS. This immediately tests two things: your gateway AV (firewall or proxy) and your endpoint AV. And it exposes a gap that many teams don't realize exists.

If your firewall has SSL decryption enabled, the gateway should catch the threat file before it reaches the endpoint. You'll see a block page or a connection reset. If SSL decryption is not enabled, the gateway sees only encrypted traffic — the threat file passes through the firewall invisibly, and only the endpoint AV has a chance to catch it.

Key insight:If your EICAR test passes at the endpoint but fails at the gateway, you almost certainly have SSL/TLS inspection disabled on the domain or category. Without SSL inspection, the gateway sees only encrypted bytes — it physically can't scan content. Enable DPI-SSL or add an inspection policy for security-validation traffic.

Run the test from machines on different network segments. A common finding: the security team's VLAN has full protection (SSL inspection on, both gateway and endpoint AV catch EICAR), but the guest Wi-Fi or a branch office subnet has no gateway scanning at all (only endpoint catches it).

What Your Results Tell You

Gateway blocks all three formats (.com, .txt, .zip): Your firewall has SSL inspection enabled, content scanning is active, and archive unpack policy is in place. Endpoint protection serves as defence-in-depth.

Gateway blocks .com but misses .txt or .zip: Content inspection only covers executable MIME types. Configure the gateway to inspect text/plain and application/zip categories, and review the max-archive-depth setting.

Gateway misses everything, endpoint catches all three: Your gateway lacks SSL/TLS inspection for this traffic class. Endpoint AV is the only line of defence — risky if it ever fails or is disabled. Enable DPI-SSL on the gateway.

Nothing blocked anywhere: Critical configuration failure. Verify endpoint AV real-time protection is on, signature database is up to date, and the AV service is actually running. Then check gateway SSL inspection and content-filtering policy.

Forcepoint NGFW log showing blocked threats
Test Your Full Threat Detection Stack →

Related Searches & Tools

Free heuristic malware behavior testing simulatorGenerate benign Ransomware VBS test scripts onlineTest Endpoint AV macro payload dropping onlineEICAR test file alternatives for heuristic enginesSimulate malware Dropper in browserTest EDR payload execution