|
Serverless Execution: Invoking Lambda Function
AWS Specific Sub-Technique
Other sub-techniques of Serverless Execution (1)
| ID | Name |
|---|---|
| T1648.A001 | Invoking Lambda Function |
AWS Specific Content
A prerequisite for this technique is that a threat actor has already gained control of an AWS identity with the permissions to perform the action in the Event Name(s) section.
AWS Lambda is a compute service that provides a way to run code without provisioning or managing servers. You can invoke Lambda functions directly with the Lambda console, the Lambda API, the AWS SDK, the AWS CLI, and AWS toolkits. You can also configure other AWS services to invoke a Lambda function, or Lambda can be configured to read from a stream or queue and invoke a function.
With access to an AWS identity that has the appropriate permissions, threat actors may use Lambda to run code in response to events, such as changes to data in an Amazon S3 bucket or an Amazon DynamoDB table; to run code in response to HTTP requests using Amazon API Gateway; or invoke code using API calls made using AWS SDKs.
Detection
AWS Specific Content
When this technique is used by the threat actor, actions taken by the threat actor using the credentials obtained will be logged in CloudTrail. You can use the Event History page in the AWS CloudTrail console to view the last 90 days of management events in an AWS Region for the events listed in the AWS CloudTrail Event Name(s) section, such as
lambda:Invoke.To view object-level API activity such as
lambda:Invoke, you will need to log data events with a separate CloudTrail trail as object-level API activity will not show up in CloudTrail Event history. A separate CloudTrail trail will also give you an ongoing record of events in your AWS account past 90 days and can be configured to log events in multiple regions. You can also review events using the console as well as the AWS CLI.It is also possible to create a CloudWatch metric filter to watch for when specific AWS API calls are used and perform notification actions if logged, and additionally configure CloudWatch to automatically perform an action in response to an alarm.
If a Lambda function gets invoked in your environment and Amazon GuardDuty is configured within the AWS account, a GuardDuty finding may be created when the Lambda function is invoked. For example, the Backdoor:Lambda/C&CActivity.B finding is used to identify when a Lambda function in the environment is querying an IP address associated with a known command and control server. To view additional information on the GuardDuty Lambda Protection finding types, click here, and for more information on GuardDuty Lambda Protection, click here.
Mitigation
AWS Specific Content
The security best practices for using Lambda include monitoring the usage of Lambda and reviewing network activity logs for potential threats. AWS Security Hub controls for Lambda provide additional detailed guidance on how to configure Lambda securely.
You can make sure that principals are scoped with the least-privileged permissions necessary to perform duties, limiting the ability to perform unauthorized actions in an AWS account when not required. One possible method of applying the principle of least-privileged permissions is to use Service Control Policies to restrict the maximum available permissions for the IAM users and IAM roles within your AWS Organizations accounts (note - you should test SCPs in a development environment before deploying them in production).
You can also use IAM Access Analyzer to regularly review and verify access and manage permissions across your AWS environment, which will highlight AWS identities with excessive permissions and the actions performed by those identities.