Wargames, April 2025 – Command and Control (C2), Introduction and RustDesk

To accomplish this goal we created a lab using cloud IaaS, network firewalls with decryption enabled, and a series of ‘victim’ virtual machines with an EDR agent installed. Our testing team were granted administrative level access to those machines through remote desktop – above and beyond what your average threat actor might have in the early stages of an attack but an effective emulation all the same.

Our team worked with a range of tools including the open source version of RustDesk and Command and Control frameworks from GitHub.

MITRE through the ATT&CK framework describes Command and Control as:

Command and Control consists of techniques that adversaries may use to communicate with systems under their control within a victim network. Adversaries commonly attempt to mimic normal, expected traffic to avoid detection. There are many ways an adversary can establish command and control with various levels of stealth depending on the victim’s network structure and defenses.

With Command and Control established it is often only a matter of time until the threat actor gains access to systems desired to achieve their objectives through Privilege Escalation.

Depending on the level of an organisations security maturity, threat actors will have a range of options to choose from when looking to establish Command and Control – ranging from widely adopted remote support tools (as seen in the malicious use of AnyDesk observed by the Computer Emergency Response Team of Ukraine), to open source post exploitation toolkits available on GitHub, or even previously unseen entirely proprietary tools used only against high value targets. Regardless of the method used there are many tools available to even casual or determined but low skilled threat actors which may be effective against poorly secured networks and infrastructure.

RustDesk

Words heard on a recent Threat Emulation after dropping the remote support tool onto the provided users desktop, executing it without administrative permissions required, and then promptly exfiltrating the contents of the users OneDrive.

It’s frightfully easy to go sign up for a trial of your remote support software of choice (think the likes of TeamViewer, AnyDesk, or Splashtop) some without even needing a payment card number to avoid attribution and start sending links to download and run the tool to a victim. But what about for the threat actor who enjoys the ‘self-hosting’ experience? Here we have RustDesk open source with a self hosting option.

After spinning up a virtual machine on an IaaS provider of choice the installation of RustDesk is simple to follow with video tutorials, a 3 line installer, and docker options – even as someone who doesn’t have too much to do directly with Linux systems it’s a trivial setup.

Once installed you are provided with a randomly generated password to access a web file transfer service which provides a PowerShell script to use to install and setup the agent, you’ll need one computer to run as the attacker and another as the victim both having run the same script.

With decryption enabled on our network firewall and examining the traffic from our victim machine we see the download of the RustDesk agent direct from GitHub. Perhaps our first opportunity to prevent such an attack by blocking the download of executables from unauthorised sources or outright blocking the ‘shareware-and-freeware’ category from devices which don’t need to access such services.

With the agent installed on the victims machine the threat actor may graciously say something like ‘for added security you’ll see a code displayed, to protect the encryption between our machines to prevent eavesdropping please let me know what that code is’, this being the remote access code to connect to the victim.

After which the threat actor is connected to the victims session, most helpfully of all with full read/write access to the users file system – at a minimum allowing data exfiltration directly through the Command and Control channel of everything accessible to the user, at most allowing methods to establish persistence and revisit the computer at a later date to further the attack.

Of note the EDR agent installed on the machine didn’t generate any alerts – after all there is no malware involved just a widely used remote support tool.

Our network firewall did however correctly identify the application in use, another opportunity to prevent the use of such tools by creating an application list of all the known remote support tools and denying broad use while enabling the use of the specific tools by devices that require it for their normal operation.

• At the network:

  • Use URL filtering categories to block access to sites that host shareware/freeware.

  • Deploy network decryption, and:

    • Prevent the download of executables from unauthorised sources (requires allowlisting of update services and legitimate distribution sites).

    • Prevent access to unauthorised remote support tools across the entire organisation.

    • Fine-grain policies to permit access to authorised remote support tools from only the devices that require them.

• At the device:

  • Use application control software to allowlist authorised applications and block all others.

  • Use application controls software to alert SOC teams on attempts to launch previously unseen applications.

  • When using authorised remote support tools investigate configuration controls to prevent access from unauthorised 3rd parties (tenant restrictions).

• At the user:

  • Train staff to check with IT through establish communications methods before accepting remote support requests.