multi-OS RAT

/root

Lt. Commander
Registriert
Okt. 2007
Beiträge
1.285
Hallo,

Ich möchte eine simple Software erstellen die auf (so ziemlich) allen gängigen Betriebssystemen lauffähig ist:
Windows XP/7/8/10/Server
Linux (ubuntu, debian)
BSD (openBSD, FreeBSD) => nur wenn möglich

Die Software soll eine Netzwerkverbindung zu einem Server herstellen und/oder einen Port öffnen über den man vom Server Befehle auf dem Client ausführen kann d.h. RAT = Remote Access Tool

Bevor jemand meckert => Nein ich möchte damit keinen Unfug treiben sondern das Tool bei einer Cyber Defence Übung einesetzen die regelmäßig an unserer Uni veranstaltet wird.
Bei der Übung spielt ein RED gegen ein BLUE Team und ich möchte im Blue Team meine ganzen heterogenen Systeme im Blick haben und im Anlassfall Gegenmaßnahmen einleiten.

Wir haben schon dinge versucht die Powershell, psexec, sshd, metasploit meterpreter, netcat usw. aber das kennt das RED Team schon alles und da kicken sie sofort raus wenn sie ein System übernehmen. Eine kleine und leise executable (die man customizen kann) wäre dafür einfach super. Am besten auch passwort/zertifikatsgeschützt & verschlüsselt in der Übertragung sonst kann man das eben wieder hijacken oder abhören.

Jetzt zu meiner Frage: In welcher Programmiersprache würdet ihr das umsetzen? C? Python?

Grundsätzlich habe ich Erfahrung in C, Java, bash, powershell und die üblichen Skriptpsrachen aber mit Netzwerkprogrammierung leider noch nicht.

Danke und LG!
 
Ich würde das ganze in C schreiben, damit kriegst du schön kleine Binaries hin. Die höhere Logik (z.B. Kommunikation über Sockets, das Befehlsinterface etc.) kannst du dann plattformunabhängig für alle Betriebssysteme schreiben. Du wirst aber nicht umhin kommen, für jedes OS eine eigene Abstraktionsschicht zu schreiben.
 
Du wirst aber nicht umhin kommen, für jedes OS eine eigene Abstraktionsschicht zu schreiben.
Mit python geht das natürlich schon - aber dann liegts als .py im Klartext lesbar vor was der TE wohl vermeiden will ;)

Ich glaub die Sprache ist hier garnicht das Problem... sondern sich klar machen was eigtl erreicht werden soll?
und da kicken sie sofort raus wenn sie ein System übernehmen

Verhindert "migrate <PID#>" nicht genau das bei meterpreter?
Wenn aber jemand auf das System drauf kommt kann er doch eh mit wireshark gucken was läuft und jeden Prozess killen der Kommuniziert.. wie soll man das verhindern? Da nützt auch keine Verschlüsselung solange denen egal ist, evtl zu viel auszuschalten.
Nimm doch OpenBSD - dann kommt wahrscheinlich garnicht erst jemand drauf ;)
 
danke für die Rückmeldungen!

C wäre mein geheimer Favorit nachdem ich da nicht ganz unwissend dastehe - stimmt, der agent muss wohl für windows/linux angepasst werden (z.b. winsock,...)

meterpreter bietet zwar einige funktionen => kann man aber nur bedingt customizen, wird gerne vom AV oder IPS gefressen und alle änderungen sind einfach sehr umständlich. wir möchten das verhalten von persistenz etc. selbst kontrollieren. evt soll der agent auch active defense betreiben wie suid Prozesse beenden etc. das geht mit meterpreter einfach nicht.

natürlich kann man alles wegschießen wenn man root/system auf einem system ist aber man kann es durch customizen schwieriger machen und mit persistenz wenigstens den prozess wiederbeleben. RT hat auch nicht ewig zeit ein System zu analysieren, die müssen unter Zeitdruck ihre Flags holen.

leider können wir uns die systeme nicht aussuchen ;) das sind sinngemäß eher windows xp Gurken mit einem Patchstand von 1970 :D

Ich glaub die Sprache ist hier garnicht das Problem... sondern sich klar machen was eigtl erreicht werden soll?
An den Ideen für die Defense ist es meistens nicht gescheitert sondern einfach daran alle Systeme unter Kontrolle zu bringen. Da müssen 10 Mann ~ 80 Systeme im Auge behalten und wir hatten bis jetzt keine Möglichkeit alle Systeme (halbwegs) einheitlich über die Konsole zu steuern. Mal Windows Patches ausrollen dauert dann einfach ewig wenn nur 50% der Windows PCs in ein AD gejoined sind. Es geht hier vorallem darum mit wenig Vorbereitungszeit alle Systeme auf Knopfdruck bedienen zu können d.h. Befehle absetzen zu können. Das ist eben das große Problem an einem heterogenen Netzwerk.
Ergänzung ()

hab gestern in Visual Studio und C mal den Anfang gemacht und nach einer Stunde hatte ich schon eine interaktive Commandline übers Netzwerk, ging deutlich einfacher als gedacht :) verschlüsselung werde ich evt über XOR abwickeln und jeder client bekommt eben seinen eigenen Schlüssel, sollte für diesen Zweck ausreichen.
 
Zurück
Oben