Skip to main content
Corgea AI Pentest führt autonome Penetrationstests gegen Ihre laufenden Webanwendungen durch. Während SAST den Quellcode analysiert, greift ein Pentest die ausgerollte Anwendung so an, wie es ein echter Angreifer tun würde: Er erfasst die Angriffsfläche, verkettet einzelne Schwachstellen miteinander und belegt jedes Finding mit einem funktionierenden Exploit. Jeder Lauf liefert Findings mit reproduzierbarem Proof of Concept sowie einen PDF-Bericht, den Sie direkt an Kunden, Auditoren oder Ihr eigenes Engineering-Team weitergeben können.
Pentesting befindet sich in der Beta-Phase und ist als Add-on verfügbar. Wenn Pentests nicht in der Seitenleiste auftaucht, wenden Sie sich an Ihren Corgea-Administrator oder an sales@corgea.com.

​
So läuft ein Pentest ab

Jeder Lauf durchläuft dieselben drei Phasen.
1

Aufklärung

Die Agenten erfassen die Angriffsfläche Ihres Targets: Endpunkte, Authentifizierungsabläufe, Parameter und Routen, auf die nirgends offensichtlich verlinkt wird.
2

Angriff

Spezialisierte Agenten bearbeiten das Target parallel, jeder mit einem eigenen Fachgebiet. Statt nach Mustern zu suchen, versuchen sie eine tatsächliche Ausnutzung und verketten Schwachstellen über Fachgebiete hinweg, um Angriffe mit größerer Wirkung zu erreichen.
3

Bericht

Bestätigte Findings werden mit Beschreibung, geschäftlichen Auswirkungen, Angriffskette, Exploit-Skript und Hinweisen zur Behebung dokumentiert und anschließend in einem herunterladbaren Bericht zusammengefasst.
Bei jedem Lauf kommen diese Agenten zum Einsatz: Ein Deep-Lauf ergänzt einen erweiterten Red-Team-Agenten, der über diese Fachgebiete hinaus sucht und mehrstufige Angriffsketten über sie hinweg aufbaut.
Corgea meldet ausschließlich Findings, die seine Agenten gegen die laufende Anwendung verifizieren konnten. Was im Bericht steht, wurde tatsächlich reproduziert und nicht nur vermutet.

​
Bevor Sie starten

Führen Sie Pentests nur gegen Anwendungen aus, die Ihrer Organisation gehören oder für deren Prüfung Sie ausdrücklich autorisiert sind. Ein Pentest erzeugt echten Angriffsverkehr und kann Daten anlegen, verändern oder löschen. Richten Sie Läufe auf eine Staging- oder eine dedizierte Testumgebung, solange Sie das Risiko eines Tests in der Produktion nicht bewusst in Kauf nehmen.
Die URL Ihres Targets muss öffentlich über http oder https erreichbar sein. Corgea weist Targets ab, die:
  • ein anderes Schema als http oder https verwenden
  • Zugangsdaten direkt in der URL enthalten, etwa https://user:pass@example.com
  • auf localhost, einen privaten Netzbereich oder eine Cloud-Metadatenadresse auflösen
Ist Ihre Anwendung nicht aus dem Internet erreichbar, stellen Sie eine Testinstanz bereit oder sprechen Sie uns an, um Alternativen zu besprechen.

​
Targets

Ein Target ist eine wiederverwendbare Konfiguration: wohin der Angriff geht, welche Zugangsdaten verwendet werden und welche dauerhaften Anweisungen gelten. Jeder Lauf wird gegen ein Target ausgeführt – Sie konfigurieren es also einmal und starten es bei jedem Release erneut.
Die Pentesting-Seite mit dem Targets-Tab und einer Liste konfigurierter Targets samt URL, Zeitpunkt des letzten Laufs und Ersteller sowie dem verbleibenden Standard- und Deep-Kontingent oben rechts
Im Kopfbereich sehen Sie, wie viel Pentest-Kontingent Ihnen je Scan-Modus noch bleibt. Der Tab Pentest runs listet sämtliche Läufe über alle Targets hinweg auf; Sie können darin suchen und nach Status filtern.

​
Ein Target anlegen

1

Pentests öffnen

Wählen Sie Pentests in der Seitenleiste und klicken Sie anschließend auf New target.
2

Target benennen und URL eintragen

Verwenden Sie einen Namen, den Ihr Team wiedererkennt, zum Beispiel Acme Public API. Die URL ist die Wurzel der Anwendung, von der aus die Agenten starten sollen.
3

Zugangsdaten hinterlegen, wenn authentifiziert getestet werden soll

Zugangsdaten sind Freitext, der an die Agenten weitergegeben wird – also genau das, was auch ein menschlicher Tester zum Anmelden bräuchte. Eine Zeile wie demo@example.com / hunter2 genügt. Ohne Zugangsdaten testen die Agenten die Anwendung als anonymer externer Angreifer.
4

Anweisungen ergänzen, falls vorhanden

Nutzen Sie Additional instructions für Testregeln, Scope-Ausschlüsse oder Endpunkte, auf die sich die Agenten konzentrieren sollen.
5

Standard-Scan-Modus wählen

Balanced oder Deep. Pro Lauf können Sie diese Vorgabe überschreiben.
Der Dialog New target mit Feldern für Target name, Target URL, optionale Credentials, optionale Additional instructions und einer Auswahl für den Default scan mode
Zugangsdaten werden verschlüsselt gespeichert und nur entschlüsselt, solange ein Lauf gegen das betreffende Target ausgeführt wird.

​
Bearbeiten und Archivieren

Über das Aktionsmenü eines Targets starten Sie einen Lauf, bearbeiten das Target oder archivieren es. Änderungen gelten ausschließlich für künftige Läufe. Jeder Lauf hält die Target-Konfiguration fest, mit der er gestartet ist. Vergangene Läufe und ihre Findings geben deshalb immer den Stand wieder, aus dem sie hervorgegangen sind. Eine geänderte URL oder rotierte Zugangsdaten schreiben nie um, was ein früherer Lauf gemeldet hat. Lassen Sie beim Bearbeiten eines Targets das Feld Credentials leer, bleiben die gespeicherten Zugangsdaten unverändert. Um sie vollständig zu entfernen, wählen Sie Clear stored credentials. Beim Archivieren verschwindet ein Target aus der Liste, alle bisherigen Läufe bleiben aber einsehbar.

​
Einen Lauf starten

Wählen Sie im Aktionsmenü eines Targets Start new run.
Eine schnellere Prüfung, die Authentifizierung und Autorisierung, Geschäftslogik sowie Injection abdeckt. Geeignet für Routinetests in regelmäßigen Abständen.
Instruction override ersetzt die dauerhaften Anweisungen des Targets für genau diesen einen Lauf. Bleibt das Feld leer, gelten die am Target hinterlegten Anweisungen. Praktisch ist das, wenn sich ein einzelner Lauf auf ein frisch ausgeliefertes Feature konzentrieren soll, ohne das Target dauerhaft einzuengen. Balanced- und Deep-Läufe werden auf getrennte Kontingente angerechnet. Das Dropdown für den Scan-Modus zeigt, wie viele Läufe Ihnen jeweils noch bleiben; ein Modus ohne verbleibendes Kontingent lässt sich nicht auswählen. Um Ihr Kontingent aufzustocken, wenden Sie sich an sales@corgea.com.

​
Einen Lauf verfolgen

Je nach Scan-Modus und Größe der Anwendung dauert ein Lauf einige Stunden. Sie müssen die Seite nicht geöffnet lassen: Findings werden gespeichert, sobald sie bestätigt sind, und Admins können sich per E-Mail über das Ende des Laufs informieren lassen. Solange ein Lauf aktiv ist, aktualisiert sich die Seite von selbst. Findings erscheinen, sobald die Agenten sie verifiziert haben – kritische Probleme können Sie also bereits triagieren, bevor der Lauf abgeschlossen ist. Über Logs sehen Sie den Agenten bei der Arbeit zu.
Die Ansicht Corgea Pentest Agents mit einem Baum parallel arbeitender Agenten, laufenden Summen für Tool-Aufrufe und Findings sowie einem Seitenbereich, der die aktuelle Aufgabe und die letzten Aktivitäten des ausgewählten Agenten beschreibt
Der Baum zeigt jeden Agenten, seine aktuelle Aufgabe und die Zahl der von ihm bestätigten Findings. Wählen Sie einen Agenten aus, sehen Sie dessen laufende Aufgabe und die jüngsten Aktivitäten. Agenten starten dabei eigene Unteragenten: Stößt einer auf eine Spur, die sich zu verfolgen lohnt, delegiert er die gezielte Nachverfolgung, statt seinen eigenen Angriffsweg aufzugeben.

​
Findings prüfen

Nach Abschluss eines Laufs fasst die Seite des Laufs zusammen, was gefunden wurde.
Ein abgeschlossener Pentest-Lauf mit insgesamt 76 Findings, aufgeschlüsselt in die Kategoriekarten Auth and AuthZ, Business Logic und Injection samt Anzahl nach Schweregrad, darunter eine nach CWE gruppierte Liste der Findings
Die Karten am oberen Rand teilen die Findings anhand der CWE in Kategorien auf. Ein Klick darauf filtert die Liste darunter.
  • All findings – alles, was der Lauf bestätigt hat, mit Anzahl nach Schweregrad
  • Auth & AuthZ – fehlerhafte Zugriffskontrolle sowie Probleme bei Authentifizierung und Sessions
  • Business Logic – Probleme bei Workflows und Transaktionsintegrität
  • Injection – Injection, Traversal und Probleme mit nicht vertrauenswürdigen Eingaben
  • Validated SAST – demnächst verfügbar; gleicht bestätigte SAST-Findings mit der Ausnutzbarkeit zur Laufzeit ab
Findings, deren CWE keiner dieser Kategorien zugeordnet ist, erscheinen weiterhin unter All findings.

​
Filtern und Gruppieren

Die Werkzeugleiste über der Finding-Liste bietet Ihnen:
  • Status-Pills – Open, Fixed, Closed und False Positive, jeweils mit aktueller Anzahl. Über More kommen Accepted Risk, Duplicate und sämtliche Status hinzu.
  • Suche – durchsucht Titel, CWE und Endpunkt
  • Schweregrad – Filter auf Critical, High, Medium, Low oder Info
  • Umschalter CWE / Endpoint – gruppiert Findings nach Schwachstellentyp oder nach dem betroffenen Endpunkt
Die Gruppierung nach CWE beantwortet die Frage, welche Fehlerklassen diese Anwendung hat. Die Gruppierung nach Endpunkt beantwortet, welcher Teil der Anwendung am schlechtesten dasteht – meist die nützlichere Sicht, wenn Sie Behebungsarbeiten verteilen.

​
Details zu einem Finding

Öffnen Sie ein beliebiges Finding, um die vollständige Auswertung in fünf Tabs zu sehen.

​
Finding-Details

Beschreibung, geschäftliche Auswirkungen, betroffene Rollen und Benutzer sowie die technische Ursachenanalyse. In der Seitenleiste stehen CWE-Kennung, Schweregrad, CVSS-Score, Target, Endpunkt und die Zahl der erneuten Erkennungen über alle Läufe hinweg.
Der Tab Finding Details zu einem kritischen Finding zur Account-Übernahme mit Beschreibung, Auswirkungen und betroffenen Rollen sowie einer Seitenleiste mit CWE-639, Schweregrad kritisch, einem CVSS-Score von 9,4 und dem betroffenen Target und Endpunkt

​
Angriffskette

Die exakte Abfolge, die der Agent genutzt hat, als nummerierte Schritte. Jeder Schritt nennt den gesendeten Request und die Antwort der Anwendung, sodass Entwicklerinnen und Entwickler den Weg ohne Rätselraten nachvollziehen können.
Der Tab Attack Chain mit vier aufeinanderfolgenden Schritten, die eine Account-Übernahme reproduzieren – von der Registrierung eines Opfer-Accounts bis zur Bestätigung der vollständigen Übernahme

​
Exploit-Skript

Ein ausführbares Skript, das das Finding reproduziert. Führen Sie es gegen Ihr Target aus, um das Problem selbst zu bestätigen – und nach der Behebung erneut, um zu prüfen, ob der Fix hält.
Der Tab Exploit Script mit einem Python-Skript, das das Finding gegen die Zielanwendung reproduziert
Exploit-Skripte führen echte Angriffe aus. Setzen Sie sie nur gegen Systeme ein, für deren Prüfung Sie autorisiert sind, und rechnen Sie damit, dass dabei Daten angelegt oder verändert werden.

​
Behebung

Konkrete Schritte zur Behebung des jeweiligen Findings sowie Verweise auf einschlägige Standards und Leitfäden.
Der Tab Remediation mit vier aufeinanderfolgenden Schritten zur Behebung und einem Abschnitt mit Verweisen auf OWASP-Leitfäden

​
Verlauf

Eine laufübergreifende Zeitleiste für das Finding: wann es zuerst erkannt wurde, wann es erneut auftrat und jede Statusänderung samt Kommentar – jeweils mit der Person, die sie vorgenommen hat. Corgea erkennt dasselbe zugrunde liegende Problem über Läufe hinweg wieder. Taucht ein Finding in einem späteren Pentest erneut auf, wird es mit dem ursprünglichen verknüpft statt als etwas Neues angelegt. Der Verlauf bleibt dadurch eine durchgehende Geschichte.

​
Findings triagieren

Über Current Status halten Sie bei einem Finding Ihre Entscheidung fest. Zur Auswahl stehen: Eine Statusänderung gilt für jede Erkennung desselben Problems: Einmal triagieren aktualisiert also den gesamten Verlauf und nicht nur die geöffnete Zeile. Zusätzlich können Sie Kommentare hinterlassen, um Kontext für Ihr Team festzuhalten.
Closed erscheint zwar als Status, lässt sich aber nicht von Hand setzen. Corgea vergibt ihn automatisch, sobald ein Revalidierungslauf ein Finding nicht mehr reproduzieren kann.

​
Bericht exportieren

Nach Abschluss eines Laufs stellt Export report zwei PDFs bereit.

Technical report

Die vollständige Prüfung inklusive technischer Analyse, Proof of Concept, Exploit-Code und Hinweisen zur Behebung für jedes Finding. Für Ihr Engineering-Team.

Executive report

Dieselbe Prüfung mit denselben Findings, aber ohne technischen Tiefgang, ohne Proof of Concept und ohne Details zur Behebung. Für Kunden, Auditoren und das Management.
Beide Berichte enthalten:
  • eine Vertraulichkeitserklärung und ein Inhaltsverzeichnis
  • eine Management-Zusammenfassung und ein Dashboard der Findings
  • Scope und Methodik, inklusive der eingesetzten Agenten und ihrer jeweiligen Abdeckung, sowie eine ausdrückliche Angabe dessen, was außerhalb des Scopes lag
  • Definitionen der Schweregrade und die empfohlene Maßnahme je Stufe
  • eine Übersichtstabelle aller Findings
  • detaillierte Findings, gruppiert nach Schweregrad
Die Berichte können als Nachweis für Penetrationstests in Audits nach SOC 2 und ISO 27001 dienen und sind dafür gedacht, unverändert an Kunden und Auditoren weitergegeben zu werden. Ob ein Bericht eine konkrete Anforderung erfüllt, hängt vom Umfang Ihres Audits, den von Ihnen gewählten Kontrollen und Ihrem Auditor ab.

​
Nach Fixes erneut validieren

Sobald Sie Fixes ausgeliefert haben, prüfen Sie diese erneut, ohne einen vollständigen Pentest über die gesamte Anwendung zu verbrauchen. Öffnen Sie bei einem abgeschlossenen Lauf das Menü New run und wählen Sie Revalidate Findings. Ein Revalidierungslauf testet ausschließlich die Findings des ursprünglichen Laufs erneut und meldet:
  • Still open – Findings, die er erneut reproduzieren konnte
  • Closed by this run – Findings, die sich nicht mehr reproduzieren ließen und automatisch auf Closed gesetzt werden
1

Findings beheben

Arbeiten Sie die Schritte zur Behebung ab und markieren Sie Findings dabei als Fixed.
2

Erneut validieren

Wählen Sie im abgeschlossenen Lauf New run und anschließend Revalidate Findings.
3

Bestätigen

Findings, die sich nicht mehr reproduzieren lassen, wechseln auf Closed. Alles, was weiterhin reproduzierbar ist, bleibt offen – mit frischen Nachweisen.
Eine Revalidierung setzt einen abgeschlossenen Lauf mit mindestens einem Finding im Status Open oder Fixed voraus. Ein Revalidierungslauf selbst lässt sich nicht erneut validieren – starten Sie stattdessen eine weitere Revalidierung aus dem ursprünglichen Lauf.
Die Revalidierung ist der schnellste Weg, eine Behebung gegenüber Auditoren oder Kunden zu belegen: Sie zeigt, dass derselbe Test, der das Problem gefunden hat, es nicht mehr reproduzieren kann.

​
Benachrichtigungen

Unternehmensadministratoren können nach Abschluss eines Laufs eine AI Pentest Completed-E-Mail erhalten – mit Target, Scan-Modus, Gesamtzahl der Findings und Aufschlüsselung nach Schweregrad. Die Einstellung gilt pro Administrator: Wer die E-Mail nicht möchte, schaltet sie für sich ab, ohne dass das jemand anderen betrifft. Zusätzlich löst Corgea beim Abschluss einen Webhook aus. Damit können Sie Ergebnisse in Slack posten, Tickets anlegen oder eine Release-Pipeline absichern. Details zu Einrichtung und Payload finden Sie unter Webhooks. Revalidierungsläufe versenden keine Abschlussbenachrichtigungen.

​
Häufige Fragen

Einige Stunden, abhängig vom Scan-Modus sowie von Größe und Komplexität Ihrer Anwendung. Deep-Läufe dauern länger als Balanced-Läufe. Sie müssen den Lauf nicht beobachten: Findings werden gespeichert, sobald sie bestätigt sind, und Admins können sich zum Abschluss per E-Mail benachrichtigen lassen.
Ja. Hinterlegen Sie Zugangsdaten am Target, dann prüfen die Agenten authentifizierte Bereiche als angemeldeter Benutzer. Jeder Lauf umfasst zusätzlich unauthentifizierte Tests – Sie erhalten also sowohl die Perspektive eines externen Angreifers als auch die eines angemeldeten Benutzers.
Die Agenten führen echte Angriffe aus und können dabei Daten anlegen, verändern oder löschen. Denial-of-Service und volumetrische Lasttests sind ausdrücklich ausgeschlossen. Für regelmäßige Läufe sollten Sie dennoch eine Staging- oder eine dedizierte Testumgebung bevorzugen.
Targets müssen http oder https verwenden, dürfen keine Zugangsdaten in der URL enthalten und nicht auf localhost, einen privaten Netzbereich oder eine Cloud-Metadatenadresse auflösen. Stellen Sie stattdessen eine erreichbare Testinstanz bereit.
Für diesen Modus ist das Kontingent aufgebraucht. Balanced und Deep werden getrennt gezählt; die verbleibende Anzahl sehen Sie im Seitenkopf und im Dropdown für den Scan-Modus. Zum Aufstocken wenden Sie sich an sales@corgea.com.
Der Status des Laufs nennt den Grund. Am häufigsten liegt es an einem Target, das mitten im Lauf nicht mehr erreichbar war, oder an Zugangsdaten, die nicht mehr funktionieren. Prüfen Sie, ob das Target läuft und die Zugangsdaten aktuell sind, und starten Sie dann einen neuen Lauf.
Nicht zwangsläufig. Es bedeutet, dass die Agenten im Scope keine ausnutzbaren Probleme verifizieren konnten. Wenn Sie Findings erwartet haben, prüfen Sie, ob die Zugangsdaten korrekt sind und authentifizierte Bereiche damit erreichbar waren – und ziehen Sie für eine breitere Abdeckung einen Deep-Lauf in Betracht.
SAST analysiert den Quellcode und findet Probleme, bevor Sie ausrollen. Ein Pentest greift die laufende Anwendung an und weist nach, was in Ihrer ausgerollten Konfiguration tatsächlich ausnutzbar ist. Beide finden unterschiedliche Dinge, und Corgea verfolgt die Findings aus beiden getrennt.

​
Verwandte Themen

BLAST

AI-native SAST, um Schwachstellen im Quellcode schon vor dem Deployment zu finden.

Webhooks

Ereignisse zum Abschluss eines Pentests in Ihren eigenen Systemen empfangen.

Reporting

Die Sicherheitslage Ihrer Organisation im Zeitverlauf verfolgen.

Policies

Festlegen, wie Issues priorisiert und bearbeitet werden.