part 1: disassembling and understanding shellcode

About a month ago I signed up for the Securitytube Linux Assembly Expert certification to get a deeper understanding of assembly and GDB. Doing so has helped me understand what is actually going on in the registers and not just relying on “hail-mary” advice like “use pop, pop, ret when dealing with SEH.” If you’re interested in Assembly or writing shellcode, I’d highly recommend you take the certification.

My first SLAE assignment was to write my own bind shell. I don’t know C well enough to code straight from memory, and even though I understand how individual assembly instructions affect data in the registers and the stack, I didn’t know how to string these together to create working shellcode. I couldn’t find many tutorials devoted to the subject so I decided to just dive in and build it from scratch.

build a heartbleed test lab in 5 minutes

Lets be clear, I’m all about the offensive side of information security. I’m a pentester and I enjoy popping, rooting, owning and pwning all the things. I am aware that what we do is there to assist and encourage better defensive countermeasures but I just leave that to the experts. My colleague sitting nearby has the more unfortunate “defensive” job consisting of writing detections for all the evil things I do.

post exploitation: finding passwords in haystacks

Often while conducting an internal pentest you may gain access to a user machine through some vulnerability or more commonly via social engineering. Let’s say that you pop a shell, unprivileged, and incognito only finds unprivileged domain tokens. You could move onto another target or you can try some post exploitation reconnaissance. A commonly overlooked source of sensitive information is documents that are stored on the company servers as well as staff who think they know enough to start sharing folders with their peers and end up sharing the root of ‘C’. These can be a fantastic source of juicy info if you know how to index and then search through them effectively.

decrypting base64 encrypted binary hashes

I came across a database while testing the other day which happily contained a table called users with the good old id, username and password fields. What made this a somewhat interesting find was the fact that the passwords appeared to be encrypted as base64.

After I stopped giggling I dumped the database and grabbed the first few hashes in an attempt to quickly script the decryption. The script ran fine although I ended up with a lot of garbled text and no plain text passwords. I decided to try decrypt these passwords using several online websites when I discovered that they were actually binary files that had be encoded with base64. I began to doubt my sanity and asked myself why anyone would have passwords stored as binary files. I mean, the log in page didn’t have a field for username and an upload box for password so what was going on?

apache log poisoning with local file inclusion

So we have our Local File Inclusion vulnerability and we can read the “/etc/passwd” file, now it’s time to start escalating the attack so that we are able to execute our own commands on the target system.


In the previous post, we found the Apache log files and particularly the Apache “error.log” file using Burp Suite’s Intruder module. We are now going to use this log file to inject our own PHP code into this page.

If we tried to access “” we should get an Error 404 telling us the the page was not found. Additionally, this should also echo our invalid request into the “error.log” file and we can now clearly see that by requesting anything that generates and error we have the ability to influence the contents of the “error.log” file.


finding the apache log files using burp intruder

Often when conducting security assessments it is necessary to go beyond just identifying the vulnerability, reporting it and heading out for a beer. Sometimes, like when conducting a penetration test or when asked by a client to demonstrate business risk, it is necessary to gain command line line access to the machine to show the risks associated with having a web user being able to execute commands on their machine. Often this involves getting a shell by some means but in the case of Local File Inclusion (LFI) simply finding the Apache Log location folder can be enough to start running commands on the system as the Apache service account.

Often I’ve wasted hours trying all sorts of combinations trying to find the correct location of the log files by looking up version numbers and identifying operating systems but being the true to the Pentesters code, sometimes it’s better to be lazy and just automate the damn thing. So what a buddy of mine and me did was to compile a list of common Apache … read more