How to Execute an SAP Incident Response Strategy: The Step-by-Step Playbook

Most Security Operations Centers (SOCs) operate with a dangerous blind spot. While they have mature playbooks for isolating infected endpoints or blocking malicious IPs at the firewall, they often lack a specific protocol for the organization’s most critical asset: the ERP system.

This gap is existential. You cannot simply “pull the plug” on a production SAP system without freezing supply chains, halting financial closes, and costing the business millions in downtime. According to industry benchmarks, unplanned downtime for critical applications costs enterprise organizations between $500,000 and $1 million per hour.

To avoid this scenario, security leaders must move beyond generic IT protocols and adopt a specialized SAP Threat Intelligence strategy. This guide provides a procedural, step-by-step playbook for isolating an attacker within the SAP application layer to neutralize the threat without disrupting business continuity.

Phase 1: Preparation (The Pre-Breach Checklist)

Incident response begins long before the alert triggers; it requires pre-authorized “Break-Glass” access and granular logging visibility that standard default configurations do not provide.

If you wait until a breach occurs to request administrative access, you have already lost. The attacker will move laterally while you are waiting for approval workflows. Ensure the following three controls are established immediately:

1. Establish “Break-Glass” Access

Standard administrative accounts are often the first targets in an identity-based attack. If your Identity Provider (IdP) is compromised, Single Sign-On (SSO) may become unavailable or untrustworthy.

• Action: Create a dedicated “Firefighter” account (e.g., FF_ADMIN) with SAP_ALL privileges.
• Constraint: This account must be excluded from SSO/LDAP and secured with a complex, static password stored in a physical or digital vault.
• Policy: Define a “Rules of Engagement” document that pre-authorizes the use of this ID during a confirmed Severity-1 incident.

2. Enable Granular Logging

Default SAP logging is often insufficient for forensic analysis. To catch sophisticated threat actors, you must enable specific logs that capture the “context” of user behavior.

• Action: Verify that the Security Audit Log (SM20) is active and configured to capture all critical events, including successful and unsuccessful logons, transaction starts, and report executions.
• Action: Enable Gateway Logging (SMGW) to monitor external RFC connections. This is critical for detecting attacks that bypass the user interface, such as the 10KBLAZE exploit.
• Action: Ensure “Read Access Logging” (RAL) is active for sensitive data fields (e.g., Credit Card Numbers, HR Data) to determine exactly what data was viewed, not just what was changed.

3. Deploy a Forensic Workstation

• Action: Pre-configure a dedicated “Clean PC” for the incident response team. This machine should have the SAP GUI installed, network access to the SAP management subnet, and forensic analysis tools pre-loaded. It must be kept offline until needed to ensure it remains uncompromised.

Phase 2: Detection & Triage (Is It Real?)

The primary goal of triage is to distinguish between a legitimate “Basis” administrative task and a true threat by correlating the user identity with the connection context.

In complex SAP environments, “abnormal” behavior is often just a Basis administrator troubleshooting a performance issue. Reacting to false positives creates “alert fatigue” and disrupts operations. To validate an alert, execute the following triage steps:

Step 1: Analyze the User Type

Differentiate between Dialog Users (humans) and System Users (applications).

• The Check: Inspect the user type in the alert metadata.
• The Red Flag: If a System User (such as DDIC, SAP*, or TMSADM) is logging in via the SAP GUI (a “Dialog” logon), this is a critical Indicator of Compromise (IoC). These accounts are hard-coded for background processing and should never initiate an interactive session.

Step 2: Check the Context (The “Impossible Travel” Test)

Correlate the SAP application log with your network/VPN logs to validate the session origin.

• The Check: Use transaction SM04 or your Threat Detection Platform to view the terminal ID and IP address of the suspicious session.
• The Red Flag: Does the IP address match a known VPN node? Is the user logging in from a geolocation they have never used before?
• The Context: If a user logs in from “Home” (VPN) and simultaneously logs in from “Office” (LAN), this concurrent session often indicates credential theft.

Step 3: Transaction Analysis (The Kill Chain)

Sophisticated attackers use specific transaction codes (T-codes) to escalate privileges or steal data. Look for the execution of these high-risk transactions:

• SM49 / SM69: Used to execute Operating System commands directly from SAP. This is a common technique for lateral movement from the application to the OS level.
• SE16 / SE16N: Used to view raw table data. Attackers use this to dump the USR02 table (password hashes) or customer master data.
• SE80 / SE38: The ABAP development workbench. Usage by a non-developer account in a production system indicates an attempt to inject malicious code (e.g., a webshell).

Phase 3: Containment (The “Soft Kill”)

The objective of containment is to isolate the attacker’s access and sever their connection to the system without taking the entire SAP landscape offline.

“Pulling the plug” (shutting down the SAP application server) is rarely the correct first response. A hard shutdown destroys data residing in RAM, which holds critical evidence needed for forensics, and causes immediate financial loss. Instead, execute a surgical isolation:

Step 1: Identity Isolation (Lock, Don’t Delete)

Immediate revocation of access is the priority.

• The Action: Use transaction SU01 (User Maintenance) to select the compromised User ID and click the “Lock” icon.
• The Critical Detail: Do not delete the user account. Deleting the ID wipes the change logs associated with that user, effectively destroying the audit trail of what the attacker touched. You need this history for the legal team.

Step 2: Session Termination

Locking a user prevents new logins, but it does not stop an active session.

• The Action: Navigate to transaction SM04 (User List). Locate the specific terminal session associated with the compromised ID and select “Log Off User” / “End Session.”
• The Verification: Refresh the SM04 list to confirm the line item disappears. If the session persists, the attacker may be using a scripted “keep-alive” mechanism; proceed to network isolation.

Step 3: Network & Interface Blocking

If the attack is originating from an external API or RFC connection rather than a GUI login, user locking may be insufficient.

• The Action: Use the SAP Gateway Monitor (SMGW) to identify the external program ID or IP address.
• The Action: Update the secinfo and reginfo Access Control Lists (ACLs) to explicitly deny traffic from that specific IP range while allowing internal application servers to communicate.
• The Tooling: In modern environments, Unified Connectivity (UCON) can be used to block specific RFC function modules (e.g., RFC_READ_TABLE) without severing the entire connection.

Phase 4: Eradication & Forensics (Removing Persistence)

Attackers rarely rely on a single point of entry; they establish “persistence” mechanisms (backdoors, scheduled jobs, or malicious code) to ensure they can return if the original account is locked.

Once the active threat is contained, you must hunt for these hidden entry points before declaring the system clean.

Step 1: The “Ghost User” Check

Attackers often create backup administrator accounts immediately after gaining access.

• The Action: Audit the USR02 table (Logon Data) for any users created or modified within 24 hours of the initial alert.
• The Red Flag: Look for users with the “System” type that have been assigned the SAP_ALL profile. These are often named to look like legitimate service accounts (e.g., SAP_SUPPORT_01) to evade detection.

Step 2: The “Code” Check (Webshells)

In SAP, “malware” is often just ABAP code. Attackers inject “webshells” (small programs that allow them to execute OS commands via a web browser) into the system.

• The Action: Scan for any ABAP reports or “Z-programs” created or modified in the last 24 hours.
• The Tooling: Manual review of code is slow and error-prone. Use Onapsis Control to automatically scan custom code repositories for known webshell signatures (e.g., COMMAND injection or CALL ‘SYSTEM’).

Step 3: The Transport Audit

If the attacker gained development access, they may have “transported” their malicious code from Development to Production, making it look like a legitimate change.

• The Action: Review the Transport Management System (STMS) for any transport requests released during the incident window.
• The Check: Verify the “Owner” of the transport. If a transport was released by the compromised user ID, it must be rolled back immediately.

Step 4: The Background Job Check

Attackers often schedule “time bombs” to execute malicious programs hours or days after they have been detected.

• The Action: Use transaction SM37 (Simple Job Selection) to review all background jobs scheduled to run in the next 7 days.
• The Red Flag: Look for jobs running under high-privilege users (like SAP* or DDIC) that execute external OS commands (programs like RSCOMMAND or RSBDCOS0).
• The Verification: Cancel any unknown jobs immediately and trace the user ID that scheduled them.

Phase 5: Root Cause Analysis

Restoring operations is not just about unlocking users. It requires proving that the vulnerability is closed and the system is clean.

You cannot declare the incident resolved until you have identified the “Patient Zero” entry point. If you don’t understand the root cause and patch the hole, the attacker will simply walk back in.

Step 1: Patch the Entry Point

Forensics should reveal how the attacker gained access. Was it a weak password? A known exploit like ICMAD? Or a missing patch?

• The Action: Run a full Vulnerability Assessment against the specific application server to identify missing Security Notes.
• The Fix: Apply the relevant SAP Security Note or implement the workaround immediately. Do not wait for the next maintenance window.

Step 2: Credential Rotation

Assume all administrative credentials used during the incident window are compromised.

• The Action: Reset passwords for all SAP_ALL users, including the Firefighter ID used by the Incident Response team.
• The Action: If the attack involved an external interface, regenerate the API keys and technical user passwords associated with that connection.

Step 3: The “All Clear” Validation

Define specific criteria for returning to standard operations.

• The Check: Monitor the specific Indicator of Compromise (IoC) for 24 hours. For example, if the attack came from IP 1.2.3.4, ensure zero connection attempts are recorded in the Gateway Log (SMGW) for a full day.
• The Check: Verify that no new “Z-programs” or users have been created since the containment phase.

Common Pitfalls to Avoid

In the heat of a breach, panic often leads to mistakes that destroy evidence or worsen the outage.

Avoid these three common errors during your response:

1. The “Reboot” Reflex: Do not restart the SAP server. Rebooting destroys the contents of the RAM, which holds critical forensic evidence like active user sessions and uncommitted data. It also alerts the attacker that they have been detected.
2. The “Silo” Problem: Incident Response often fails because the SOC team (who sees the alert) and the Basis team (who owns the system) do not speak the same language. The SOC sees “Network Traffic,” while Basis sees “RFC Calls.” Bridge this gap by having a Basis engineer permanently assigned to the IR team.
3. The “Delete” Mistake: Never delete a compromised user or a malicious file. Always “Lock” or “Quarantine” instead. Deleting artifacts breaks the chain of custody required for legal action or cyber insurance claims.

Conclusion

An SAP breach does not have to be a catastrophe. With a defined Incident Response Strategy, you can turn a potential disaster into a managed event.

The difference between a minor disruption and a headline-making outage is rarely the severity of the attack. It is the speed and precision of the response. By preparing your “Break-Glass” accounts, enabling granular logging, and practicing this playbook, you ensure your team is ready when the alarm sounds.

Next Step: Is your team ready to defend your most critical assets? Don’t wait for a breach to test your readiness. Contact Us to speak with an SAP security expert, or Request a Demo to see how the Onapsis Platform can automate your incident response.

Frequently Asked Questions (FAQ)

Why can’t we just shut down the SAP server during an attack? 

Shutting down an SAP production server (“pulling the plug”) destroys data residing in the RAM, which is critical for forensic analysis. It also halts core business processes—like shipping, billing, and payroll—potentially costing the organization millions of dollars per hour. The goal of SAP Incident Response is to isolate the threat (the “Soft Kill”) while keeping the business running.

What is the most important log source for SAP forensics? 

The Security Audit Log (SM20) is the primary source for user behavior (logins, transaction starts). However, for external attacks that bypass the user interface, the Gateway Log (SMGW) is critical for identifying malicious RFC connections. Both must be enabled and forwarded to your SIEM for effective detection.

How does SAP Incident Response differ from standard IT Incident Response? 

Standard IT response often focuses on endpoints (laptops) and relies on re-imaging infected machines. SAP response focuses on the application layer. You cannot simply “wipe and reload” an ERP system without significant data loss. SAP IR requires understanding business logic (e.g., “Why is this user modifying a vendor bank account?”) rather than just malware signatures.

Do we need a dedicated “Firefighter” ID if we use Single Sign-On (SSO)? 

Yes. If an attacker compromises your Identity Provider (IdP), your SSO mechanism becomes untrustworthy or unavailable. You must have a pre-created local administrative account (e.g., FF_ADMIN) with a complex password stored in a secure vault to ensure you can access the system during an identity crisis.

How often should we test our SAP Incident Response plan? 

You should conduct a tabletop exercise specifically for SAP at least annually. Additionally, you should re-test your “Break-Glass” procedures and log visibility whenever there is a major infrastructure change, such as migrating to SAP S/4HANA or moving to the cloud (RISE with SAP).