Metasploit MsfVenom - Payload associa la shell, ma non riesce a generarlo con netcat

2

Esecuzione di uno script di exploit SEH BoF che contiene un payload generato da msfvenom in quanto tale:

msfvenom --payload windows/shell/bind_tcp --format py --arch x86 --platform windows --bad-chars "\x00\x20" EXITFUNC=seh

Dopo aver eseguito lo script contenente il suddetto payload, ho controllato tutte le connessioni attive sulla macchina vittima (WinXp SP3) eseguendo netstat -an, c'è una porta aperta in ascolto su 4444 (la porta predefinita dal payload msf). Tuttavia sulla macchina dell'attaccante (Fedora 27) non ero in grado di generare la shell usando netcat come tale:

nc [victim IP] 4444

dopo aver eseguito il comando precedente il cursore lampeggia appena sotto di esso. E dopo aver premuto invio (invio), nc viene ucciso e così è il programma vulnerabile dal PC della vittima. Qualcuno ha qualche idea?

L'unica spiegazione possibile in questo momento è che il problema si trova all'interno del carico utile di msfvenom? Suppongo che sia perché il carico utile è stato sicuramente eseguito poiché c'era una porta aperta sul 4444 sul PC della vittima. Quindi se il problema non esisteva mentre lo script era in esecuzione, allora deve essere il payload che sta creando il problema, cosa ne pensate voi ragazzi?

    
posta Rennitbaby 13.04.2018 - 08:51
fonte

1 risposta

0

Dopo un po 'di pasticcio con l'attacco, ho notato come l'exploit avrebbe fatto crashare il programma e il messaggio di errore allertato conteneva un modulo chiamato hungapp e offset di 00000000. Altre ricerche sono state fatte, hungapp sembra una funzionalità di sicurezza Microsoft che blocca le connessioni TCP. L'ultimo aggiornamento di sicurezza di Microsoft per il PC della vittima è stato pubblicato il 15/5/2017, che molto probabilmente ha risolto il problema con questo tipo di attacco di Seh.

    
risposta data 14.04.2018 - 01:22
fonte