Ho appena finito di creare il mio strumento di amministrazione remota "un server su più client uno" utilizzando System.Net.Socket , - "Fan di Watch Dog: P"
poiprovoacercaresugooglecomefannooprogettanoilloroprocessodiamministrazioneremotaehotrovatoquesto
Sono solo curioso di sapere perché la vittima usa il server al posto del client nella sua progettazione? È meglio usare il client come controller? o è lo stesso per il server?
Non ci sono regole "fisse" quando si costruisce uno strumento di accesso remoto. Dipende dall'obiettivo e dal tipo di macchina vittima che desideri controllare. I diversi tipi di architetture hanno molto a che fare con NAT .
Client C2 - server vittima
Questo è il caso che viene visualizzato nel diagramma. Il C2 avvia la sessione raggiungendo il server della vittima. Il server delle vittime deve avere un indirizzo IP pubblicamente instradabile e avere una porta aperta per consentire le connessioni in entrata.
Le implementazioni di Cleaver richiedono una sorta di port knocking . In entrambi i casi il client (C2) è dietro NAT e avvia la comunicazione con il server (vittima).
C2 Server - Victim Client
Questo potrebbe essere ciò a cui pensa la maggior parte della gente quando pensa ai RAT. C'è un server C2 che ascolta le connessioni in arrivo dai bot delle vittime. La maggior parte delle segnalazioni di malware che incontrate parleranno di algoritmi per produrre indirizzi di server C2 dinamici. Questi tipi di malware utilizzano questo tipo di architettura.
Perché uno sull'altro?
Bene, l'obiettivo determinerà l'architettura che verrà scelta. Se invii un sacco di e-mail di phishing e aspetti che le vittime si connettano; vorrai un server C2 e un client vittima. Tuttavia, se si desidera una backdoor in un'organizzazione, un server vittima e un client C2 significheranno che le modifiche alle regole del firewall, l'architettura di rete interna, le reimpostazioni di password ecc non chiuderanno la connessione, consentendo una backdoor persistente.
Tutto riguarda i ruoli di tutte le persone coinvolte. Sia che tu stia navigando su un sito web, sia che acquisti un muffin da quel bar, sai, il risultato è lo stesso.
Il server non è il dispositivo più potente, è quello che "serve" le richieste. Il client è proprio questo, quello che rende le richieste che devono essere soddisfatte. Sei il cliente quando richiedi un muffin o un sito web o, in questo caso, l'accesso remoto.
Come cliente chiedi "sposta il mouse qui", "apri questo per me" e "cosa vedi adesso?". Quindi il server ti ti serve inviando ciò che hai chiesto. Questa è la relazione in tutte le applicazioni RAT.
Non è meglio né peggio, dipende dal fatto che le macchine che si stanno compromettendo abbiano IP pubblicamente instradabili o meno.
Se lo sono, il vantaggio di chi ascolta e di essere il server è che puoi connetterti da qualsiasi parte e il tuo controller / comando e computer di controllo non ha bisogno di essere sempre connesso a loro - parla solo con loro dove c'è un vero comando.
Se i computer di destinazione non hanno un IP instradabile pubblicamente, come fa la maggior parte dei computer domestici (sono dietro un NAT), allora è meglio che il computer controller sia il server e le macchine compromesse per connettersi ad esso, tuttavia questo ha il rovescio della medaglia di essere meno subdolo (una connessione permanente, in uscita è più probabile che venga notata rispetto a una rara connessione in ingresso come nel primo scenario) e il computer del controller deve essere sempre raggiungibile allo stesso IP - se improvvisamente cambia, e non hai modo di tornare al vecchio IP per riprendere il controllo dei bot e dire loro il nuovo IP, quindi hai perso i bot a meno che tu non abbia un altro modo di contattarli.
Personalmente, tuttavia, raccomanderei di utilizzare un protocollo P2P per questo, simile a Tor, dove i robot sono interconnessi e inoltrano i comandi a se stessi, in questo modo non hai un punto centrale di errore e devi solo raggiungere un singolo bot per controlla l'intera botnet, poiché trasmetterà il tuo comando a tutti gli altri. Assicurati di utilizzare firme, crittografia e steganografia se possibile, per nascondere il tuo traffico e impedire a qualcuno (come i ricercatori di sicurezza) di falsificare comandi validi e assumere il controllo della tua botnet.