Zum Inhalt wechseln

Willkommen Gast

Navigation

Links

Als Gast hast du nur eingeschränkten Zugriff!


Anmelden 

Benutzerkonto erstellen
Du bist nicht angemeldet und hast somit nur einen sehr eingeschränkten Zugriff auf die Features unserer Community.
Um vollen Zugriff zu erlangen musst du dir einen Account erstellen. Der Vorgang sollte nicht länger als 1 Minute dauern.
  • Antworte auf Themen oder erstelle deine eigenen.
  • Schalte dir alle Downloads mit Highspeed & ohne Wartezeit frei.
  • Erhalte Zugriff auf alle Bereiche und entdecke interessante Inhalte.
  • Tausche dich mich anderen Usern in der Shoutbox oder via PN aus.
 

   

Foto

[VX] C2 Kommunikationsprotokolle

- - - - - http spdy mqtt zmq xmpp c2 malware spyware https

  • Bitte melde dich an um zu Antworten
6 Antworten in diesem Thema

#1
sub0

sub0

    Hacktivist

  • Premium Member
  • Likes
    32
  • 63 Beiträge
  • 13 Bedankt
  • Android
  • Windows, Linux

Hey Leute, ich würde gerne von euch hören, welche Protokolle eure Favoriten sind oder mit welche ihr gute/schlechte Erfahrungen ihr gemacht habt.
 
Ich persönlich liebe HTTP(S). Ich Liste hier einige Punkte auf und bin offen für eure Kritik und alternative Methoden.
 
Vorteile

  • Es ist ein Klartext Protokoll
  • Es ist auf dem TCP/IP Layer aufgebaut (Keine eigene Socket Programmierung nötig)
  • (Fast) Jede Programmsprache hat ein HTTP Client Library
  • Es ist sehr leicht zu bedienen und selbst zu implementieren (falls keine Libs zur Verfügung stehen)
  • Sollte via Reverse Conncetion ohne Probleme durch jede Firewall durchkommen
  • Den Server Part können, vorhande Webserver übernehmen. (z.B. NGINX, Apache, etc)
  • Durch TLS/SSL-Zertifikate ist die Verbindung mit dem Webserver (C2) verschlüsselt (Cert-Pinning bzw. Fingerprint Verifizierung implementieren nicht vergessen!)
  • Mit Reverses-Proxies (nginx) und Redirector (z.B. socat) kann man den Haupt C2 Standort verschleiern

Nachteile

  • Webserver kann nicht "pushen" der Client muss nach neuen Befehlen "requesten"
  • Bidirektionale Verbindungen sind nicht so ohne weiteres möglich (Abhilfe vielleicht mit Websockets oder HTTP/2 ?)
  • Dadurch dass HTTP/1.x ein Klartext Protokoll ist, entsteht oft sehr viel unnötiger und wiederholter Traffic

Alternativen

  • HTTP/2 und SPDY
  • MQTT oder ZMQ
  • XMPP

 

Jetzt seid ihr dran. Postet eure Meinung/Kritik und eure Favoriten und bitte mit Begründung, damit wir alle mitlernen.


/dev/zero - PN für XMPP


#2
abrax

abrax

    Noob

  • Members
  • PIPPIP
  • Likes
    2
  • 13 Beiträge
  • 0 Bedankt

Würde da eindeutig auf HTTPS setzen. Die negativ-behaftete Bidirektionalität kannst du mit Websockets implementieren. Wiederholter Traffic lässt sich über einen Round-Robin vermeiden, kannst da theoretisch auch neuere Methoden nutzen, C2 Kommunikation via:

 

- Google Translator:

Please Login HERE or Register HERE to see this link!

- Github:

Please Login HERE or Register HERE to see this link!

 

Da geht dein malicious Traffic "dann unter".

Zu den Alternativen:

 

- HTTP/2 => Leider noch etwas holprig und kaum Standart, würde daher eher auffallen, selbiges für SPDY/MQTT/ZMQ und Jabber


  • sub0 gefällt das

#3
im_nobody

im_nobody

    Lamer

  • Members
  • PIPPIPPIP
  • Likes
    19
  • 21 Beiträge
  • 2 Bedankt
  • Android [root]
  • Linux

Vorteil:

- HTTPS  ist im Vergleich zu anderen Protokollarten recht unauffällig

 

Nachteil:

- Botnetze deren C&C Server auf einem Webserver laufen und auf das DNS angewiesen sind, sind sehr anfällig für DNS Sinkholing

- Ip/Domain könnte in einem Firewall Filter aufgenommen werden (z.B. von Spamfilter), somit sind diese Bots "tot".

- IP/Domain vom C&C kann leicht ermittelt werden

 

 

Durch TLS/SSL-Zertifikate ist die Verbindung mit dem Webserver (C2) verschlüsselt (Cert-Pinning bzw. Fingerprint Verifizierung implementieren nicht vergessen!)

 

Viele Firewalls bieten eine DPI Funktion an und können zumindest Teile des Traffics mitlesen!

 

P2P Botnetze:

Vorteile:

- Dezentral

- Bots können als Proxys agieren und somit dazu beitragen die Identität des C&C Servers zu verschleiern.

 

Nachteile:

- Fehler in der Verschlüsselung der Kommunikation oder in der Authentifizierung ermöglicht es Angreifern eigene Befehle an die Bots zu versenden

 

Man könnte für die Kommunikation auch das DNS-Protokoll verwenden :896:


  • sub0 gefällt das

Where there is a Shell, there is a way


#4
IRET

IRET

    Script Kiddie

  • Members
  • PIPPIPPIPPIP
  • Likes
    47
  • 25 Beiträge
  • 1 Bedankt

Man sollte immer praktisch denken bei sowas.

 

Websockets sind etwas anstrengender als HTTP zu implementieren. Indem man das Timeout beim HTTP setzt kann man 1 Verbindung offen lassen für Push-Nachrichten, während diverse Anfragen zum C&C über einen weiteren Request gesendet werden.

 

Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen. Außerdem sind lokal installierte CAs mit Interceptors da ein Problem wenn Traffic nicht mitgelesen werden soll.

 

 

Die Protokolle bestimmt man dann aber eh je nach Anwendungsgebiet und da gehört die Malware-Szene jetzt nicht zu den Inventoren. P2P-Botnetze sind unrealisitisch für den kleinen Mann. Die meisten Router haben mittlerweile standardmäßig UPnP aus und Malware die auf Server aus ist ist sowieso entweder ein Reinfall (HF Booter zB) oder was für große Projekte.

 

DNS-Protokoll für die Kommunikation dürfte ich was verpasst haben. Ich kenne da nur DNS-Cache-Bruteforce (wenn Antwort schneller kommt, wurde die von wen anderen vorher angefragt).

Was mir da einfällt ist aber NTP mit dem monlist Command. Da werden bis zu 600 Hosts gelistet die zuletzt mit dem NTP-Server kommuniziert haben. Ist aber wegen der Nutzung von NTP Amplification Floods weniger geworden (aber gibt es noch).


  • DR.zydz gefällt das

#5
sub0

sub0

    Hacktivist

  • Premium Member
  • Likes
    32
  • 63 Beiträge
  • 13 Bedankt
  • Android
  • Windows, Linux

Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen. Außerdem sind lokal installierte CAs mit Interceptors da ein Problem wenn Traffic nicht mitgelesen werden soll.

Da muss ich dir widersprechen. DNS Anfragen zu einer Domain werden nicht verschlüsselt. Alles andere was mit HTTP(S) zu tun hat, ist TLS/SSL-Verschlüsselt. Ich lasse mich aber gerne belehren in der Hinsicht.

 

Die Protokolle bestimmt man dann aber eh je nach Anwendungsgebiet und da gehört die Malware-Szene jetzt nicht zu den Inventoren. P2P-Botnetze sind unrealisitisch für den kleinen Mann. Die meisten Router haben mittlerweile standardmäßig UPnP aus und Malware die auf Server aus ist ist sowieso entweder ein Reinfall (HF Booter zB) oder was für große Projekte.

Ja, da stimme ich dir zu. Je nach Anwendung sollte die Malware/Spyware programmiert werden, außer natürlich man will etwas generisches programmieren.
 

DNS-Protokoll für die Kommunikation dürfte ich was verpasst haben. Ich kenne da nur DNS-Cache-Bruteforce (wenn Antwort schneller kommt, wurde die von wen anderen vorher angefragt).

Ja, doch nennt sich DNS Exfiltration, DNS Tunneling, etc. Google mal danach, sehr interessantes Thema.


/dev/zero - PN für XMPP


#6
abrax

abrax

    Noob

  • Members
  • PIPPIP
  • Likes
    2
  • 13 Beiträge
  • 0 Bedankt

 

 Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen

 

Das ist leider nicht korrekt. "HTTPS" requests sind "HTTP requests" über eine verschlüsselte (SSL/TLS) TCP Verbindung. "URLs" oder "GET-Parameter" sind Bestandteile vom HTTP Header (Location) und somit verschlüsselt.

 

 

- Botnetze deren C&C Server auf einem Webserver laufen und auf das DNS angewiesen sind, sind sehr anfällig für DNS Sinkholing

 

DGA Generation könnte da Abhilfe schaffen, beschrieben z.B. hier:

Please Login HERE or Register HERE to see this link!



#7
sup3ria

sup3ria

    Hacker

  • Premium Member
  • Likes
    115
  • 181 Beiträge
  • 46 Bedankt

Kann dir HTTP/2  gRPC streams mit protobuf empfehlen.

 

Verwende Ich in produktion seit einigen jahren fuer IoT wo man auch keine Firewall usw auschalten kann.


 

 

Bei HTTPS sollte man aber beachten dass URLs nicht vercshlüsselt werden. Also GET-Parameter werde im Klartext übertragen.

Die Parameter werden bei GET sehrwohl verschluesselt nur nicht der Host.


Bearbeitet von sup3ria, 03 Dezember 2019 - 22:17 Uhr.




  Thema Forum Themenstarter Statistik Letzter Beitrag

Auch mit einem oder mehreren dieser Stichwörter versehen: http, spdy, mqtt, zmq, xmpp, c2, malware, spyware, https

Besucher die dieses Thema lesen: 1

Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0

Die besten Hacking Tools zum downloaden : Released, Leaked, Cracked. Größte deutschsprachige Hacker Sammlung.