Data Exfiltration, Persistence & Business Impact

Once an attacker holds an authenticated foothold (any of the initial-access techniques cataloged elsewhere in this playbook) or an OS-level shell as <sid>adm, the same small set of SAP-native primitives repeats across engagements to turn access into impact: bulk table reads and file-transfer objects for exfiltration, backdoored transports and privileged-user creation for persistence, and a predictable set of business-critical tables that turn “we have RFC access” into board-room-language business impact. This page indexes those end-states and cross-links the primitive-level pages elsewhere in this playbook rather than re-describing techniques already documented there.

Anti-forensics (Security Audit Log suppression, table-change-log purging) is a real capability class attackers use to blind detection after the fact - it is documented on this page for detection and impact framing only; deployment mechanics are intentionally not reproduced (see the Anti-Forensics section below).

Post-exploitation activity converts an authenticated foothold into full-scope compromise: confidentiality (bulk PII/financial/IP exfiltration), integrity (backdoored transports, privileged-user creation, business-data tampering), and availability (production-order/planned-order sabotage potential) are all reachable from the same small set of primitives below, typically without any additional vulnerability - only the authorizations the compromised credential or OS foothold already carries.

• Table dump via RFC - RFC_READ_TABLE (or the SOAP-RFC/XBP-report equivalents) against any table the credential’s S_TABU_DIS/S_TABU_NAM scope reaches; see Critical RFC-Enabled Function Modules for the full technique, gating authorizations, and detection signature. Remote ABAP Report Execution via XBP documents a stealthier RFC-landscape-discovery route (RSRFCCHK) that bypasses RFC_READ_TABLE/S_TABU_DIS restrictions entirely.
• File-transfer objects - client- and server-side file read/write primitives reachable from ABAP: transaction AL11/AL11_old and OPEN DATASET FOR INPUT for server-side reads, CL_GUI_FRONTEND_SERVICES=>GUI_DOWNLOAD/GUI_UPLOAD and transaction CG3Z/report RC1TCG3Z for SAP-GUI-side file transfer, function modules C13Z_FILE_DOWNLOAD_ASCII/C13Z_FILE_DOWNLOAD_BINARY/C13Z_FILE_UPLOAD_BINARY. See Accessing filesystem (read), Accessing filesystem (write), and Network File Access for the full technique set, gated by S_DATASET/S_PATH.
• Secure Store extraction - RSECTAB/SSFS credential material, not business data, but the standard precursor to landscape-wide lateral pivoting once exfiltrated; see Decrypting SAP Secure Storage.

• Backdoored transports - upload a pre-built transport (one cofile + one matching datafile) via an OS-exec channel, register it with tp addtobuffer, and import directly with unconditional-mode flags (tp import ... U1268), completely bypassing STMS, QA-approval workflow, and transport-authorization objects (S_TRANSPRT, S_CTS_ADMI). SAPMAP automates the delivery/import end-to-end (modules/exploitation/sap_transport_import.py) over either the unauthenticated Gateway SAPXPG channel or authenticated SXPG_STEP_XPG_START; the upstream “build the malicious transport” step is Transport Creation, the import itself is Import a malicious transport. This is not a CVE - direct tp/R3trans manipulation bypassing the QA-approval procedural control is documented, named SAP security literature (“command-line exploits”).
• Privileged user creation - BAPI_USER_CREATE1 -> BAPI_USER_PROFILES_ASSIGN(SAP_ALL) -> BAPI_TRANSACTION_COMMIT in one RFC round trip; see Critical RFC-Enabled Function Modules.
• Virtual/hardcoded SAP* - a time-limited, in-memory super-user with no USR02 row and no SU01 visibility (kernel ≥ 790, via dpmon), or the classic hardcoded fallback; see Hardcoded and Virtual Super-User SAP* for both variants and their detection signatures.
• SSO trust-list tampering - adding an attacker-controlled certificate to STRUSTSSO2 (or failing to prune a stolen-PSE-issued certificate after a suspected compromise) is a durable, easy-to-overlook persistence path parallel to the trust-list review already called out in MYSAPSSO2 ticket forgery mitigation - most incident response reviews role collections and user lists, far fewer review the trust-configuration/certificate list itself.

The following table-level read scenarios are what turns “we have RFC access as user X” into a report-ready business-impact statement - every scenario is a read-only RFC_READ_TABLE call against a table the credential already has some authorized access to (no separate exploit); the technique itself is Critical RFC-Enabled Function Modules, this list is the “so what” framing:

Note

A cross-platform analog exists for NetWeaver Java (component-detection-driven rather than table-read-driven - PI/PO message-tampering potential, NWDI/CTS+ supply-chain injection into production ABAP, HR ESS/MSS PII, KMC document-repository exposure, a combined-evidence Portal+SSO+UME availability-outage scenario). No dedicated NetWeaver Java business-impact page exists yet in this playbook.

Attacker tooling in this space (audit-log suppression, table-change-log purging) is documented here for detection and impact framing only - deployment mechanics are intentionally not reproduced, consistent with this playbook’s handling of unpatched/high-sensitivity primitives.

• Security Audit Log suppression - a class of technique that intercepts the Security Audit Log’s write paths at the OS/kernel-process level (requiring an existing OS shell as <sid>adm and a permissive kernel.yama.ptrace_scope) so that logon/transaction/table-access events matching an attacker-chosen filter are silently dropped before they reach the .AUD file, the database, or an SIEM/threat-detection forwarder - simultaneously across all three sinks, for the duration the suppression stays active. This is not a 0-day: it requires an OS-level foothold that a hardened SAP host should already be preventing at the perimeter, and its reliability is kernel-build-dependent (some modern kernel builds using archive-interface audit recording route events through a code path the classic suppression point doesn’t reach - a real detection gap defenders can exploit if their monitoring covers that path).
• DBTABLOG post-hoc purge - a class of technique that lets table-change logging proceed normally, then deletes the specific DBTABLOG rows an attacker’s own actions wrote, filtered by a captured LOGDATE+LOGTIME baseline (DBTABLOG is delivery class L - a log table itself not registered for change logging, so the deletes don’t recurse) rather than blocking the kernel’s logging path outright (which would require dictionary-level mutation, is loud, and is transport-tracked).

• Restrict S_TABU_DIS/S_TABU_NAM to the minimum role population per business-data domain (HR, finance, vendor/customer master) - the actual control point behind every business-impact scenario above.
• Enable table-access logging (RSAU_CONFIG) on the highest-value tables (PA0008, LFBK, USR02, KNA1) independent of any specific tool’s existence.
• Restrict RFCDES read access - anyone who can read it can enumerate stored-credential destinations landscape-wide.
• See Import a malicious transport, Critical RFC-Enabled Function Modules, and Hardcoded and Virtual Super-User SAP* for persistence-specific mitigations.
• Keep STRUSTSSO2 pruned and reviewed as part of every incident-response and periodic access review, not only role collections and user lists.
• Anti-forensics: set kernel.yama.ptrace_scope ≥ 2 (admin-only ptrace) on SAP application-server hosts; forward the Security Audit Log to an independent, near-real-time destination (SAP Enterprise Threat Detection or an external SIEM) so host-local suppression cannot retroactively affect already-shipped events - suppression only blocks writes before they leave the host; deploy host EDR/auditd monitoring for PTRACE_ATTACH against disp+work/kernel-worker processes; restrict RFC_ABAP_INSTALL_AND_RUN/S_DEVELOP (the standard delivery channel for both the audit-suppression hook and the DBTABLOG purge) to genuine developer/service accounts.

• Table-dump pattern: a fixed, predictable table set (T000, PA0002/PA0008, LFA1/LFBK, EKKO/EKPO, USR02/AGR_USERS, KNA1, MARA/MAKT, VBAK, AUFK/PLAF, RFCDES) read in rapid, fixed sequence from one RFC session is a strong automated-business-impact-scan signature, distinct from ad-hoc SE16N browsing by a real business user - correlate via ST05/gateway logging.
• File-transfer: see Accessing filesystem (read) and Accessing filesystem (write) Mitigation/Detection guidance.
• Backdoored transports: tp/R3trans execution from a non-interactive parent process (sapxpg/disp+work, an RFC session) rather than an admin’s interactive shell/scheduled job; a chunked binary-write pattern immediately followed by tp addtobuffer/tp import from the same session.
• Privileged-user creation: any BAPI_USER_PROFILES_ASSIGN call granting SAP_ALL - high-confidence indicator regardless of caller; Security Audit Log event EUP for virtual SAP* create/delete.
• Anti-forensics (host-level, primary): unexpected ptrace attach to a running disp+work/SAP_<SID>_<inst>_W<n> process from a sibling process owned by the same <sid>adm UID is anomalous - alert on PTRACE_ATTACH syscalls targeting SAP kernel binaries. A newly-appeared, unexplained process with an open file handle on a disp+work PID is a strong indicator.
• Anti-forensics (filesystem): newly-executable ELF binaries dropped to /tmp (or similar) on SAP hosts.
• Anti-forensics (gap-based, the most reliable defender signal): a sustained period with zero Security Audit Log entries on an application server that is otherwise actively processing dialog/RFC traffic (cross-check via SM50/work-process statistics or DB transaction volume against Security Audit Log volume) - the suppression is invisible to SM20 itself by design, so an independent activity signal is necessary.
• Anti-forensics (DBTABLOG-specific): forward table-change logs off-host in near-real-time rather than relying on retrospective host-local review; compare DBTABLOG row counts/gaps against an independent change-tracking source; monitor RFC_ABAP_INSTALL_AND_RUN executions that compile and run short-lived, throwaway DELETE-style programs against DBTABLOG specifically - legitimate Basis administration does not do this ad hoc.

• SAP Note 2253549 - SAP Security Baseline Template
• Book: Cybersecurity for SAP® (SAP PRESS) - “Unauthorized Access to SAP Data” / “Unauthorized Use of Critical Business Process” (MITRE ATT&CK T1098, T1078, T1087, T1657)
• Book: SAP® System Security (SAP PRESS, 2026) - Chapter 11, “Command-line exploits” and “Inserting a foreign transport into the transport queue”
• Critical RFC-Enabled Function Modules
• Remote ABAP Report Execution via XBP
• Accessing filesystem (read)
• Accessing filesystem (write)
• Network File Access
• Import a malicious transport
• Transport Creation
• Hardcoded and Virtual Super-User SAP*
• Secure Store decryption
• MYSAPSSO2 ticket forgery
• Lateral Movement Across SAP Landscapes