Domanda Test connettività Metasploit - AIUTO problema tecnico

Stato
Discussione chiusa ad ulteriori risposte.
Ordina per data Ordina commenti per reazioni
N

Netcat

Utente Jade
17 Gennaio 2022
455
129
332
691
Sapete se sperso per internet c'è un server o un forum dove fanno fare i test per la connettività delle backdoor? Una specie di Metasploitable insomma, che però invece di essere una VM locale è un server remoto allestito appositamente. Mi servirebbe perché ho riscontrato durante i miei test che la sessione è stabile (sia in LAN che in WAN) sui computer di casa, ma quando faccio l'esperimento con il computer aziendale la sessione crasha dopo 5 minuti di perfetto funzionamento, e non ne capisco il motivo. Non so se si tratti dun problema di ngrok, di metasploit o della mia connessione (ho provato sia in tethering hotspot con il 4G di TIM che con il router wifi di casa)

Qualcuno di voi che è mai riuscito a creare una sessione stabile e persistente con Metasploit over WAN, che configurazione usare? Cambiare router? Abbandonare ngrok? Rispondete solo se siete sicuri, non voglio essere dirottato fuori strada grazie.
 
Il computer aziendale ha a bordo Antivirus, EDR o simili? E' collegato ad un Active Directory?
Se la configurazione funziona bene col tuo pc personale e il pc aziendale utilizza la stessa configurazione potrebbe essere un "problema" dovuto alle configurazioni di rete dell'azienda (IPS? IDS? WAF? Proxy?).
Non posso avere la certezza che sia la problematica del tuo caso, però ho la certezza che anche queste cose possano influire perchè mi sono capitate, perciò è sempre bene dare un'occhiata.

Non conosco nessuna macchina accessibile pubblicamente per questi test, però potresti provare a prendere un hosting o un'istanza AWS/Azure. AWS mi pare che fornisse anche un piano gratuito molto limitato, potrebbe però fare al caso tuo
 
E' solo un test, AV è disabilitato, anche qualora fosse abilitato è l'ultimo problema. Succede che dopo aver inviato qualche comando alla sessione, a un certo punto fa Error Rex:: Operation TimedOut error. Anche con Verbose -> True l'output è sempre lo stesso, quindi non capisco la natura del problema.
Il payload usato è il reverse_HTTPS, questo payload usa la porta 443, specciando il traffico di Metasploit per richieste HTTPS legali, quindi bypassando tutte le configurazioni di rete ecc. E quindi dico... Ma dov'è il problema? Cioè boh io non lo so, ma un'idea cel'avrei:

- Si potrebbe pagare qualcuno, magari un freelancer, che per 3 ore al giorno sta su Inforge ad aprire le backdoor mettendo a disposizione una sua VM (senza dati critici ovviamente) in modo che noi possiamo testare la connettività. Le aziende di IT security moderne hanno fame di pentesters, quindi secondo me un'iniziativa del genere farebbe aumentare anche di più il prestigio e la popolarità di Inforge, oltre che a essere utile.
 
Ultima modifica:
Ciao

curiosità:

- qualè l'URL e/o l'indirizzo IP con la quale viene inizializzata la connessione HTTPS?
- qual'è l'User Agent String di questa connessione?
- "5 minuti" lo hai scritto così tanto per scrivere oppure è un timing accurato dulla durata della connessione?

Mi sono fatto l'idea di "sandboxing" sulla connessione
 
Per AV disattivato intendi Defender? Perchè quello che descrivi sembra proprio quello, Defender che si allerta e termina il processo, è molto comune con payload non offuscati e ci può mettere un po' di tempo per riconoscere la minaccia ed eliminarla. Se hai un accesso alternativo alla macchina controlla se il payload esiste ancora su disco o se è stato cancellato, come possibile fix migra in un altro processo con il comando migrate appena stabilisci la sessione di meterpreter per salvarti da una possibile terminazione del processo originale, controlla se il timeout si ripresenta.
Alternativamente, riesci a pingare l'host dopo il timeout? Senza ulteriori informazioni sulla rete e sul tuo target non saprei cosa altro proporre.
 
Baud ha detto:
Per AV disattivato intendi Defender? Perchè quello che descrivi sembra proprio quello, Defender che si allerta e termina il processo, è molto comune con payload non offuscati e ci può mettere un po' di tempo per riconoscere la minaccia ed eliminarla. Se hai un accesso alternativo alla macchina controlla se il payload esiste ancora su disco o se è stato cancellato, come possibile fix migra in un altro processo con il comando migrate appena stabilisci la sessione di meterpreter per salvarti da una possibile terminazione del processo originale, controlla se il timeout si ripresenta.
Alternativamente, riesci a pingare l'host dopo il timeout? Senza ulteriori informazioni sulla rete e sul tuo target non saprei cosa altro proporre.
Clicca per espandere...
Già provato, ho fatto AutoRunScript -> migrate -n winlogon.exe (il payload ha UAC access) e Defender è full disabled
Messaggio unito automaticamente:

waido ha detto:
Ciao

curiosità:

- qualè l'URL e/o l'indirizzo IP con la quale viene inizializzata la connessione HTTPS?
- qual'è l'User Agent String di questa connessione?
- "5 minuti" lo hai scritto così tanto per scrivere oppure è un timing accurato dulla durata della connessione?

Mi sono fatto l'idea di "sandboxing" sulla connessione
Clicca per espandere...
- L'indirizzo IP è quello di ngrok perché a causa di limitazioni del mio provider non posso fare portforwarding. Non ho né IP statico né possibilità di rendere disponibile una porta dall'esterno, quindi sono forzato a ngrok;
- User agent casuale, ma nei test locali non crasha mai, quindi sono passato sopra la cosa;
- 5 minuti: sì, è un timing approssimativo. La sessione appena aperta riceve i comandi normalmente, ma ad una certa restituisce il rex:timeout error, e poi crasha. Nonostante la migrazione in winlogon.exe
 
Purtroppo in questo caso il tuo test in locale è poco significativo poichè avviene in condizioni al contorno, leggasi policy di sicurezza, molto diverse rispetto a quelle presenti in azienda. Ma immagino tu lo abbia già preso in considerazione.

Sempre con riferimento alla mia ipotesi di "sandboxing", l'eventuale sistema di protezione della rete potrebbe decidere di interrompere la connessione poichè vede che è diretta ad un indirizzo IP/dominio sospetto/pericoloso e non ha una User Agent String tipica di un browser ... ma è solo un'ipotesi.
In alcune aziende che ho avuto modo di frequentare e in cui so per certo che vengano utilizzate tali discriminanti, una connessione del genere non si sarebbe comunque mai avviata, da qui la mia perplessità sulla mia ipotesi: nel tuo caso la connessione si avvia ma poi viene interrotta.
 
waido ha detto:
Purtroppo in questo caso il tuo test in locale è poco significativo poichè avviene in condizioni al contorno, leggasi policy di sicurezza, molto diverse rispetto a quelle presenti in azienda. Ma immagino tu lo abbia già preso in considerazione.

Sempre con riferimento alla mia ipotesi di "sandboxing", l'eventuale sistema di protezione della rete potrebbe decidere di interrompere la connessione poichè vede che è diretta ad un indirizzo IP/dominio sospetto/pericoloso e non ha una User Agent String tipica di un browser ... ma è solo un'ipotesi.
In alcune aziende che ho avuto modo di frequentare e in cui so per certo che vengano utilizzate tali discriminanti, una connessione del genere non si sarebbe comunque mai avviata, da qui la mia perplessità sulla mia ipotesi: nel tuo caso la connessione si avvia ma poi viene interrotta.
Clicca per espandere...
Quello che dici forse era vero nel mio caso se la connessione crashava immediatamente, qui funziona per un po' e poi cade
Secondo me è un problema di latenza, o di ngrok
 
Stato
Discussione chiusa ad ulteriori risposte.
Top Bottom
Indietro