T1648: Serverless Execution
Adversaries may abuse serverless computing, integration, and automation services to execute arbitrary code in cloud environments. Many cloud providers offer a variety of serverless resources, including compute engines, application integration services, and web servers.
Adversaries may abuse these resources in various ways as a means of executing arbitrary commands. For example, adversaries may use serverless functions to execute malicious code, such as crypto-mining malware (i.e. Resource Hijacking).[1] Adversaries may also create functions that enable further compromise of the cloud environment. For example, an adversary may use the `IAM:PassRole` permission in AWS or the `iam.serviceAccounts.actAs` permission in Google Cloud to add Additional Cloud Roles to a serverless cloud function, which may then be able to perform actions the original user cannot.[2][3]
Serverless functions can also be invoked in response to cloud events (i.e. Event Triggered Execution), potentially enabling persistent execution over time. For example, in AWS environments, an adversary may create a Lambda function that automatically adds Additional Cloud Credentials to a user and a corresponding CloudWatch events rule that invokes that function whenever a new user is created.[4] This is also possible in many cloud-based office application suites. For example, in Microsoft 365 environments, an adversary may create a Power Automate workflow that forwards all emails a user receives or creates anonymous sharing links whenever a user is granted access to a document in SharePoint.[5][6] In Google Workspace environments, they may instead create an Apps Script that exfiltrates a user's data when they open a file.[7][8]
Analyst context for executives and security teams
Serverless Execution matters because cloud and SaaS automation can run attacker-controlled logic without a traditional server or endpoint. If an identity has permission to create functions, workflows, scripts, roles, or event triggers, that identity may be enough to execute code, automate data access, or maintain recurring execution in platforms such as IaaS, SaaS, and office suites.
Executive priority
Treat this as an identity-and-cloud control issue, not only a malware issue. Leaders should ask whether privileged cloud and office-suite automation is inventoried, logged, reviewed, and governed by least privilege. The business risk is that legitimate serverless and workflow features can be abused for persistence, privilege expansion, resource hijacking, or automated access to mail and documents, while producing little or no endpoint evidence.
Technical view
For SOC, cloud, and IR teams, validate visibility into creation, modification, permission assignment, and invocation of serverless functions, cloud event rules, Power Automate workflows, Google Workspace Apps Script activity, and comparable SaaS automation. Pay particular attention to role-passing permissions such as AWS IAM:PassRole and Google Cloud iam.serviceAccounts.actAs, event-triggered execution paths, and automation that touches email, SharePoint, files, credentials, or account lifecycle events. ATT&CK provides no official detection text for T1648, but the object is related to DET0374, a detection strategy for Serverless Execution.
Likely telemetry
- Cloud control-plane audit logs for serverless function creation, update, deletion, permission changes, and invocation
- IAM audit logs showing role attachment, service account use, pass-role style permissions, and privilege changes
- Eventing and scheduler logs for rules or triggers that invoke functions over time
- SaaS and office-suite audit logs for Power Automate workflows, Apps Script activity, sharing-link creation, mail forwarding, and document access automation
- Resource usage and billing telemetry that may indicate unusual serverless compute activity
Detection direction
- Baseline approved serverless functions, workflows, scripts, triggers, and service accounts, then alert on newly created or materially changed automation outside expected deployment paths.
- Correlate automation creation with the identity that created it, the permissions granted to it, and the resources it can access.
- Review event-triggered functions or workflows that run on account creation, file access, mail receipt, document sharing, or other high-value business events.
- Tune for administrative and DevOps false positives by distinguishing normal CI/CD or business automation from ad hoc creation by unusual users, unusual locations, or identities with newly granted privileges.
- Do not rely on endpoint telemetry alone; this behavior can occur entirely inside cloud or SaaS control planes.
Mitigation priorities
- Prioritize least privilege for users, service accounts, and automation identities, especially permissions that allow role passing, acting as service accounts, or creating serverless resources.
- Use user account management and account use policies to govern who can create, modify, and run automation in cloud and office-suite environments.
- Require review and ownership for serverless functions, workflows, scripts, triggers, and their attached roles or service accounts.
- Limit automation access to mail, documents, credentials, and account lifecycle events unless there is a documented business need.
- Periodically audit dormant, anonymous, or broadly permissioned automation and remove unnecessary functions, workflows, scripts, triggers, and credentials.
Analyst notes and limits
This technique is in the Enterprise ATT&CK domain under the Execution tactic and applies to SaaS, IaaS, and Office Suite platforms. The supplied relationships identify User Account Management and Account Use Policies as mitigations, Pacu as related IaaS software, and DET0374 as a related detection strategy. Examples in the ATT&CK description include AWS Lambda, Google Cloud service account behavior, Microsoft 365 Power Automate, SharePoint, and Google Workspace Apps Script.
The official ATT&CK object does not provide detection text, so detection guidance here is derived from the technique description, platforms, tactics, external references, and stated relationships. Local cloud provider, SaaS licensing, logging configuration, retention, and identity architecture determine whether the suggested telemetry is actually available.
Serverless Execution
Adversaries may abuse serverless computing, integration, and automation services to execute arbitrary code in cloud environments. Many cloud providers offer a variety of serverless resources, including compute engines, application integration services, and web servers.
Adversaries may abuse these resources in various ways as a means of executing arbitrary commands. For example, adversaries may use serverless functions to execute malicious code, such as crypto-mining malware (i.e. Resource Hijacking).[1] Adversaries may also create functions that enable further compromise of the cloud environment. For example, an adversary may use the `IAM:PassRole` permission in AWS or the `iam.serviceAccounts.actAs` permission in Google Cloud to add Additional Cloud Roles to a serverless cloud function, which may then be able to perform actions the original user cannot.[2][3]
Serverless functions can also be invoked in response to cloud events (i.e. Event Triggered Execution), potentially enabling persistent execution over time. For example, in AWS environments, an adversary may create a Lambda function that automatically adds Additional Cloud Credentials to a user and a corresponding CloudWatch events rule that invokes that function whenever a new user is created.[4] This is also possible in many cloud-based office application suites. For example, in Microsoft 365 environments, an adversary may create a Power Automate workflow that forwards all emails a user receives or creates anonymous sharing links whenever a user is granted access to a document in SharePoint.[5][6] In Google Workspace environments, they may instead create an Apps Script that exfiltrates a user's data when they open a file.[7][8]
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Groups, software, and campaigns
S1091: Pacu
Pacu is an open-source AWS exploitation framework. The tool is written in Python and publicly available on GitHub.[1]
All related ATT&CK context
Mitigation direction
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.2 | Current bundle | 63cc9978d50c… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Cado Security Denonia
Matt Muir. (2022, April 6). Cado Discovers Denonia: The First Malware Specifically Targeting Lambda. Retrieved May 27, 2022.
Open source URL -
[2]
Rhino Security Labs AWS Privilege Escalation
Rhino Security Labs. (n.d.). AWS IAM Privilege Escalation – Methods and Mitigation. Retrieved May 27, 2022.
Open source URL -
[3]
Rhingo Security Labs GCP Privilege Escalation
Spencer Gietzen. (n.d.). Privilege Escalation in Google Cloud Platform – Part 1 (IAM). Retrieved May 27, 2022.
Open source URL -
[4]
Backdooring an AWS account
Daniel Grzelak. (2016, July 9). Backdooring an AWS account. Retrieved May 27, 2022.
Open source URL -
[5]
Varonis Power Automate Data Exfiltration
Eric Saraga. (2022, February 2). Using Power Automate for Covert Data Exfiltration in Microsoft 365. Retrieved May 27, 2022.
Open source URL -
[6]
Microsoft DART Case Report 001
Berk Veral. (2020, March 9). Real-life cybercrime stories from DART, the Microsoft Detection and Response Team. Retrieved May 27, 2022.
Open source URL -
[7]
Cloud Hack Tricks GWS Apps Script
HackTricks Cloud. (n.d.). GWS - App Scripts. Retrieved July 1, 2024.
Open source URL -
[8]
OWN-CERT Google App Script 2024
L'Hutereau Arnaud. (n.d.). Google Workspace Malicious App Script analysis. Retrieved October 2, 2024.
Open source URL -
[9]
mitre-attack T1648Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.