Detecting T1648 Serverless execution

How T1648 serverless execution shows up in cloud and SaaS estates

T1648 Serverless execution lets an adversary run code or logic through a managed execution service, such as a function, automation rule or workflow trigger, without ever touching a server the security team monitors. For a SOC lead, the practical problem is that the code runs inside a platform the team rarely instruments: the cloud provider handles the host, so there is no endpoint agent to alert on. In intrusions, the technique is most useful to an attacker who already holds a valid identity with permission to create or edit these triggers, because the execution then looks like routine automation to anyone reviewing it. ATT&CK places T1648 under the Execution tactic, TA0002, whose stated purpose is that the adversary is trying to run malicious code or instructions on a system. Technique IDs take the form T####, and this one has no sub-techniques in the mappings this page uses. The page targets Enterprise ATT&CK version 20.0, which is the version named in the supplied mapping data. Because MITRE can rename, deprecate or revoke techniques between releases, your detection content should record the version it was written against and be rechecked when the version changes. Confirm the exact platform coverage for T1648 against the technique page in that version before you scope your telemetry, since the set of platforms a technique lists is part of the mapping you will be relying on. For the rest of this page, treat T1648 as a question about who can create, modify or invoke managed execution logic in your SaaS and IaaS tenants, and whether those changes are logged and reviewed. Start by listing every platform where your organization has a managed execution service, then ask the platform owner who holds rights to deploy or edit that logic. Those answers determine which audit sources you need to forward to your SIEM before any detection rule is written.

Which telemetry reveals serverless execution and which open-source collectors gather it

This table maps each telemetry source to the serverless execution signal it can reveal and the open-source collector that brings it into the monitoring stack. Read it as a checklist: a signal is only useful if the collector forwards it, so confirm each log source reaches the SIEM before relying on it. The main takeaway is that cloud control-plane and application logs carry most of the evidence, while host-based telemetry plays a minor role.

Telemetry source	Signal it can reveal	Open-source collection path	Confirm before relying on it
Application Log Content (DC0038)	Function invocations from unfamiliar identities, unexpected runtime errors, or execution outside normal schedules	Wazuh log collection from forwarded cloud or SaaS audit feeds, with decoders normalizing the fields	Which fields record the invoking identity and source address, and their retention period
Cloud Service Modification	New or changed serverless functions, altered triggers, or new event subscriptions that were not part of a change record	Cloud provider audit logs forwarded to Wazuh or a SIEM, mapped to rules for function and trigger create, update and delete actions	That the provider audit trail is enabled for every account and region in scope
Identity and authentication events	Function management actions performed by service principals or users with no prior history of doing so	Identity provider logs forwarded to Wazuh, correlated with cloud audit events by identity	Whether service accounts are distinguishable from human users in the logs
Network Connection Creation (DC0082)	Outbound connections from function runtimes to destinations outside the expected allow list	Zeek or Suricata on egress points or VPC flow log forwarding, correlated with function identifiers	Whether serverless traffic traverses an inspected egress path at all
Network Traffic Content (DC0085)	Payloads or requests in plaintext or inspectable protocols that match known malicious patterns	Suricata rules or Zeek scripts on inspected egress, where encryption permits	That most serverless traffic is encrypted, so content inspection may be limited to specific paths
Process Creation and Command Execution	Process starts inside a managed runtime only where a host-based agent or container image is present	Wazuh agent on self-hosted runtimes, such as container hosts that run functions	That fully managed functions expose no host telemetry, so these sources may not apply

Detection logic for serverless execution, with tuning and false positives

The four detection ideas below share one goal: separate execution of serverless code that someone intended from execution that someone slipped in. Each idea pairs a telemetry source with a baseline, so analysts can tune thresholds against their own pipelines before alerting. Express each as a Sigma rule and name ATT&CK v20.0 in the rule metadata so the mapping stays traceable across releases.

Execution from new or modified functions

Alert when a serverless function is invoked for the first time after its code, configuration or environment variables changed, and the change was not made by the deployment pipeline's service identity. Application Log Content from the provider's function logs and Cloud Service Modification records should be correlated on the function name and a time window of minutes, not hours. Tune by building a baseline of which functions deploy often. Common false positives come from CI/CD deployments, blue-green releases and scheduled infrastructure-as-code runs. Confirm each source's log retention with your provider before writing the rule.

Trigger or permission change followed by execution

Flag a sequence where a function's trigger, such as an event source or schedule, or its attached execution role is modified, and the function then runs within a short window. Cloud Service Modification events supply the change, and Application Log Content supplies the invocation. The rule is most useful when the modifier is a human principal rather than a pipeline role. Tune the window to match your deployment cadence. False positives include routine permission grants during onboarding, new scheduled jobs created by platform teams, and event source mapping updates made by managed services.

Execution by service identities off-pattern

Establish which service identities normally invoke each function, then alert when an identity outside that set triggers execution, or when a known identity invokes from an unusual source network or at an unusual hour. Application Log Content and User Account Authentication events are the core inputs. Tune with a per-function allowlist reviewed quarterly. Common false positives include shared automation accounts, monitoring probes that call health endpoints, and cross-account invocations used by legitimate integrations. Ask each platform owner to document their invoking identities before the baseline is locked.

SaaS automation runs created by unexpected users

In SaaS automation tools, alert when a workflow, macro or scripted automation is created or edited by a user who has not previously owned automations, and that automation runs against sensitive data or external endpoints within a set period. Cloud Service Modification and Application Log Content from the SaaS audit log are the main sources. Tune by listing the groups allowed to author automations and by flagging new external connectors separately. False positives include employees building legitimate personal automations, scheduled runs from vendor-provided templates, and automation migrations during platform upgrades. Confirm the audit log fields your SaaS vendor exposes before drafting the rule.

Tuning thresholds and suppressions

Every rule above depends on thresholds that differ by environment, so record each threshold, its owner and the date it was last reviewed. Start with suppressions for named pipelines and scheduled jobs, then review suppressed events monthly to catch abuse that hides behind a trusted name. Validate each rule by replaying known deployments and known test executions in the cyber range before enabling it in production. Document the ATT&CK v20.0 technique mapping in each Sigma rule so reviewers can trace changes when ATT&CK releases rename or deprecate content.

How to validate that the T1648 detection fires

This sequence proves, in a non-production tenant, that a T1648 Serverless Execution detection receives the right telemetry, raises an alert with the expected fields, and performs at an acceptable false positive rate. It ends with a tuning record that the detection team can audit.

Agree the scenario and test identity
The detection team and the platform owner agree in writing which serverless function behavior the emulation will represent, which SaaS, IaaS or Office Suite tenant it runs in, and which dedicated test identity performs it. The scope names the systems that may be touched, the people who are told before each run, and the stop conditions. The output is a signed scope note that a reviewer can check against the run record. Confirm with your own change process whether any approvals are needed before the test identity is created.
Confirm the non-production tenant is isolated
Before any emulation, the team verifies that the target is a non-production tenant or project, that it has no shared credentials with production, and that its audit and application logging match the production configuration as closely as the platform allows. The owner of the cloud or SaaS administration plane checks that the test identity has only the permissions the scenario needs, which ties the step to the ATT&CK mitigations User Account Management and Account Use Policies. The output is a short configuration check that lists any gaps in logging or permissions.
Run the emulation with a written runbook
A named operator runs the agreed scenario from the runbook, records the start and end time in UTC, and keeps a log of every action taken under the test identity. The runbook describes the intended behavior in words and references the approved tooling, and it does not contain commands or payloads in the shared document. A second person observes the run so that actions outside the runbook are caught. The output is a timed activity record linked to the scope note.
Confirm the logs arrived
The analyst searches the SIEM, such as Wazuh or a Security Onion deployment, for the events generated by the run, using the Application Log Content and Cloud Service Modification data sources that the detection depends on. They compare event counts and timestamps against the activity record and check for ingestion delay, dropped fields or parsing failures. If events are missing, the team records which source failed and stops before judging the detection. The output is a log completeness check per data source.
Check the alert fires with expected fields
The analyst confirms that the detection rule, written against the ATT&CK version the team has targeted, produced an alert for the run and that the alert carries the identity, tenant, resource, time and source fields the triage process needs. The team measures time to detect as the gap between the first recorded action and the alert timestamp, using the same clock source for both. The output is a pass or fail result per expected field, plus the measured time to detect for each run.
Record false positive rate and run results
Over a defined set of normal administrative activity in the same tenant, such as legitimate deployments and configuration changes, the team counts alerts that were not caused by the emulation and classifies each as expected or unexpected. The false positive rate is calculated from those counts and reported next to the number of emulated runs. The record for each run includes the scenario ID, operator, timestamps, data sources checked, alert result, time to detect, and any analyst notes. The output is a run ledger that the detection owner signs off.
File tuning changes through change control
When a run exposes a missing field, a noisy condition or a gap in coverage, the detection engineer opens a tuning ticket that states the observed problem, the proposed rule change, the expected effect on false positives, and the run IDs that prove the problem. The change is reviewed by a second engineer, tested against the same runs and the normal activity set, and then deployed with its version recorded. The output is a versioned rule change and a before and after result, so an auditor can trace the detection's history.

Mitigations that reduce serverless execution risk

Serverless execution depends on who can create, change and trigger workloads, so these controls focus on accounts and their privileges. Each card names an ATT&CK mitigation or account policy, explains how it narrows the identities able to run code in your SaaS or IaaS estate, and lists the evidence to keep. Confirm the mapping for T1648 against the ATT&CK v20.0 technique page before you cite it in an assessment.

User account management

Inventory every identity that can create or edit serverless workloads. M1018 covers how accounts are provisioned, reviewed and removed, so start with a current list of human users, service accounts and API keys that hold those rights. Remove dormant accounts, retire shared logins and require a named owner for each service identity. Keep the role assignment exports from each SaaS or cloud console, the joiner, mover and leaver tickets, and the dated results of periodic access reviews. Illustrative: a deployment service account that nobody has used for months is a candidate for removal.

Privileged account management

Limit administrator roles to the people who must change production automation. M1026 restricts who holds elevated rights, so deploying a function, changing its trigger or altering the service it connects to should require a role that few identities hold. Where your platform supports time-bound or approval-based elevation, use it for these actions and record the approver. Confirm that break-glass accounts are documented, monitored and tested. Evidence to keep: the holders of each privileged role, elevation requests with approvals, and alerts raised when those roles are assigned.

Account use policies

Set conditions under which accounts that can run workloads may sign in. Account Use Policies govern how accounts are used, including where and how they authenticate. For serverless execution, require strong authentication for console and automation logins, alert on use from unexpected locations and set sensible token lifetimes for service identities. Confirm on the ATT&CK v20.0 technique page whether this mitigation is mapped to T1648 before citing it. Evidence to keep: identity provider policy exports, conditional access rules and sign-in logs for the accounts in scope.

User training for automation admins

Teach the people who build automation what a suspicious trigger looks like. M1017 concerns training, and for this technique the audience is administrators who create functions, flows and scheduled jobs. Cover how to review the code, permissions and trigger of each new workload, when a change needs a second reviewer and how to report an automation they did not create. Refresh the content after significant platform changes. Evidence to keep: course outlines, attendance records, dated acknowledgments of the change review procedure and the version of material delivered.

Audit of automation changes

Keep logs that show who created, changed or triggered each serverless workload. M1047 focuses on enabling and reviewing audit records. For T1648 the useful records are creation and modification events for functions, workflows and their triggers, along with the identity behind each event. Confirm that the audit feature is on for every account in scope, that retention meets your policy and that someone reviews new automation on a set schedule. Evidence to keep: the audit configuration export, retention settings and review sign-offs.

What the SOC does when a serverless execution alert fires

The first job when a serverless execution alert fires is to decide whether the activity is authorized, and the SOC cannot make that call until it confirms the alert is real. Start by pulling the raw event from the application log or cloud audit trail that triggered the detection, then identify the function, workflow or automation object that ran, the identity that created or invoked it, the trigger that started it (a schedule, an HTTP endpoint, a queue message or a SaaS event), and the time window in which it executed. Compare that record against your change calendar, deployment pipeline history and the owner's known automations. Before anyone edits, disables or deletes anything, export and hash the relevant audit logs and the current configuration of the object, so that the evidence survives any remediation the team performs.

If the activity is not authorized, containment should remove the trigger or the credential first, not the code. Disabling the trigger stops new executions while preserving the artifact for analysis. Revoking the token, API key or service principal that the object runs under cuts off its ability to act elsewhere, but it can also break legitimate workloads, so confirm the blast radius with the owning team before revocation. Eradication then means reviewing everything else the same identity created, modified or invoked during the window the alert covers, including other serverless objects, SaaS automations, scheduled triggers and new credentials. Recovery should restore only from reviewed, version-controlled definitions, and the team should confirm with the platform vendor's documentation how each SaaS or IaaS provider records these changes, because retention periods and field names differ by platform.

Once the incident is closed, tune the detection against what the investigation actually showed. Record which triggers, identities and deployment paths generated false positives, and add those to a documented allow-list tied to an owner and review date, rather than muting the rule. Confirm that the rule still maps to the ATT&CK version your team targets, because mappings can change between releases, and re-run your cyber range scenario after each tuning change to check that the detection still fires on the behavior it was written for. Feed the findings back into the mitigations that were relevant here, such as User Account Management and Account Use Policies, and make sure the owner of each automation can be identified from the audit trail without a manual search.

Rehearsing T1648 detection in a private cyber range

A private cyber range for T1648 needs a test SaaS or cloud tenant that mirrors the client's configuration without holding real data, a log pipeline that collects its audit events, and a place to store the exercise evidence. Wazuh or Security Onion can receive the cloud audit and application logs, and Velociraptor or a direct log source path can be added where endpoint or host context is needed. Keep the range network isolated from production, use separate identities and credentials, and confirm that the tenant's audit logging is enabled before the exercise starts.

Isolated test tenant: Use a non-production SaaS or cloud tenant or project with synthetic accounts, never a copy of live data.
Log collection: Confirm how the chosen platform ingests the provider's audit and application logs, and record the ingestion path in the exercise plan.
Identity separation: Create dedicated range accounts with no trust relationship to production directories or administrators.
Network boundary: Block outbound paths from the range to production systems and document the boundary rules.
Baseline capture: Export configuration and log samples before the exercise so later changes can be compared.

Before starting, confirm with the platform owner which audit events the tenant actually emits and whether they are retained long enough for review.

Questions SOC leads and detection engineers ask about T1648

How does T1648 Serverless Execution differ from T1059 or T1609?

T1648 covers code that runs on a cloud provider's serverless or managed function service, so the execution happens outside any host you operate. T1059 describes command and scripting interpreters on endpoints, and T1609 describes running commands inside containers, so their main evidence sits in process and container telemetry. For T1648, the signals usually come from cloud control plane records, function configuration changes and application logs. Confirm the exact platform scope and detection strategies for your target ATT&CK version before you map alerts to a technique ID.

Is Application Log Content enough without host telemetry for T1648?

For serverless workloads, Application Log Content is often the most useful data component because there may be no host where you can install an agent. It works best when paired with Cloud Service Modification, which shows who changed a function, its trigger or its permissions. Host telemetry can still help where functions call into your own network, so check which network and identity records your provider exposes. Treat log coverage gaps as a finding to document, not an assumption that the technique is covered.

How do we avoid alerting on legitimate CI/CD pipeline deployments?

Start by inventorying the service accounts, pipeline identities and deployment paths that are expected to create or update functions. Write detections that alert on changes from identities outside that list, or on changes outside approved deployment windows, rather than on every function update. Tie alerts to a change record or pipeline run identifier where your logs provide one, so analysts can close routine deploys quickly. Tune the allowlist through a documented review, and retest it whenever pipelines or service accounts change.

Which MITRE ATT&CK version should our detections pin to?

Pin detections to one named ATT&CK version and record it in every rule and mapping. MITRE publishes ATT&CK content as STIX 2.1 bundles per domain and version, and releases can rename, deprecate or revoke techniques and detection strategies. The page's pillar facts reference Enterprise ATT&CK 20.0, so confirm that version against the enterprise-attack 20.0 STIX bundle before you adopt it. Plan a review at each release so that mappings for T1648 stay accurate.

How can we test T1648 detections without touching a production tenant?

Build a private cyber range that mirrors your cloud account structure, logging configuration and deployment pipelines, but uses isolated accounts and synthetic data. Run controlled, scoped exercises that create and modify test functions, then confirm that the expected Application Log Content and Cloud Service Modification records reach your SIEM. Measure whether each alert fires, carries enough context to act on and routes to the right queue. Keep a written rollback plan and remove test resources after each run.

Who should own T1648 detection and response in our organization?

Detection content usually sits with the detection engineering or SOC team, while the cloud platform team owns logging configuration, identities and function deployment standards. Incident response needs a named owner who can disable a function, rotate credentials or revoke a trigger without waiting for a change board. The User Account Management and Account Use Policies mitigations need joint ownership, because they depend on identity administration and on how deployment accounts are used. Document this split in a RACI so that alerts do not stall between teams.

Can our own team run T1648 exercises, or do we need outside help?

Your team can run these exercises if it has cloud administration skills, a test environment and clear rules of engagement. External help is most useful for scoping the exercise, building the range and reviewing detection quality against your logging design. Engagements of this kind are usually fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts. Ask any provider to state which parts of the exercise they will run, which parts you retain, and how results are documented for your audit evidence.

How the detection and range work is scoped in practice

A detection and purple team engagement for T1648 Serverless execution starts by fixing the platforms in scope before anyone writes a rule. For this technique that means naming each SaaS, IaaS and office suite tenant the engagement covers, the accounts and projects inside them, and which functions or automation services are allowed to be exercised in the range. The client should confirm which of its own cloud accounts or SaaS tenants can be used, who approves changes to them, and whether production tenants are excluded. Scope also records the ATT&CK version the detections will map to. The current release is Enterprise ATT&CK 20.0, and the mapping should cite it explicitly because technique names and mappings can change between releases.

Next, the team inventories the log sources that will actually be available. The core telemetry for this technique is Application Log Content (DC0038) and Cloud Service Modification, so the questions are concrete: does each platform export audit and administrative events, how long are they retained, are they forwarded to the SIEM in a parseable form, and can the team see who created, changed or invoked a function or workflow. Gaps should be written down as known limitations rather than discovered during the exercise. Where a platform does not expose the event needed, the scope should say so and name a compensating source, such as identity sign-in logs or control plane changes, instead of implying full coverage.

Success criteria should be agreed in advance and written as observable outcomes: which simulated behaviors must raise an alert, within which review window, and which must be recorded as a detection gap with a tuning ticket. The range scenario is then planned as a sequence of short cycles: run, review alerts, tune the rule to reduce noise without removing coverage, and rerun. Each cycle should be dated and owned, and the final report should separate what was detected, what was missed and what needs owner action. Effort, duration and cost depend on the number of platforms, the state of logging and the number of tuning cycles, so ask for those drivers to be itemized in any written scope rather than relying on a general estimate.

How DeployOpen builds T1648 detections and range exercises

DeployOpen works on T1648 Serverless execution inside the client's own cloud, SaaS and office suite tenants, starting from a written scope. The work turns the telemetry for application logs and cloud service modifications into detections that are tested in a private cyber range before handover.

How we scope

Confirm which SaaS, IaaS and office suite tenants produce Application Log Content and Cloud Service Modification events for the review.
Agree in writing which serverless functions, automation runtimes and identities are in the monitored estate.
Record the ATT&CK version the detection mappings target, so later technique changes can be traced.

How we build

Write detection logic for serverless function creation and modification in plain language, then express it as open-source rules for the client's SIEM.
Map log sources into Wazuh or Security Onion pipelines, checking field coverage for each tenant before alerts are enabled.
Test detections against benign administrative changes in the range to measure false positives before production rollout.

How we hand over

Deliver detection documentation covering data components, expected log fields, tuning notes and known blind spots for T1648.
Provide range exercise runbooks so the client's analysts can replay the scenarios and confirm alerts still fire after changes.
Document the account hardening work tied to User Account Management and Account Use Policies, with evidence the client can keep.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, covering detection updates when ATT&CK releases change.
Retest detections after tenant configuration changes, new serverless services or changes to log retention settings.
Confirm with the client's compliance lead which evidence the independent auditor will need, since DeployOpen prepares evidence but does not issue audit reports.

T1648 Serverless execution