The Shady Secrets of Shadow Networks - Security Boulevard

The Shady Secrets of Shadow Networks

Shadow networks are side channels to traditional networks, undetected and working quietly in the background alongside what the traditional network was designed to do.

Command and Control (sometimes referred to as C2) servers maintain links with compromised end points (IoT, PCs, Printers etc) within an unsuspecting target network. In this post, I will discuss how the malware is controlled using communication techniques.

Sometimes, even large companies with their own security teams can fail to grasp the concepts around Command and Control or the techniques involved. They fall into the trap of thinking traditional endpoint security and appliances are enough to combat this little-known threat. Command and Control, like the military term, does exactly that. It commands and controls armies, but in the I.T. world, these “armies” are called Botnets. This can sometimes be as simple as keeping tabs on sleeping compromised systems. This is done by sending heartbeats, so the unscrupulous operators can keep tabs on where their compromised assets are in order to exfiltrate data or to cause mayhem with malware propagation. So, how do we get to that state? Let’s look at how the endpoint device becomes infected.

As mentioned previously, some networks have very simplistic security functionality such as IDS/IDP, Firewalls and perhaps some endpoint anti-virus software. Unfortunately, these often prove ineffective to zero-day exploits. These countermeasures are ineffective against email phishing attempts, where a victim is tricked into either entering their credentials to known websites or opening malicious attachments on webpages that carry the malware payload. These payloads then use system vulnerabilities to covertly compromise the endpoint. Once loaded on an endpoint, a common practice is to include evasive anti-malware and anti-virus methods to avoid detection.

The malware sends out beacons to the pre-programmed command and control servers out on the internet. This can contain hundreds of fully qualified domains and IP addresses used to cycle through to connect to its mothership. There are different ways of doing this, using Internet Relay Channels (IRC), HTTP, SSL and more increasingly DNS. Why DNS? This is because DNS is usually allowed out to the internet unabated and to all hosts, making it a really easy way to make a connection to a command and control server.

Once connected to a malware server via a traditional http session, additional rootkits and remote access tools can be loaded on the compromised endpoint to enable lateral movement within the host network.

Most “out of the box” antivirus and malware signatures often fail to spot current Indicators of Compromise (IOCs) which are usually DNS names of the hosts affiliated with the communications of the infected endpoint. One way to combat this is by checking this against some known command and control domains, while another is with machine learning on how domains are being used. But it’s not that easy; Command and Control operators often use multiple hosts, and use dynamic DNS registrations to obfuscate their intentions and keep their systems highly available. Other techniques include using publicly available DNS servers. The bad actors try to use these public DNS services to avoid being detected.

What is the plan of action?

The most effective way of stopping this type of intrusion is to disrupt the communications with the Command and Control servers – cutting the head off the snake, so to speak. Malware will permeate networks, through external influence, driven by infections on sometimes legitimate websites. It’s unavoidable, but to prevent the malware from manifesting itself and gaining a foothold, breaking the kill chain would accomplish this. Actively stopping the communication at the DNS level will go a long way into achieving this, stopping the most advanced malware, and allowing the enterprise to function without the shady network that lurks alongside your core business infrastructure.

*** This is a Security Bloggers Network syndicated blog from The Akamai Blog authored by Dan Kirwan-Taylor CISSP. Read the original post at: