Caution:
Before we start, it’s important to note that the activities in this research have been conducted in our own testing and researching environment, locally and in the cloud, for research purposes against assets that we fully own. Any unauthorised use of these techniques in tests or engagements is strictly prohibited and illegal, and Samurai Digital Security Ltd. researchers are not liable for any illegal or unethical use of them. This research was a simulation and roleplay for cyber threats and black hat hackers to help us develop our red teaming techniques and tactics, helping us improve the red team side and provide more attacking scenarios for the blue team to detect their organisations and the clients for which they are responsible.
Abstract:
When we consider modern threats (detected or known), we can clearly see that they are constantly hiding themselves and their activities in places, and security analysts and security appliances can remain in place for years monitoring networks, believing that no threats are actively present, only to discover that they have been compromised. Our role as “red teamers” is to try developing techniques that simulate these activities and to improve organisational security by training defensive security teams to check for every single bit (not literally) of data and also anticipate the locations from which attackers may conduct their operations. The technique discussed in this research only shows the basic mindset that can be developed further with each engagement. We developed it so that when we are performing the engagements, each time we add more techniques to it, so, as we always say, take the mindset, not the method. Stay secure.
First Scenario: Data Exfiltration
Introduction:
Data exfiltration is an important phase that most red teamers and even penetration testers forget about. It’s critical to use OPSEC (Operational Security) throughout your phases, but what about data exfiltration? Do you think we can use OPSEC to make it silent or undetectable? This is a question you should ask before embarking on any assessment that requires data exfiltration for security appliance measurement or any other purpose depending on the scope of the engagement. If you plan to use standard HTTP or DNS exfiltration, you should know that you will be caught in 95% of cases, and even if you don’t get caught right away, the investigations by the forensics team and security analysts will! If you planned to exfiltrate your data through MQTT, that’s a good idea, but believe me, you don’t want to send the data through an unused protocol in the infrastructure you are in—in case nobody uses it, which is very common—because that’s going to be like performing port scanning on a firewall (joke). So, the mission now is to exfiltrate the data using an ordinary protocol (which must be used) without revealing the data and, at some point, without making any noise or sending strange malicious packets.
Analysing the network:
It’s important to think about the protocols that must exist in any infrastructure, and if you’re thinking about TCP, then I’m happy to tell you that yes, that is correct. If you spend some time analysing multiple networks, you can see that no network can function without at least one TCP packet being sent, which means that choosing TCP as our protocol to see how we can exfiltrate data through will be the ideal way. Our goal is not to send encrypted data or hide the data that we want to exfiltrate in a strange or secure protocol; our goal is to completely conceal the transmission operation to avoid raising alarms in the network, so if you decided to exfiltrate your data through SSH, for example, in an environment where no SSH service was used, that would be strange behaviour and would likely be flagged.
Let’s analyse a TCP packet to see what the content and structure of a TCP packet are. You may ask, “Why should we analyse or even determine the content of a TCP packet?” The answer simply is something I always say: “If you want to use something, you should deeply know it, and to know it, you should analyse it, and if you want to excel at it, you should script it.” So, the steps that we are going to take are completely clear now. We are going to analyse it deeply by clarifying the anatomy of a TCP packet, then simply write a script to reach our goal, which is exfiltrating the data anonymously. The following diagram shows the anatomy of a TCP/IP packet:
Surely, we are not going to analyse everything (in this article) as it’s going to take a lot of time to read, and we don’t want to make it boring by explaining a lot of theoretical concepts. It’s highly recommended to analyse them yourself later after you finish this article, but here we are going to analyse the core points of our technique.
- Source Address
- Destination Address
- Source Port
- Destination Port
- Window
- Checksum
- TCP lags
- Total Length
Let’s define each of the parts mentioned above to see what it is.
What is its functionality? How can it benefit us from a security knowledge perspective? You need to know that to send a TCP packet, you must have valid details inside that packet, whether the destination is existing or not; for example, there is no packet without a destination port or TCP flags, and the reason is as simple as why we must have lungs to breathe. So, having these parts in a TCP packet served its purposes from a security and network perspective.
The source address is the address of the sender of the packet; it helps the network devices know from which place the packet has been sent, and it also helps the security analysts determine which devices are infected in case malicious behaviours start to show up in a network, while the destination address is simply the remote device that’s going to receive the packet.
The source port is the port from which the packet is sent to the sender device; this port is probably random. The reason I’m telling you this is that in some engagements, when it comes to crafting their own packets, make static source ports, which is clearly not the normal case and may cause security analysts to detect suspicious traffic as a result, so always keep in mind to bypass security solutions and act like a device that should be protected J.
The destination port is the port that the packet will be sent to at the destination address; this port probably is a service port. For example, if a packet is sent to an FTP server, the destination port will be 21. A “window size” flag is used by the receiver to indicate to the sender the amount of data that it can accept.
Checksum is an error detection mechanism to determine the integrity of the data transmitted over a network. The TCP flags are flags that indicate a particular connection state, provide some additional helpful information for troubleshooting purposes, or handle control of a specific connection, for example:
- SYN
- Used to initiate the TCP three-way handshake.
- URG
- Says that the data should be treated with priority over other data.
- ACK
- Used to confirm that the data packets have been received.
- PSH
- Tells an application that the data should be transmitted immediately, and we do not want to wait to fill the entire TCP segment.
- FIN
- Used to end the TCP connection. TCP is a full duplex, so both the sender and receiver must use the FIN bit to end the connection. This is the standard method of how both parties end the connection.
- RST
- Resets the connection. When the host receives this, it must terminate the connection right away. This is only used when there are unrecoverable errors, and it is not a normal way to finish the TCP connection.
When it comes to raw packet sending, each flag has its own binary representative; here are some examples of binary representatives for some flags:
- SYN
- 00000010
- ACK / SYN
- 00010010
- ACK
- 00010000
- ACK / RST
- 00010100
- RST
- 00000100
- URG / PSH / FIN
- 00101001
If you decide to craft a raw packet, the flag representatives above are a must to identify the communication steps that you are going to follow. As we mentioned before, there are a lot of parts to a TCP packet, and we did deep research to find a way that we can use one of these parts without breaking the packet to transmit the data. We found that window flags will be one of the ideal packets that we can use. The following diagram shows the capacity of each TCP flag that holds data:
So, we have a capacity of up to 16 bits in the window size and changing its value will not interrupt the communication or corrupt the packet unless you overflow it by more than 16 bits. The mission now is to find a way to fill the flag with transmitted data without causing any corruption. We knew that the window holds integers; you can clearly see that if you analyse a TCP packet in depth:
Then, we can transmit our data (in the case of ASCII) as integers and have a decoding script that knows the algorithm, we are using to decode it. To make it clear, the following diagram would be great to explain:
An attacker can use a proxy to forward the sent packets to it and can fill them with some data to avoid sending strange TCP packets, and on the other side, a decoder-script will be there to receive the packets and decode the TCP window flags. We have created a script to do the whole process on both the victim and attacker sides, as shown below:
The script is designed to send one packet every second, allowing us to control network noise and send TCP packets in the correct order to avoid sending entire packets in a short period of time and occasionally having the remote device receive them in the wrong order. The practices and techniques for hiding the data and its flow and the places to choose for exfiltration are uncountable. As you can see, there are multiple protocols, flags, and even methods that are being used for multiple functions in the network to transmit or control data, so taking the mindset from here and developing it is the key to building a good new technique as well.
Second Scenario: Command and Control
We talked before about the exfiltration of data through the window flag in TCP packets, but what about command and control? Because of the noisy, clear text or easy-to-detect methods used in many engagements, red teamers face the challenge of sending commands to remote devices. As a result, we created a script that automates the commands sent through the window flag in TCP packets, with additional customisation for the time to delay and more! We added the ROT encoding algorithm to make it more difficult for anyone to combine everything together if the method is detected; for example, if we sent “pwd,” it will look like “cjq,” with a note that we can create our own algorithm and obfuscate our script using custom obfuscation techniques or a popular one like PyArmor, etc. The following screenshot shows the command and control through this technique:
Finally, it’s important to note that this method didn’t require packets to be sent directly to the victim machine, as the malware captures raw packets from the network, so we can specify the attacker’s proxy IP or even rarely used port etc, to capture its traffic which will be converted to captured data. This means we can send data through the network by sending packets to different devices without detection. This is because the network device can see any network packets sent in the network, and we can configure the malware to capture the data through window flags in TCP packets that come from specific IP addresses or data that is being sent to specific ports, all without being detected by the victim device itself.
You may face challenges such as setting the right checksum and putting data in packets in case empty packets are denied by security appliances, etc. All these challenges can be solved by deep thinking, and the good thinker is the one who takes the challenges and uses them to solve them.