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 Business Technology Platform
  4. /
  5. Known Attack Vectors
  6. /
  7. Audit Log Blind Spots
Edit page

Audit Log Blind Spots

Description

The BTP Audit Log service is often assumed to be a complete forensic trail - “it’s on, so we have the evidence.”

This page is a detection-oriented reference to where that assumption breaks: what the Audit Log service cannot be tuned to capture, which attacker actions never generate a record, how long evidence survives, and where the boundary between platform-plane and data-plane logging leaves gaps. Understanding these blind spots is what lets a defender place compensating controls, and lets a tester articulate why an action went unseen. It ties together the audit caveats noted across Identity Persistence, Cloud Foundry, and Cloud Connector.

Risk

Blind spots in the audit trail let post-exploitation, credential exfiltration, and persistence go unrecorded or age out before a SOC sees them - turning a detectable intrusion into an invisible one. The risk is not a single exploit but a systemic gap in incident-response capability across the BTP estate.

Options

From a tester’s perspective these are things to enumerate and demonstrate (which of my test actions produced a record?); from a defender’s, they are the gaps to close.

  • Coverage cannot be tuned. Once the Audit Log service is enabled, the platform writes events automatically and administrators cannot configure it to log specific additional events
  • What is not logged at all:
    • In-container OS activity after direct access to the App shell via e.g. Cloud Foundry SSH (cf ssh) - shell actions inside an app container are not in the BTP Audit Log.
    • Data-plane access - direct SQL to HANA Cloud / PostgreSQL via a harvested service key or `Cloud Foundry SSH forwarding tunnel is captured only by the database’s own audit mechanism (e.g. HANA’s SQL audit log), not the BTP platform log.
    • App-to-app / most in-app data reads - application-internal data access is not a platform event.
    • Kyma runtime activity lives on a separate logging plane entirely. kubectl actions, Secret reads in kyma-system, Function execution, and APIRule changes are recorded (if at all) by the cluster’s own Kubernetes audit log, not the BTP platform Audit Log - and the same data-plane blind spot applies (a ServiceBinding-Secret-derived HANA/on-prem access is invisible to both the BTP log and the k8s audit log). Enable and ship the cluster audit log separately; do not assume the BTP Audit Log covers a Kyma engagement. See Kyma.
  • Retention expires (default 90 days). For SAP-generated audit data (Cloud Foundry), the subaccount retains data for 90 days free of charge, then it is automatically deleted. Longer retention requires the Audit Log service, premium edition and a support request (component BC-CP-CF-SEC-AUDITLG). Customer-generated audit data has no free retention at all. An attacker who dwells beyond the window - or returns after it - leaves no queryable trace on the free tier.
  • Subaccount logs do not roll up automatically. Subaccount-level events do not automatically appear in a global-account-level central instance - an attacker operating entirely within one subaccount generates evidence a global-account SOC view will not see without explicitly pulling that subaccount’s logs.
  • Retrieval friction. The log is retrieved via an OAuth-authenticated Retrieval API and its structure is non-trivial.
  • Cloud Connector’s own blind spot compounds this. At SCC’s default audit level (“Security”), successful tunnel accesses are not logged - so an on-prem pivot through an over-broad SCC ACL is invisible on both the SCC side and (being data-plane) the BTP side.

Mitigation

  • Continuously export the BTP Audit Log to an external SIEM (evidence then survives past the BTP retention window), and enable the premium edition where longer in-platform retention is required.
  • Explicitly pull and ship subaccount-level logs rather than relying on global-account visibility; inventory all subaccounts (including stale/orphaned ones) so none are unmonitored.
  • Enable and centrally aggregate the data-plane logs the platform doesn’t cover: HANA’s native SQL audit policies, PostgreSQL logging, and application-level audit for sensitive reads.
  • Raise Cloud Connector’s (SCC) audit level to “All” on sensitive backends so successful on-prem access is recorded.
  • Treat Cloud Foundry SSH enablement as an out-of-band monitored event, since in-container activity itself is not captured.

Detection and Monitoring

  • Build absence-of-logs detection: alert on gaps in the audit export stream itself - a sudden silence can indicate tampering, a disabled export, or an unmonitored subaccount.
  • Baseline the events the platform does emit (role-collection assignment, service-key creation, destination edits, trust-configuration changes, cf SSH session events) and alert on anomalies - see the specific IOCs on Identity Persistence and Service Key Abuse.
  • Correlate BTP platform events with the database and SCC audit logs to cover the data-plane and on-prem-pivot gaps the BTP log misses.
  • Periodically verify, don’t assume, coverage: in a controlled test, run representative actions and confirm which produced an entry and how long it was retained.

References