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. AS ABAP Credential-Material Taxonomy
Edit page

AS ABAP Credential-Material Taxonomy

Description

AS ABAP stores secrets in several formats, each with its own storage location, protection scheme, and recovery technique. This page maps every ABAP credential-material type an attacker encounters after gaining a foothold to where it lives, how it is recovered, and the page documenting that technique.

Most are post-compromise primitives: they turn one foothold (OS command execution, table read, or file access) into credentials that enable lateral movement across the whole landscape. The recurring theme is that SAP’s default protection for stored secrets is frequently obfuscation, not encryption (SAP itself says so for Secure Storage in SAP Note 1902611) - so the control is protecting the storage and the key, not the format.

Credential material on the non-ABAP platforms lives in that platform’s own tree - see the per-service pages linked at the bottom.

Risk

Recovered credential material - RFC/DB destination passwords, ticket-signing keys, OAuth secrets - lets an attacker authenticate as legitimate users and services across trusting systems without any further exploitation, defeating the authorization concept landscape-wide. A single compromised application server frequently yields the keys to every system it trusts (RFC and SSO). Impact spans confidentiality, integrity, and availability across the trust domain.

Options

ABAP credential material, by type - recover the ciphertext/file via the foothold, then decrypt with the referenced tool (lead with an existing PoC, do not re-implement crypto):

Credential materialWhere it livesProtectionRecoveryPage
Password hashes (USR02 etc.)ABAP DB tablesBCODE/PASSCODE (weak) / PWDSALTEDHASHtable read -> hashcat/JohnPassword hashes
MYSAPSSO2 logon ticketsissued/verified via STRUSTSSO2PKCS#7 sig by SAPSYS.pse keysteal PSE+PIN -> forgeMYSAPSSO2 forgery
SAPSYS.pse + cred_v2 (PSE PIN)$SECUDIR (OS)PIN-wrapped; cred_v2 self-decrypts as <sid>admOS read as <sid>admMYSAPSSO2 forgery
ABAP Secure Storage (RSECTAB)ABAP DB tabledefault 3DES key (obfuscation, Note 1902611)table read -> ERPScan RSECTAB algoSecure Store decryption
SSFS (SSFS_<SID>.KEY/.DAT).../rsecssfs/ (OS)RSECCipher, hardcoded KEKfile read -> pysap SAPSSFSSecure Store decryption
OAuth 2.0 client secrets/OA2C/CS_* in Secure Storageas Secure StorageOA2C config read + SecStore decryptSecure Store decryption

General methodology: after a foothold, harvest every reachable store above, decrypt with the referenced PoC, then follow the recovered RFC/HTTP/DB destinations and SSO trust to pivot (see Lateral movement).

Mitigation

  • Configure an individual key where the default is obfuscation-only: SECSTORE individual key (Note 1902611), per-system SSO certs.
  • Restrict OS-level access to $SECUDIR and .../rsecssfs/ to the relevant service account only; no world-readable key/PSE files.
  • Restrict table read (S_TABU_DIS/S_TABU_NAM, RFC_READ_TABLE) on credential tables (USR02, RSECTAB, OA2C_*).
  • Harden the upstream footholds (RFC Gateway ACLs, SXPG, CVE patching) that grant the OS/DB access these recoveries depend on.
  • Prune SSO/RFC trust (STRUSTSSO2, SMT1).
  • After suspected exposure, rotate the key AND the downstream secrets it protected - rotating the key alone is insufficient.

Detection and Monitoring

  • OS-level file-access auditing on $SECUDIR / rsecssfs directories.
  • Security Audit Log (SM20/RSAU): RFC_ABAP_INSTALL_AND_RUN, SXPG external commands, RFC_READ_TABLE on credential tables, SSO-ticket logons from unusual sources.
  • Watch for the specific IOCs in the individual pages (e.g. the sapmap@pentest SSH key, virtual SAP* EUP events).

References