The Red Fortress: hardening for your C&C

Sapphire
void security
Published in
6 min readSep 25, 2018

--

In this story, I’ve decided to talk a little bit about this cool mixture that almost everyone in infosec love: read team + blue team.

For this particular case, I wanted to add something out of the words and start talking about more real-scenarios for penetration testing and then this idea came to my mind “Would be nice if I think about some options from black box ethical hacking exercise…?”, so after months of busyness with my own stuff and work, I want to go hands on or something simple but introductory like I did with my story about ICS-SCADA red team.

As in a black box pentesting scenario, we start from an outside perspective like a real attacker so we want to ensure several things:

  • We have a solid C&C structure for attacking, beaconing and exfiltration
  • Some of our attacks will be detected and our “faced” servers will fall ¯\_(ツ)_/¯ but our 2nd and 3rd phase C&C have to remain active and undetected
  • We have to ensure anonymity in any case

If you wonder what I mean with “phase based servers”, don’t worry, I will explain it as well.

We can do a pentest from our company’s server, which could be identified by the client, but in some scenarios, the simulation goes further and is a full team imitating TTPs so the client has a more solid understanding about what is going on when a real attack happen by actors like APTs, CyberInsurgency Cybercrime and sometimes hacktivist ops.

For this example I will explain it using CIA’s HIVE server infrastructure.

Hive is a program-tool created by the Central Intelligence Agency of the US published by Wikileaks in Vault 7 to perform a full circuit with similarities with a botnet to control implants from over the World at once using SSL tunnels along with a layered circuit to cover their tracks, ensuring that the heart of this system is always up and running, collecting information and storing it into CIA’s databases.

APTs by the other hand do the same with some of it ops, exposing some of its Command and Controls to download the payload once the dropper lands into the target, but as you might see in whitepapers, in the IOCs are always IP and Domains that always belong to that faced and expendable servers, while the real ones for redirection and storage are always hidden.

Why is this so important? Because if one C2 get caught, your whole Op goes down, so you should always have multiple server for staging. So forget that old idea about having a super-strong server because once your URL’s or IPs are in blue team hands, you won’t be able to keep knocking the doors.

Moreover, if your team is deploying a big scale red team operation, you’ll have to build up a good server infrastructure thinking in a long period of time like an APT would do. I won’t go further about how to deploy a red team infrastructure in this story, so let’s begin with the steps and options available for your different stage C&C:

IPTables is your friend

IPTables will always be the first security layer at hand. A basic iptables commands to enhance ssh port (remember the usual countermeasures for your ssh connections like change the port, max tries… the whole config will help you here) but will be better adding some improvements.

  • Fail2Ban? not necessary when you have such an amazing tool that directly interacts with your kernel
iptables -N SSHATTACK
iptables -A SSHATTACK -j LOG --log-prefix "[!]Possible SSH attack logged" --log-level 7
iptables -A SSHATTACK -j DROP
iptables -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dpor 2222 -m recent --set
iptables -A INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 2222 -m recent --update --seconds 600 --hitcount 2 --name DEFAULT --mask 255.255.255.255 --rsource -j SSHATTACK
  • Block ping requests or ban icmp. Sometimes blocking echo-request is not enough and another actor could try other techniques with icmp in order to discover the host. Explore icmp types to add rules. You can also use this to avoid ping bursts.
iptables -A INPUT -i eth0 -p icmp -m icmp --icmp-type 8 -j DROP
iptables -A INPUT -i eth0 -p icmp --icmp-type echo-request -m hashlimit --hashlimit-name ping --hashlimit-above 1/s --hashlimit-burst 2 --hashlimit-mode srcip -j DROP
  • Remember to drop everything in IPv6 if you don’t use it and install persistent iptables. If you want or need changes seting up a couple of iptables scripts synchronized with cron-anacron in order to open some ports and then close it for certain periods of time could be a good idea.
sudo apt-get install iptables-persistent

Remember to use chains to forward and route everything from the inside automatically, just to make sure that you don’t have to set up the tunnels everytime you connect to the remote implant.

Knockin’ on Hell’s door

Port-knocking is an interesting technique used to hide direct access ports like ssh. It works deploying a security layer by obscurity protecting our valuable and available resources by an under demand request using a sequence of packets in a determined threshold. However we can use Single Packet Authorization, a variant of the standard port-knocking technique to improve our system’s reaction against port-knock attacks.

Onionizing your C&C

If you want to go shady, there’s another why to have access while avoiding open ports to the world is using Tor to deploy your covert network.

Is well known the use of hidden services for hosting websites and some companies are adding their services to the Tor Network as well like facebook.

  • Nevertheless, any service (remember, Tor only supports TCP) can be opened in the Tor Network by configuring it in the torrc file for hidden services. Since V3 onion services are available, remember to use it because they added some cool features increasing their crypto and making the URL even longer changing the hash algorithms to increase security.
## This section is just for location-hidden services ###
HiddenServiceDir /var/lib/tor/my_hidden_service
HiddenServicePort 22 127.0.0.1:2222
HiddenServiceVersion 3
SocksPort auto
  • As a tip of best practices, change the ssh host keys to stay safe ;) and remember to change ssh port to listen to localhost only in the sshd config file.
ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t ed25519 -b 256 -f /etc/ssh/ssh_host_ed25519_key

Then you will have a V3 hidden service hostname like 4acth47i6kxnvkewtm6q7ib2s3ufpo5sqbsnzjpbi7utijcltosqemad.onion that only you and whoever you want will now. Now the team can reach the server using TorSocks proxy with SOCAT to create a ssh encrypted tunnel through the Tor Network to reach the server while this server remain will all the ports apparently closed.

Hope you like it, tell me what you think about it and if you want more, just ask!

--

--

Sapphire
void security

Kimchi and Ransomware. Incident Responder and sort of malware analyst in my free time. Personal blog, opinions are my own.