The Necromancer: 1 – VulnHub Writeup

Source: https://www.vulnhub.com/entry/the-necromancer-1,154/

Starting off with a quick netdiscover to figure out what IP we’re dealing with:

 Mysteriously NMAP returns no meaningful results initially.

Hoping that services are just being run on non-standard ports I rerun the scan expansively checking all 65535 this time around.  Again, the nmap scan returns nothing.

I fire up Wireshark to see if I’m getting any sort of response that NMAP isn’t recognizing and at least from the scan I don’t see any response whatsoever.  I do see that the server is sending out ARP broadcast requests probing what’s out there on the subnet, though.

Following the broadcasts until they reach my Kali machine I notice something interesting.  As soon as it confirms there’s an available host on the IP it sends a request to me at destination port 4444.

4444…some quick googling and I find out that’s the default listening port for Metasploit.  Let’s try opening a reverse shell on that port and see what happens.

Not what it’s looking for but I think we’re definitely on the right track. PHP shell instead?

This time the connect is established but dies right away.  I try once more just to be sure but get the same result.  Maybe just a simple netcat listener?

Aha! It worked and I got a large block of some sort of encoded text.  My first instinct is correct and using a base 64 decoder I get the following text:


  • Welcome!

    You find yourself staring towards the horizon, with nothing but silence surrounding you.
    You look east, then south, then west, all you can see is a great wasteland of nothingness.

    Turning to your north you notice a small flicker of light in the distance.
    You walk north towards the flicker of light, only to be stopped by some type of invisible barrier.  

    The air around you begins to get thicker, and your heart begins to beat against your chest. 
    You turn to your left.. then to your right!  You are trapped!

    You fumble through your pockets.. nothing!  
    You look down and see you are standing in sand.  
    Dropping to your knees you begin to dig frantically.

    As you dig you notice the barrier extends underground!  
    Frantically you keep digging and digging until your nails suddenly catch on an object.

    You dig further and discover a small wooden box.  
    flag1{e6078b9b1aac915d11b9fd59791030bf} is engraved on the lid.

    You open the box, and find a parchment with the following written on it. “Chant the string of flag1 – u666”

Googling “e6078b9b1aac915d11b9fd59791030bf” I find it is an MD5 hash which translates to: opensesame

Chant the string of flag1 to u666….I’m guessing this probably means UDP port 666, but how?

I try a netcat connection over port 666…
Telnet over 666…
SSH…
I try connecting over SSH with user ID “opensesame”…

With each attempt I am seeing a TCP Retransmission from the server but nothing meaningful.  With some extra googling on how to send simple strings over UDP I come across this thread.

After sending I check in in Wireshark again and …we got a response!

Thinking it is wanting me to send a loop of strings I try a cluster of 5 in rapid succession but keep getting the same combination of responses.  I try a continuous loop ….and the same result.  I try repeating it several times in a single string and sending that….but same again.

Feeling like I’m missing something easy I backtrack and try the netcat connection again and realize I didn’t have the UDP flag set the first time I tried it.

It really was that simple.  This time a session opened right away and after typing in the password we now officially have flag 1!  And a new HTTP site to greet us:

We’re now faced with a website and another MD5 for flag 2:

c39cd4df8f2e35d20d92c2e44de5f7c6

The MD5 decrypts to: 1033750779

A Nikto scan doesn’t yield any obvious vulnerabilities in the BSD server.   Other than the /pics/ directory looking at the main site doesn’t seem to leak anything useful right away.  I’ll open Dirbuster and see if I can enumerate any hidden directories on the webserver.

While letting it run I try to think of what the “1033750779”, “pile of feathers” (name of the picture on the site), or “gaseous blue haze” could all be referring to.  I can’t help but think there’s some sort of clue in the picture.

Let’s take a look at the pileoffeathers.jpg and just cat it to see if there’s anything funny going on:

Looking closely I see “feathers.txtUT” and other text that doesn’t look random at all.  But how to extract it?

Trying to extract via Steghide I try using the password 1033750779, feathers.txt, pile of feathers, gaseous blue haze, others without success.  I’m guessing another tool was used to combine the files together.  Meanwhile Dirbuster hasn’t found anything useful.

Doing some more googling trying to figure out the most likely method someone would use to bind files with the image I came across binwalk which should give us a readout of all files contains in a merged file like this one.

More than just a txt file, there’s a zip in there as well.

Feathers.txt is just a long string:

ZmxhZzN7OWFkM2Y2MmRiN2I5MWMyOGI2ODEzNzAwMDM5NDYzOWZ9IC0gQ3Jvc3MgdGhlIGNoYXNtIGF0IC9hbWFnaWNicmlkZ2VhcHBlYXJzYXR0aGVjaGFzbQ==

The == gives it away as base64…decoded it comes out to be:

flag3{9ad3f62db7b91c28b68137000394639f} – Cross the chasm at /amagicbridgeappearsatthechasm


The zip file as it turns out was just a container for feathers.txt so nothing extra in there.

The flag 3 hash decrypts to “345465869

And guessing correctly amagicbridgeappearsatthechasm comes out to be a URL path pretty well immune to casual bruteforcing:  http://192.168.111.100/amagicbridgeappearsatthechasm/

Another page and another picture.  Copying magicbook.jpg and checking binwalk again this time it is (seemingly) now nothing more than just a picture.

345465869 again seems to be a timestamp but it’s not apparent yet how or why that would be useful.  Searching through the available Kali tools I’m trying to find anything that would fit with clues given.

Checking NMAP again to see if anything opened up except port 80…..nope.
Tried the 345465869 a number of different ways as part of the URL…..nope.
Tried googling and thinking of a list of things that would possibly match the clue:

  • pendant
  • ring
  • scarab
  • orb
  • staff
  • amulet
  • talisman
  • bracelet
  • rod
  • scroll
  • shield
  • (possibly any type of armor/weapon)
  • wand
  • circlet
  • cloak
  • cape
  • necklace
  • robe
  • brooch

Coming back after a break and with a (hopefully) clear mind I again looked through the Kali tool list and nothing really seemed to make any sense fitting with the clues.  As the URL itself could have only been bruteforced otherwise…I’m wondering if there’s something inside this /amagicbridgeappearsatthechasm/ folder that is similar.I prepend my word list to directory-list-2.3-medium.txt and fire away trying to bruteforce a file/folder underneath http://192.168.111.100/amagicbridgeappearsatthechasm/.

Not long at all and one of my words is a successful 200 response!

And it’s not a folder at all but an extension-less file.  Saving the file and taking a look at it again through binwalk we find out it’s an “ELF” executable.  Trying to run it straightaway I have little or no luck so let’s see if we can get any info from the file.

A LOT of options here using “readelf” so let’s just start with the -a all first.  Scrolling through a few pages of output under “system table ‘.symtab'” I finally notice some interesting items noting especially the hidden “wearTalisman” & “chantToBreakSpell”.

Looking at the binwalk again I notice it’s a 32 bit executable.  I’ll have to do some digging to find out how to get it to run on my x64 VM.

After doing a little bit of googling again I found instructions on how to configure Kali to run x86 executables.

sudo dpkg --add-architecture i386
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

Now let’s try running the file again…success!

Somehow I need to trigger the “wearTalisman” or “chantToBreakSpell” functions, but at least from the main screen they’re giving me there isn’t a clear way to do that.  Trying yes, no, wearTalisman, chant, and a handful of other commands I’m getting the same result.  What happens if I just type in a bunch of garbage?

I get a segmentation fault.  I’m sure there’s a good way to exploit this…Although I’ve had a little practice with buffer overflows already in the OSCP training, I’m still pretty new to it so I’ve found a good guide online to try and walk me through the process in GDB (Linux debugger).

With a little trial an error I figure out the exact point at which I can trigger an overflow (it allows 31 characters, any more trigger the error):

Then we check the memory address of the main function, and dump the assembler code so we can better follow the path the program takes:

The “wearTalisman” function call comes up here.  Let’s try dumping the code for that function as well:

Nothing interesting right away (lots of filler MOVB), but then we start seeing several blocks of text outputs.  If we can either decode this or force the program to cut to this function directly we should be in business.

At this point I tried running from break point starting at func wearTalisman, or starting in the main function then jumping to wearTalisman from there but didn’t have any luck.  The function  didn’t appear to be doing anything at least in the way I was trying to call it, but I do remember seeing other interesting items when I looked in ReadELF, so let’s see if we can get a function list in GDB.

A LONG list of functions (mostly looking like system functions after this first page) but again I see reference to “chantToBreakSpell”, “unhide”, and “hide” that I saw before.  Let’s try those as well:

And it worked!  I now have flag 4.

  • flag4{ea50536158db50247e110a6c89fcf3d3}
  • Chant these words at u31337

MD5 for “ea50536158db50247e110a6c89fcf3d3” is blackmagic.  Copying the pattern from before let’s try netcat on UDP port 31337.

For once an easy one!  But I know well enough to start getting cocky.
Trying the /thenecromancerwillabsorbyoursoul path in the URL, though, I also get the next flag immediately.

Clicking the “necromancer” link I get a necromancer bin file that extracts to a packet capture file (*.CAP).  U161 must either be a reference to netcat or maybe a clue on what to look for in Wireshark?

Viewing the CAP in Wireshark I identify several devices by source that are responsible for most of traffic (all is over 802.11):

  • D-LinkIn_0d:5e:95
  • SamsungE_20:52:75
  • Technico_a2:f5:a1
  • Tp-LinkT_05:b5:c3
  • Apple_20:68:48
  • Apple_6a:9f:5e
  • Apple_14:65:8f
  • Tp-LinkT_05:b5:c3

I see probe responses and a beacon frame from D-LinkIn_0d:5e:95 returning with an SSID of Community.

SamsungE_20:52:75 is also constantly sending out de-auth packets.  This is suspicious and exactly the type of activity you might see if someone was trying to de-auth and spoof an access point, or if someone was trying to get other devices to re-auth constantly in order to crack the password.

Looking at the broadcast in detail we can also gather that the network is capable of 802.11n, is running on channel 11, and is using WPA.

Using the instructions here I’ll port the CAP file over to a file that hashcat can parse and then attempt to crack.  In my case I just used the advertised site to perform the conversion (https://hashcat.net/cap2hccapx/) and it downloaded in the needed hccapx format.

Now let’s start up hashcat using rockyou as the dictionary (located in /usr/share/wordlists in Kali):

After running for over 2 hours I started getting impatient.  Googling suggested I might get results faster using aircrack instead so I did that.  I was starting to regret my decision when I started getting estimates of 2-3 hours to crack, but then after just a few seconds I got back the key.

Now back to the clue on http://192.168.111.100/thenecromancerwillabsorbyoursoul/

  • Looking closer at the skull, you can see u161 engraved into the forehead.

Like in previous flags, I open a netcat session on UDP 161, and get a session opened, but entering the password doesn’t seem to get me anywhere.

NMAP scan returns nothing.  I open the session and try NMAP again in another terminal while the session is open and I get nothing.

I open up Wireshark to track network activity as I try the netcat session again.  I see the string data getting sent from my Kali machine, but no response and no other network activity happening.

More googling and I came to this site about crafting test SNMP quuries using snmpwalk.  Now the “community” SSID part makes a lot more sense.  After some trial and error figuring out the correct version I finally get some interesting output!

Using the new community string of “death2allrw” I get a huge readout of OID values to look through.

Grepping for “unlock” I find this:

  • iso.3.6.1.2.1.25.4.2.1.5.27695 = STRING: “-i unlocked”

Grepping for “flag” I hit the jackpot (I think), but I’m confused why there would be flag5 and flag6 here….we already have those:

I grep for “lock”:

Maybe it’s as simple as just setting the string to read “The door is unlocked”?  Checking the parameters for snmpwalk I don’t see anything that would allow me to set/replace strings.  Googling isn’t helping too much either for a while until I realize I need to change the values with a separate command (snmpset)

My first try didn’t do anything, but updating the “Locked – death2allrw!” string did the trick, and there is flag 7!

The starting clues for flag 8 (only 3 more to go!) are an md5 hash of 9e5494108d10bbd5f9e7ae52239546c4 and “T22“.

The hash decodes to demonslayer and the T22…TCP port 22?  Probably SSH?  Let’s try NMAP:


I then try to SSH in with login ID root, necromancer, demonslayer, tacos with several different passwords.  No feedback on whether login IDs are valid or not.

I create a login ID dictionary (logins.txt) of:

  • root
  • demonslayer
  • fearthenecromancer
  • necromancer

And then setup Hydra to try and bruteforce SSH with that and the “rockyou.txt” passwor dictionary from before.  I’ve prepended the 4 above entries to the password list as well.

Wait a sec…[STATUS] 447.33 tries/min, 1342 tries in 00:03h, 57376250 to do in 2137:43h, 16 active

No, no way we can test all those logins.  We’ll have to just try one and make it count so let’s do demonslayer as it’s the most logical (unless I’m missing an obvious hint on the password, I hope not):

Yes!  Like a previous bruteforce attempt it took only a few seconds to hit on the password when targeted correctly.  Now with the password…

In the local dir I find:

Time to fire up Wireshark and see what’s being sent.  I watch for a few minutes and only see a periodic ACK back on my SSH connection.  Let’s try netcat on UDP again with the port 777 they specify.

I open the session and type in some gibberish.  No response.  And still no clues from Wireshark.  I got stuck for a long time here until I tried running netcat in the SSH session itself.  It must be a different version of netcat because I had to modify switches to get it to work.

I better not get any more wrong…I’ll have to be more serious in my google-fu:

Crap, nevermind.

I restart the server hoping SSH is just hung, but no cigar.  We’ll have to try backtracking.

NMAP scan to see if SNMP is back up. It isn’t, and neither is SSH.  And I can’t get to the website to shortcut a few flags back.  I guess this will be a learning experience.
nc -l -p 4444  // DECODE, flag 1!
nc -nvu 192.168.111.100 666 // chant opensesame, flag 2!
// flag 3 is still in feathers, jump to http://192.168.111.100/amagicbridgeappearsatthechasm/
// then /talisman to download the file (in case this is needed to trigger next event)
// we already cracked the talisman ELF file for flag 4
nc -nvu 192.168.111.100 31337 // chant blackmagic, flag 5!
go to: http://192.168.111.100/thenecromancerwillabsorbyoursoul/  // flag 6!
nc -nvu 192.168.111.100 161 // open SNMP
snmpwalk -c death2all -v1 192.168.111.100 // (actually didn’t work the first time, so did netcat and typed in “community” and “death2all”, closed out, and then reattempted – it worked 2nd time…
snmpset -c death2allrw -v1 192.168.111.100 iso.3.6.1.2.1.1.6.0 s “Unlocked!”
snmpwalk -c death2all -v1 192.168.111.100 // flag 7!
ssh demonslayer@192.168.111.100 // pass 12345678
cat flag8.txt
nc -u localhost 777 // WHEW, BACK WHERE WE LEFT OFF

Devil (more commonly known as Mephistopheles in Faust literature)

And now we have flag 8 and flag 9!

Flag 10! Almost done!

Thanks to the locate command, it looks like “vile” was a hidden file right in the home directory.

But now what?  I try re-opening the same netcat session again but no response.

I check my ID:

Nope, no root priv.

I try:

  • cd /root – access denied
  • sudo cd /root – access denied with demonslayer password
  • locate flag – nothing interesting
  • sudo su – Sorry, user demonslayer is not allowed to execute ‘/usr/bin/su’ as root on thenecromancer.
  • I go to /usr/bin/su and run “su”: you are not in group wheel
  • Maybe I can add myself to the group with sudo priv?  Sorry, user demonslayer is not allowed to execute ‘/usr/sbin/group add wheel’ as root on thenecromancer.
  • visudo? visudo: /etc/sudoers: Permission denied
  • sudo -l?

WAIT I THINK WE GOT IT.

And that’s the last flag!  Awesome challenge and few days in the making (breaking).  :)Thanks Xerubus!