hosaka

⊕ a tessier-ashpool subsidiary

systemd user persistence in metasploit

⊕ 2019-02-18

A couple of years back I wrote about how to use the systemd --user options to create a semi-stealthy backdoor in this post. Since then I have begin to finally contribute back to the Metasploit framework, and I decided to do a run through of merging some of my projects into the framework. The first one that I have pushed last week can be seen here in this pull request.

One of the core benefits to merging this into Metasploit is to add a mechanism for service persistence that does not require administrative privileges.

usage

In order to use the persistence modules you must have already shelled a box and need to establish a longterm foothold. If the pull request was merged then it's simple to use, otherwise get a copy of my feature branch located here, then launch your payloads with the module loaded.

Set your normal callback LHOST, LPORT, and SESSION parameters, but then finally select the systemd user target with set target 4. Lastly it's important to change the payload drop location to a world writable directory, the rest of the persistence modules expect you to already be an administrator, so doing a SHELLPATH /tmp will usually do. Additionally, I added the "enable" behaviour to be an advanced option. Then execute your payload. If everything is successfull you will get an initial shell back and on each subsequent user authentication (if ENABLE true is set).

future

Once this gets merged into the framework I will aditionally start rehauling some of the logic in the service persistence, especially in the context of systemd. I have already got the code for selecting the "login" and "logout" behaviour that I described in my original post.

Additionally, I'd like to get the service persistence callbacks to allow for certain behaviors like time based callbacks and more, but that's less fleshed out.

I have begun making some core library changes off of branch to try and encourge the ability to use built-in system calls as opposed to the habit of calling exec, I think this would be valuable in a couple of common situations. So look forward to that in the next decade.