Low-Code Platform Compromise Playbook: Contain and Revoke

A compromised low-code or workflow automation platform gives an attacker every connection its makers have ever authorised, wrapped in flows that run quietly on a schedule under someone else's name. These platforms store OAuth refresh tokens, API keys and database credentials for email, file storage, CRM, finance and cloud services, and their flows can read, forward and change data without anyone logging in. That makes them a natural place for persistence and exfiltration that survives password resets. This vendor-neutral playbook covers hosted and self-hosted platforms. It is for SaaS security, identity and incident response teams, and for the platform owners who will do much of the work. It covers how the compromise shows up, triage, containment in priority order, connection and token revocation, cleaning flows, recovery, evidence and notification. Hardening is covered in Securing the low-code and automation platform itself.

Key takeaways

Connections are the crown jewels. Each stored connection is a non-human credential acting for a person or a service account, often with broad scopes and no expiry.
Revoke at the source, not just in the platform. Deleting a connection inside the platform does not always revoke the token at the identity provider or SaaS app that issued it.
Flows are persistence. A scheduled or event-triggered flow that forwards mail or shares files keeps working after the attacker's password is reset.
Logs will show the maker, not the attacker. Shared and embedded connections make every action look like the connection owner, so correlate platform audit logs with identity and SaaS logs.
Disable, do not delete, while you investigate. Suspending flows and connections keeps the evidence; deleting them loses run history and configuration.

Why a low-code platform compromise is different

The OWASP Citizen Development Top 10 (formerly the Low-Code/No-Code Top 10) explains the core problem. Under CD-SEC-02, Account Impersonation, apps often run under an embedded identity, such as the maker's own account or a shared service account, so monitoring sees every action as coming from that identity and any user of the app can act as its creator. Under CD-SEC-03, Authorization Misuse, OAuth flows, refresh tokens and API keys are stored or shared across apps, persist beyond their intended lifecycle and accumulate as long-lived, broadly scoped "zombie" connections that are hard to monitor or revoke. CD-SEC-04 adds that exported components can carry connection strings in plain text, and CD-SEC-10 warns that platforms often under-log or over-log.

MITRE ATT&CK recognises the abuse directly: Serverless Execution (T1648) covers adversaries abusing integration and automation services, and its examples include an office-suite automation workflow that forwards all the email a user receives. Cloud Application Integration (T1671) covers persistence through OAuth integrations. The platform is therefore both an execution environment and a credential store. See the Low-Code and No-Code Application Security Guide for the wider risk picture.

How the compromise shows up

Signal	What it usually means	ATT&CK
New flows that forward email, copy files or sync records to an external destination	Exfiltration and persistence through automation	T1648 Serverless Execution, T1114.003 Email Forwarding Rule
Existing flows edited by an unexpected account, or with new steps or destinations	Takeover of a maker or admin account	T1078.004 Cloud Accounts
New connections with high-privilege scopes, or a sudden rise in token use	Token theft or consent abuse	T1528 Steal Application Access Token, T1550.001 Application Access Token
New custom connectors pointing at unknown endpoints	Data routing to attacker infrastructure	T1567 Exfiltration Over Web Service
Bulk reads of CRM, file or ticketing data by a connection identity	Collection using stored connections	T1213 Data from Information Repositories
Apps or flows shared with everyone, or new public endpoints and webhooks	Opening an external trigger or data path	T1671 Cloud Application Integration
Self-hosted platform: unexpected processes, new admin users, exposed management port	Host or application vulnerability exploited	Check the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog
Vendor advisory that the hosted platform or an integration partner was breached	Provider-side token exposure	T1199 Trusted Relationship

Triage: questions to answer first

What was compromised? A maker account, an environment or tenant admin, a service account used by connections, a single app or flow, the self-hosted server, or the provider.
Which connections could that identity use or see? Export the connection inventory with owner, target service, scopes and sharing. Shared connections widen the scope to everyone who could use them.
Which flows ran in the exposure window, and what did they touch? Pull run history for every flow that the compromised identity created, edited or owns.
Where did data go? List external destinations: mailboxes, storage, webhooks, custom connector endpoints, HTTP steps.
Which other systems trust the platform? Note service principals, OAuth apps and API keys registered for the platform in your identity provider and SaaS apps.
Are there exports? Check whether solutions, packages or components were exported during the window, since exports can contain connection strings (CD-SEC-04).

Decision: the incident lead sets severity. Critical if an environment or tenant admin, a connection to finance, email or identity systems, or the self-hosted server was compromised, or if data left the organisation through a flow.

Containment in priority order

Preserve evidence. Export platform audit logs, flow definitions and run history, connection inventory (no secrets), sharing settings and data policy configuration. Platform log retention can be short, so do this first. See the Evidence Handling and Chain of Custody Guide.
Turn off malicious and suspect flows. Suspend them rather than delete them, so definitions and run history stay available.
Block outbound paths. Tighten the platform's data policies or connector allow-lists to block the destinations the attacker used, and disable custom connectors and generic HTTP steps where you can.
Revoke tokens at the issuer. For each affected connection, revoke the grant at the identity provider or SaaS app that issued it. RFC 7009 requires revocation endpoints to support refresh tokens but only recommends support for access tokens, and revoking a refresh token does not always invalidate access tokens already issued, so expect short-lived access tokens to work until they expire and watch for their use.
Contain the accounts. Reset and require phishing-resistant MFA for compromised makers and admins, end their sessions, and remove any admin role grants made in the window.
Remove the platform's own excess rights. Suspend or narrow service principals and OAuth apps that belong to the platform where their scope is wider than needed. See the OAuth Token Theft Incident Playbook.
Self-hosted only: take the server off the internet, keep disk and memory images, and rotate its encryption key and database credentials after imaging.

Connections and credentials: rotation plan

Credential type	Where to revoke	Re-issue as
OAuth connection acting as a person	The user's grants at the identity provider or SaaS app	A dedicated service identity with least-privilege scopes, per CD-SEC-02
OAuth connection acting as a service account	The service account's grants and refresh tokens	Per-app service identity with an owner and review date
API keys stored in connections or variables	The target service's key management	New key with narrow permissions; held in a secrets manager where the platform supports it
Database and file share credentials	The database or directory	New credential, network-restricted to the platform's gateway
On-premises data gateway or agent keys	The gateway registration	Re-registered gateway on a clean host
Webhook signing secrets and inbound trigger URLs	The flow trigger	New secret and URL; old ones disabled
Platform's own app registrations	The identity provider	New client secret or certificate; consider moving to certificate credentials

The Salesloft Drift breach showed how stolen OAuth tokens held by one integration platform opened data across hundreds of customer environments, and the Gainsight Salesforce breach involved long-lived OAuth tokens. In both, the fix depended on revoking tokens at the SaaS side and knowing which connections existed. See OAuth Token Introspection and Revocation.

Eradication: cleaning flows and apps

Diff every flow touched in the window against its last known-good version. Look for new destinations, extra steps, changed triggers and widened sharing.
Hunt for persistence outside the platform created by flows: mailbox forwarding rules, anonymous file sharing links, new OAuth consents, new users or role grants in connected apps.
Review custom connectors and components for changed endpoints and unvetted community or marketplace components (CD-SEC-06).
Remove orphaned and zombie connections that have no owner or no flow using them; they are easy targets next time.
Self-hosted: rebuild the server from a clean, patched image and restore flow definitions from a trusted export, not from the compromised database.

Recovery and decision guidance

Option	When to choose it	Trade-off
Clean in place	One or a few maker accounts compromised; no admin or server access	Fast; relies on a complete flow and connection review
Rebuild the environment	Environment or tenant admin compromised, or too many flows to review	Flows must be re-imported and connections re-created; business disruption
Rebuild the self-hosted platform	Server exploited or host access suspected	Requires clean exports and new encryption keys; removes host persistence
Temporary shutdown of the platform	Provider-side breach with unknown scope	Business processes stop; use manual workarounds and keep it short

Small organisations with a single environment can usually revoke connections and review flows in a few days. Large organisations with many environments and thousands of makers should start with environments that hold finance, HR, email and identity connections, and use the platform's admin inventory to find shared connections first. Re-enable flows in rings: platform-team flows, then business-critical flows after owner confirmation, then everything else after review. Keep suspended copies until each re-enabled flow has run cleanly, so you can roll back.

Evidence and notification

Platform: audit logs, flow definitions and version history, run history with inputs and outputs where retained, sharing changes, connection creation and use.
Identity provider and SaaS apps: sign-in and token issuance for connection identities, consent grants, mailbox rules, sharing link creation.
Self-hosted: server images, database backups, reverse proxy logs.

Flows often move personal data. If personal data was accessed or sent out, GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to individuals; Article 34 requires telling individuals where the risk is likely to be high. NIS2 entities must send an early warning within 24 hours and an incident notification within 72 hours of becoming aware of a significant incident. Use the Data Breach Notification Checklist for other regimes.

Detection and measurement

Alert on: new flows with external destinations; email forwarding or file sharing actions created by flows; new custom connectors; connections with admin scopes; flows shared with everyone; admin role grants in the platform; token use by connection identities from unexpected networks.
Metrics: percentage of connections using dedicated service identities rather than personal accounts; number of shared connections; number of connections without an owner or unused for 90 days; percentage of environments covered by data policies; time to suspend all flows of a named maker in an exercise; platform audit log retention in days.

Common failure patterns

Resetting the password and stopping there. Flows and connections keep running with tokens that the reset did not touch.
Deleting the connection only in the platform. The grant stays valid at the SaaS app.
Missing the side effects. Forwarding rules and sharing links created by flows outlive the flows themselves.
Trusting the maker attribution. Embedded connections mean the logs name the maker even when someone else ran the app.
Restoring from a compromised export. Re-importing solutions that still contain attacker steps or plaintext connection strings.
No owner for the platform. Without a named platform team, nobody can suspend flows across the tenant quickly. See the Citizen Developer and Internal AI App Governance Guide.

Framework mapping

Activity	NIST CSF 2.0	NIST SP 800-53 Rev. 5
Triage and manage	RS.MA, RS.AN	IR-4 Incident Handling, IR-5 Incident Monitoring
Suspend flows, revoke connections	RS.MI	IA-5 Authenticator Management, AC-6 Least Privilege
Connection and flow inventory	ID.AM	CM-8 System Component Inventory
Restore flows from known-good versions	RC.RP	CM-2 Baseline Configuration, CP-10 System Recovery and Reconstitution
Identity and access for makers and connections	PR.AA	AC-6 Least Privilege
Logging and review	DE.CM	AU-6 Audit Record Review, Analysis, and Reporting, AU-9 Protection of Audit Information
Report	RS.MA	IR-6 Incident Reporting

Practitioner checklist

Keep a current inventory of connections with owner, target, scopes and sharing.
Know how to suspend every flow of a given maker or environment, and test it.
Document where each connection type is revoked at its issuer.
Send platform audit logs to your SIEM with longer retention than the platform's default.
Replace personal and shared connections with dedicated service identities for shared apps.
Restrict custom connectors and outbound HTTP steps to approved destinations.
Alert on flows that create forwarding rules or anonymous sharing links.
Patch self-hosted platforms quickly and keep management interfaces off the internet.
Remove orphaned and unused connections every quarter.

If your low-code and automation platform is compromised: contain flows, revoke connections and rebuild trust