Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
purpleteam-s2-containers — Stage two containers | Kitploit
Tools/GitLabGitLab/purpleteam-labs/purpleteam-s2-containers
Vulnerability ScannersContainer SecurityDynamic Analysis (Sandboxing)Web SecurityPenetration TestingCloud SecurityDevSecOpsLearning & EducationArchived

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
GitLabpurpleteam-labs/purpleteam-s2-containers

purpleteam-s2-containers

Stage two containers

Repository anzeigen
1vor 5 JahrenNoch nicht geprüft

purpleteam Logo

purpleteam Stage Two Container


Stage Two Container von purpleteam




Diese Container werden dynamisch basierend auf der Build-Benutzerkonfiguration (Job) gestartet, die über die purpleteam CLI bereitgestellt wird, insbesondere der Anzahl der von Ihnen definierten testSessions.

Die folgenden Konfigurationen sind relevant, wenn Sie beabsichtigen, das purpleteam Backend in der local-Umgebung auszuführen. In der cloud wird dies alles für Sie erledigt.

Klonen Sie dieses Repository.

Definieren Sie die Umgebungsvariablen

app-slave (Zap)

Wir verwenden eine .env-Datei direkt im app-slave-Verzeichnis zum Testen.

ZAP_API_KEY

Stellen Sie sicher, dass Sie der Umgebungsvariable ZAP_API_KEY einen Wert zugewiesen haben.

Der ZAP_API_KEY kann von Ihnen frei gewählt werden, stellen Sie nur sicher, dass Sie ihn nicht nur für app-slave definieren, sondern auch in der app-scanner-Projektkonfiguration hinzufügen. Das app-scanner-Projekt benötigt den Zap-API-Key zur Authentifizierung gegenüber Zap, der im Stage Two Container läuft. Für das app-scanner-Projekt muss dies wie folgt gesetzt werden:
{ "slave": { "apiKey": <zap-api-key-here> } }

HOST_ZAP_LOG4J_PROPERTIES_PATH und ZAP_LOG4J_PROPERTIES_PATH_MOUNT_TARGET

Wenn/sobald Sie Zap-Debug-Logs benötigen, müssen Sie auch die Umgebungsvariablen für die LOG4J-Debug-Konfiguration hinzufügen.

.env-Datei

Wenn Sie sich für eine .env-Datei entscheiden, würde das Hinzufügen all dieser Umgebungsvariablen wie folgt aussehen:

root@kitploit:~
ZAP_API_KEY=<zap-api-key-here>
HOST_ZAP_LOG4J_PROPERTIES_PATH=<absolute-path-to/purpleteam-s2-containers/app-slave/log4j.properties>
ZAP_LOG4J_PROPERTIES_PATH_MOUNT_TARGET=/home/zap/.ZAP/log4j.properties

Debugging

app-slave (Zap)

Debug-Logging

Vorausgesetzt, Sie haben die oben besprochenen Umgebungsvariablen eingerichtet:

Um das Debug-Logging für die app-slave (Zap)-Container zu aktivieren, die in der local-Umgebung laufen, kommentieren Sie das volumes-Array und das Element mit dem source-Schlüssel und der Umgebungsvariable HOST_ZAP_LOG4J_PROPERTIES_PATH aus.

Details unten zur eigentlichen Anzeige der Logs.

Interaktion mit Zap

Sie können während der Ausführung Ihrer Tests mit Zap interagieren (die Zap-Benutzeroberfläche abfragen). Wir fanden dies in der Vergangenheit nützlich, um den Zustand von Zap beim Debuggen des app-scanner zu überprüfen.

  1. Überprüfen Sie, ob der Container appslave_zap_[n] läuft, mit:
    root@kitploit:~
    docker stats
    
  2. Überprüfen Sie, an welchen Host-Port der Container appslave_zap_[n] gebunden ist, mit:
    root@kitploit:~
    docker container ls
    
    Dies kann jeder Port zwischen 8080-8091 sein, wie in der docker-compose.yml definiert.
    Der Port, auf dem Zap im Container lauscht, ist immer 8080
  3. Richten Sie in Ihrem Browser mit FoxyProxy einen Proxy auf localhost:[zap-host-port] ein
    FoxyProxyDetails_Zap-min
    Optional: Richten Sie das folgende URL-Muster in FoxyProxy ein: zap:8080/*
    FoxyProxyURLPattern_Zap-min
    Wenn Sie das URL-Muster verwenden, können Sie FoxyProxy eingeschaltet lassen und "Use proxies based on their predefined patterns and priorities" auswählen. Andernfalls können Sie einfach den spezifischen von Ihnen erstellten Proxy auswählen
  4. Navigieren Sie zu http://zap:8080/
    Ihre Anfragen werden über Ihren Host-Port weitergeleitet und von dem zap-Prozess im Container beantwortet, der durch den Host-Port in Ihrer FoxyProxy-Konfiguration angegeben wird

selenium-standalone

Debug-Logging

Um das Debug-Logging für die Selenium-Container zu aktivieren, die in der local-Umgebung laufen, kommentieren Sie das environment-Array und das Element SE_OPTS=-debug für chrome und/oder firefox aus.

Details unten zur eigentlichen Anzeige der Logs.

Browser im Selenium-Container anzeigen

Das Folgende beschreibt, was Sie tun müssen, um den Browser in einem der von diesem Projekt ausgeführten Selenium-Container anzuzeigen.

docker-compose.yml Einrichtung:

  • Tauschen Sie die Container-Images gegen die -debug-Images aus. Die -debug-Images sind möglicherweise auskommentiert. Kommentieren Sie daher einfach das übliche Image aus und das Image mit angehängtem -debug ein.
  • Stellen Sie sicher, dass Sie auf den VNC-Server im Container zugreifen können, indem Sie den 5900-Portbereich auskommentieren. Durch die Angabe eines Bereichs als externen Port (z.B. 5900-5901) können Sie gleichzeitig per VNC auf mehrere Container zugreifen. Im Beispiel haben wir zwei gleichzeitige Sitzungen zugelassen. Wenn Sie mehr als zwei per VNC erreichen möchten, erweitern Sie einfach den externen Portbereich.

VNC-Client Einrichtung:

  1. Sie benötigen einen VNC-Client, um eine Verbindung zum VNC-Server im Container herzustellen. Wir hatten Erfolg mit dem Remmina Remote Desktop Client unter Linux Mint. Installieren Sie das Remmina-plugin-vnc über den Software-Manager

  2. Starten Sie Ihren Remmina Remote Desktop Client

  3. Erstellen Sie neue Einträge. Wenn Sie beabsichtigen, per VNC auf mehrere Selenium-Container gleichzeitig zuzugreifen, könnten Sie jeden wie folgt einrichten:

Weitere Details auf dem SeleniumHQ github

Browser im Selenium-Container anzeigen

Sobald die Selenium-Container laufen (Es ist praktisch, docker stats in einem Terminal offen zu lassen, um dies zu sehen), können Sie mit docker container ls überprüfen, welcher Selenium-Container welchen externen Port verwendet. Docker weiß nicht, welche Ports Sie welchen Ihrer VNC-Client-Einträge zugewiesen haben. Der Name eines bestimmten VNC-Client-Eintrags stimmt möglicherweise nicht mit dem gleichnamigen Selenium-Container überein. Aus diesem Grund ist es ratsam, die Port-Zuordnungen mit docker container ls zu überprüfen.

Um zu korrelieren, welcher Selenium-Container für welche Test-Sitzung verwendet wird, wenn Sie mehrere Test-Sitzungen haben, müssen Sie möglicherweise das laufende app-scanner-Log überprüfen. Möglicherweise müssen Sie auch sicherstellen, dass der app-scanner auf Log-Level debug konfiguriert ist, um einige oder mehr der folgenden Log-Meldungen zu sehen:

[app.parallel] cucCli process with PID "28" has been spawned for test session with Id "lowPrivUser"

[app.parallel] cucCli process with PID "34" has been spawned for test session with Id "adminUser"

[pid-28,world] seleniumContainerName is: seleniumstandalone_chrome_1

[pid-34,world] seleniumContainerName is: seleniumstandalone_chrome_2

In diesem Beispiel haben wir zwei Test-Sitzungen in unserer Build-Benutzerkonfiguration (Job) konfiguriert. Eine hat die id lowPrivUser und die andere adminUser. In diesem Beispiel hat die Test-Sitzung lowPrivUser einen Prozess mit PID 28 und die Test-Sitzung adminUser einen Prozess mit PID 34.
In den nächsten beiden Log-Meldungen sehen wir durch Korrelation der PIDs, dass die Test-Sitzung lowPrivUser einen Container namens seleniumstandalone_chrome_1 ausführt und die Test-Sitzung adminUser einen Container namens seleniumstandalone_chrome_2.
Es gibt keine Garantie, welche Test-Sitzung welchen der seleniumstandalone_chrome_[n]-Container ausführt. Wenn Sie sicher sein müssen, verwenden Sie diese Korrelationstechnik.

Um per VNC auf die Selenium-Container zuzugreifen, sobald Remmina läuft, doppelklicken Sie einfach auf einen oder mehrere der oben erstellten VNC-Einträge. Sie sollten dann den Browser sehen können, mit dem interagiert wird... vorausgesetzt, die Cucumber-Test-Schritte im app-scanner sind tatsächlich an diesem Punkt angelangt.
Sie können natürlich Ihre Tests verlangsamen, anhalten oder mit einem Debugger Schritt für Schritt durchgehen. Details dazu finden Sie im purpleteam-Wiki auf der Workflow-Seite.

Weiterleitung und Ansicht von Container-Logs

local können Sie docker stats laufen lassen, wenn Sie sehen möchten, welche Container laufen und wann sie gestartet und gestoppt werden. Dies gibt Ihnen auch ihre Namen für die folgenden Befehle.

Um die Stage Two Container-Logs anzuzeigen, tailen Sie stdout (und stderr, da Docker stdout und stderr zusammenführt) eines Containers:

root@kitploit:~
docker logs --follow [container-name]

Wenn Sie diese Logs auch in eine Datei senden möchten:

root@kitploit:~
docker logs --follow [container-name] |tee output.log$(date '+%Y-%m-%d_%T')

Wenn Sie diese Logs in eine Datei senden möchten, ohne sie im Terminal zu sehen:

root@kitploit:~
docker logs --follow [container-name] > output.log$(date '+%Y-%m-%d_%T')
Tool herunterladen
SchlüsselWert
Nameseleniumstandalone_chrome_1
ProtokollVNC - Virtual Network Computing
Im Reiter Basic
Server127.0.0.1:5900
Passwortsecret
FarbtiefeTrue color (24 bit) # Dies war die einzige, die bei uns funktioniert hat
QualitätPoor (fastest)
SchlüsselWert
Nameseleniumstandalone_chrome_2
ProtokollVNC - Virtual Network Computing
Im Reiter Basic
Server127.0.0.1:5901
Passwortsecret
FarbtiefeTrue color (24 bit) # Dies war die einzige, die bei uns funktioniert hat
QualitätPoor (fastest)