La shell TCP inversa a 64 bit di Windows non funziona

Question

La shell TCP inversa a 64 bit di Windows non funziona

#1 da (1 voti)

1

Sto inviando shellcode a un binario a 64 bit in esecuzione su una macchina Windows. Questo binario, copia lo shellcode in una regione di memoria eseguibile e lo esegue.

Sto generando lo shellcode usando msfvenom e ho scelto il payload: windows / x64 / shell_reverse_tcp

Sul computer locale, sto ascoltando sulla porta 3004 con netcat.

Quando invio lo shellcode, dal lato listener, ottengo momentaneamente il prompt dei comandi e quindi la connessione viene chiusa immediatamente come mostrato di seguito:

listening on [any] 3004 ...
connect to [192.168.2.10] from (UNKNOWN) [192.168.2.20] 42485
Microsoft Windows [Version 10.0.17134.112]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>

C:\Users\user\Documents\netcat-win32-1.11>

Chiude la connessione così velocemente che non ho la possibilità di digitare un comando.

Nota: non ho accesso all'ambiente lab del server in cui è in esecuzione il binario. Tutto quello che so è che esiste una soluzione di sicurezza in esecuzione su quella macchina che impedisce questo. Tuttavia, conosco i dettagli del binario e che richiede uno shellcode, assegna una nuova memoria, la copia lì e la esegue.

Quindi, quali sono le mie opzioni per aggirare le soluzioni di sicurezza in questo caso?

C'è un problema di blocco delle porte qui perché sono in grado di ottenere la shell inversa attraverso qualsiasi porta. Il problema è che la connessione viene chiusa immediatamente. E non è un problema di rete, c'è una soluzione di sicurezza in esecuzione sul lato server. È un ambiente di laboratorio e quindi lo so.
C'è un modo per configurare nmap per inviare un elenco di comandi non appena riceve risposta dal server?

Grazie

windows shellcode metasploit msfvenom

posta Neon Flash 27.10.2018 - 01:04

fonte

1 risposta

Leggi altre domande sui tag windows shellcode metasploit msfvenom

Public Key Crypto - firma il nome di Bob nel messaggio di Alice o cripta il nome di Alice openssl vs gpg per la crittografia basata su file? Pro contro contro per la sicurezza?

score 1 · Answer 1

Di solito per ottenere inversioni di shell che funzionano le prime porte che uso sono 80 o 443 perché anche con il firewall impostato sulla macchina vittima queste porte di solito funzionano. La ragione è ovvia, che le porte sono utilizzate per navigare su Internet su Internet e anche su configurazioni ristrette possono essere aperte. Se non sono aperti dovresti controllare le porte aperte. Per fare questo supponiamo uno scenario:

Se stai cercando di ottenere un guscio inverso perché hai una specie di RCE. Se disponi di privilegi elevati, puoi controllare la configurazione del firewall (usando iptables su Linux o comandi netsh su Windows) e puoi aprire qualsiasi porta necessaria.

Anche se non disponi di privilegi elevati, puoi provare a leggere la configurazione del firewall per vedere se ci sono porte aperte sulle connessioni in uscita. Per Windows puoi controllare questo usando comandi come questo: netsh advfirewall firewall show rule dir=out name=all status=enabled . Questo mostrerà tutte le regole in uscita e quindi puoi provare a cercare una porta aperta.

Se hai un accesso limitato molto strano o strano e non sei in grado di controllare la configurazione del firewall, puoi comunque eseguire "bruteforce" per verificare se è aperta una qualsiasi porta per le connessioni in uscita. Puoi prima preparare l'ascolto della tua macchina attaccante in molte porte: for j in {1..1000}; do nc -lvnp $j & done e poi puoi eseguire un ciclo sul computer vittima che sta tentando di connettersi alla macchina attaccante. Se la macchina vittima è Linux, puoi eseguire un ciclo di bash usando netcat. Se è Windows dipende dal software disponibile (forse hai netcat per windows, o openssl o qualsiasi altro strumento) ed è possibile eseguire un ciclo batch cercando di connettersi alla tua macchina. Quindi puoi verificare se una qualsiasi porta è stata connessa correttamente lanciando un comando netstat sulla tua macchina locale e filtrando per vedere solo le connessioni ESTABLISHED, ma come ho detto questo è solo per ambienti molto strani ed è un modo disperato di trovare una porta aperta in uscita.

Spero che ti aiuti.

Modifica

Come stai ascoltando su netcat? fai nc -lnvp <port> per evitare la risoluzione del nome host di dns (il parametro -n) perché sul tuo caso sembra che ci sia un qualche tipo di problema con questo.

EDIT2

Dopo aver controllato i tuoi commenti e la tua modifica sulla domanda, sembra che tu abbia detto che una soluzione di sicurezza sta bloccando la connessione una volta stabilita. Non è correlato a cose firewall. Forse puoi provare a codificare il tuo payload per evaderlo (forse è un antivirus che lo blocca una volta eseguito). Per questo puoi provare shellter o unicorno invece di usare msfvenom. Shellter funziona bene su Linux usando il vino. Le soluzioni che codificano per i payload sono molto buone per eludere gli AV. Provalo!