Push vs Pull in Command and Control.
This is just another loose dump of a few thoughts I was having this morning while working on a small implant related project that I'd forgotten about ages ago and decided to revive for a blog post in the coming weeks.
Mostly - this is just something for me to refer back to later. No great insights here.
Most of the time, implants used by pentesters and red teamers tend to use a "pull" model, or "beaconing" model, where the implant connects out to the attackers infrastructure to retrieve tasks or submit output.
An example of this would be Cobalt Strike or Empire - where the "beacon" periodically polls for things to do. This is - in many ways - conceptually similar to a reverse shell.
The upside of this is that network egress controls are usually more lax than ingress controls, so it is usually more feasible for your agent to "beacon out".
The downside is you need to maintain command and control infrastructure, that needs to be somewhat persistent for the implant to "phone home" to, along with redundant infrastructure for failover, in case your infra gets burned or blocked.
Worse yet - many implants on the market entirely lack a "update" feature for dynamically updating the command and control configuration, meaning if you want to swap out your command and control infrastructure you need to deploy an entirely new implant.
The other, somewhat lesser used mechanism for command and control is the "push" model, where you connect to the implant and submit commands, retrieve output, etc. Conceptually - similar to a bind shell, and most commonly used in webshells.
The major upside of a "push" model is that you do not need to maintain any infrastructure of your own. If you can talk to the target, you can submit commands.
The obvious downside is that you need to be able to connect to your target in order to submit commands - so ingress controls become an issue.
So, where am I going with this? Well, I was thinking about edge/perimeter devices such as routers, firewalls, VPN's and such.
With edge devices, more often than not (in my experience) ingress controls are a non-issue, which means "push" based command and control becomes an extremely viable option.
However, for some reason that I don't fully understand, most attackers still seem to deploy "pull" based implants on these appliances - increasing their own costs and infrastructure exposure for no tangible benefit. I often see this with examples in talks or blog posts of deploying Sliver or similar on compromised F5 or Fortinet devices.
Furthermore - from a network perspective, on these edge devices a passive "push" based command and control is significantly stealthier as there is no periodic "beaconing out". It just sits there, waiting, until you get around to activating it.
A fine example of "push" based command and control being used in the wild, which I will be referring to in a later post, was BPFDoor. BPFDoor is entirely passive, simply "waiting" to be activated by magic packets that tell it what to do.
There are a few other considerations - BPFDoor suffered a small weakness that allowed us to trivially scan for instances of it, by simply spamming the internet with its "ping" packet and listening for responses. This could have been mitigated with per-implant keying/activation strings and disciplined deployment practices, but that is a topic for another time (much like the topic of scanning for command and control servers in "pull" based implants).
I'll leave it at that for now, and refer back to this later.