ipers
asked on
eicar test string download attempt
Hi, I hope somebody can help me understand the root cause of an issue I see in my virtual environment.
I run vCenter 6.7U3g with the latest version of ESXi build. I backup my VMs using the latest version of VEEAM backup and replication software. All of a sudden one of the VEEAM-backed up servers started failing to replicate with this error:
Processing “server_name” Error: VDDK error: 14009 (The server refused connection). Value: 0x00000000000036b9 Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.
Error: VDDK error: 14009 (The server refused connection). Value: 0x00000000000036b9 Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.
At the same time my firewall log shows that the conversation between one of my ESXi hosts and the destination VEEAM backup server is being blocked due to the eicar test virus being detected in the packet:
fp4120-serv-1 %FTD-7-430001: DeviceUUID: 7e94860c-160d-11ea-b130-d2
Total New Alerts: 2
Filter Matching : 2
+-------------------------
Alerts (shown: 2/available: 2) (limit: 50)
+-------------------------
Device : FP4120-SERV-1
Timestamp : 2020-05-26 08:31:12
Protocol : tcp
Alert Message : POLICY-OTHER eicar test string download attempt (1:37732:4)
Session : IP_ADDR_GOES_HERE:902 -> IP_ADDR_GOES_HERE:58472
[*] 1 more events originated from this Source IP
Device : FP4120-SERV-1
Timestamp : 2020-05-26 08:33:31
Protocol : tcp
Alert Message : POLICY-OTHER eicar test string download attempt (1:37732:4)
Session : IP_ADDR_GOES_HERE:902 -> IP_ADDR_GOES_HERE:58484
[*] 1 more events originated from this Source IP
+-------------------------
| Destination Port Count
+-------------------------
58472 1
58484 1
+-------------------------
| Source IP Count
+-------------------------
IP_ADDR_GOES_HERE 2
I opened a support case with VEEAM. They suggested to do a storage vmotion of the server, which is failing to backup with VEEAM software. They said this operation would re-write each and every block of storage representing the vm. Indeed, this workaround worked and I had no issues for a few weeks, but then the same “virus” re-appeared.
No other machines running on the same ESXi host and the same datastore have an issues with the backup. The vm in question was full-scanned with Windows Defender and no threats were found.
With no intervention on my part the VEEAM backup job that was failing for a few nights in a row is now backing up without errors. My virus alerting systems are not reporting this virus as being found anywhere.
My understanding is that a virus cannot disappear on its own, so how is it possible that with no intervention on my part the virus was removed.
Please help me understand if this is a false positive or if indeed there is a problem that needs to be addressed.
Thanks.
I run vCenter 6.7U3g with the latest version of ESXi build. I backup my VMs using the latest version of VEEAM backup and replication software. All of a sudden one of the VEEAM-backed up servers started failing to replicate with this error:
Processing “server_name” Error: VDDK error: 14009 (The server refused connection). Value: 0x00000000000036b9 Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.
Error: VDDK error: 14009 (The server refused connection). Value: 0x00000000000036b9 Failed to upload disk. Agent failed to process method {DataTransfer.SyncDisk}.
At the same time my firewall log shows that the conversation between one of my ESXi hosts and the destination VEEAM backup server is being blocked due to the eicar test virus being detected in the packet:
fp4120-serv-1 %FTD-7-430001: DeviceUUID: 7e94860c-160d-11ea-b130-d2
Total New Alerts: 2
Filter Matching : 2
+-------------------------
Alerts (shown: 2/available: 2) (limit: 50)
+-------------------------
Device : FP4120-SERV-1
Timestamp : 2020-05-26 08:31:12
Protocol : tcp
Alert Message : POLICY-OTHER eicar test string download attempt (1:37732:4)
Session : IP_ADDR_GOES_HERE:902 -> IP_ADDR_GOES_HERE:58472
[*] 1 more events originated from this Source IP
Device : FP4120-SERV-1
Timestamp : 2020-05-26 08:33:31
Protocol : tcp
Alert Message : POLICY-OTHER eicar test string download attempt (1:37732:4)
Session : IP_ADDR_GOES_HERE:902 -> IP_ADDR_GOES_HERE:58484
[*] 1 more events originated from this Source IP
+-------------------------
| Destination Port Count
+-------------------------
58472 1
58484 1
+-------------------------
| Source IP Count
+-------------------------
IP_ADDR_GOES_HERE 2
I opened a support case with VEEAM. They suggested to do a storage vmotion of the server, which is failing to backup with VEEAM software. They said this operation would re-write each and every block of storage representing the vm. Indeed, this workaround worked and I had no issues for a few weeks, but then the same “virus” re-appeared.
No other machines running on the same ESXi host and the same datastore have an issues with the backup. The vm in question was full-scanned with Windows Defender and no threats were found.
With no intervention on my part the VEEAM backup job that was failing for a few nights in a row is now backing up without errors. My virus alerting systems are not reporting this virus as being found anywhere.
My understanding is that a virus cannot disappear on its own, so how is it possible that with no intervention on my part the virus was removed.
Please help me understand if this is a false positive or if indeed there is a problem that needs to be addressed.
Thanks.
ASKER
Hi Kimuter, thank you for your comment. This virus cannot be downloaded in my environment since my SCCM antimalware engine would block the download. My servers are not even allowed to go to the internet unless is it required by an application and even then it would be allowed to go only to that specified IP or URL. There is no way this test virus could have even be moved to the server in question because of the protections I have in place. I just went to the https://www.eicar.org/?page_id=3950 from my machine and attempted to download the file and it was stopped by my Forcepoint server. Thanks.
According to CIsco and Snort, this rule is not known to ever have a false positives:
https://www.snort.org/rule_docs/1-37732
Can you think of another way to introduce the EICAR file into your environment? Think USB, encrypted transfer, etc
https://www.snort.org/rule_docs/1-37732
Can you think of another way to introduce the EICAR file into your environment? Think USB, encrypted transfer, etc
ASKER
Thanks for the link. Good to know that there are no known FPs.
I copied the text string representing the virus (X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* ) and tried to create a text file with this string on the server in question. My SCCM had immediately deleted the file, which indicates to me that the file could not have existed on the server when my VEEAM replication job was failing.
Thanks.
I copied the text string representing the virus (X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* ) and tried to create a text file with this string on the server in question. My SCCM had immediately deleted the file, which indicates to me that the file could not have existed on the server when my VEEAM replication job was failing.
Thanks.
This question needs an answer!
Become an EE member today
7 DAY FREE TRIALMembers can start a 7-Day Free trial then enjoy unlimited access to the platform.
View membership options
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Please double check by downloading the eicar text file again on the same server, and see if the virus alert system did or did not fire.