 Hello, everybody. Welcome to this talk. My name is Jose Carduño, and the title of the talk is C2 Centipede. It's actually the name of a tool I made to try to evade certain type of blue team detection strategies. A little bit about me. Okay, I was born in Mexico. I took a small detour. I ended up in Switzerland after 15 years of wandering around. I'm a senior security consultant for dream lab technologies. And I have been in the Audi team since the year 2014. So basically pen testing, infrastructure applications, and so on. I've been a speaker previously in other conferences. I would actually recommend you, especially the ones in Latin America. Very nice and fun places to be. Okay, so let's start. Why are you here? Why are you watching this? So you are a red teamer, and you want to know how your tools work. You want to know how you can exploit or empire. And a little bit of how it works. It's magic to you. Like how do you get the shell? What's happening behind the scenes? Also, it could be that you are not an APT, but you want to emulate more advanced scenarios than what the default vanilla metasploit or empire can give you. Interactive shell without getting detected by your tools beaconing. Okay, so this is one reason for the red teamers. And for the blue team, of course, how can you catch the bad guys now? I will talk about some techniques, how you can do it right now. And of course, with the techniques presented here, what's maybe coming next. So you can see what the bad guys are planning. So the context of these, basically, I just approached the blue team, the sock team at Dream Lab because I wanted to learn their techniques. Basically, I'm a little bit maybe sometimes too focused on the offensive part and just hope they don't catch you. So this was a little bit of finding out what the blue team is doing now, what techniques they use, what tools they use, and maybe how I could evade them. The talk is about this journey to try to evade the blue team detection on the network only. So I will not talk about antivirus evasion or any other host-based evasion. In this tool, I implemented some techniques used by APTs. And I will briefly go over some vulnerabilities I discovered along the way. Okay, so the basic objectives as an adversary, especially, let's say a red team adversary, is to maintain access in the organization and to have this interactive command with the host inside the organization and maybe exfiltrate some data. You also want to have a resilient command and control infrastructure. So basically, maybe the blue team will try to block you or they will try to bring down your infrastructure as well. And then how can you do this while staying as anonymous as possible? So we will discuss that as well. So basically, I just started surveying what techniques are APTs using. Most of them are used with botnets, so fast flux networks where there is a domain name that responds with several or very many IPs to every request they get. So this is why they get the name fast flux. And basically, botnets, for example, have or they install a proxy. So they can use all of these infected hosts to proxy the traffic from the victim to the command and control server. Also they use, especially for botnets as well, domain generation algorithms. So basically, adversaries don't have to hard code at the main name that maybe if they do reverse engineering, they can maybe sync hold it, or if they add some hard coded IPs, they can just perform some maybe a sandbox analysis or something like this and get the IP and then just block it, right? So this is why they use domain generation algorithms. Also, a very common technique for hiding malicious traffic is domain fronting. And I will talk about that and how all of this is somehow integrated in the tool. So let's talk about shells. So basically, a shell allows you to execute interactive commands in a host, right? That you have already owned via phishing or exploit or something like this. There are basically two types of shells, the bind shell, which listens on the target or on the victim. Basically, the malware opens a port on the victim host and then the attacker connects to the victim in that port and starts executing commands there. This works when there is not a firewall here or maybe this user is knotted. So the attacker has difficulty reaching the victim inside this knotted network or through this firewall. So the alternative is a reverse shell. A reverse shell is the other way around. Instead of the attacker connecting to the victim, the roles are reversed. So the attacker opens a port in his machine or in a server he controls and then the malware he executes on the victim makes the connection back to his server. Some types of reverse shells, a basic simple TCP connection like I just talked about with NetCut or this very simple, very typical bash reverse shell. Another way is to have HTTP reverse shell. So basically here the attacker hosts an HTTP service and the victim connects to it asking for commands to execute. So basically the victim connects, says, do I have something to execute? The server says then, yes, you can execute this. The victim will execute it and will send the result back to the attacker. Why choose reverse HTTP shells? So outgoing HTTP traffic is usually allowed in enterprise networks. There is a lot of traffic to blend in. There are also different very wide variety of content inside this HTTP traffic where you can hide your command and control communications. Additionally, techniques like domain fronting can help you hide this malicious traffic. Then let's look at a specific example on how Metasploit reverse shell payload works. So basically you have here the Metasploit handler and in the other side you have a meterpreter or the Metasploit Trojan. When you execute the Trojan it makes a request, a GET request to the server asking if there are any commands that it needs to execute. If they are not the server response with the HTTP response, there is nothing you should execute. The Trojan then waits for 10 seconds and it asks again the same thing. In the meanwhile an attacker can say, okay, I want this Trojan to actually execute this command. So the next time the meterpreter goes to the HTTP server and asks, do you got a command for me, this HTTP server will actually respond, yes, I have a command that I need you to execute. So the Trojan will execute it and then will post with the HTTP post request, will post the result. So as you can see there are like this very continuous request. This is called a beacon. How is actually the beacon implemented in Metasploit? So I said 10 seconds before, it's a little bit more complicated than that, but not so much. So when the Trojan of Metasploit, the meterpreter connects to the server, the initial interval between each connection is about one-tenth of a second. So 100 milliseconds and every time the Trojan doesn't get any task to execute, it adds another 100 milliseconds. So the interval starts growing until it's 10 seconds. After it's 10 seconds, it just keeps the interval at 10 seconds. So it just asks, do you have a task for me? No, do you have a test for me? No, and so on every 10 seconds. When it actually has a task for this Trojan, then the delay becomes again 100 milliseconds and then starts increasing the interval. You can see how it's implemented actually in the Python meterpreter, in the Java meterpreter and so on. So how do you detect these with very simple statistics? There is a great project called RITA, a tool to detect this beaconing behavior. So they use basically just statistics with this interval, the sizes and so on. It's made by Active Countermeasures. They have some threat hunting labs where you can actually test all of this. You can install SecurityOnion, which is a distribution that, I could say it's like the Kali for Blue Team. So if you want to test all of these tools like RITA, Kivana and all of that, it's a very easy way to test it actually. If you want to learn a little bit more about beaconing, you should really check these resources. So the beaconing detection in RITA, actually the source code, it's in GitHub and it's very well documented actually. You can see here how they are basically scoring the beacons. They do a scoring based on interval of each of the connections, the number of the connections between two hosts, the data size of the data in these connections, the dispersion which is like, okay, you have intervals of 10 seconds, but maybe you vary by maybe plus minus two seconds around this 10 second interval. So that's the dispersion. The really great thing is that it's protocol independent. So you can have a Trojan that connects via DNS or one that connects via HTTP or a custom TCP or whatever protocol and it will be still detected by RITA because they just focus on the connections, not in the content of the connections. So the thing is I saw that RITA focuses on IP pairs. So basically you have a source of the communication and then a destination. So this is basically saying that you will have your compromised host on one side and then just one command and control server. This is the usual case actually. So this is where the whole idea of implementing this tool was born actually. So what are the possible evasion strategies for RITA? So I thought maybe if I become less of them, I can reduce the score. Also, if I modify the interval and add some jitter, which is the deviation of the periodic signal, I could also affect it. You can modify the interval of your normal, let's say, command and control interaction. If you just, in Metasploit, you just use a command sleep. This will just stop all the connections and then resume them after the number of seconds that you specify. Then I thought, okay, so if RITA is making the analysis on IP pairs, maybe I should distribute all the connections that the infected host makes to the C2 to go through several or many command and control addresses. You can do this also with Metasploit transports, but I wanted to make a more generic and a little bit more dynamic way of doing it. So where can we get multiple IP addresses for our command and control? Well, the first thing I thought about was using reverse HTTP and reverse TCP proxies. So I started by doing a survey of reverse HTTP and reverse TCP software and services. Some of the services I found was localhost.run, which is basically a SSH service that you can do a reverse tunnel with it. NROC, which is also a very popular service where you can do HTTP and TCP proxies and pagekite. LocalTunnel is very interesting because they also have the code in GitHub, so you can host your own server for localTunnel and you can also use their service. And then FRP and Venom. FRP and Venom I found in the Mitre attack page. So I started by searching how many FRP, which is fast reverse proxy, actually the name. I found 15,731. From those, well, the majority was hosted in China, actually, then the United States and Hong Kong. Of all of those, I found 810 that were open, meaning no authentication to establish a TCP reverse tunnel, and 416 for establishing reverse HTTP connections. Well, this was actually a fantastic news for me because I said, okay, if I wanted more IPs to send the traffic of my command and control, well, now I have more than 1000 IPs on my disposal. So this was great news, actually. Then localTunnel, I found 290. You can do reverse HTTP proxying through it. The C2 centipede features that I implemented is the modification of the beacon interval, the type of charge and detection. So it detects if you are using an interpreter or if you are using an empire agent or any other, well, not any other, but other generic responses. The Foxflux part is just sending, let's say, many IPs to the client, so it can not directly send the request to the command and control, but through these many IPs. The multi-fronting is just a domain fronting, but that is not actually just using one domain. So you can send many domains that you want to front through in one CDN or two or an amount of CDNs. I also implemented the domain generation algorithm of Flubot and DGA kind of thing for generating the virtual hosts for the FRP reverse proxying. You don't have to configure everything before sending the Trojan. So the Trojan can establish one connection on, let's say, one of all of these ways, and then it can just add more IP addresses or change the beacon interval or all of this stuff dynamically. So how do we change the beacon interval? We have seen, for example, the Metasploit case that it has its own beaconing strategy, let's say sending a beacon every 10 seconds. So what we're doing in the C2 centipede is just faking the response of what Metasploit handler would say to say there are no tasks for you to execute. So it connects 10 times and you can say, okay, instead of sending 10 times, which is a lot of beaconing for my taste, just fake 20 times saying that there are no tasks and then the 21st attempt that you want to communicate with the command and control, then you actually send it. And then the rest, again, 20, you don't send it and then and so on. So the beaconing gets reduced a lot. The FoxFlox, as I was saying, is basically not using DNS because I don't have a botnet available. But I do want to use many IPs. So we are using the, let's say, open reverse proxy approach. And so there is a kind of a DGA that is used on both the client and the server. When the server requests reverse HTTP tunnel from an FRP server, it converts the IP of this server into a host. So you can see here news.biohub.io is generated by this IP that is here. So when the C2 centipede server tells the client, okay, now which you should send your request through this FRP proxy, both server and client know how to set up the proxy by telling FRP, I want to use this host. And then the client also has the same algorithm. So knows what host to send in the HTTP request. So that the HTTP request goes from the C2 centipede server client to the server. So multi-domain fronting basically, domain fronting abuses the routing scheme in content delivery networks to hide the intended destination of the HTTPS traffic. So basically, let's say that the TLS outer wrapping is saying, hey, I want to go to Amazon or whatever. But inside the HTTP header is saying, not really. I don't want to go to Amazon. I want to go to evilserver.in the same CDN. So the CDN actually like unwraps this TLS stuff and then just routes the request to the server specified in the HTTP host header. This is very easily implemented in the tool. You just need to send like this front it and then the domain you want to front through and then you specify the host that you have assigned in that CDN. You cannot use one, two CDNs as you wish. Then the domain generation algorithm. I already talked a little bit about it. I implemented the flubot actually based a lot on this blog post on switch.ch Basically, flubot has an algorithm that you provide a seed. Then you say how many domains you want to generate. And here in the C2 centipede, you specify to what port you want to connect on those generated domains. And then the dynamic configuration. Basically, you have every time the Trojan wants to connect to the C2 server, it connects actually to the C2 centipede proxy first. And then the C2 centipede protocol is piggybacked on this call. The original request from the Trojan, it's kind of wrapped and then sent to the C2 centipede server where it's unwrapped. Then the original request is passed to the Metasploit handler or the Empire handler. And then the control data for the C2 centipede application, it's embedded and wrapped and sent to the C2 centipede client. So this means that the operator can add more C2 addresses, change the encryption key, also this whole thing is encrypted on top of the encryption of Metasploit if you're using Metasploit. You can change the number of fake answers it sends at any moment. So you can change it while it's running. Here we have the C2 centipede architecture. Well, this is the normal architecture that you use when you have a normal Metasploit that connects directly to the handler. Then this connection is repeated every 10 seconds, every time to the same server. What we want to achieve is connect through many IPs, let's say, and to alter the beginning interval. So basically the Meta operator instead of connecting directly to the handler, it connects to this sort of proxy. The C2 centipede proxy then has an internal routing table and it decides on the desired route it wants to take to reach the handler. So the Trojan sends the request to the local host and then the C2 centipede client chooses one of these, can be through the main fronting or through a FRP reverse tunnel, and then it reaches the C2 centipede server. The C2 centipede server kind of unwraps the original call and sends it to the destination Metasploit HTTP handler. Then it obtains the response and sends it back to the C2 centipede client and then from there to the Meta operator client to the Meta operator Trojan. You can also have this configuration where you have one host with a Meta operator and also with the C2 centipede client. And then you can have other compromised hosts in that same network connecting to this one only host with the C2 centipede client so that all the traffic goes through this host and does all this routing for them. So this is the C2 centipede operation. Basically, you need first to set up the Metasploit empire or whatever you're using handler. So basically this is the command to set up a Metasploit handler. You set the payload for whatever payload you want. It has to be reverse HTTP. Here I'm using a stateless HTTP shell. Then you set up the port of the handler and then the host you want to bind to and you run the Metasploit handler. Then you need to configure on the server as well the C2 centipede server. You need to specify a port and then the destination where all the requests that it gets will be forwarded to. So this will be the Metasploit or empire handler. Then on the client you need to set up the C2 centipede client. You specify on what interface you want to bind. This is in the case of just having it in one host not anyone else connecting to it. You specify the port that you want to run the C2 centipede client on. Then the list of C2 centipede servers is either domain-fronted or through FRP proxies. Or you can also give with the minus S you can give the individual servers. Of course then you need to generate the Trojan and then you just need to execute the Trojan in the same host that you are executing the C2 centipede client. Of course you can also compile it for Windows and then just run it there. Right now we will test a shell with C2 centipede. We will actually fire up a Windows machine. We will set up the C2 centipede server. We will set up the port in 1993 and then we will say that the Metasploit handler will be in this host and IP. In this case it's on the same machine but you can also let's say point to Metasploit handler in another machine. So here I will with Metasploit I will run a handler so I will use the exploit multi handler and then set the payload for Windows Metasploit Reversed HTTP. This is a stateless HTTP payload and we set the port to 8888 then we set the host to all interfaces and then just run. And we can start as well the C2 centipede server on port 1993. Okay, so we already have the multi handler listening on that port with this payload. We can start the C2 centipede client. We need to specify the web interface we are binding to and then the port. Let's use port 2233 because I already generated a stateless meterpreter pointing to localhost and port 2233. And then we will connect it specifying the C2 centipede server. It was running on port 1993. That should be running. We can test the connection all the way to the handler by issuing a crawl command to localhost. So this is the actual response from the Metasploit HTTP handler. It actually emulates an Apache server but you can see that the connection actually was sent through the C2 centipede client and to send to the C2 centipede server as you can see here. We execute the crawl again. You get the connection again through the same route. And here you can see the connections. Okay, so let's now execute the meterpreter. What you hear is every connection that gets to the C2 centipede server. So you will see how much the Metasploit or the meterpreter Trojan connects to the handler is a connection, an HTTP request action. And as you can hear, the interval between each call is little by little growing. So if we continue, we could see that the interval grows until 10 seconds and then it just keeps being 10 seconds long. But what happens when we interact with the Trojan? We said that it goes back to 100 milliseconds and then it does this growing of the interval again. Let's interact with it. As you can see, there are more connections now. Let's execute something again. So this is all the noise that you are generating every time that your meterpreter connects to your handler. So it's not magic, it generates a lot of noise and actually quite very nice looking beacons all the time. So this is very easy for the blue team to detect with a tool like Rita. So this is where we come and try to do things a little bit different. This is the C2 Centipede operator interface. We say to what server we are connecting to and then we can see the client that are currently connected. We can set up another route. Let's first fake the responses. I will just execute one more command to get a faster beacon. And then I will send the command to fake four requests. The responses for four requests. As you can see here, it's now one, two, three. You don't hear anything because nothing is going through the network. Here you will also see the gap. Now it's sent again the request. So you see this was the original beacon and with the C2 Centipede we are now adding this gap. So adding to the interval. We are now only faking four responses. What we can do, of course, more. We can go back to zero if we want more interactivity. Here you can see how many times it has faked. So it starts again. Fake one, fake two, out of four. Fake three, out of four. Fake four, out of four. And then it will go again out as you can see now. So let's say you want more interactivity. Of course, I can show that you can still retain. Let's see. It will take a little bit longer because not all requests are coming, but now it will execute. So you can still execute commands. So now let's add some proxies. Let's try. So we will set up some... Let's try three or four. So these are open on the internet. I will just press set up and then it will establish the connections. As you can see, these two are no longer working. So we can actually remove them. So let's add some other ones. So let's send it to the C2. Bye. Let's see to send a bit clearer. So I will press send. So the next time it connects because now it's faking. So when it connects, it will get the servers, add it to its routing table, and then it will actually use it to route the traffic through them. You can see I still have command over the Trojan. And actually the frequency of the beeps means that it's using... Like each IP generates a different frequency. So here, if we see it, it will be using like these IPs we added. So this is going through China, the US, and so on. Okay, so we can also use the main fronting. As we saw previously, I will just, again, using this tool, I will send multiple servers at them here with the format I was telling you before, front it, and then the domain you want to front through. And then the host, it should actually redirect. So there it will send it. It adds to the routing table. And then it will use them. So here it sent through this one. There are some debugging things going on. So at some point it stops, but then it continues. As you can see here, the domains that it's using to front here. Okay, so that's the demo. I hope you liked it. And we'll continue with the presentation. Okay, so how does the traffic looks for the blue team? Here, I executed the interpreter against these hosts only. Only one host using no sleeping, let's say, or faking, just direct connections. As you saw here, there are six, all of this is one minute intervals. So there is six requests per minute. You have here this big peak when you execute the who is command. So you can see there are like many, many more connections in a minute. And then it uses that algorithm from Metasploit and then just reaches 10 per one request every 10 seconds. So six per minute. And here Rita, this is already the output from Rita. It gives a score of 70% to that IP that we were beginning to. Here, we have to specify that this is just like half an hour of it running. Of course, when you do this beginning detection with Rita, you want much bigger amounts of time like the traffic for a day or more. Here, just for the experiment and for the proof of concept, we just have nine, sorry, half an hour period of time. So this is the normal way. And then how does it look when we do it with the C2 centipede? So we, for this test, we added 10 IPs. These are 10 FRP HTTP reverse proxies. And then we set some faking of the responses so that it doesn't become so often. Okay. So the result is this, that sometimes you have many more, well, not that many actually, but at some point, you have some request and then it doesn't fake for a while. And then you have periods of time that for five minutes, for example, you don't have any beacon. And then you can see that at this point of time, it uses one server, then here, maybe it uses the same. Maybe here it uses another one. And then it uses the green one, the blue one, the green one, the pink one, and so on. So the beacon is not a perfect beacon. So that tools like Rita don't see these perfect beacons. Okay. So the results from Rita also by this half an hour period of time. Is that it doesn't see a beaconing pattern basically because there are less beacons and because it is routed through several C2 IPs. So we can conclude at least for this very small experiment that it is like mission accomplished at least for this. So the conclusion is basically that the beaconing is, of course, not the only threat hunting technique, but one that blue teams should be doing. So if you are using the default vanilla metasploit empire, know that if the blue team is doing beacon detection, it will jump right at the blue team. It's very visible. Also, if you use 1000 of servers to proxy to your command and control server, of course, because it's not the only threat hunting technique, this beaconing detection, you will be detected because the host is connecting to this so many servers. So you need to balance. It's a balancing act of how often you want to beacon. And so how much interactivity you are willing to lose and also how stealthy you want to be. If you use really many servers, then you will be more visible. So you have to balance this, all of these things. Okay, so that was all I would like to thank you. It's a shame that I, of course, most of us could not be there in DevCon. Actually, I wished it was my first time there. But that's how it goes. I wish you are safe and that you can maybe contact me, give me a little bit of feedback and maybe chat or something like that. Okay, thank you very much. See you later.