- Newest
- Most votes
- Most comments
My understanding is, this is expected behavior and not a cause for concern regarding actual malware detection.
AWS continuously updates GuardDuty's underlying scanning engines and heuristics. The EICAR string embedded inside a PDF file is technically harmless and cannot be executed. To reduce processing overhead and false positives, modern AV engines frequently update their logic to ignore the EICAR string when it is encapsulated inside non-native document containers (like PDFs).
Solution: To reliably trigger the THREATS_FOUND tag and test your application logic, you should use the raw EICAR string in a plain text file rather than a PDF.
-
Create a simple text file named eicar.txt (or eicar.com).
-
Insert only the exact, standard 68-byte EICAR string:
X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H* -
Upload this .txt file to your S3 bucket.
This conforms to the official EICAR testing standard. A plain text or .com file guarantees a direct signature match and will reliably trigger the THREATS_FOUND tag for your tests, bypassing any document parser adjustments.
This means that an EICAR file wrapped in a PDF might no longer be detected if the GuardDuty scanning engine is updated.
Alternative Test File Options
- EICAR Text Format (Most Reliable) Official AWS re:Post resources and documentation recommend the EICAR text file (.txt format) for GuardDuty testing.
curl https://secure.eicar.org/eicar.com.txt -o eicar.com.txt
- EICAR ZIP File
Actual verification cases have confirmed that uploading
eicar_com.zipto S3 results in aTHREATS_FOUNDresponse. bash# Download the ZIP version from the official EICAR website
curl https://secure.eicar.org/eicar_com.zip -o eicar_com.zip
- EICAR + PDF (Embedded Format) There are also confirmed cases of GuardDuty detection using a method where the EICAR file is embedded in a Word document, which is then embedded into a PDF (a technique introduced on Didier Stevens' blog).
I strongly recommend switching to eicar.com.txt (text format) for your tests. Since detection involving PDF wrappers depends on GuardDuty engine updates, that method may no longer be suitable for testing purposes.
answered a month ago
Florian, thank you for taking time to answer my question.
I am testing a filepond that only accepts PDFs, JPEGs, and PNGs.
Is there anyway to get GD to rollback the change?
As far as I know, No, rollbacks are not possible. GuardDuty is a fully managed service, so engine updates are applied globally.
workaround: Create a standard eicar.txt file (containing only the exact 68-byte string) and rename it to eicar.pdf. GuardDuty ignores file extensions and scans raw file content. It will read the bytes, detect the EICAR string, and reliably flag it as THREATS_FOUND. Note: If FilePond's strict MIME-type validation blocks this spoofed file in the browser, simply upload the eicar.pdf directly to your S3 bucket via the AWS Console to test your backend logic.
So the file I was using, that file cannot be used by anyone to test s3's malicious upload response anymore?
Yes, exactly. Because an EICAR string simply pasted into a PDF does not constitute an executable threat, it is standard industry behavior for modern AV engines (like those powering GuardDuty) to eventually stop flagging them to reduce false positives. Anyone using that exact same PDF will see the same result.
To continue testing your application's response, using the spoofed .pdf workaround mentioned above is your simplest bet. Just remember that if your frontend (FilePond) checks for valid PDF 'magic bytes' in the file header, it might reject the spoofed file client-side, so you may need to upload it directly to S3 via the console to trigger the backend test.
Florian, Thank you for your continued help. So the spoofed pdf option did not work. I am going to look into trying to imbed the EICAR string into a jpeg. The full workflow needs to be tested and demonstrated, specifically frontend features tied to the upload of a malicious file, so I can't just do a backend test.
If I was a security developer for the GuardDuty team, wouldn't I not want GuardDuty to flag that specific file though, for the sake of everybody testing applications?