9

I just finished creating my own remote administration tool "a server to multiple client one" using System.Net.Socket, - "Watch Dogs fan :P"

RAT

then I try to search on google how they make or design their remote administration tool process and I found this Blog by Joseph Bisaillon, In his Basic RAT Design and other RAT Design they used "a multiple server to client",

I'm just curious why the victim use the server instead of the client in their Design? Its better to use the client as the controller? or its the same to server?

RAT Design

KDEx
  • 4,981
  • 2
  • 20
  • 34
Leonel Sarmiento
  • 159
  • 6
  • The C2 would generally be a server hosted remotely from the client in your pic and the zombies, a lot of the time it is within a hosting service that isn't too fussy about who their clients are with a IP(s) from a dodgy ISP or from a hi-jacked range. – TheJulyPlot Aug 27 '15 at 11:51

3 Answers3

7

This is all about the roles of everyone involved. Whether you are browsing a website, or buying a muffin from that cafe you know, the result is the same.

The server isn't the more powerful device, it's the one "serving" requests. The client is just that, the one that makes the requests that need to be served. You are the client when you request a muffin, or a website, or in this case remote access.

As a client you ask "move the mouse here", "open this for me", and "what do you see right now?". Then the server serves you by sending what you asked for. This is the relationship in all RAT applications.

Amateur NetMan
  • 105
  • 8
  • Interestingly [Teamviewer](https://www.teamviewer.com/en/index.aspx) _also_ uses a central login and connection manager server since their app resembles a social networking system combined with RAT. – Amateur NetMan Oct 07 '15 at 02:21
  • I think @Morgoroth's answer better explains the difference between the 2 ideas, and shows that a "C2 Server - Victim Client" scenario only works if you're using a virus to create a bot-net. I hope both our answers help. – Amateur NetMan Oct 07 '15 at 10:04
7

There are no hard set "rules" when building a remote access tool. It depends on the goal and the type of victim machine that you wish to control. The different types of architectures have a lot to do with NAT.

C2 Client - Victim Server

This is the case that you display in your diagram. The C2 initiates the session by reaching out to the victim server. The victim server has to have a publicly routable IP address and have a port open to allow incoming connections.

Cleaver implementations by require a sort of port knocking. Either way the client (C2) is behind NAT and initiates the communication with the server (victim).

C2 Server - Victim Client

This might be what most people think about when they think about RATs. There is a C2 server that listens for incoming connections from victim bots. Most malware reports that you come across will talk about algorithms to produce dynamic C2 server addresses. These types of malware use this type of architecture.

Why one over the other?

Well the goal will dictate the architecture that will be chosen. If you send out a bunch of phishing emails and wait for victims to connect; you will want a C2 server and victim client. However if you want a backdoor into an organization a victim server and a client C2 will mean that changes in firewall rules, internal network architecture, password resets etc will not close your connection allowing you a persistent back door.

KDEx
  • 4,981
  • 2
  • 20
  • 34
3

It isn't better nor worse, it depends on whether the machines you will be compromising will have publicly routable IPs or not.

If they have, then the advantage of them listening and being the server is that you can connect to them from anywhere and your controller/command and control computer doesn't need to be always connected to them - it only talks to them where there is an actual command.

If the target computers don't have a publicly routable IP, as most home computers do (they're behind a NAT), then it's better for your controller computer to be the server and the compromised machines to connect to it, however that has the downside of being less sneaky (a permanent, outgoing connection is more likely to be noticed than a rare, incoming connection like in the first scenario) and your controller computer needs to be always reachable at the same IP - if it suddenly changes, and you have no way of going back to the old IP to regain control of your bots and tell them the new IP, then you lost your bots unless you have another way of contacting them.

Personally though, I'd recommend using a P2P protocol for this - similar to Tor, where bots are interconnected and relay commands to themselves, that way you have no central point of failure and you only need to reach any single bot to control the entire botnet, since it will relay your command to everyone else. Make sure to use signatures, crypto and steganography if possible, to hide your traffic and preventing someone (like security researchers) from forging valid commands and taking control of your botnet.

André Borie
  • 12,706
  • 3
  • 39
  • 76
  • 1
    (a permanent, outgoing connection is more likely to be noticed than a rare, incoming connection like in the first scenario) While this makes a lot of sense: I'd find an open port more suspicious than an outbound connection personally. And P2P is essentially doing both - way more likely to be noticed but as you say no central point of failure. Also nothing to say you cant have a periodic connection to the C2 to look for updated commands – user2867314 Oct 07 '15 at 15:57
  • @user2867314 a periodic connection means you can't send commands in real-time, depending on the purpose of the botnet it can be a problem (let's say it's a DDoS botnet - if would be worthless if an attack needs to wait 4 hours for the bots to receive the command). – André Borie Oct 08 '15 at 01:19