Forem: Mehmet Ayberk

Managing Security Alarms with Automation in AWS

Mehmet Ayberk — Tue, 28 Jan 2025 11:32:50 +0000

TLDR;

Automated detection of security threats and taking necessary actions are among the most important aspects. As the attack surface expands daily, the number of topics requiring regular monitoring also increases. At this point, it is critical to build, design, and maintain automated systems as well as manual controls and human power. AWS has various security services that allow us to perform some security checks on a regular basis. Using these services more efficiently depends on the architecture we will design depending on the structure of our organization. In this blog post, I will take some security alarms that we think may be harmful in AWS by using AWS's security services and take automatic actions thanks to Lambda.

What Will We Automate?

Detection and Automated Action of AWS CloudTrail Deactivation

What Else Can You Automate?

Abnormal Pod Incidents to the EKS
Unexpected Traffic Increase on EC2
Detection of Abnormal Activity of an IAM User
Disabling Encryption Settings on RDS
Automatic Check and Correction of S3 Bucket Encryption Status
Detect IAM Root User Usage and Send Alarm
Controlling EC2 Instance Security Groups
IAM High Authority Role Monitoring
And much more

Detecting and Automating Responses to AWS CloudTrail Deactivation

When attackers gain unauthorized access through the interface or CLI, there are some steps they will take. One of them will be to erase the traces they have left behind. The first method they will try for this will be to deactivate CloudTrail if it is active. In this example, we will check whether CloudTrail is active or not in an automated way and reactivate it if it is deactivated. Of course, the task of activating CloudTrail also falls to our automation.

My goal here is to give you an overview of how you can build mini security automations in AWS, rather than having you do these examples in person.

At the end of the day, our architecture will look like this:

Enable cloudtrail-enabled Rule in AWS Config

First of all, we need to activate the AWS Config service. I skip the part on how to activate AWS Config and continue my article in the scenario where it is already active. We need to check whether CloudTrail is active on AWS Config. For that from the left menu we have to go to Rules and Add Rule. By selecting AWS Managed Rule, we select cloudtrail-enabled or multi-region-cloudtrail-enabled and create our rule.

We could have created the automation for this scenario by listening to CloudTrail calls directly on EventBridge without using AWS Config. I added this step so that you can see different scenarios.

Automatic Response with Lambda Function

We need the Lambda function to take the automatic action if CloudTrail is deactivated. The code we will write here will be quite simple. Of course, you may need to improve your code depending on the needs of the organization. For this, we will of course create an IAM role, create our Lambda function, and add the IAM code to this Lambda function. (Spoiler: Yes! We will then use EventBridge to trigger the Lambda function).

Before we start creating the Lambda function, we will need to create an IAM role to give the Lambda function the authorizations it needs to make the necessary changes to CloudTrail. You can also use AWS's IAM Role Generator to create an IAM role.

For this, you must follow these steps on the IAM screen:

Go to IAM > Policies > Create Policy

Make sure to comply with the least privilege policy when creating a new IAM role. This could prevent further security problems. Here, we will create our authorization instead of authorizing our role such as AdministratorAccess.

Here is what our policy looks like:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "cloudtrail:UpdateTrail",
                "cloudtrail:StartLogging",
                "cloudtrail:DescribeTrails",
                "lambda:InvokeFunction",
                "cloudtrail:GetTrailStatus"
            ],
            "Resource": "*"
        }
    ]
}

You can customize the Policy according to your needs.

Create the policy.
Go to IAM > Roles.
Select AWS Service as Trusted entity type and proceed by selecting Lambda in the Use case field just below.
In the Permission policy tab, let's assign the role by selecting the Policy we just created and complete the new role creation step.

Finally we can create our Lambda function. I will create the Lambda function in Python 3.x. You can of course use any other programming language that suits you or that you are comfortable with. Anyway, it is up to you to improve and extend the code here according to your needs. Here is my PoC code:

# Import the required libs
import json
import boto3
import logging
from botocore.exceptions import ClientError

# Making logging settings
logger = logging.getLogger()
logger.setLevel(logging.INFO)

def lambda_handler(event, context):
    # Create a client to access the AWS CloudTrail service
    cloudtrail = boto3.client('cloudtrail')

    try:
        # Log the incoming event
        logger.info(f"Received event: {json.dumps(event)}")
        # List all CloudTrails in the account
        response = cloudtrail.describe_trails()

        # If there is no trail, return an error
        if not response['trailList']:
            logger.warning("No CloudTrail trails found in the account")
            return {
                'statusCode': 404,
                'body': 'No CloudTrail trails found'
            }

        # Perform operations for each trail
        for trail in response['trailList']:
            trail_name = trail['Name']

            try:
                # Checking the current status of the trail
                status = cloudtrail.get_trail_status(Name=trail_name)

                # If logging is closed then do them
                if not status['IsLogging']:
                    logger.info(f"Trail {trail_name} is disabled. Enabling it...")

                    # Activate the Trail
                    cloudtrail.start_logging(Name=trail_name)

                    logger.info(f"Successfully enabled trail: {trail_name}")
                else:
                    logger.info(f"Trail {trail_name} is already enabled")

            except ClientError as e:
                # If an error occurs while activating a trail, we continue with other trails
                logger.error(f"Error processing trail {trail_name}: {str(e)}")
                continue

        return {
            'statusCode': 200,
            'body': 'Successfully processed all trails'
        }

    except ClientError as e:
        logger.error(f"Error: {str(e)}")
        return {
            'statusCode': 500,
            'body': f"Error: {str(e)}"
        }

Event Triggering with EventBridge

We need to connect the Lambda function to an Event via EventBridge to automatically take action when the case we expect occurs. For this let's create a new event. While creating our rule, we select the Config Rules Compliance Change option in the Sample event section. As the creation method, we will write our own rule by selecting Custom pattern again. Our rule will be as follows:

For this scenario, we want to trigger the Lambda function we wrote to recognize when a Trail is stopped. We need to create our EventBridge rule as follows:

You can fill in the Event name field as you wish.
In our scenario here, the Rule Type field should be Rule with an event pattern.
On the next page we must select Other in the Event Source field.
On the Build event pattern page, we can go down to the bottom and write our rule in the Event pattern field just below by making the Creation method Custom pattern without changing any other settings.
You can write the following code in the event pattern field:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["cloudtrail-enabled"],
    "newEvaluationResult": {
      "complianceType": ["NON_COMPLIANT"]
    }
  }
}

I can say that the writing format of Event Patterns is very clear and simple. If you have more questions about writing Custom Event Patterns, you can check AWS's official documentation..

Select the AWS service radio button as the target and then select the Lambda function in the Select a target section and the Lambda function we have prepared in the Function section.
Create the rule.

The EventBridge Rule summary we created should look like this:

That's all. Now we have a mini automation that will reactivate any of the CloudTrail Trails in case any of them is deactivated. Of course, you can also develop different solutions specific to your organization. For example:

If you have Trails that should not be included in this automation, you can create an Exception list and develop your code accordingly.
When the automation runs, you can send an e-mail containing information such as the Trail name, the user who deactivated the Trail, the time when the Lambda function was triggered.
You can visualize the logs of all these operations by sending them to ELK.

Test

Just deactivate an existing Trail. After a short time, you will see that the Trail has been reactivated. You can also observe your test by following these metrics after deactivating your Trail:

You can observe whether your Lambda code is triggered or not from CloudWatch Log groups.
You can observe your EventBridge metrics.

Also after a while you have to see Noncompliant Warning on the AWS Config.

In fact, we could have triggered our Lambda function by selecting the Create custom Lambda rule option while creating our Config Rule without using EventBridge. I would like to state again that my goal here is to provide you with different perspectives. There are many different ways to create such mini security automations on AWS. Of course, you can create the most suitable architecture according to your needs and by getting to know AWS services.

Last Word

In this blog post, my goal was to give you a perspective on how you can set up mini automations to make your AWS environment more secure. I strongly encourage you to try building the other automations in the "What Else Can You Automate?" section or develop the automations mentioned in this blog post.

Depending on your business needs, the automations you can build will vary and change. The code you write may change and the AWS services you use may change.

If you have any suggestions for the article, please feel free to contact me through any communication channel (Linkedin, Twitter, Threema, etc.). I am constantly updating the articles in line with your feedback.

Incident Response On AWS

Mehmet Ayberk — Tue, 20 Sep 2022 09:05:34 +0000

TLDR;

As in on-prem environments, security in cloud environments should be considered as a whole. As it can happen in any environment, hacking cases can occur in AWS environments. We see examples of this situation from time to time. In this article, I will not go into the details of Incident Response processes. I will mostly explain how you can run Incident Response processes on AWS.

Is It So Different from Incident Response?

In essence, no. Of course there are some differences. But it is important to remember that cloud systems are not much different from normal computer systems. Without going deeper, I should mention that I will not talk about Incident Response processes in this article. I will talk about how Incident Response processes are implemented in AWS. If you do not have basic knowledge about Incident Response, I recommend you take a break here and read a short articles about Incident Response processes.

AWS Incident Manager

There is a service offered by AWS that allows you to easily manage Incident Response processes. Incident Manager. With the Incident Manager service, you can plan your Incident Response processes, define Runbooks, send notifications to relevant teams and review incident details for up-to-date information during an incident. Incident Manager does all this by leveraging other AWS services.

Let's examine how Incident Manager is configured and how to use it.

Setting Up Replication

After entering Incident Manager's panel, we can start configuring it by clicking the Set up button under General Settings. Then let's continue by confirming the Terms and conditions.

At this point, we make general adjustments to Incident Manager. In the Regions field, we determine in which Regions we will use Incident Manager. We need to select at least one Region. But there is no upper limit to the number of Regions we will select.

You can use the KMS Encryption field to guarantee that the data stored in Incident Manager is protected and cannot be changed without deletion. Once you have done this, it can take up to 5 minutes to set up Replication (but it usually takes a few seconds). You can get yourself a cup of coffee.

Setting Up Contact Details

This stage is optional. You do not have to set it. But I recommend you
to follow every step in Incident Manager to run a good Incident Response process. This is the area where we set the people and communication channels to respond to the Incident.

In the Contact details field, the name of the person who will deal with IR processes and an alias are specified.

In the Contact channel field, we specify how to contact the person we specified in the Contact details field in case of a case. In this field, we can specify a communication channel via E-mail, SMS, or Voice. We can also specify more than one communication channel. My recommendation is to specify at least two communication channels. Thus, if the relevant person cannot be reached through one channel, they can be reached through the other channel.

In the Engagement area, you can specify when to contact the relevant contact(s) in case of an incident. Note that after you have set up the contact channels, a validation will be sent for each contact channel you have set up.

If you want to set more than one contact you have to repeat the same procedure.

Setting Up Escalation Plans

Creating an escalation plan is optional, just like creating a contact. But this time, if you want to create an escalation plan, you need to have already created a contact. You can use it in situations where you want more than one person to deal with a case at the same time. You can designate more than one person and forward the case to the other person(s) in case the first person does not respond to the case.

In the Escalation plan details field you must assign a name and alias to the related plan. In the Stages field, you can specify which people will deal with the case, and with the Duration parameter, you can specify how long in minutes it will be escalated to the next Responder. Duration must be 30 or less than 30.

If you want to create more than one Escalation plan you should repeat the same steps.

Setting Up Response Plan

I think the most crucial part is the Response Plan. You can use this area to plan how to respond to incidents, determine the severity of incidents, determine which contacts to contact, select metrics to track, and determine the automated runbooks to start.

As always, we start by specifying a name and alias for the Response plan in the Response plan details field. The values in the Incident Defaults field and their descriptions are as follows:

Title: The incident title helps to identify an incident on the incidents home page.
Impact: It allows you to identify an impact to determine the potential risk of the case.
Summary: It allows you to write a summary of the case. It is an optional field.
Dedupe String: Incident Manager uses the dedupe string to prevent the same root cause from creating multiple incidents in the same account. Incident Manager deduplicates Incidents created from the same CloudWatch alarm or EventBridge event into the same incident. (Source: AWS Docs.)
Tags: If you are familiar with AWS, you should be familiar with the tagging structure. Every event that starts using this response plan will have these tags. This will make it easier for you to do things like reporting.

The chat channel field is optional but very useful. Select a chat channel for responders to interact during the case. Currently, only Slack and Chime are supported. In order to use this area, you must first configure a Chatbot Client. For more detailed information, you can review the AWS document.

I explained the Engagements section in the previous chapter, so I will continue by skipping this section.

Runbooks allow you to automate some processes. You can create and use a Runbook, use one of the Runbooks created by AWS, or use another Runbook that has been shared with you. I should mention that for Runbooks to work, you must assign an IAM role with ssm:StartAutomationExecution authorization. Also, if you are going to use Runbook in Cross-Accounts, you must have sts:AssumeRole role.

Creating A New Runbook

Creating a new Runbook is quite easy. You need to enter a description in Markdown format and set up the Runbook steps.

Again, it contains a lot of detail. For detailed information on how to create a Runbook in AWS, you can check the AWS documentation.

Finally, you can tag the Response plan you created if you want. After all these steps, you can create the Response plan with the "Create response plan" button. You can also edit and delete the Response Plan, Escalation Plan and Contacts you created later.

Starting A Incident

Now that we have done our preliminary preparation, we can return to the Incident Manager dashboard and start a new Incident. There are three ways we can start an Incident. These are:

Automatically create incidents with CloudWatch alarms
Automatically create incidents with EventBridge events
Manually create incidents

In this article, I will talk about how to start an Incident manually and automaticly via CloudWatch.

Manually Create Incidents

Starting an Incident manually is quite easy and does not require much information. Click the "Start Incident" button on the Incident Manager dashboard. Select the Response Plan we prepared before and optionally give a title to the Incident and determine its Impact. Immediately afterward, the Incident is started by clicking the "Start" button.

Automatically Start Incidents With CloudWatch Alarms

With CloudWatch, we can track metrics and ensure that cases are automatically created in line with the conditions we want. For this, you must first create an Alarm from the CloudWatch panel. When creating an alarm, select Create Incident under Systems Manager Action menu and then select Response Plan to create an alarm.

From this moment on, an Incident will automatically occur in every situation that matches the condition you set when creating the Alarm.

Tracking And Resolving Incidents

You can follow the created cases from the Incident Manager dashboard. Here you can see general data about the cases, metrics, timeline, runbooks, engagements and you can edit some of them.

In order to Resolve the Incident, all you need to do is to click on the "Resolve incident" button on the top left.

Post-Incident Analysis

After the relevant case is resolved, you can start an analysis of this case and review the issues related to improving your processes. This analysis process is done with Templates. You can create your Template or use the Template created by AWS. Analysis details include metrics, timeline, question set, actions and a checklist. Once an analysis has been created, some areas, such as the question set, can be edited later.

Isolating EC2 Instances

In the event of an incident on an EC2 Instance, it is critical to isolate that Instance from the network. The steps to be followed at this point are as follows:

Detach the related Instance if it belongs to an Autoscaling group.
Create a new Security Group that denies all Inbound and Outbound traffic so that in case of an Incident the related Instance will not communicate with any address.
Detach the existing Security Group of the related Instance and attach the Security Group you created in the previous step.
Detach if an IAM role is defined on the related Instance. This will allow you to minimize the damage. Make sure that no IAM role is defined on the related Instance.
Take a Snapshot of the root volume of the respective Instance. You will need this Snapshot during the analysis. It will help you understand the root cause of the incident.
Finally, again create the AMI of the relevant Instance for analysis.
Remember that using tags at these stages will be very useful for you in stages such as analysis and report generation.

I mentioned that I will not go into the details of Incident Response processes or AWS in this document, but the steps described (such as creating a new Security Group) are quite simple. If there are any missing points here, you can use AWS's documents.

Open Source Incident Response Toolkit

There are some open open-source toolkits created by Andrew Krug, Alex McCormack, Joel Ferrier, and Jeff Parr that streamline our Incident Response processes in cloud environments.

Margarita Shotgun

Margarita Shotgun is a very simple to use memory dump tool written in Python programming language. It is designed to work in AWS environments. Detailed information is available in its own documentation.

Incident Pony

Incident Pony is a first of its kind case management and Incident Response orchestration tool specifically designed for AWS (Source: ThreatResponse).

AWS_IR CLI

AWS_IR CLI is the third and final Incident Response tool written by the ThreatResponse team. The purpose of the tool is to automate Incident Response processes. You can review the Black Hat document about the AWS_IR tool and other tools.

Yet Another Automation

There are many ways to automate Incident Response processes in an AWS environment. These processes can be automated with third-party tools and/or AWS's own services. At this point, it is important to choose the most suitable solution for your needs. In this blogpost, I will show you an automation that AWS describes in their Security Blog and I will also link to some other automations.

The automatization we will use takes the necessary actions by following AWS GuardDuty and AWS Config controls. The architecture is as in the image below.

The installation steps are quite easy. Because we don't do the installation manually. We can quickly install it with CloudFormation Stack.
CloudFormation Stack

In the Stack Parameters section, it asks us for some information. These are as follows:

S3 Bucket with sources: S3 Bucket name summarizing all AWS resources used. If you cannot provide this information, you can leave it as default.
Prefix for S3 bucket with sources: This is the setting where you can specify the Prefix for your S3 bucket objects.
Security IR Role Name: The name of the IAM role to be given to Lambda functions for actions to be taken automatically.
Security Exception Tag: This is the setting where you specify the name of the Tag you should use when you want to define an exception.
Organization Id: As a Best Practice, your security account should be a different account. This setting is your AWS organization ID, which is used to authorize CloudWatch data to be forwarded to the security account.
Allowed Network Range IPv4/IPv6: This is the setting used to limit all security groups that are not defined as exceptions.
Isolate EC2 Findings: This is a list of all GuardDuty findings that should lead to an EC2 instance being isolated.
Block Printcipal Finding: This is a list of all GuardDuty findings that should lead to blocking this role or user by attaching a deny all policy.

After all these settings, you can start Stack. Once Stack is complete, you will now have an automated IR process. For more details, you can read the AWS Security Blog.

Other Automations

I mentioned that there are many different ways to automate Incident Response processes in AWS. At this point, you should determine the most suitable solution for you. I have linked some other automatizations in the list below.

Last Word

In this blogpost, I aimed to give you basic information about Indicent Response processes in AWS. I hope it has contributed. Please note that Incident Response processes are not limited to what is described in this document. Incident Response and DFIR processes require expertise on their own. Also make sure to do the following in Incident Response processes in AWS:

Create CloudWatch alarms to suit your needs and connect them with Incident Manager.
Follow AWS’s Security Incident Response Guide.
Don't forget to use AWS's other security services.
Set up different security accounts for use in AWS. Make sure everything is isolated and apply the Least Privilege method.
Establish a process that complies with NIST's Incident Response Guidelines.
Improve your team and yourself Incident Response processes by solving AWS's Well-Architected Labs

Detection of Malicious Content in Files Uploaded to S3 Bucket

Mehmet Ayberk — Thu, 07 Apr 2022 18:37:02 +0000

TLDR;

No service scans for malicious content on files uploaded to S3 Buckets on AWS. There are some free and paid 3rd solutions to this problem. This article focuses on installing and using one of these open source solutions, along with a brief introduction to paid and other free solutions. We will briefly talk about S3 Antiviruses.

The Problem

Undoubtedly, S3 is one of the most frequently used services of AWS. You can keep the files uploaded to your applications on S3, use it to store log files, and use S3 for almost any build that requires storage. This will be completely tailored to your needs. Of course, in some scenarios, you may want the files uploaded to S3 to be viewed and/or downloaded by the end-users of your application. At this point, you can use Macie, a service of AWS, to detect sensitive data in the files uploaded to your S3 Bucket and take necessary actions regarding this data. So, isn't it important to check whether the files uploaded to your S3 Bucket contain harmful content? At this point, there is no service available from AWS. But of course, there is a solution to this too. It even has multiple solutions. In this blogpost, I will tell you how we can detect harmful content uploaded to S3 Buckets.

Detection of Malicious File Uploaded to S3 Buckets with BucketAV (ClamAV)

BucketAV offers both free and paid solutions. In this blog post, I will focus on the free and open-source version. You can find detailed information about the paid version here.

Let's take a closer look at this solution and experience it by installing it in our AWS environment. It is really simple to set up and use. CloudFormation Templates perform most of the configurations we need to do.

Some Feature The Project

It uses ClamAV to detect harmful content and its signature database is constantly updated.
It automatically deletes harmful content from S3 Bucket. (Optionally)
When a malicious file is uploaded to Bucket, it can send a Mail notification via SNS.
Logs to CloudWatch.
An EC2 wakes up the machine and the system runs there. At this point, it automatically scales the machines. (The reason it needs an EC2 machine is that it uses the clamscan command for malicious content detection.)

Installation

As I said before, the installation is quite simple. We'll be installing using CloudFormation Templates soon, but let's talk about what these Templates do in the background.

The first template we will use creates public and private subnets in two different AZs using VPC. Of course, it also makes Route Tables for these subnets, Internet Gateway, and Network ACL settings for the Public subnet. You can analyze it yourself by downloading the Template we use from here.

The other template we will use is to set up the EC2 instance, configure the Auto Scaling Group, and make all other settings such as SQS, SNS, and CloudWatch. In other words, the main template that helps us to solve the problem we focus on is this second template. You can analyze it yourself by downloading the Template we use from here.

For installation, let's set up our first template on AWS from here. We don't need to make any changes to the settings for this first stack. If the installation of this stack is completed without encountering any errors, it means that we can proceed to the installation of the other template.

You can install the second template directly from here. I performed these installations in the us-east-1 (N. Virginia) Region.

There is no need to explain each setting in this area one by one. Clear explanations have already been made. I just continued by changing the InstanceType value under EC2 Parameters from t2.small to t2.micro. You can also change other settings according to your preference. If this resulted in CREATE_COMPLETE on the stack, great! We can continue on our way.

Now we need to make some settings from the S3 Bucket that we want to be scanned. I created a test Bucket named s3-virus-scan-bucket in the same Region. In case a new object is uploaded to this Bucket, we need to create a new Event so that it can be scanned and the relevant actions can be taken. For this, we click the "Create event notification" button from the Event Notification field under the Properties tab. In the Event Type field, you need to select the "All object create event" option. In the Destination field, you have to choose SQS Queue and choose the non-DLQ option at the end. You can see this area in the picture below.

You can record the Event without making any other settings. From this point on, every object uploaded to the relevant S3 Bucket will be first scanned by ClamAV, if there is no harmful content, the relevant file will be stored in the Bucket, if there is any harmful content, the relevant file will be deleted.

Finally, let's make the relevant settings to receive e-mail notification via SNS in case of a malicious file upload and test the system we have created. You will see that a new Topic is automatically created under the SNS service. All we have to do is create a new Subscription for this Topic. Just click the "Create subscription" button and then choose E-Mail as Protocol to continue. There will be no other adjustments you need to make. Finally, confirm the Subscription Confirmation e-mail sent to the e-mail address you provided.

Test

Everything is ready now. We can test the system. For this, I upload a harmless txt file called justAtxt and two file called malware.ex_ and AzorultPasswordStealer.bin which is known to be harmful. The malware.ex_ file is a file belonging to the Stuxnet malware and the AzorultPasswordStealer.bin file is a file belonging to the Azorult Stealer. So they are quite popular.

Just a few seconds after uploading the relevant files, I see that I receive mail via SNS.

In addition, when we look at the S3 Bucket, where we upload the files, we see that the related files have been deleted, but our harmless file is still with us. While installing the CloudFormation Template, you can specify settings such as not deleting the uploaded files even though they are harmful, scanning only, notifying them by mail, and tagging harmful files.

Detection of Malicious File Uploaded to S3 Buckets with ClamAV (Another Way)

While researching on this subject, I came across a very nice open-source project (bucket-antivirus-function). This project allows scanning of new objects uploaded to S3 Buckets with the help of AWS Lambda. This tool scans files uploaded to S3 with ClamAV and deletes them if they contain harmful content. With the CloudFormation Template can be installed quite easily with a few manual steps. You can check the GitHub Repo for detailed information and installation stages.

Detection of Malicious File Uploaded to S3 Buckets with Trend Micro Cloud One

Trend Micro Cloud One is a paid solution. You can use Trend Micro Cloud One Yu not only to scan files uploaded to S3 Buckets but also as a security solution at many points related to your cloud environments. I cannot give a positive or negative comment as I have not used this product except for a few PoCs and demos. I wanted to include it in the scope of Blogpost as it provides a solution to our problem. Briefly, the working structure of Cloud One is explained in the image below. (Screenshot taken from Trend Micro documentation.)

In addition, the Cloud One platform has a wider variety of capabilities. You can find detailed information here.

Detection of Malicious File Uploaded to S3 Buckets with Kaspersky Scan Engine

Kaspersky Scan Engine is a paid solution just like Trend Micro Cloud One. This platform can scan objects uploaded to S3, as well as to detect insecure configurations in Kubernetes and Docker configurations, and scan a wider variety of cloud platforms. You can find detailed information here.

Detection of Malicious File Uploaded to S3 Buckets with Cloud Storage Security

Products are available on the AWS Marketplace of Cloud Storage Security. This product can tag, delete or quarantine scanned malicious items just like any other product. In addition, findings from API-driven, real-time, and scheduled scans are published on the AWS Security Hub. These AV products of Cloud Storage Security are also paid. But there are also free trial versions.

Detection of Malicious File Uploaded to S3 Buckets with Scanii

Another paid solution is Scanii. Scanii can scan for vulnerabilities on S3 Bucket with the help of AWS Lambda. It is very simple to set up and use.

Detection of Malicious File Uploaded to S3 Buckets with BinaryAlert

According to its own explanations, BinaryAlert;

BinaryAlert is a serverless, real-time framework for detecting malicious files. Organizations can deploy BinaryAlert to their AWS account in a matter of minutes, allowing them to analyze internal files and documents within the confines of their own environment.

Since it has very detailed documentation, it can be easily installed and used.

Detection of Malicious File Uploaded to S3 Buckets ClamAV and CDK

While doing my research, I came across a blogpost from AWS. By using aws-cdk it satisfies the need we mentioned. You can find detailed information in the related blog post. The working logic is illustrated in the image below.

Feedback

In addition to all these, I recommend you to follow the steps in the Security Best Practices for Amazon S3 document published by Amazon. This was the first article I wrote in English. So, if there are points that I have mistranslated, please do not be offended. You can contact me through any channel on any technical and/or non-technical issue.