In the paragraphs that follow, I'll illustrate how to compromise one such system named Jeeves. I will then present some lessons learned regarding how this challenge might relate to the real world and how this knowledge might be applied to future engagements. Finally, I'll list a few supplemental resources that elaborate on some of the concepts used in the walkthrough. If you're still hungry for information by the end of this post, that might be a good place to start.
This post (and the box itself) are largely intended for beginner-to-intermediate students of information security. If you're already an accomplished hacker, penetration tester or CTF player, you might still find it an interesting read, but odds are that this machine does not pose much of a challenge for you and the elements of penetration testing that I describe will be review. Anyone still with me, read on.
Knowing Nothing
Since the host IP address was known, I did not perform a host discovery step. Instead I opted to scan the box speedily with nmap and begin enumerating its services.
Some quick observations: it appears that Microsoft SMB services are running on the box. A website is being hosted via MS IIS on port 80. Jetty, an open-source web server that's often associated with dev ops or web application testing, is running on port 50000. nmap guesses that the box's operating system is Windows Server 2008 (this was incorrect, but it was a decent enough guess).
I performed additional enumeration of the box's SMB services using enum4linux and nmap's collection of nifty SMB scripts. I also performed a brief UDP scan with nmap. I did not discover any additional information using these methods.
IIS 10.0 and Jetty 9.4 are modern web servers and I did not consider it likely that there was a public exploit targeting a serious remote vulnerability in either. Some research on that front seemed to prove me correct.
At this point, it was beginning to seem as though direct compromise of these services through a web server exploit or similar means was unlikely. Instead, I continued the enumeration process, shifting my attention to looking through the web content hosted on ports 80 and 50000 of the box.
Jeeves
Navigating to the website hosted on port 80 of the box with a browser produced this page:
This webpage appeared unfinished in many ways. None of the hyperlinks listed above the search bar lead to a valid URL, and searching for anything resulted in an image of an error message:
I took note of this information, but again, this was an image of an old error message (see the page's HTML above) and not an actual error message generated by me poking around.
While browsing this site to get a feel for it, I was also running Nikto and DirBuster against it in the background. This did not produce any significant information.
Unsure what to make of all this, I decided I'd perform some quick enumeration of the web application being hosted on the Jetty server before digging too deeply into the Ask Jeeves page.
Jetty, Jenkins
I followed the same enumeration procedure for the content hosted on the Jetty server as I did above, browsing its content manually to see what my eyes could find while Nikto and DirBuster slowly searched for hidden web content in the background. Locating any files or directories manually proved all but impossible, as the site did not have an index or any other discernible pages:
For this reason, I eventually opted to wait until my automated scans were done before proceeding. Nikto did not discover anything too out of the ordinary, but DirBuster and its directories 1.0 wordlist saved the day by discovering a directory named “askjeeves”:
Browsing to the “askjeeves” directory, I found an unsecured Jenkins instance:
I am not intimately familiar with Jenkins, but once upon a time I was a software engineer and I am aware that it is a dev ops assistance application used to manage code versioning, testing and deployment. This set off alarm bells in my head that this could be a prime target for attack.
In retrospect, I probably should have been able to intuit that there would be a directory named “askjeeves” here based on the information I discovered while enumerating the original web application. It's okay to be saved by automation once in a while, though. Onward to the initial breach.
Exploitation
Knowing that Jenkins is a dev ops system, I suspected it might contain a way to upload arbitrary files and/or execute arbitrary code on the webserver, conditions which could enable a compromise. Little did I know it would be this easy; after following just two links (Manage Jenkins - - > Script Console) I ended up here:
The page speaks for itself. Yes, Jenkins contains an interface for executing arbitrary statements written in the Java-esque programming language Groovy. It'll even show you the results of the statements afterward. Like most programming languages, Groovy provides ways of interacting with the underlying operating system. I already knew the box was running Windows, so with a minute or two of Groovy syntax/API research I was executing system commands on the box:
However, this isn't a very comfortable working environment. Post-exploitation is more easily performed with a reverse shell. Not wanting to write one from scratch in a language I don't know, I searched online and discovered an open-source Groovy shell at https://gist.github.com/frohoff/fed1ffaab9b9beeb1c76. Full credit to the original author. I changed the appropriate variables to allow me to catch the reverse shell connection with netcat on port 443. At that point, simply pasting the modified reverse shell code into the script field and pressing “run” gave me a reverse shell:
User Flag, Escalation
With my shell running with the privileges of a user named “kohsuke” (who was not an administrator) I began to perform post-exploitation in earnest. It's necessary to gain administrative privileges on the machine to obtain the root flag. But first, I quickly snagged the user-mode flag by changing my working directory to C:\Users\kohsuke\Desktop and running type user.txt.
After that, I performed a quick enumeration of the users, groups, and programs running on the box; these steps are not shown. I then began reading through each user's documents looking for something that I could leverage. At C:\Users\kohsuke\Documents, I found an interesting file:
Googling the kdbx extension, I discovered that it represents an encrypted data store for a password manager program named KeePass. Figuring that the passwords inside could further my compromise of the box, I downloaded the file and researched the file type more deeply. I learned that the keepass2john utility could extract a password hash from this file that would then be loadable by the hash cracking utility John The Ripper. The process of using keepass2john and John itself to obtain the master password for the KeePass file is shown below. I chose to use a wordlist attack with the well-known rockyou wordlist.
As indicated by the image, the password for the KeePass file was “moonshine1". To open the CEH.kdbx data store with this password, I downloaded the portable version of KeePass, executed it, and simply used the FIle → Open File menu option to load CEH.kdbx. When prompted, I provided the password that John found, which proved sufficient to decrypt the data store and show me many things I wasn't supposed to see:
I examined each password individually and discovered that the “Backup stuff” password was an NTLM hash aad3b435b51404eeaad3b435b51404ee:e0fb1fb85756c24235ff238cbe81fe00. I thought that I could use this in a pass-the-hash attack against the JEEVES machine's Administrator account to gain elevated privileges. There are numerous tools that could aid us in doing this. I chose to use the simple pth-winexe program, shown below. Metasploit's exploit/windows/smb/psexec module is also an option.
Bingo. With administrative privileges, the challenge was all but complete. All that was left at this point was to dump the root flag. Per HackTheBox's rules, the root flag should always be in a text file in the administrator's Desktop folder. However...
Interesting. It appeared that the challenge's author was attempting to throw one last curveball at me. I knew that the challenge was unlikely to deviate from HackTheBox's rules and the flag was probably hiding in plain sight on the desktop. I read numerous malware analyses in the past which discussed attackers using an element of NTFS files called Alternate Data Streams (ADS) to hide information from analysis tools that are not aware of this little-known feature. I thought the real flag might be in an ADS of one of the files on the desktop. You can show alternate data streams in a directory listing with the /r switch:
See that? “hm.txt” had an ADS called “root.txt”. Now that I knew it was there, the only trick left was knowing how to list it. Some Windows utilities recognize ADS and some don't. For example, type, the go-to utility for reading text from a file, does not, so I used the more command, which seemed okay with the following:
That's it! The challenge is now completed.
Lessons Learned
There is a limit to the degree with which challenges such as this can emulate reality, and many of them are not intended to emulate reality in the first place. Yet I am always thinking that games are not merely games. From the beginning of our lives, they shape the way we think, color the way we act, help us understand patterns and predict outcomes, are our first exposure to strategy, and generally help us comprehend everything that surrounds us. Perhaps the relationship isn't as direct as that of lions teaching their cubs a swipe of the claws, but it's there nonetheless. So, in that spirit, here are some echos of this challenge that I think are perfectly applicable to real-world hacking scenarios and may be valuable lessons for aspiring infosec folks like myself.
Content is often web-facing by accident
When someone is deploying numerous websites, using numerous technologies, and possibly isn't familiar with some of the tools they're using or the implications of their actions, it's quite easy for files and folders that were intended to remain private to be accidentally served to the internet. They can even be indexed by search engines. These files and folders may be backups of source code, text files, documents, database files, entire toolkits like Jenkins...nearly anything. The site operator and casual users may not notice these files or understand the risk they present, but determined bad guys will use open-source intelligence or forced browsing techniques (like the DirBuster attack used in this challenge) to locate them and take advantage of them.
This type of vulnerability seems surprisingly common. Case in point: using Google trickery I crafted a targeted search to find web-facing Jenkins installs. There were hundreds. At a glance, several appeared to expose exactly the same “Manage Jenkins” interface--and therefore the same script console--as the box in the challenge. Luckily I'm not the bad guys, but you can bet the bad guys use this same technique and have probably already compromised those systems. Some of those systems may be honeypots, but I'd wager many are real systems.
Forced browsing is wordlist-dependent
Most forced browsing programs use a list of file/folder names and simply make a request for a resource with that name to the site in question. Based on the web server's reply, the tool and its operator determine whether a resource with that name exists on the site. This means that if you don't use the right list of words, you might fail to discover content that is waiting to be exploited by someone.
For example, in this challenge I used the DirBuster program and selected a very large wordlist. If I had used another popular forced browsing program named dirb and its smaller default wordlist, it would not have discovered the "askjeeves" Jenkins directory because "askjeeves" is not in dirb's default wordlist. I would not have completed the challenge until I thought to try a different wordlist or intuited the presence of the directory through other means.
Poor password practices often enable a breach
There is a constant battle between what is convenient and what is secure, and passwords tend to be one of its first and most obvious casualties. This could include everything from unchanged default passwords to easily guessable passwords to reused passwords to passwords scribbled on sticky notes and stuck to an employee's workstation. In this case, it was a digital version of the latter.
Keeping passwords in files, whether in plaintext, encrypted, or hashed, is awfully convenient, but it's also an outright poor idea from a defensive perspective. These are among the first things that attackers should look for when they've gained partial access to a system and are seeking to elevate to complete control. Browse desktops, documents/home folders, the install directories of programs, and so on looking for files that may contain passwords. Automate the search with a command-line utility if it will help. Attackers often refer to finds such as the KeePass file in the challenge as "quick wins," which isn't what you want to hear a hacker say.
Tools that manage become tools that attack
It doesn't take a lot of imagination to turn something that's designed for managing a system into a tool for enumerating and compromising that same system--see numerous abuses of Powershell, WMIC, cron, sudo, and so on. Jenkins is obviously a powerful platform for administrating web/development servers, which means that unless it's expressly configured to prevent this sort of mischief, it can easily bite the hand that feeds it. The same goes for too many other programs to name.
I knew as soon as I saw the “Manage Jenkins” menu option that I had struck gold, and that's only scratching the surface of what you might learn from a real-world Jenkins installation. You the attacker should have a similar intuition about what programs can be leveraged for your purposes. You the defender should have a desire to configure these programs as appropriately as possible to prevent abuse.
Conclusion, Additional Resources
This challenge was a lot of fun. I thank its creator for providing this learning experience, HackTheBox for hosting their virtual labs, and anyone who made it this far for reading. Below are supplementary resources for some of the topics discussed here.
Nmap port scanning, service detection, OS detection:
https://nmap.org/book/man-port-scanning-techniques.html
https://nmap.org/book/man-version-detection.html
https://nmap.org/book/man-os-detection.html
Forced browsing, DirBuster:
https://www.owasp.org/index.php/Forced_browsing
https://www.owasp.org/images/1/19/OTGv4.pdf (Large file; discussion of forced browsing begins on page ~53)
https://www.owasp.org/index.php/Category:OWASP_DirBuster_Project
Jenkins:
https://jenkins.io/doc/ (Jenkins statement of purpose, documentation base)
https://jenkins.io/doc/book/managing/ (Section specific to the "Manage Jenkins" interface)
Practical attacks against KeePass:
http://www.harmj0y.net/blog/redteaming/a-case-study-in-attacking-keepass/
Pass-the-Hash attacks:
https://blog.ropnop.com/practical-usage-of-ntlm-hashes/
https://www.harmj0y.net/blog/redteaming/pass-the-hash-is-dead-long-live-localaccounttokenfilterpolicy/
Alternate data streams:
https://hshrzd.wordpress.com/2016/03/19/introduction-to-ads-alternate-data-streams/
https://blogs.technet.microsoft.com/askcore/2013/03/24/alternate-data-streams-in-ntfs/