Red Teaming and Proxied Execution

C2 agents like Cobalt Strike’s Beacon usually have a set of baseline core features and the capability to load and run additional post-exploitation tools. Many C2 agents use a “fork-and-run” approach to this feature: to protect the Beacon against potentially buggy code and ensure it stays responsive if the loaded tool crashes, Cobalt Strike creates a new process, injects the code into that sacrificial process, and receives the tool output through a named pipe. Many EDRs monitor process creation, including parent processes. Using data about processes and common child processes, EDRs build detections around unusual child processes, or correlate other data like network connections or file creations to parent-child processes. Detections built from this accrued baseline of process execution have made the fork-and-run model more likely to be caught.

As red teams adapt to defenders, many choose to keep their code execution inline, i. e. , executing within the implant process instead of spawning a child process. Using proxied execution has the advantage of executing code on the attacker machine instead of on the compromised machine. The proxied execution simply connects to the open SOCKS port on the compromised machine and uses the compromised machine to connect to the attackers target for their objectives.

The implant process doesn’t need to spawn child processes or load code, only act as the proxy for the attacker, potentially evading EDR detections built on parent-child process models. Many red teams see this model of using a lightweight core agent that acts as a proxy intermediary as optimal.