Repeated EICAR tests stop alerting: check clamd caching and file events

Problem

The first EICAR test generates an alert, but repeating the same test does not produce another one.

Why it happens

clamd may reuse a cached result, the filesystem monitor may not observe a new event, or the SIEM may deduplicate identical alerts. Treat these as separate stages of the detection path.

Recommended approach

Create each test with a unique filename, then verify the ClamAV log before checking the Wazuh alert. This identifies whether the failure is in scanning, log collection, rule matching, or alert presentation.

Verification order

Example approach:

• Create an EICAR file with a unique, timestamped filename
• Confirm that a new filesystem event occurred
• Confirm that ClamAV scanned and detected the file
• Confirm that the ClamAV event reached Wazuh
• Check whether an alert rule or deduplication policy suppressed the event

Use this when

• Testing ClamAV
• Wazuh integration
• Malware lab detections
• Alerting flow

Avoid this when

• Production systems without an approved detection-testing procedure

Test safely with a unique file

Use the EICAR test string only in an approved lab or detection-validation procedure. Generate a new filename for every attempt so the filesystem and alert pipeline receive a distinct event:

test_file="/approved/test/path/eicar-$(date +%s).com"
printf '%s' 'X5O!P%@AP[4\\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*' > "$test_file"

Security software may quarantine the file immediately. Do not disable protection merely to keep the file present.

Separate the detection pipeline into stages

1. File creation

Confirm the operating system emitted a new file event and the monitored path is inside the ClamAV or FIM scope.

2. ClamAV scan

Inspect the ClamAV daemon and on-access scanner logs:

sudo journalctl -u clamav-daemon -u clamav-clamonacc --since '10 minutes ago'
sudo grep -i 'Eicar-Test-Signature' /var/log/clamav/*.log

Service names and log locations differ between distributions.

3. Wazuh collection

Confirm the agent monitors the exact ClamAV log and that the new line reaches the manager. If it does not, fix log collection before editing rules.

4. Rule and alert generation

Copy the exact ClamAV log line into wazuh-logtest:

sudo /var/ossec/bin/wazuh-logtest -v

Verify the decoder, rule ID, level, and extracted filename. Then inspect /var/ossec/logs/alerts/alerts.json for the live event.

Why identical retries can disappear

• clamd can reuse cached scan results for unchanged content
• An on-access scanner might act only on a new open, close, or write event
• FIM may report a change differently from a newly created file
• A Wazuh frequency or ignore rule may suppress repeated identical events
• The dashboard can group several alerts even when the manager generated each event

Changing the filename helps test event generation, but it does not prove which stage suppressed an identical retry. Always check the raw logs in order.

Cleanup

Remove remaining test files after evidence is captured and document the expected alert, timestamps, host, and rule ID. Never use live malware samples for this validation.

References

• EICAR anti-malware test file
• ClamAV documentation