Creating S3 Honey Pots
Most people are familiar with the concept of a honey pot. A fake resource/system that replicates some vulnerable system. It sits on the internet and can be used to either distract attackers or gain information on attacker’s techniques.
In this case we’re creating a reverse honey pot. We’re not waiting for an attacker to hack our system, we’re waiting for a user to make a mistake. When creating an S3 bucket we can choose any name as long as it doesn’t conflict with another bucket name. Companies often use easy to recognize names for buckets, Facebook may use a bucket name like Facebook-files. Since there are no restrictions on the names we don’t have to work at Facebook to create facebook-files bucket.
So first up we want to create some buckets. You can choose some names that you think a company would use or your own company name to monitor if people are using random buckets.
One option is to enable logging of all actions for the buckets. We’ll also be setting up email notifications but this will track events to another bucket.
Now complete the bucket creation process. Next we’ll want to set the permissions.
We’re creating a public bucket so we need to enable public read and write. You do not want to enable public read and write of the bucket permissions as we should only control those.
Next we’ll create an SNS topic that will send emails.
For the SNS topic, we’ll use email as the protocol and whatever email you want to receive emails through. Complete the subscription. You’ll then need to confirm the email account through the link that will be sent to you.
Lastly, we’ll setup an event on the S3 bucket that will use SNS to send us an email
We name the event and set the SNS topic to the topic to the one we created earlier. We want to capture create and delete actions.
Once we have this all setup we can test it out by uploading a file to the bucket and we should be emailed about the event.
So now we receive an email once a file is uploaded. I’ve cleaned up the json you receive. You see the name of the bucket and the file, test.txt.
We can now setup lots of buckets with common names and get alerted when users upload files to access them. This is a good way to catch if your AWS users or developers are making mistakes with S3 before sensitive data gets leaked.
Thanks to @cktricky, Jerry Gamblin and @matt_ahrens for reviewing.