SAP and ERP Compromise Response Playbook: Investigating and Containing Attacks on Business Critical Apps

When an attacker reaches an SAP or other ERP system, the incident is not only a server compromise: the same access can change vendor bank details, release payments, alter financial records and move through trusted RFC connections into every connected system. This template gives [Organisation] an ERP-specific playbook for suspected compromise of SAP NetWeaver (ABAP and Java), S/4HANA and comparable ERP platforms, including exploitation of internet-facing flaws such as CVE-2025-31324 and abuse of RFC, communication and service users. It sits beneath the general Incident Response Plan Template and adds what changes when the target runs finance, supply chain and payroll. It is written for SAP Basis, SAP security, incident response, finance controls and internal audit. Replace every [bracketed] placeholder and rehearse it with Basis and finance together before you need it.

How to use this template

• Run it alongside the main IR plan: declare the incident under the Incident Response Plan, then hand the ERP workstream to the SAP Incident Lead using sections 3 to 6 here.
• Two investigations at once: one technical (how they got in and what they ran), one business (what they changed in financial and master data). Both must finish before recovery is signed off.
• Preserve before you fix: no web shell is deleted, user locked out of existence or transport reverted until evidence is captured (section 3.5). Locking is fine; deleting is not.
• Keep offline copies: system landscape list (SIDs, hosts, instance numbers, clients), emergency user procedure, RFC destination inventory and finance contacts.
• Owner and review: [Head of SAP Basis] with [Head of Financial Controls], reviewed every [12] months and after each major upgrade or SAP Security Patch Day emergency note.

1. Scope and triggers

1.1 This playbook covers SAP ABAP and Java application servers, SAP HANA databases, SAP Web Dispatcher and SAProuter, connected SAP cloud services, and [other ERP platforms] in [production and non-production] landscapes. Cloud tenant issues in SAP BTP also use the SAP BTP Security Guide.

1.2 Triggers (any one opens a [SEV1] investigation):

1.3 CISA's Known Exploited Vulnerabilities catalogue lists, among others, CVE-2025-31324 (added 29 April 2025) and CVE-2025-42999 (added 15 May 2025) in SAP NetWeaver, both marked as known to be used in ransomware campaigns. Any system that was exposed and unpatched during the exploitation window is treated as potentially compromised until checked.

2. Roles and contacts

3. Detection and triage

3.1 First hour questions:

1. Which SIDs, clients and hosts are involved, and is any of them reachable from the internet (directly, via Web Dispatcher, or via a partner connection)?
2. Is the entry point a vulnerability (unpatched Java or ABAP component), a credential (stolen user, default or RFC user) or a supplier connection?
3. Has anything business-relevant changed: vendor bank data, payment runs, user authorisations, transports?
4. Do trusted RFC connections or stored RFC credentials lead from the affected system into others?
5. Is finance about to run payments (today's or tomorrow's payment run, payroll)?

3.2 Java stack exploitation checks (for CVE-2025-31324 and CVE-2025-42999): confirm whether the Visual Composer framework (VCFRAMEWORK) is installed (System Information, Components Info); confirm SAP Notes 3594142 and 3604119 are applied or the component is removed; search the irj/servlet_jsp/irj/root, irj/work and irj/work/sync directories under /usr/sap/<SID>/<instance>/j2ee/cluster/apps/sap.com/ for unrecognised .jsp, .java or .class files, including hidden files, as SAP Note 3596125 describes. Onapsis and Mandiant published an open-source compromise assessment scanner for this vulnerability; use it under change control on a copy where possible.

3.3 ABAP stack checks: review the Security Audit Log for logons by system and communication users, RFC logons from unusual hosts, failed logon bursts and critical transaction starts; review user and authorisation change documents for the incident window; list RFC destinations with stored credentials and trusted relationships; review gateway logs for unexpected registered or started programs. See the SAP NetWeaver and S/4HANA Basis Hardening Guide for the relevant gateway and audit settings.

3.4 Business data checks: vendor master changes (especially bank accounts) for the window; payment proposals and runs since the earliest suspicious event; manual journal entries by unusual users; new or changed customer credit limits; changes to payroll bank data. Finance Controls Lead signs off each check.

3.5 Evidence to preserve:

• Copies (with hashes) of any suspicious files from the irj directories and other web-accessible paths.
• Web Dispatcher, ICM and HTTP access logs; Java default traces and dev_* trace files in the instance work directory.
• Security Audit Log files, user and authorisation change documents, system log, gateway and RFC logs.
• Transport logs and the list of transports imported in the window.
• OS logs, EDR telemetry and, where feasible, memory and disk images of the application server host.
• Exports of vendor change reports, payment run lists and bank files sent in the window.

Store evidence outside the SAP landscape with restricted access and a chain-of-custody record. SAP logs can be overwritten by size or retention settings: copy them first.

4. Containment

4.1 Contain in this order, recording time and approver for each action:

1. Stop the money: Finance Controls Lead places a hold on outgoing payment runs and bank file transmission from the affected company codes until vendor bank changes in the window are verified with the vendor through a known contact. Contact banks to recall suspicious payments.
2. Cut the entry point: block the vulnerable path at Web Dispatcher, reverse proxy or WAF (for CVE-2025-31324, /developmentserver/metadatauploader), or remove internet exposure of the system entirely.
3. Isolate hosts with active web shells: restrict network access while preserving memory; do not shut down before forensics advises.
4. Lock, do not delete, suspicious users: lock users created or changed in the window; lock compromised dialog users; set default users (SAP*, DDIC, EARLYWATCH, TMSADM) to locked or verified passwords.
5. Close trust paths: disable or restrict trusted RFC relationships and RFC destinations with stored credentials from the affected system to others, and tighten gateway ACLs (reginfo, secinfo).
6. Freeze change: lock the transport route into production and set production clients to not modifiable, except for incident changes approved by the Incident Commander.

4.2 Decision point: if business operations require the system to keep running, the Incident Commander records the risk acceptance, the compensating monitoring in place and the review time. Taking finance offline is a business decision; leaving a web shell reachable is not an acceptable option.

5. Eradication

1. Apply the relevant SAP Security Notes (for this vulnerability family, 3594142 and the cumulative 3604119) or remove the vulnerable application, then verify the fix by retesting the path.
2. Remove web shells and other attacker files only after evidence capture, and check for hidden variants and additional deployed applications.
3. Rotate credentials: <sid>adm and service accounts, database users, secure store contents, RFC user passwords and certificates for SNC where exposure is possible, and any secrets on the host. Treat machine credentials as compromised if the host was. See the SAP Identity and Access Security Guide.
4. Remove unauthorised users, roles and profile assignments identified in section 3; review emergency access (firefighter) sessions in the window.
5. Reverse unauthorised transports and direct changes through controlled transports, with code review.
6. Check for persistence at OS level: scheduled jobs (SM36/SM37 background jobs and OS cron or scheduled tasks), modified start profiles and kernel files.

6. Recovery

1. Confirm with forensics that the entry point is closed and no persistence remains before reconnecting interfaces.
2. Reconcile business data: finance confirms vendor bank data, open payments and journals in the window; reverse fraudulent postings through normal accounting procedures with audit trail.
3. Restore from backup only where data integrity cannot be re-established by reconciliation, and agree the recovery point with finance (data after the restore point must be re-entered).
4. Release payment holds company code by company code, after four-eyes review of the payment proposal.
5. Re-enable RFC trust and interfaces one at a time with monitoring.
6. Run heightened monitoring for [30] days: alerts on the exploited path, dialog logons by technical users, vendor bank changes and transports to production.

7. Communication and notification

Legal owns every external notification. Do not discuss the incident on systems that may be compromised; use the out-of-band channel in the Incident Response Contact and Call Tree Template.

8. Post-incident review

• Hold the review within [10] working days with Basis, SAP security, finance, IR and audit.
• Record root cause, time from SAP Security Note release to patch, time to detect and time to contain.
• Track actions: patch cadence against SAP Security Patch Day, internet exposure of Java and ABAP services, removal of unused components, RFC user hardening, Security Audit Log coverage and forwarding to the SIEM, vendor bank change controls.
• Assess whether internal controls over financial reporting were affected and inform internal and external audit.
• Update this playbook and rehearse the changed sections.

Implementation guidance

• Prepare the logs before you need them: enable the Security Audit Log with filters for all users in critical clients, size retention for at least [90] days, and forward to the SIEM; retain Web Dispatcher and ICM HTTP logs. Without these, section 3 cannot be completed.
• Know your exposure: keep a list of every SAP service reachable from the internet or from partner networks, and patch KEV-listed SAP vulnerabilities on those first.
• Harden technical users: RFC and communication users should be of type System or Communication (no dialog logon), with minimal authorisations; alert on any dialog use.
• Finance controls are security controls: dual approval and call-back verification of vendor bank changes stop the most direct monetisation of an ERP compromise.
• Exercise: run a tabletop with Basis and finance on a scenario combining a Java web shell and a vendor bank change, at least annually.
• Framework anchors: NIST SP 800-53 Rev. 5 IR-4 Incident Handling, IR-6 Incident Reporting, AU-9 Protection of Audit Information and CM-3 Configuration Change Control; NIST CSF 2.0 RS.MA-01 and RS.AN-03.

Standards and references

• CISA: Known Exploited Vulnerabilities Catalog
• Onapsis: Active Exploitation of SAP Vulnerability CVE-2025-31324
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Web Shell
• MITRE ATT&CK: Financial Theft
• US SEC: Cybersecurity Risk Management and Incident Disclosure Rules

Related NHI Mgmt Group resources: SAP Identity and Access Security Guide · SAP NetWeaver and S/4HANA Basis Hardening Guide · SAP and ERP Security · Incident Response Guide