How to Investigate an SAP Security Incident Step by Step

1. Initial Alert Triage and Verification

The first minutes of an SAP security investigation determine whether the incident can be contained or spirals into a full breach. Begin by verifying that the alert is genuine, not a false positive triggered by scheduled batch jobs, transport imports, or legitimate administrative activity.

Confirm the Alert Source and Context

Identify which monitoring layer generated the alert: SAP security audit log, ABAP dump analysis, table change logging, RFC call monitoring, SIEM correlation rule, or custom ABAP detection program. Each source carries different reliability and context. For example, an RFC call from an unknown external IP address to function module RFC_ABAP_INSTALL_AND_RUN carries far higher severity than a failed login from an unlicensed workstation.

Check the following immediately:

• Timestamp and time zone — correlate against known batch windows and transport schedules
• User ID and client — determine if the user is a named administrator, service account, or terminated employee
• Transaction code or program name — verify that the executed action is consistent with the user's job role
• IP address and terminal — cross-reference against authorized network segments and known jump boxes

Classify Incident Severity

Use a standardized classification matrix to prioritize next steps. A common enterprise framework maps severity across three dimensions:

For critical and high-severity incidents, immediately escalate to the SAP Basis team, IT security operations, and the designated incident response lead. Document every decision and timestamp in an incident tracking system for audit trail completeness.

2. Evidence Preservation and Log Collection

Preserve all relevant SAP and infrastructure logs before any remediation steps. The order of collection matters: collect volatile evidence first (active session data, memory-based artifacts), then persistent evidence (database logs, audit files, transport records).

Critical SAP Log Sources

Collect and preserve the following logs in their original format:

• SAP Security Audit Log (SM19/SM20) — contains all auditable events including RFC calls, transaction starts, and authorization failures
• Table Change Logging (SCU3/RsBDC) — captures before/after values for critical tables such as USR02, USR01, AGR_*
• ABAP Dump Log (ST22) — records runtime errors that may indicate attempted buffer overflow, injection, or privilege escalation
• RFC Logging (SMGW, SMQR, SMQS) — tracks all remote function call activity including gateway connections and queue status
• Transport Logs (STMS) — reveals unauthorized transport imports, especially for authorization objects or custom code
• SAP System Logs (SM21) — provides system-level error messages and kernel activity
• Work Process Logs (SM50/SM66) — captures active processes at the time of the incident, useful for identifying parallel sessions

Infrastructure and Network Logs

SAP incidents rarely exist in isolation. Correlate against:

• Active Directory or IdP authentication logs for the user account in question
• Firewall and proxy logs showing outbound connections from the SAP application server
• Database audit logs (HANA audit trail, Oracle Fine-Grained Auditing, DB2 audit facility)
• SIEM correlation records if the SAP environment feeds into a centralized security platform — this is where solutions like top 10 SIEM tools become critical for cross-platform visibility

When collecting evidence, capture the complete raw log files — not summaries or filtered views. Take cryptographic hashes (SHA-256) of each original file to establish chain of custody. Store preserved evidence on write-once media or a dedicated forensic server with restricted access.

3. Identifying the Compromised User or Account

Once evidence is preserved, shift focus to the primary actor. Determine whether the incident involved a compromised legitimate account, a malicious insider using their own credentials, or unauthorized external access through RFC or service interfaces.

Analyze User Master Records and Authorizations

Check the user master record (SU01) for recent unauthorized modifications. Pay particular attention to:

• Last login timestamp and IP — compare against the user's normal geographic and network patterns
• Profile assignments — look for recently added roles or profiles that grant critical access such as SAP_ALL, SAP_NEW, or S_DEVELOP
• Password change history — a recent forced password reset followed by unusual activity suggests account takeover
• Lock status — attackers often unlock previously disabled accounts to avoid detection
• Multiple logins — simultaneous sessions from different IPs indicate credential sharing or session hijacking

Review Authorization Trace and Activity Log

Run an authorization trace (SU53) for the user to identify which objects they accessed during the incident window. Cross-reference with the security audit log (SM20) filtered by the user ID and time range. Look for patterns that indicate SoD violations, such as a user who both creates purchase orders and processes payments — a classic combination exploited in procurement fraud.

For service accounts and RFC users, examine the RFC destination configuration (SM59) and the communication channel that triggered the incident. Attackers frequently abuse RFC destinations that use stored credentials with overly broad permissions.

4. Reconstructing the Attack Path

With the actor identified, reconstruct the full attack path — the sequence of actions, transactions, and system calls the attacker executed. This step determines the scope of data exposure, identifies lateral movement within SAP systems, and uncovers persistence mechanisms.

Trace Transaction and Program Execution

Using SAP security audit log entries, build a chronological timeline of all transactions and ABAP programs executed by the actor. Key artifacts to map include:

• SM19/SM20 audit entries — each entry records the transaction code, program name, timestamp, and terminal
• Table change logs — reveal which data records were created, deleted, or modified
• ABAP debugger logs — if the attacker used SE80 or SE38 to debug and modify code, traces remain in the kernel
• Spool and output logs — may show unauthorized report printing or data extraction via SAPscript/SmartForms

Identify Lateral Movement and Persistence

Attackers who compromise one SAP client often move laterally to others through RFC trust relationships or shared user IDs. Check:

• RFC connections between systems (SM59) for recently created or modified destinations
• Trusted RFC logon configurations that allow passwordless cross-system access
• Background jobs (SM37) with the actor's user ID that may contain malicious ABAP code
• Custom ABAP code in Z-programs that was imported via transport without proper approvals

Persistence mechanisms common in SAP breaches include hidden RFC destinations, modified user exits, BAdI implementations, and scheduled batch jobs that reactivate disabled users at regular intervals. For a deeper technical breakdown of how these techniques bypass traditional controls, see the analysis of weaknesses of SIEM and how to overcome them in SAP-specific detection contexts.

Assess Data Exposure Scope

Based on the reconstructed attack path, classify the types of data the attacker accessed or exfiltrated:

5. Containment and Rapid Remediation

Containment aims to stop active harm while preserving the ability to continue forensic analysis. Prioritize actions that block the attacker without destroying evidence or triggering automated failover that might obscure the investigation.

Immediate Containment Measures

Execute the following in order of least to most disruptive:

1. Lock the compromised user account(s) via SU01 (lock status) and verify propagation across connected systems
2. Block the source IP address(es) at the perimeter firewall and SAP router (saprouter) level
3. Revoke recently added authorization profiles by reversing transport requests or direct role modifications
4. Disable RFC destinations identified as part of the attack path — do not delete them until forensic analysis is complete
5. Stop malicious background jobs via SM37 and document the job name, creator, and scheduled recurrence
6. Deactivate critical function modules used in the attack (e.g., RFC_ABAP_INSTALL_AND_RUN, RFC_GET_ACCESS_KEY) if they are not required for business operations

If the attacker compromised a highly privileged account (like SAP_ALL), consider isolating the entire system from the network while preserving running processes for analysis. In extreme cases — such as a ransomware deployment within the SAP kernel — a controlled shutdown may be necessary, but only after capturing memory dumps of all work processes.

Temporary Rule Deployment

While containment actions stabilize the environment, deploy temporary detection rules to catch any recurrence. Focus on:

• Monitoring for reactivation of the locked user IDs
• Alerting on any new outbound RFC connections to unrecognized IP ranges
• Watching for the same function module calls that triggered the initial incident
• Auditing all transport imports in real time until the investigation concludes

6. Root Cause Analysis

Root cause analysis answers the central question: how did the attacker achieve initial access? Without identifying the root cause, any remediation leaves the same vector open for exploitation.

Common SAP Access Vectors

Investigate each potential entry point methodically:

• Weak password or default credential — check for SAP* and DDIC accounts still using factory defaults, service accounts with simple passwords, or users without password complexity enforcement
• Unsecured RFC interfaces — determine if the attacker exploited an RFC destination with stored credentials that never expire or are shared across environments
• Missing security audit log activation — verify that the security audit log was active on all relevant clients and that the audit level was set to capture critical events
• Unpatched ABAP vulnerability — cross-reference the SAP Security Notes released in the past 12 months against the system's support package level and note implementation status
• Compromised third-party integration — examine connectors for middleware, portals, or cloud integration platforms that have elevated SAP privileges
• Phishing or credential theft — review email logs, web proxies, and endpoint detection systems for evidence that SAP user credentials were harvested

Address Segregation of Duties Breakdown

Many SAP security incidents succeed because users hold incompatible authorizations that allow them to execute both an action and the verification of that action without oversight. Use an SoD analysis tool to scan for critical conflict combinations that were exploited in the incident. Common high-risk combinations include:

• Create vendor + Post payment
• Create purchase order + Goods receipt
• Change pricing conditions + Release sales order
• Financial posting + Bank reconciliation

For a comprehensive approach to automating these checks through GRC processes, refer to the top 10 compliance automation tools that integrate with SAP authorization frameworks.

7. Remediation and System Hardening

With the root cause identified, execute permanent remediation. This phase closes the exploited vulnerability, removes unauthorized modifications, and strengthens defenses against repeat attacks.

Patch and Configure

Implement the following in priority order:

• Apply relevant SAP Security Notes from the corresponding month's Patch Day — prioritize notes rated with CVSS 9.0 or higher
• Enforce password policies: minimum length of 12 characters, complexity requirements, periodic rotation for all accounts including service and RFC users
• Activate or raise the security audit log level on all production and sensitive non-production clients
• Reconfigure RFC destination security — remove trust relationships that allow passwordless access, restrict RFC destinations by source IP, and enforce logon tickets only with valid signatures
• Remove obsolete user IDs, especially generic accounts shared across teams
• Hardened SAP router configuration: restrict allowed RFC calls to whitelisted function modules only

Cleanse System of Backdoors

Attackers often leave multiple persistence mechanisms. Conduct a targeted sweep for:

• Unauthorized Z-programs and includes (SE80/SE38)
• Modified user exits and BAdI implementations (SE19/CMOD)
• Hidden background jobs with obfuscated descriptions (SM37)
• Suspicious entries in table TSTC (transaction code-to-program mapping)
• Modified variant values in SHD0 (transaction variants)
• Foreign entries in RFC destination table RFCDES (SM59)

Remediate Segregation of Duties Conflicts

Deploy a remediation plan that reduces SoD conflicts without blocking legitimate business processes. This may involve splitting critical roles, introducing approval workflows for sensitive transactions, or implementing transaction-level firewalls (such as SAP's Critical Transaction Monitoring or a third-party equivalent like CyberSilo SAP Guardian's Authorization Firewall module).

8. Post-Incident Review and Process Improvement

The final phase transforms the incident into systemic improvement. Conduct a formal post-incident review (PIR) within 30 days of containment, involving SAP Basis, security, compliance, and audit teams.

Key Questions for the Review

• Why did the existing detection controls not catch the incident earlier in the kill chain?
• Was the response process (communication, escalation, evidence handling) followed correctly?
• Are there other systems in the SAP landscape that share the same vulnerability pattern?
• Did the monitoring stack provide sufficient context to expedite the investigation? If gaps existed, consider whether the current technology adequately covers SAP-specific threats — many organizations find that general SIEM platforms lack the SAP semantic context needed for effective investigation. The SIEM platforms with built-in threat intelligence article provides a comparison of capabilities that complement SAP monitoring.
• What changes to policies, role design, or system configuration will prevent similar incidents?

Update Incident Response Runbooks

Document the specific steps taken during this investigation and update the SAP-specific incident response runbook. Include:

• Precise log sources to collect for each type of SAP incident
• Command references for extracting evidence from SAP system tables directly (e.g., SELECT * FROM CDHDR, CDPOS for change document analysis)
• Contact escalation tree for SAP-specific tools and vendor support
• Checklist for evidence chain-of-custody documentation

As the SAP threat landscape evolves — particularly with increased adoption of SAP BTP and cloud-based integration — organizations should periodically reassess their detection posture. Newer approaches that combine generative AI with security operations, as covered in the guide to platforms combining AI with SIEM and SOAR, are proving effective at identifying subtle attack patterns that traditional rule-based detection misses.

The Role of Specialized Monitoring in SAP Incident Investigation

Throughout this investigation process, one factor consistently determines success or failure: the quality and granularity of available monitoring data. SAP log data is extraordinarily rich when properly configured — but also extraordinarily large and complex to analyze without dedicated tools. Organizations that rely solely on generic SIEM platforms often miss context that is obvious to an SAP-native monitoring solution.

Dedicated SAP security monitoring platforms like CyberSilo SAP Guardian address these challenges by providing:

• Pre-built detection rules mapped to the MITRE ATT&CK for SAP framework and SAP security baseline recommendations
• Automated log correlation across SAP ERP, S/4HANA, and BTP environments without requiring complex SIEM parsing
• Role-level forensics that map suspicious activity directly to authorization objects, roles, and SoD conflicts
• Audit-ready evidence packages with chain-of-custody documentation for SOX, GDPR, and PCI DSS compliance
• Real-time alerting with severity classification based on business context — distinguishing between a true exploitation attempt and a legitimate transport import