If your ITSM platform is compromised: containment, credential rotation and rebuild playbook

An IT service management platform holds the integration credentials, automation workflows and ticket history that let it reset passwords, grant access, approve changes and talk to customers, so an attacker inside it can act as your IT department. This playbook covers a compromise of the ITSM platform itself: the service desk tenant, its administrators, its integration accounts and tokens, its on-premises discovery and orchestration agents, and the workflows that provision access. It sets out how the incident shows up, triage questions, containment in priority order, which credentials to rotate and in what order, when to rebuild, the evidence to keep and when notification rules apply. It is vendor-neutral and written for service management owners, identity teams and incident responders. Hardening the platform before an incident is covered in the ServiceNow Security Guide and the SaaS Security Guide, and in Securing the ITSM platform itself; this page is about response.

Key takeaways

• Move response off the platform. If the ticketing system is compromised, the incident ticket, the change records and the on-call chat tied to it may be visible to the attacker, so run the response through an out-of-band channel.
• Integration accounts matter more than people. Accounts and OAuth clients that connect the platform to the identity provider, directory, cloud and monitoring tools often hold more privilege than any administrator, and they keep working after human passwords are reset.
• Automation is a weapon. Access request fulfilment, password reset workflows and orchestration agents let an attacker grant themselves access with a legitimate approval trail, so freeze them before investigating.
• Tickets hold secrets. Years of attachments, notes and knowledge articles contain passwords, API keys, identity documents and network diagrams; scope what was readable and rotate what was in it.
• Revoke tokens, not just passwords. Under RFC 7009, revoking a refresh token should invalidate access tokens from the same grant only where the server supports it, so confirm each integration's behaviour rather than assume it.

How the incident shows up

ITSM compromises often surface through a user or customer complaint, an unexpected access grant, or an alert in a connected system rather than in the platform itself. Initial access is usually a stolen administrator or agent credential (MITRE ATT&CK T1078 Valid Accounts), a stolen integration token (T1528 Steal Application Access Token), a flaw in an agent-facing feature, or a compromised service provider that operates the desk (T1199 Trusted Relationship).

Two live incidents show the pattern. In the Canvas Instructure Breach 2026, a support ticket carrying hidden script ran in an agent's session and gave the attacker a privileged token. In the Internet Archive Breach 2024, support platform API tokens that were not rotated after an earlier code theft let the attacker reach years of support tickets and send replies through the genuine account.

Triage questions

1. Which identity did it? A human administrator, a service desk agent, an integration user, an OAuth client or an orchestration agent? Each points to a different root cause and containment step.
2. Is the incident visible to the attacker? Assume the ticket queue, chat integrations and on-call rotas tied to the platform are being watched. The joint advisory on Scattered Spider (CISA AA23-320A) reports that actors search messaging and email for signs of the response and frequently join remediation calls.
3. What can the platform's integrations do? List every outbound connection: identity provider and directory provisioning, privileged access tools, cloud accounts, endpoint management, monitoring and chat. Note the credential type and its privileges.
4. Do on-premises agents run commands? Discovery and orchestration agents in the internal network usually hold domain, SSH, SNMP or hypervisor credentials. If the platform could instruct them, the internal network is in scope.
5. Which workflows grant access or reset credentials? Identify automated provisioning, group membership changes, password and MFA resets and approvals that skip a human.
6. What data was readable? Tickets, attachments, knowledge base, HR cases, customer records and stored credentials, and for how long.
7. Is the provider or a managed service partner involved? If the platform is SaaS or run by a partner, open the provider's security incident route now and agree who holds which logs.

Containment priorities

1. Start out-of-band coordination: move the response to a channel and case record outside the platform and outside any chat it integrates with. See the Out-of-Band Communications Plan Template.
2. Preserve logs: export platform audit, transaction, API and login logs and integration activity before changing configuration; SaaS retention can be short and some logs are only available through the provider.
3. Suspend compromised identities: disable the suspect accounts at the identity provider, revoke their sessions, and remove any local platform accounts that bypass SSO.
4. Freeze automation that grants access: pause automated fulfilment of access requests, password and MFA reset workflows, and group or role provisioning. Route urgent requests to a manual process with verification by a second channel. See the Help Desk Identity Verification Policy Template.
5. Stop on-premises agents: stop or isolate discovery and orchestration agents until their stored credentials are rotated and their job queue is reviewed.
6. Cut outbound integrations by risk: disable or revoke integrations with write access to identity, privileged access and cloud systems first, then read-only feeds. Accept the operational cost for the containment window.
7. Lock down outbound messaging: restrict outbound notifications and customer replies to templates, or pause them, if the attacker has used the platform to message people.

Credential rotation order

Rotate from the most powerful downstream credential to the least, and verify each one is invalid, not just replaced. The OAuth Security Best Current Practice (RFC 9700) recommends audience-restricted, least-privilege tokens; use the rebuild as the moment to apply it.

Use the Secrets Rotation Runbook Template for tracking and the OAuth Token Introspection and Revocation Guide for token behaviour. The Secrets in chat and tickets guide covers searching ticket data for credentials.

Eradication and rebuild

• Configuration review: compare server-side scripts, automation rules, scheduled jobs, workflows, inbound email actions, access control rules and SSO settings with the last known good configuration export. Remove anything without an owner and change record.
• Access granted during the window: list every account, group membership and role granted through the platform since the first attacker action, and reverse any that cannot be confirmed with the requester through a second channel.
• Agents and hosts: review jobs run by orchestration agents and treat hosts that received attacker commands as compromised endpoints; see How to Isolate a Compromised Endpoint.
• Records: check change, incident and problem records for tampering, using platform record history and exported copies; restore from provider backups where integrity is in doubt.
• Agent-facing content: where a malicious ticket, attachment or knowledge article was the entry point, remove it, check for others with the same pattern, and fix the rendering flaw class, not just the instance.

Rebuild or clean in place

• Clean in place: the usual choice for SaaS tenants, when the provider can confirm the platform itself was not breached, logs cover the whole window, and configuration can be compared with a known good export.
• Rebuild or restore: for self-hosted platforms where the attacker had server or database access, rebuild hosts from trusted images and restore configuration from a pre-incident backup that has been checked.
• Small organisations: with a few integrations, rotate everything in one window and accept a short service desk outage.
• Large or outsourced desks: stage reconnection of integrations by risk and confirm the managed service provider's own accounts and access paths are clean; see the Compromised MSP Playbook.

Recovery

1. Reconnect integrations one at a time with new credentials, least-privilege scopes and alerting on use from new IPs.
2. Restore automation with guardrails: privileged access grants and resets for administrators need a second approver and out-of-band verification.
3. Move admin to SSO only, with phishing-resistant MFA and no local accounts except monitored break-glass.
4. Reduce stored secrets: replace stored passwords for agents with vault retrieval or short-lived credentials, and enable secret detection on ticket and knowledge content.
5. Tell users what changed, including how the service desk will and will not contact them, to blunt follow-on phishing.

Detection and measurement

Evidence to preserve

Keep hashes and chain of custody; see the Evidence Handling and Chain of Custody Guide.

Notification triggers

• Personal data: service desks hold employee and often customer data. 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; a processor, such as a SaaS provider or outsourced desk, must notify the controller without undue delay.
• Customers and partners: contracts may set shorter notice; tell customers quickly if the platform was used to message them.
• Other regimes: NIS2, sector rules and securities disclosure may apply; see the Breach Notification Laws by Country Guide.

Common failure patterns

• Running the response in the compromised ticket queue, so the attacker reads every containment step.
• Resetting people but not integrations: service accounts and OAuth clients keep working. The Okta Support System Breach 2023 began with a service account credential, and the Cloudflare Thanksgiving Breach 2023 shows what follows when credentials are left unrotated after a related incident.
• Leaving automated fulfilment on, so the attacker's next request is approved and provisioned while you investigate.
• Forgetting on-premises agents, whose stored domain and SSH credentials give a path back into the internal network.
• Not searching ticket data for secrets, so credentials pasted by staff years ago stay live.

Framework mapping

ISO/IEC 20000-1:2018 sets service management system requirements; use its incident and change management processes, but run them outside the compromised tool until it is trusted again.

Where identity fits

An ITSM platform is a hub of non-human identities: integration users, OAuth clients, API keys, webhook secrets and agent credentials, plus workflows that act on human identities. Give each an owner, a scope and a rotation date before the incident, so this playbook becomes a list rather than a hunt. See the ServiceNow Integration Users and OAuth Security Guide and the Non-Human Identity (NHI) Guide.

Practitioner checklist

• An out-of-band response channel and case record exist and are tested.
• A single switch pauses automated access fulfilment and reset workflows.
• Every integration is inventoried with owner, scope, credential type and rotation steps.
• On-premises agents retrieve credentials from a vault and can be stopped centrally.
• Platform audit and API logs stream to a SIEM with retention beyond the provider default.
• Administrator access is SSO only with phishing-resistant MFA, with break-glass accounts monitored.
• Secret detection runs on new tickets, attachments and knowledge articles.
• The provider's security contact and log request process are documented.
• Privileged resets and access grants require a second approver and out-of-band verification.

Standards and references

• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• CISA and FBI: Scattered Spider advisory AA23-320A
• IETF: RFC 7009 OAuth 2.0 Token Revocation
• IETF: RFC 9700 Best Current Practice for OAuth 2.0 Security
• ISO: ISO/IEC 20000-1:2018 Service management system requirements
• GDPR: Article 33 Notification of a personal data breach to the supervisory authority
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: ServiceNow Security Guide, Help Desk Social Engineering Incident Playbook, If your CMDB and asset inventory is compromised, Third-Party Incident Response Playbook, Identity Incident Response Playbook.