Command And Control Ports

[Barton Ostby]

Adversariesmay communicate over a commonly used port to bypass firewalls or network detection systems and to blend in with normal network activity, to avoid more detailed inspection. They may use the protocol associated with the port, or a completely different protocol. They may use commonly open ports, such as the examples provided below.

All field controllers should require users to authenticate for all remote or local management sessions. The authentication mechanisms should also support Account Use Policies, Password Policies, and User Account Management.

Network intrusion detection and prevention systems that use network signatures to identify traffic for specific adversary malware can be used to mitigate activity at the network level. Signatures are often for unique indicators within protocols and may be based on the specific protocol used by a particular adversary or tool and will likely be different across various malware families and versions. Adversaries will likely change tool C2 signatures over time or construct protocols in such a way as to avoid detection by common defensive tools. [4]

Monitor for mismatches between protocols and their expected ports (e.g., non-HTTP traffic on tcp:80). Analyze packet contents to detect communications that do not follow the expected protocol behavior for the port that is being used.[5]

Analyze network data for uncommon data flows (e.g., new protocols in use between hosts, unexpected ports in use). Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.

I new to Palo Alto and loving it but I am looking for PAN-OS cli commands similar to telnet, nc (netcat) or curl etc.. I have seen there is an option to do ssh source port (the scp command also supports this), can this replace the telnet source port? From what I tested I think that the SSH without specifying the source is sourced by the managment interface but I don't see a service route for this. If I specify the source IP of a data plane interface. From what I see is if the tcp handshake works but it get dropped at application level (this is normal as I am using not the real application but SSH to check the port), I get the message "ssh_echange_identification: Connection closed by remote host", if the server does not listen to this I get the message "Connection timed out". I think that when the server silently drops it I will see "session timed out" and the pcap confirms this. If the server sends RST for the first SYN packet, I will see from the Traffic log that Server RST was seen and when it works, it will be still TCP RST by the server but after the 3-Way handshake is done or in my tests to a test dns on port 53 and ssh command I got just TCP-FIN for the session (don't forget to enable intra zone log on session end) after the 3-Way handshake and the message "ssh_echange_identification: Connection closed by remote host". Can you confirm that this is the way to test with the ssh command? I think that this is an interesting idea and if possible give me some advices.

The telnet command was taken out a long time ago. All that is left, as you already discovered, is the ssh (and ping and traceroute) command which you can source from a dataplane interface (default is management)

As I tested the SSH can also do it but you need to check the Traffic logs for what was the reason for the session to be closed (in most cases intra zone log at session end needs to be enabled) and/or pcap captures. In some cases people want to check such things from the firewall not an external host but thanks for the reply.

Sorry for the late reply but I couldn't help myself while researching this thread.

Sure it's definitely more fruitful to test from an external machine... but when it's 3AM local time and you're barely awake dealing with an on-call issue my god is it helpful to have a command like this that can test port functionality directly on the firewall. This is the kind of feature that engineers who work in the trenches think about when looking at purchase decisions.

The way infrastructure is established depends on the resources the APT group poses. In some cases, the infrastructure is kept simple due to lack of financial resources or low priority of the campaign. It might also be a sign of poor skills of the threat actor. A very sophisticated C&C is usually used by skilled and well sponsored APT groups who want to keep their campaign very stealth for a long time. In any case, C&C is a crucial part of the attack carried out by these adversaries.

One of the most common techniques used for establishing C&C servers is the usage of domain names which match a pattern of legitimate software or e-mail services, mimic common naming of online advertisement services or sites that are relevant to a current campaign. The main reason of using these techniques is to make sure that the malicious traffic blends into a regular one. Here are some examples:

The easiest implementation of such a concept requires a single tool capable redirecting network traffic. Best examples of such tools are socat and netcat. These tools are widely spread across Unix systems and can be easily abused on compromised machines. In order to create a simple port redirect it is sufficient to execute the following command line on a controlled system.

Depending on the actual C&C and malware implementation, the communication which is being transmitted over HTTP/HTTPS ports can be a legit HTTP protocol or a binary communication. Additionally, malware might be connecting via proxies in order to mask the real location of the C&C server. An example of such a setup is shown in Figure 2.

In addition to HTTP protocols, DNS is also known to be adapted by APTs as a covert channel [7]. In this case, attackers register a malicious domain and point it to their C&C server. A special software is used on this server which mimics a DNS server, but embeds malicious commands in the response packets. Malware on the infected system interprets the malicious DNS response and executes given command. Once the command is executed, the result might be returned back to the C&C in a similar manner. An example of such an infrastructure is show in Figure 3.

Due to specifics of the tool, the command string appears twice in the payload. The reason for this is the fact that the first occurrence is later used an identifier of the created thread and the second occurrence is the actual command which gets executed. Moreover, this tool supports encryption for commands which are sent to the infected host and therefore makes this kind of communication analysis very difficult. An example of encrypted communications which execute the same command is show in Figure 5.

The presented concepts of the C&C implementations are the most common. In a real world, attackers might chain these concepts or apply various modifications. Nevertheless, in most cases a central point of command distribution must exist in order to efficiently control the infected machines while executing campaign. The implementation of the C&C infrastructure depends on the APT group and the specifics of the campaign.

For concealing the information being transmitted to an HTTP based C&C, APT28 employs encryption and encoding as means of obfuscation. Known techniques used by this group include RC4 or XOR encryption of the initial data and further encoding with modified Base64 encoding which is meant to prevent investigators from easily deciphering the data [8]. Another technique used by APT28 is the transmission of C&C commands over SMTP. For this purpose one of the malware components used by the group had e-mail accounts hard-coded within the binary for sending and receiving control data. The information being transmitted over such a communication was obfuscated with XOR encryption [9]. In order to hide true origin of the C&C in some cases this group implemented proxies for communications between malware and C&C. For example, during the campaign against Georgian Ministry of Internal Affairs, the communication with command and control server was relayed via an internal mail server [8]. In another case, an external email server was used as a proxy [9].

Finally, for breaching air-gapped networks, a USB stealer was identified to be used by APT28. The purpose of this module was to infect removable drives in order to spread to systems which had no direct connectivity to the internet. Once such a system was infected, the same USB drive was used to exfiltrate data and receive further commands [10].

The second stage backdoor is installed using a dropper which writes the backdoor and the C&C configuration information to a registry location or to an encrypted file. The following table shows the C&C configuration locations used by APT28 [11].

First, the downloader sends a beacon that contains the process listing of the compromised host to its C&C server. After that it downloads and executes the second-stage payloads from C&C. Communication between the downloader and C&C is carried out by using HTTP POST requests with encrypted and Base64 encoded data in the request body. The data is encrypted with a custom stream cipher algorithm using a six-byte key. However, the commands sent from the C&C server to the Downloader implant are encrypted using another stream cipher with an eight-byte key [8].

The backdoor begins communicating with one of its C&C servers by first testing its connectivity with an initial HTTP GET request. Then it starts uploading file contents of the hidden temp-file created to store the collected host information to the C&C server using HTTP POST requests. After uploading the file, it continues HTTP GET requests to query its C&C for further instructions. In order to protect data from interception, the payload sent to C&C by CHOPSTICK is usually encrypted with RC4 before initiating connection [8].

The command and control infrastructure used by APT30 consists of two main components: the first and the second stage C&C servers. The purpose of the first stage server, which is hard-coded in the initial backdoor, is to collect data from the infected host, provide means of updating the backdoor and orchestrate an interactive channel to the second stage server on demand. While earlier variants of the backdoor communicated over clear text channels, the successors were improved to apply a custom XOR or RC4 encryption which is meant to obfuscate transmitted data [13].

3a8082e126