> For the complete documentation index, see [llms.txt](https://exploit-pack.gitbook.io/exploit-pack-manual-pages/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://exploit-pack.gitbook.io/exploit-pack-manual-pages/control-pack/the-watchdog.md).
# The Watchdog
We have noticed in many post-exploitation frameworks that persistence access is a recurring weakness. The issue remains by design in their single-process execution model.\
\
This could become a real problem if the target (victim) process is terminated due to a crash, service restart, or defensive interaction, resulting in recovery, if even possible, depending on external persistence mechanisms or manual redeployment.\
\
This problem is technically solved in Control Pack C2. And the approach we adopted is a dual-process supervision model, which we called "The Watchdog", and this is how it works:\
\
1\. First, Stage 2 must be enabled:
2. Then, deploy the Watchdog. An execution thread with the Control Pack agent is injected in real-time into a legitimate running service
\
3\. An independent thread is then spawned (The Watchdog), linking the same process structure and monitoring the agent’s execution state:\
\- Mutual supervision between: Control Pack Agent <-> Watchdog\
\- Automatic re-establishment if either side terminates or is terminated\
\- Logging capabilities during runtime and unhooking/direct syscalling still apply while the execution remains active.
\
Revenge: If a protection process, such as an AV or EDR (userland), successfully kills the agent thread, the watchdog fights back: It lists the process tree and active files of the offending process, killing the tree and injecting itself, when possible, as a new watchdog into the offending process, effectively running behind enemy lines.