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
Edit page

Network Service Discovery & Fingerprinting

Description

SAP NetWeaver AS Java exposes several independently-fingerprintable network services on ports derived from the two-digit instance number (NN, 0099), following the 5NN0x numbering scheme documented in Technology Overview: HTTP(S) (5NN00/5NN01), P4 (5NN04), and the Telnet/Shell Administrator console (5NN08). Each responds distinctly enough to positively identify AS Java (versus AS ABAP or a non-SAP web server) and, on unhardened systems, to leak version and deployed-component information before any authentication is attempted. A parallel goal of AS Java recon is establishing the UME landscape - which persistence store backs user management (local J2EE DB, LDAP, or a connected ABAP system), and whether well-known default administrative accounts still hold default or weak credentials.

Options

HTTP(S) fingerprinting (5NN00/5NN01)

  • GET / or GET /irj/portal - a redirect to the Portal logon page, or a sap.com cookie/header, confirms AS Java (vs. a generic web server).
  • GET /sap/monitoring/SystemInfo or the ICM_GET_INFO-equivalent web-based system info servlets - version/patch-level disclosure on unhardened systems.
  • HEAD /CTCWebService/CTCWebServiceBean - 200 is a strong signal of an exposed, possibly-unpatched LM Configuration Wizard; see LM Configuration Wizard / RECON.
  • GET /useradmin/ - the UME administration UI; a reachable, unauthenticated logon page confirms UME is HTTP-exposed and is the entry point for credential-spray reconnaissance below.
  • GET /nwa - SAP NetWeaver Administrator; confirms the modern (7.1+) administration UI is present.
  • WebDynpro/servlet path enumeration (e.g. /webdynpro/resources/sap.com/..., /irj/servlet/prt/portal/...) - deployed-application fingerprinting; a wordlist-driven sweep of known WebDynpro application aliases reveals which SAP components (PI/PO, Solution Manager Diagnostics, Visual Composer, CTS+) are installed.

P4 fingerprinting (5NN04)

  • A raw TCP connect confirms the port is open; P4 is SAP’s proprietary RMI-based protocol (not a text banner protocol), so positive identification generally requires either a protocol-aware client (e.g. the legacy Visual Administrator, or a P4-speaking library) or correlating the open port against a positively-identified AS Java HTTP fingerprint on the same host/instance-number pair.
  • Because P4 is the transport for the RMI-based remote-object protocol underlying CVE-2025-42944 (see P4/RMI Insecure Deserialization), simply confirming this port is reachable from an untrusted network is itself a reportable finding independent of further exploitation.

Telnet fingerprinting (5NN08)

  • A raw TCP connect followed by reading the initial banner up to the first > prompt - SAP’s Shell Administrator console banner is distinctive. Per SAP’s own hardening guidance, this port is frequently not externally reachable (recommended to be VPN-tunneled or deactivated entirely), so a positive hit here is itself a hardening-gap finding.
  • Post-connect, an unauthenticated lsc attempt (before any login) typically fails/is rejected, confirming authentication is enforced without needing valid credentials.

Default users / UME landscape

  • J2EE_ADMIN - the standard installation-time super-administrator account for the J2EE Engine’s local UME store (distinct from ABAP’s SAP*/DDIC).
  • Administrator - the conventional UME Administrator-role account name used across NWA/Portal/useradmin documentation and tooling; frequently the account an attacker creates via RECON (CVE-2020-6287) when targeting a specific role name.
  • Where UME is configured against an external ABAP system or LDAP directory (common in Portal/PI landscapes), local default-credential testing is not applicable - recon must first determine the persistence store (visible, when authenticated, via NWA → Configuration → UME → Data Sources), since a Java-side credential spray against an ABAP-backed UME is really an ABAP-side dialog-logon attack in disguise, subject to the same lockout considerations as Default SAP Users and Passwords.
  • Test credentials sequentially against /useradmin/ or j_security_check form-based logon, respecting lockout thresholds the same way as ABAP DIAG credential testing.

References