Basic Implementation of Persistence

In recent explorations, I've been learning about BlackBasta and various methods of process injection, topics I touched upon in my previous blog post. My goal was to deepen my understanding of these concepts by simulating a basic persistence mechanism within a virtual environment. This hands-on approach allowed me to experiment with techniques similar to those used by malicious actors to gain unauthorised access to systems.

BlackBasta utilises DLL injection to gain initial access to target systems, injecting malicious code into legitimate processes to operate discreetly. Inspired by these methods, I decided to create a simple reverse shell script as a proof-of-concept for persistence within a VM.

Setting Up the Scripts

For this experiment, I envisioned a scenario where an email might deliver a zip file containing two key scripts: a Python reverse shell script and a batch script to execute the Python script. This mirrors a common attack vector where users unknowingly run malicious software.

Creating the Batch Script:

I crafted a batch script (batch.bat) to automatically execute the reverse shell Python script. This script ensures that the reverse shell launches each time the user starts their computer.

Developing the Python Reverse Shell Script:

The Python script serves as the reverse shell, connecting back to my host machine and allowing me to send commands and receive responses from the target VM. This reverse shell acts as a bridge between the attacker's system and the victim's machine, facilitating remote command execution.

Achieving Persistence

To make the reverse shell persist across system reboots, I needed it to execute automatically each time the VM started. This involved modifying the Windows Registry on the VM:

Adding the Batch Script to Run Keys:

I added an entry to the CURRENT USER Run Keys in the Windows Registry, directing it to execute the batch script. Run Keys are often used as a persistence mechanism, allowing programs to run automatically during startup. By embedding the batch script here, the reverse shell was set to launch at every boot, maintaining a constant connection with my host machine.

Setting Up the Listener

On my host machine, I set up a listener using Python. This listener awaited incoming connections from the VM, ready to interact with the reverse shell once executed. The listener acts as the server-side component of the reverse shell, managing communication between the two systems.

Execution and Results

With the setup complete, I proceeded to test the entire process:

Booting the Windows VM:

Upon starting the VM, the system automatically executed the batch.bat script due to the Run Key entry. This, in turn, triggered the Python reverse shell script, establishing a connection with the listener on my host machine.

In this scenario, the VM created a Command Prompt window upon boot. A key aspect of stealthy operation is preventing the Command Prompt window from appearing, as this could alert the user to suspicious activity. By using the start /b command in the batch script, we can suppress the appearance of this window.

Connection Established:

Once the reverse shell was active, I received confirmation on the host machine that the connection was successfully established. The listener displayed a message indicating it was "Currently listening" and that a connection was made with the VM.

Gaining Access:

At this point, I had remote access to the VM and could execute commands. I started by checking the current user identity with commands like whoami and then attempted to explore the user's Desktop files. This exploration was meant to simulate an attacker browsing through sensitive information or hidden files.

Unexpected Disconnection:

Unfortunately, before I could delve deeper into the VM's contents, the user of the VM (also me) noticed the Command Prompt window and closed it, inadvertently terminating the reverse shell session. This action severed the connection, highlighting a common risk where user intervention can disrupt unauthorised access attempts.

Conclusion

Through this exercise, I was able to gain a foundational understanding of how persistence mechanisms can be implemented in a virtual environment. By creating and deploying a reverse shell, modifying registry keys, and establishing a listener, I simulated a basic attack scenario. Although the session was terminated prematurely, the experiment provided valuable insights into the practical aspects of persistence and remote access techniques.

This exploration underscored the importance of awareness and caution when dealing with executable files and registry modifications. Understanding these mechanisms not only aids in recognising potential security threats but also helps in developing effective countermeasures to protect systems from unauthorised access. Additionally, learning about hiding processes and utilising DLL injections offers insight into the more sophisticated methods used by attackers, helping to build a comprehensive approach to cybersecurity.