Serverless Execution (T1648) is an Execution technique. MITRE lists SaaS, IaaS and Office Suite as platforms. Adversaries abuse serverless computing, integration and automation services to run arbitrary code in cloud environments.
These services are designed to run code in response to events, with little infrastructure to watch. That makes them useful for defenders and attackers alike.
How attackers use it
MITRE gives these examples:
- Running malicious code, such as crypto mining (Resource Hijacking).
- Escalating the function itself. Using the IAM:PassRole permission in AWS or iam.serviceAccounts.actAs in Google Cloud to add Additional Cloud Roles to a function, which may then do things the original user cannot.
- Persistence through events. Functions can be invoked in response to cloud events (Event Triggered Execution). In AWS, an adversary might create a Lambda function that adds Additional Cloud Credentials to every new user, and a CloudWatch events rule to invoke it whenever a user is created.
- Office suites. In Microsoft 365, a Power Automate workflow can forward all of a user's email or create anonymous sharing links when someone is granted access to a document in SharePoint. MITRE notes Google Workspace has comparable scripting features.
Pacu, a tool listed on the page, can create malicious Lambda functions.
How to detect it
MITRE's analytics, by environment:
- IaaS: correlate creation or modification of functions (AWS Lambda, Google Cloud Functions, Azure Functions) with unusual IAM role assignments or permission escalation. Watch for later executions that make outbound connections, reach sensitive resources or create more credentials.
- Microsoft 365: creation of new Power Automate flows or similar automations that trigger on user or file events, followed by actions such as email forwarding, anonymous link creation or calls to external endpoints.
- Google Workspace: creation or updates of Apps Script projects bound to user events such as file opens or account changes, followed by unusual API calls that move or modify data.
The creation event is the best moment to catch it. A function that appears at 02:00 from an identity that never deploys code deserves a look before it ever runs.
How to reduce the risk
MITRE lists two mitigations:
- Restrict who can use serverless features. Apply conditional access to users who create workflows in Power Automate, and limit Google Apps Script access that uses OAuth by restricting high risk OAuth scopes.
- Remove permissions from people who do not need them. Take away the ability to create, change or run serverless resources from users with no explicit requirement.
Check your own environment
Read-only (AWS CLI, with credentials for an audit role):
aws lambda list-functions --query 'Functions[].[FunctionName,Role,LastModified]' --output table
Then check:
- Which identities hold iam:PassRole, and on which roles? A broad grant is a privilege path.
- In Microsoft 365, who can create flows, and are flows reviewed? Can flows send data to outside connectors?
- Which Apps Script projects have OAuth scopes that read mail or drive files?
- Do alerts exist for new functions and new automations?
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is iam:PassRole sensitive?
It lets a user attach a role to a serverless function, which can then act with permissions the user does not hold. MITRE names it, along with iam.serviceAccounts.actAs in Google Cloud.
How can a function give an attacker persistence?
By running whenever a cloud event fires, such as a new user being created, so it keeps acting even after the original session ends.
