Cyber games

Wargames, April 2025 – Command and Control (C2), Sliver

As a 20+ year “blue” veteran, our yearly wargames arranged by James always offer an insight into the other side of the fence. This time around we focused on some of the different C2 frameworks that are out there, some used by legitimate red teams, and bad actors alike.

I ended up with the “sliver” framework:

Sliver is an open source cross-platform adversary emulation/red team framework, it can be used by organizations of all sizes to perform security testing. Sliver’s implants support C2 over Mutual TLS (mTLS), WireGuard, HTTP(S), and DNS and are dynamically compiled with per-binary asymmetric encryption keys.

Setup

Linuz one liner

All done in a single command, on my cloud Linux VM, I’m ready to start creating implants. Which again is a single command with a few options referencing the ports and IP addresses.

I hosted the implant over HTTP to keep things simple, I wouldn’t anticipate any but the laziest of threat actors to do this! Download to my target endpoint (stand-alone windows 11) and run!

Web page blocked

We typically have everything in “listen only” mode for an exercise like this, see how far we can get, and track back through alerts and notifications to determine different points in the lifecycle of the threat where we could have taken action. Apparently we weren’t quite FULLY in listen only.

With that disabled, Defender steps in and destroys the file.

Windows security

This is great, but I’ve made no real effort to bypass Defender, and realistically this would be plausible with basic obfuscation, payload encryption, or more sophisticated techniques like process injection or memory-only execution. A determined attacker would almost certainly invest in these methods to avoid detection, highlighting the need for layered defenses.

And with that I have a C2 session back to my sliver VM.

Sliver rearmed

Thankfully at this point the Palo Alto firewall would also have had a chance to break the connection.

The executable was detected by the inline machine learning engine as malicious (and with correct configuration of the firewall would have been blocked).

Likewise the C2 channel was detected and would also have been blocked.

Remember, I didn’t use TLS for my download or the C2 channel, at this point TLS inspection on your firewall for internet traffic becomes important.

Next Steps

How about some persistence? I have a remote shell, so easiest would be to live off the land and use a bit of PowerShell.

And there’s my executable ready to run at startup. No skilled threat actor is going to leave this in the downloads folder, finding a software distribution folder for example, these are regularly excluded from malware scanning.

At this point I’m already getting quite a few alerts from the Palo Alto XDR agent, which I’ll circle back to shortly.

Next up, I attempted to dump some accounts and password hashes using nanodump, a built in tool in sliver, having essentially full access to system tools at this point, I just listed all system processes to get the process ID of lsass, and away we go.

A quick read of the dump using pypykatz

The password for this account was FAR from strong, so it took seconds to reverse it from a lookup table.

What else could be done?

The sliver framework has a myriad of tools which time wouldn’t allow me to explore much further, however of note,

  • Upload/Download of files, I used this to deliver winPEAS https://github.com/peass-ng/PEASS-ng/tree/master/winPEAS, an excellent discovery tool

  • Keystroke logging

  • Privilege escalation tools

  • Network discover tools

  • An extensive “Armory” of other 3rd party tools, including in-memory/fileless versions too

  • Inject the implant into legitimate software.

Detections

Now, from my perspective to the good bit, where could we have broken the attack chain?

I’ve already covered the Firewall detections, these would almost certainly depend on TLS inspection being enabled and working correctly, no serious threat actor is going to use clear text http.

In addition I also noticed a couple of extra sessions to my C2.

John and Ralph were NOT part of this exercise, they were in fact sandbox machines belonging to Palo Alto Networks, the XDR agent and the firewall, had both submitted the file to the Wildfire sandbox service. which in turn flagged it as malicious.

Heading back to the XDR console, it was pretty busy. of note with our Lab tenant for XDR we don’t have 100% coverage as we are not feeding firewall logs in to the cloud, I’d have expected the firewall detections for C2 to have appeared here if we did.

That’s a lot of alarms!

Firstly, my remote shell was detected, that’s the resource development tactic.

Next my attempt to inject my implant into notepad.exe

Likewise my credential gathering was spotted.

Along with my previous attempt to use mimikatz rather than nanodump.

In the next article

Our key findings and final thoughts from this tour of remote command and control.


LET’S TALK ABOUT  YOUR CYBER SECURITY