Skip to main content
SAP Pentest Playbook
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Back to homepage
  2. /
  3. SAP ABAP Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Logging and Detection Surface to Watch
Edit page

Logging and Detection Surface to Watch

Description

Unlike a network IDS, most of SAP’s detection surface is application-layer, per-component, and off by default - meaning its presence or absence on a given system says a great deal about how mature the target’s security operations are, and every one of these sources persists independently of the others. Before or during an engagement it is worth establishing which of the following are actually active, because none of them can be assumed:

  • Security Audit Log (SM19/RSAU_CONFIG to configure, SM20/RSAU_READ_LOG to read) - the primary application-level event log: dialog/RFC/CPIC logon attempts, RFC function-module calls, transaction/report starts, transaction lock/unlock, user-master and authorization changes, virus-scanner hits, application-server start/stop, and changes to the audit log’s own configuration. Disabled out of the box (rsau/enable = 0). Where enabled, it writes to files (DIR_AUDIT/FN_AUDIT, capped by rsau/max_diskspace/*) and/or the database as of the newer RSAU_CONFIG interface (SAP Note 2140313), which also introduced the S_SAL authorization object, up to 90 filters/profile (vs. 10 previously), and integrity protection (HMAC) via RSAU_ADMIN. Filters combine client/user selection (generic user-name wildcards require rsau/user_selection=1, SAP Note 574914) with audit classes (dialog logon, RFC/CPIC logon, RFC function call, transaction start, report start, user/authorization changes, …) and an event-severity threshold.
  • System log / SM21 - kernel/technical-level log (/usr/sap/<SID>/<INST>/log/SLOG<NR>, capped by rslg/max_diskspace/local), active by default. Independent of the Security Audit Log; captures program errors and low-level system events regardless of whether SAL is configured.
  • Table-change logging (DBTABLOG/SCU3) - data-level logging of changes to specific tables, split into two independently-activated paths: application changes (profile parameter rec/client = ALL or an explicit client list) and transport-driven changes (tp parameter RECCLIENT=ALL in the transport profile, STMS). Only tables individually flagged for logging (SE13, checkable in bulk via report RDDPRCHK) generate entries, regardless of rec/client; SAP Note 112388 lists tables that should be flagged for logging but are not logged by default. Entries land in table DBTABLOG with no built-in size cap - read via SCU3.
  • User/authorization change logging - automatic, always-on, and independent of the Security Audit Log: every change to a user master or authorization is written to the USHxx tables (USH02, USH04, …) with unlimited retention, readable via report RSUSR100N. Grant/revocation of SAP_ALL/SAP_NEW is visible here even if SAL is fully disabled.
  • Change documents (CDHDR/CDPOS, report RSSCD200) - business-object-level logging (sales documents, vendor master changes, credit-card data, …) for objects registered for change-document tracking; also unlimited retention.
  • Usage and Procedure Logging (UPL) - activated via /SDF/UPL_CONTROL (SE38); once on, it silently records every call of every custom program/transaction/class into table /SDF/UPL_LOG (SAP-standard code is not covered). No user identity is stored, only call counts - a call-frequency map of the custom code footprint, readable via function module /SDF/UPL_GET_USAGE or report /SDF/SHOW_UPL. The performance overhead is under 2%, and it is frequently left running continuously.
  • Gateway logging (gw/logging, configured via SMGW), ICM/Web Dispatcher HTTP log (icm/HTTP/logging_XX, read via SMICM) - both off by default; the HTTP log specifically captures unauthenticated (401) and malformed (400) requests, full request/response with headers, which is exactly the traffic profile of unauthenticated recon and exploitation attempts against exposed ICF services (see Exposed ICF Services).
  • System trace (ST01) and developer trace - short-window, size-capped (ST01: ~10 MB × 10 files, overwritten on rollover) traces of authorization checks, DB access, and RFC calls; not continuous logging, but frequently switched on reactively during an active investigation.
  • Blue-team platform awareness - SAP Enterprise Threat Detection (ETD) correlates Security Audit Log, system log, DB access logs/traces, and OS/network events in a HANA-based real-time engine with predefined and custom detection patterns (blacklisted transactions/function modules, critical-authorization assignment, anomalous logon geography/timing); where deployed, it materially shortens the defender’s time-to-detect versus raw log review. SAP Code Vulnerability Analysis/Analyzer is a static ABAP scanner (SQL injection, missing AUTHORITY-CHECK, hard-coded credentials, directory traversal) usually run via ATC/CI pipelines against custom code - its presence indicates custom RFC-enabled function modules and reports are more likely to have been reviewed. Solution Manager’s Security Optimization Service/Self-Service runs periodic configuration/authorization/administration checks (SAProuter config, SNC, AS Java config, super-user passwords, spool/batch-input authorizations, transport control, profile parameters) against roughly 226 individual checks - its presence is itself a signal of baseline hygiene.

Risk

None of these sources are mutually exclusive with each other being off: a system can have the Security Audit Log fully disabled while DBTABLOG, CDHDR/CDPOS, and the USHxx change logs still silently and permanently capture privilege-escalation activity (any SAP_ALL grant, any critical table row change) - meaning a target that “looks unmonitored” from the SAL/SM20 angle may still have a complete forensic trail elsewhere, discoverable during incident response weeks later. Conversely, a target with Security Audit Log enabled but table logging off will have no row-level record of a RFC_READ_TABLE/direct-SQL data exfiltration even though the RFC call itself was logged. Confusing “no visible detection” with “no detection” is a recurring assessment error; each source below needs to be checked independently, not inferred from the others.

Options

  • Establish Security Audit Log posture - if any authenticated access exists, RSAU_CONFIG_SHOW/SM19 (read-only display) shows active filters and audit classes directly. From an unauthenticated or low-privilege RFC foothold, PFL_GET_SINGLE_PARAMETER (function group SPFL, remote-enabled, callable by any authenticated RFC user - see Security-Relevant Profile Parameters) against rsau/enable gives a fast yes/no without needing SAL-viewing authority itself.
  • Establish table-logging posture - RDDPRCHK (Audit Information System) reports which tables are flagged for logging; the live value of rec/client (again via PFL_GET_SINGLE_PARAMETER, or RZ11/RSPFPAR with any Basis access) tells you whether flagged-table changes are actually being written to DBTABLOG in the current client.
  • Check for UPL - if SE38/report execution is reachable, /SDF/SHOW_UPL either returns populated usage data (UPL has been running - and therefore silently recording every custom-code call made during the engagement) or errors/returns empty (not activated). This is a pre-flight check worth doing early: a live UPL means every custom RFC-enabled FM or report exercised during testing is being counted, even without user attribution.
  • Check for ETD/SIEM integration - look for outbound RFC destinations (SM59) or scheduled jobs referencing SECM_CONFIGURATION/SECM_LOG_2_ES (ABAP-side ETD log-forwarding reports) as evidence of an active ETD pipeline; their presence means Security Audit Log and system-log events are likely being correlated in near-real-time rather than reviewed reactively.
  • Gateway/HTTP logging posture - SMGW -> Goto -> Expert Functions -> Logging shows whether Gateway logging is on; for ICM/Web Dispatcher, SMICM shows the configured icm/HTTP/logging_XX path (if any). Both being off is common and a gap worth calling out - the HTTP log is one of the few sources that would otherwise capture raw exploitation payloads.
Note
This page is reconnaissance, not evasion guidance: it exists so an assessment can accurately report what an attacker’s activity would and would not generate a durable record of, and so testers can scope their own activity against an agreed logging/monitoring baseline with the client. Deliberately degrading, deleting, or suppressing any of these logs during an engagement is outside the scope of this page and, absent explicit written authorization for a red-team/adversary-simulation exercise, is not a technique this playbook documents.

Mitigation

  • Enable the Security Audit Log with, at minimum, dialog/RFC/CPIC logon, RFC function-module call, transaction start, and user/authorization-change audit classes, in every productive client; migrate to RSAU_CONFIG/database storage and enable RSAU_ADMIN integrity protection (SAP Note 2140313) rather than relying on filesystem-only SM19 files.
  • Set rec/client = ALL and explicitly flag business-critical tables (RSECTAB, USR02, AGR_*, RFCDES/RFCTRUST/RFCSYSACL, and anything listed in SAP Note 112388) for DBTABLOG logging.
  • Activate UPL (/SDF/UPL_CONTROL) continuously - the performance cost is negligible and it is the only source that maps custom-code usage frequency, valuable both for security risk-prioritization and for post-incident scoping.
  • Enable Gateway and ICM/Web Dispatcher HTTP logging on internet-facing and DMZ-tier instances at minimum.
  • Route Security Audit Log, system log, and DB access logs into SAP Enterprise Threat Detection or an equivalent SIEM rather than relying on ad-hoc SM20 review; periodic Security Optimization Service runs via Solution Manager catch configuration drift between reviews.

Detection and Monitoring

  • Because reading logging configuration itself (PFL_GET_SINGLE_PARAMETER sweeps of rsau/*/rec/client, RSAU_CONFIG_SHOW, RDDPRCHK) is an unusual, scripted pattern versus normal interactive Basis administration, it is itself visible in an RFC/function-module-call trace (ST05/gateway logging/Security Audit Log RFC-call class) - the same signature noted in Security-Relevant Profile Parameters for the SSO2-parameter sweep.
  • Any change to Security Audit Log configuration is itself an audited event (audit class “changes to Security Audit Log configuration”) - an unexpected reconfiguration during an active window is a strong incident indicator independent of what was subsequently done.
  • USHxx/RSUSR100N and CDHDR/CDPOS/RSSCD200 are unconditional and unlimited-retention - they will show privilege and business-object changes even on systems where Security Audit Log was never enabled, making them a standard first stop in any post-engagement or post-incident review.
  • Internal-context misattribution: RFC activity that runs under the kernel-internal SAPSYS identity - for example a forged internal-state conversation (see Trusted-RFC Impersonation and Callback Abuse) - has no USR02 user record, so any audit entry it does generate attributes the activity to a housekeeping identity rather than an attacker. Function modules that bypass the RFC authority check never produce an S_RFC-denial event either (the check is skipped, not failed). Do not read the absence of an attributable user or an S_RFC denial as absence of activity; correlate with gateway/ICM HTTP logs, which capture the raw call.

References