While reviewing some tools and links posted in various infosec discord servers, I stumbled upon an interesting one utilizing Windows reboots as a persistence mechanism. I encourage you to refer to the Phantom Persistence blog linked below as it is a good read and with just enough detail to be dangerous. The main takeaways are utilizing RegisterApplicationRestart to register an executable to run anytime the system has a reboot. Now at a glance, you'd be thinking "Well how is that different than many other ways that achieve the same goal?". Well the answer is OPSEC! A common issue with many persistence mechanisms is trackable changes to the originating process, usually your stage0 loader. Most AV/EDR will monitor for registry changes from applications or users that should not be touching it, causing detections. But what if you can tell Windows to have another process write it for you, and to write it basically when everything else is going offline such as EDR process? Now we have something to work with.

TLDR:

PROS:

Your application never writes to anything. Your application will not write to the registry, instead instructing csrss.exe to write to it for you. It also writes to this registry so late in the shutdown process that most monitoring processes have exited or are in the process of exiting, effectively gutting any possible detections.

CONS:
Technique is not a guarantee your application will persist if there is a hard shutdown. This basically includes power loss or system crashes. The application must be running for 60 seconds or longer for it to be registered for restart, to prevent infinite looping.

Weaponized:

A POC is provided to give you a basic starting point on the Phantom blog along with a little video. I figured lets take this a little further and weaponize it to run a beacon. Below we will see it in action running AdaptixC2 v.06 shellcode on a Windows Defender host. Below we see Defender is on and the PhantomPersistence.exe is not currently running.

We double click our payload, and let it run!

So we have a good callback, but we need to prove our persistence works. You can force a reboot programmatically, a BOF/.NET, or social engineer one however you wish. I am lazy here and just restart :P

We successfully have a callback after the 60 second wait period. The application has also setup itself to perform this same sequence again so long as the system does not suffer a hard reboot.

Conclusion:

While not a home run method that is bullet proof for maintaining access in any scenario, the lack of logs and registry interactions against the payload process is an amazing advantage against EDR protections and blending in for OPSEC required gigs. I would include this into your toolbox and see if you can find good candidates to try this out. I would say this is probably best reserved for user workstations as servers tend to not shutdown very often. Please be sure to give the original blog post that inspired this a read and give it a go at implementing it in your lab.

Till next time, farewell and happy hacking!

References:

Phantom Persistence | PhantomSec Blog

(PhantomPersist) Written by: Grant Smith (S1n1st3r) - President @ Phantom Security Group

PhantomSec Blog