Der neue hybride SAP Pen Test: Attacke und Architektur

Warum eine moderne SAP-Landschaft zwei unterschiedliche Prüfmethoden braucht – und wo die beiden Welten gefährlich aneinanderstoßen.

Wenn ein CISO heute „SAP“ hört, denkt er meist an eine Blackbox, die irgendwo im Rechenzentrum läuft und die das SAP-Team verwaltet. Diese Vorstellung ist seit Jahren überholt. Aus dem alten, in sich geschlossenen ERP-System ist eine hybride Landschaft geworden: klassische On-Premise-Systeme auf der einen Seite, eine wachsende Cloud-Plattform – die SAP Business Technology Platform (BTP) – auf der anderen. Beide Welten hängen zusammen, beide tragen die Kronjuwelen des Unternehmens, und beide haben völlig unterschiedliche Sicherheitsprofile.

Genau hier scheitern die meisten Sicherheitsprüfungen. Wer eine hybride SAP-Landschaft mit einer einheitlichen Methode testet, testet die Hälfte falsch. Der On-Premise-Teil verlangt einen aktiven, gegnerischen Red Team Pen Test. Der Cloud-Teil verlangt etwas anderes: eine strukturierte Sicherheitsanalyse aus Interviews und Konfigurationsreviews. Dieser Beitrag erklärt, warum diese Trennung kein methodischer Luxus ist, sondern die einzige Methode, die der heutigen Architektur gerecht wird – und warum gerade die Naht zwischen beiden Welten der gefährlichste Punkt überhaupt ist.

Warum SAP für Ihr Standard-Pentest-Toolset unsichtbar ist

Als CISO kennen Sie Angriffsflächen, Shared Responsibility, Detection-Lücken und Rules of Engagement. Was Sie wahrscheinlich nicht kennen, ist, warum SAP eine eigene Disziplin ist.

SAP ist keine Web-Anwendung mit einer Datenbank dahinter. Es ist eine eigene technische Welt mit eigenen Protokollen (RFC und DIAG statt nur HTTP), einer eigenen Programmiersprache (ABAP), einem eigenen Benutzer- und Berechtigungsmodell und einem eigenen Transportwesen für Software-Auslieferung. Ein klassischer Web-Pentest läuft an diesen Systemen weitgehend vorbei – er sieht den HTTP-Port, aber nicht das, was darunter liegt. Genau dort sitzen aber die kritischen Angriffsvektoren.

Wie ernst das ist, hat das Jahr 2025 sehr deutlich gezeigt. Mit CVE-2025-31324 wurde eine Schwachstelle im SAP NetWeaver bekannt: CVSS-Score 10.0, ohne Authentifizierung ausnutzbar, die maximale Risikobewertung. Angreifer konnten ohne jeden Login Schadcode hochladen und ausführen – vollständige Systemübernahme. Die Schwachstelle wurde nachweislich seit März 2025 aktiv ausgenutzt, unter anderem durch staatsnahe Akteure, landete auf der KEV-Liste der US-Behörde CISA, und mehrere tausend NetWeaver-Instanzen standen offen im Internet. Wer hier nicht innerhalb von Stunden gepatcht hat, hatte potenziell bereits eine Web-Shell auf seinem ERP-Backbone.

Das ist die zentrale Botschaft an dieser Stelle: Der klassische On-Premise-Stack ist kein Altbestand, der vor sich hin läuft. Er ist ein lebendes, aktiv beschossenes Ziel. Und ein lebendes Ziel prüft man, indem man es angreift – kontrolliert, autorisiert und mit dem Mindset eines echten Angreifers.

Zwei Welten, zwei Methoden

Der entscheidende Punkt einer modernen SAP-Prüfung ist die saubere Trennung in zwei Prüfmodi, weil die beiden Hälften der Landschaft technisch grundverschieden sind.

On-Premise (klassischer ABAP-Stack, NetWeaver, S/4HANA): Hier kontrollieren Sie die Infrastruktur. Hier gibt es ausnutzbare Schwachstellen, exponierte Dienste, schwache RFC-Absicherung, kritische Standardbenutzer und Berechtigungsfehler. Hier ist der Angriff das richtige Werkzeug. Der passende Modus ist der aktive Red Team Pen Test.

BTP Cloud (Platform-as-a-Service / Software-as-a-Service): Hier kontrollieren Sie die Infrastruktur nicht. Die Plattform gehört SAP, sie ist mandantenfähig, und sie unterliegt dem Modell der geteilten Verantwortung. Ein aktiver Angriff auf die BTP-Infrastruktur ist nicht nur vertraglich heikel – er zielt schlicht auf die falsche Ebene. Das reale Risiko in der Cloud liegt fast nie in einer ausnutzbaren Plattform-Lücke, sondern in Ihrer Konfiguration und Ihren Integrationen. Und Konfiguration prüft man nicht mit einem Exploit, sondern mit Review und Interview. Der passende Modus ist die Sicherheitsanalyse.

Diese Unterscheidung ist nicht akademisch. Sie entscheidet darüber, ob ein Test überhaupt Findings produziert, die etwas wert sind.

Teil 1: Der aktive SAP Red Team Pen Test (On-Premise)

Im aktiven Teil arbeiten wir nach dem Prinzip, das jeder Angreifer verfolgt – nur autorisiert und dokumentiert: nicht Audit-konform nach Playbook, sondern entlang der Frage, was sich tatsächlich erreichen lässt. Hacker kommen nicht mit einer Checkliste, sie wollen Verschlüsselung, Datendiebstahl oder Sabotage. Genau dieses Verhalten bilden wir nach.

Der Ablauf eskaliert in Stufen:

• Externe Aufklärung (OSINT / Reconnaissance): Was ist von außen über das Unternehmen, seine Hoster, seine Subnetze und exponierten Dienste sichtbar? Welche SAP-Komponenten – Application Server, Message Server, Gateway – sind erreichbar? Gibt es bereits geleakte Zugangsdaten im Darknet?
• Black Box: Der anonyme Angriff von außen, ohne Benutzer. Ergibt das belastbare Bild der externen Angriffsoberfläche.
• Grey Box: Der Tester schlüpft in eine definierte Rolle – typischerweise die eines externen Entwicklers mit Zugang zum Entwicklungssystem – und versucht von dort, die produktiven Systeme zu kompromittieren. BASIS-Konfiguration, RFC-Architektur, kritische Benutzer, bekannte ausnutzbare Schwachstellen, Ransomware-typische Pfade.
• Red Team: Der Hauptangriff. Die Leitfrage lautet: Was kann ein autorisierter Angreifer in dieser Landschaft tatsächlich anrichten – bis hin zur vollständigen Übernahme?

Wichtig für Sie als CISO: Wir arbeiten nach dem Grundsatz „aufzeigen, nicht ausführen“. Das Ziel ist der bewiesene Angriffspfad, nicht der ausgelöste Schaden. Sie bekommen am Ende keine Liste theoretischer Risiken, sondern nachvollziehbar belegte Wege, auf denen ein Angreifer von außen bis zu Ihren produktiven Daten gelangt – und an welcher Stelle genau die Kette gerissen wäre, wenn die Härtung gestimmt hätte.

Teil 2: Die Sicherheitsanalyse der BTP Cloud

Der Cloud-Teil läuft methodisch anders – aber keineswegs weniger gründlich. Statt zu schießen, sezieren wir die Konfiguration jedes relevanten Dienstes und gleichen sie in strukturierten Interviews mit den Verantwortlichen gegen die Soll-Architektur ab. Das deckt genau die Risiken auf, die ein Angriff übersieht: stillschweigend gewachsene Berechtigungen, vergessene Verbindungen, ungehärtete Integrationen.

Diese Dienste stehen im Fokus – jeweils in CISO-Sprache, mit dem konkreten Risikofokus:

• SAP BTP (die Plattform selbst). Das Fundament: globale Accounts, Subaccounts, Berechtigungspakete (Entitlements) und vor allem die Identitätsschicht – Identity Authentication und Identity Provisioning sowie das Vertrauensverhältnis zu Ihrem Unternehmens-IdP. Risikofokus: Wer hat Administratorrechte? Wie ist die Identität föderiert? Wuchern Entitlements unkontrolliert? Hier entscheidet sich, wer überhaupt durch die Eingangstür kommt.
• SAP Build und Work Zone. Build ist die Low-Code-/No-Code-Umgebung, in der Fachbereiche eigene Anwendungen bauen – „Citizen Development“. Work Zone ist der digitale Arbeitsplatz beziehungsweise das Launchpad, auf dem Anwender landen und auf dem Apps ausgespielt werden. Risikofokus: ungesteuertes App-Building, vor allem aber die Destinations – gespeicherte Verbindungen in die Backend-Systeme, die gerne wiederverwendet und überberechtigt werden. Wer darf bauen, wer darf veröffentlichen, und welche Backend-Verbindung hängt an welcher App?
• Data Fabric / SAP Datasphere. Die Datenschicht – der Ort, an dem Unternehmensdaten aus vielen Quellen zusammengeführt und bereitgestellt werden. Risikofokus: Datenexposition über Spaces und Verbindungen, Freigaben, die mehr offenlegen als gewollt. In der Datenschicht entsteht der Schaden leise und großflächig.
• Data Analytics / SAP Analytics Cloud. Business Intelligence, Planung, Dashboards. Risikofokus: Live-Verbindungen zurück in die Quellsysteme und das Freigabemodell – öffentlich geteilte Stories, übergreifend sichtbare Modelle, Links, die das Haus verlassen. Ein Dashboard ist nur so sicher wie die Verbindung, die es speist.
• Integration Suite mit Cloud Connector. Die Integrationsschicht: die Middleware (iPaaS), die Cloud und On-Premise verbindet – und der Cloud Connector als technische Brücke dorthin. Diesem Punkt ist der nächste Abschnitt gewidmet, denn hier laufen beide Prüfwelten zusammen.

Die Naht: der Cloud Connector als kritischste Schnittstelle

Hier liegt die eigentliche Pointe der hybriden Prüfung.

Der Cloud Connector ist ein Tunnel. Er öffnet aus der BTP Cloud heraus einen Pfad in Ihr internes On-Premise-Netz, damit Cloud-Anwendungen auf die alten Backend-Systeme zugreifen können. In der Theorie gibt er exakt definierte Ressourcen frei. In der Praxis ist er einer der häufigsten Punkte, an denen „intern“ und „extern“ verschwimmen: zu weit gefasste Freigaben, zu großzügige Principal-Propagation, vergessene Verbindungen aus Projekten, die längst beendet sind.

Und damit kippt eine reine Cloud-Konfigurationsfrage plötzlich in eine On-Premise-Angriffsfrage. Ein im Analyse-Teil entdeckter zu offener Cloud Connector ist kein abstraktes Konfigurationsrisiko mehr – er ist ein realer Pfad, den der aktive Red-Team-Teil auf der On-Premise-Seite verfolgen kann. Was Sie für ein sauber abgeschottetes internes Netz hielten, ist über die Cloud erreichbar.

Genau deshalb gehören die beiden Hälften in eine Untersuchung und nicht in zwei voneinander getrennte Audits. Zwei isolierte Prüfberichte – einer für die Cloud, einer für On-Premise – sehen diese Naht nie. Sie liegt definitionsgemäß zwischen ihren Zuständigkeiten. Erst die integrierte Betrachtung macht aus einem Konfigurations-Finding einen bewiesenen Angriffspfad.

Was Sie als CISO davon haben

Der konkrete Mehrwert dieses Vorgehens lässt sich in vier Punkten zusammenfassen:

• Ein ganzheitliches Bedrohungsbild statt zweier Silos. Die früher getrennt betrachteten Welten – „allgemeine“ IT und SAP, Cloud und On-Premise – wachsen in einer einzigen Bewertung zusammen, so wie sie es in der realen Architektur längst getan haben.
• Priorisierung nach echter Ausnutzbarkeit. Sie bekommen keine generische CVSS-Liste, sondern eine Reihung danach, was ein Angreifer in Ihrer Landschaft tatsächlich erreichen kann – belegt, nicht vermutet.
• Anschluss an Ihr bestehendes Sicherheitsprogramm. Die Ergebnisse lassen sich gegen eine gemeinsam definierte Baseline auswerten und an SOC/SIEM, an NIS2, an den BSI-Grundschutz und an ISO 27001 anbinden. Stichwort „Stand der Technik“ – nachweisbar und prüffest.
• Die Naht im Blick. Die Schnittstellen zwischen Cloud und On-Premise werden explizit geprüft, statt durch das Raster zweier getrennter Audits zu fallen.

Fazit

Die hybride Realität verlangt eine hybride Methode. Aktiv dort, wo der Angriff das richtige Werkzeug ist – auf dem On-Premise-Stack, der nachweislich täglich beschossen wird. Analytisch dort, wo das reale Risiko in Konfiguration und Integration liegt – in der BTP Cloud, über Interviews und Configuration Reviews ihrer Kerndienste. Und mit besonderer Aufmerksamkeit für die Naht dazwischen, an der aus einer Cloud-Einstellung ein On-Premise-Einfallstor wird.

Wer seine SAP-Landschaft noch immer mit einer Methode prüft, prüft an der Architektur vorbei. Die Frage ist nicht mehr, ob Cloud und On-Premise zusammen betrachtet werden müssen – sondern nur noch, ob Ihr letzter Pen Test das bereits getan hat.