Skip to main content

Advanced Exploitation Techniques - Part 2



Understanding Egg hunting


 Tutorial 1 – Hello World! Let’s hunting with Eggs

Welcome to the module where we will debate about an advanced technique in the exploit development lifecycle. This is a step where you move slightly up in the field of security testing by means of using key concepts of the language of machine. However it is strongly believed that the overall concepts in exploit development can not be delivered in a single course and you have to keep learning more and more until you quite understand this type of work!

What we are talking about?

Egg-hunters, wow delicious name or at least it sounds delicious for people who love to eat eggs. Ah, anyhow, this is basically the name of a concept or a technique which is used in advanced exploit development.

What is egghunter?

Before we start discussing the concept of egghunter we would like your attention to be focused on shell code. If you have a good understanding of a shell code then understanding the underlying mechanism of egghunter won’t be that difficult for you to absorb.

Shell code

They are small pieces of code written in any programming language, which are used as payload when we are exploiting any vulnerability. Now this is de-facto whereas the payload is the actual action required to be performed by an exploit.

Types of Shell code

There are two main types of shell code that are commonly known. Remote shell code and local shell code; the only difference in these types are where and how these shell codes can be launched. Anyhow this is enough here to put onto as a definition.

Now, back to egghunter. Okay, imagine that vulnerability, which you have discovered, only gives you a small space in the memory where you can put your shell code. This could be hardly one byte? Well so far I haven’t heard or faced anything like this small space but it could be 20 bytes or anything. The amount of space is compared to the shell code you want to fire.

More on Egghunter

Now imagine, you have a shell code which requires N number of bytes in memory for successful execution but the discovered vulnerability gives you space which is not enough for the required shell code to be executed successfully. Now this means that you cannot execute this shell code, which requires more bytes of space in memory than the available space you have after the crash.

Purpose of Egg Hunters

“Now, basically egg hunters are a group of instructions which directs the code to search for memory address by address for certain specific bytes of memory where you can put your shell code. These specific bytes of memory are called an egg”

They are also called staged shell code because an attacker injects a small piece of shell code and then this shell code searched the address space for larger shell code which it is destined to look for and you can say eggs or larger shell code or stage2 shell code.

“Now easiest way of explaining egg hunting is that it is a technique in which staged shell code is used which allows you to use a small amount of custom shell code to find your actual bigger shell code “egg” by searching for stage2 shell code in memory” [concept from corelan team explanation]

And this is an awesome explanation. It is like you went fishing using
a small fish to hunt a bigger one!


Further Explained – w00tw00t

Now, this is something which is considered as a key in understanding egg hunters; they are awesome. Basically it’s a technique for hunting the larger shell code you execute and stored somewhere in memory.

When you send bigger shell code and this shell code is somewhere in the buffer at a dynamic memory location, and this memory location is not known to you, therefore you can not direct the EIP for such memory location for execution the larger shell code. So your egg hunter code which is generated with a tag, its purpose is to look for the special tag and then execute the code after that. So we add the reserved tag before the larger shell code.

Stack arrangement would look like this.

JunkData → Egg Hunter Code → EIP → Padding → HunterTag → LargeShell code

What is the trick to execute shell code stored somewhere in memory?

Well obviously, the answer is egg hunter!

We will explain this shortly on what is “w00tw00t”. Let’s make it easier for you to understand egg hunters. Imagine you want to execute a shell code of total size 841 bytes but you have 200 bytes available in memory either ESP or somewhere else, which you can control (means you know the address location).

To overcome such situations in buffer overflow exploits we used two shell codes. Out of these two shellcodes one is very small in size which can easily fit into the known memory space you have to put your shell code and the other shell code, which is of larger size we placed somewhere (anywhere) in the memory with our exploit after successfully overflowing the buffer.

Now we have two things, firstly our small shell code is in memory and we know the address and our larger shell code is in memory too but we don’t know the address of the shell code residing in memory. Hence we can not execute the larger shell code but our small shell code can be easily executed as that is normally what happens in buffer overflow exploits which you have experienced in the previous module while exploiting Ability Server.

Now, the question is how to find the location of our larger shell code?


Well, the answer is available in the smaller shell code, yes! This is a code that will locate our larger shell code and execute it by looking for the tag placed on top of the larger shell code and search the space like ESP.

Tutorial 2 – Implementing Egg Hunters

How does it happen?

How the smaller shell code hunts for the larger shell code is basically an easy algorithm designed to look for a “tag” in the memory that is prefixed in the larger shell code and that tag is “w00twoot”. It can be any other tag, however, we use the default as generated by “!mona.py”

When we specifically talk about Windows Operating System, there are two known de-facto methods by which you can search this address space and locate the tag “w00tw00t” and they are called SEH (Structured Exception Handling) and System Call Validation.


Egg hunters logic types

To understand the core logic behind egg hunters you need to be good enough in reading the assembly statements and this is only possible if you have prior experience in programming and good understanding of assembly language.

What we will present here is the code in assembly with a bit of explanation statements to make it human readable, however, we will demonstrate how you can easily generate egg hunters and use it in your exploit code. I have just realized that in our previous module we fortunately had enough space to put the larger shell code, or smarter shell code, which is closer in size as compared to the available space in memory. We will look for such shell code and use it in our example.

Let’s practice


So to explain and practice the egg hunter logic we have to look for a vulnerability which gives less space initially, which is less than the size of our larger shell code as we will be using that as our main shell code while implementing egg hunter in our exploit code.

Here, with a couple of searches over the Internet, we found Bison FTP Server which can be used in implementing this concept. However, we will continue with Ability FTP Server and leave Bison FTP server for you to practice with and submit your results on the forum.

Okay, back to egg hunter logic types. To become an expert in egg hunter concepts, it is recommended to go through the de-facto paper on egg hunters written by “skape”, browse hick.org for more info on egg hunters.

However, most common is NtDisplayString egg hunter implementation, which is considered the smallest and efficient, too, and it is basically a System Call prototype. The use of this egg hunter type is obvious from the name “display text”.

Exercise 1 – Mona.py & Egg Hunters


So far we have understood the core concepts on egg hunters. Let’s have a quick exercise on how you can generate code that can be used as an egg hunter. We haven’t talked much in this syllabus on “Mona.py” so for newcomers this would be a new word and I can guarantee that if you started using this small tool you will definitely fall in love with this great tool which really helps a lot in exploit development and security advisories research. Okay, practice time.

We now have FTP Server installed and running in our virtual lab environment as shown below on IP address 192.168.81.140.

Let’s run Immunity Debugger and attach process with Immunity Debugger for keeping an eye on what will happen if we are able to crash this server. We have already presented how to fuzz FTP servers in the previous module, so you should do it on your own for practicing, however, here we will only show end results.

Logs as shown below show that we are able to connect to the server now while it is attached with Immunity Debugger.


Now, we have sent the evil buffer of known size and were able to crash the application as shown below. We will submit the PoC code on the forum as well as in this module shortly.



We also know the offset which is 968 bytes after which the EIP will be overwritten on which we will talk about later in next module, here our focus is on how you can have that small shell code to be used as an egg hunter. So now “Mona.py” will help us by means of a single command which we will run and get our egg hunter code ready to be plugged in our exploit code as shown in below snapshot.




As easy as you can notice command “!mona egg –t w00t” however the story behind the scene we will discuss in the next module. Let’s have a quick look at the file created by this command with the egg hunter code.

“mona.py” creates a file in the working directory with name “egghunter.txt” and in our case our egg hunter code is ready to be used in our exploit code. The egg hunter code is shown below.




See you in the next module! For further study in, and practicing on, egg hunters, keep learning

Popular posts from this blog

Haking On Demand_WireShark - Part 5

Detect/Analyze Scanning Traffic Using Wireshark “Wireshark”, the world’s most popular Network Protocol Analyzer is a multipurpose tool. It can be used as a Packet Sniffer, Network Analyser, Protocol Analyser & Forensic tool. Through this article my focus is on how to use Wireshark to detect/analyze any scanning & suspect traffic. Let’s start with Scanning first. As a thief studies surroundings before stealing something from a target, similarly attackers or hackers also perform foot printing and scanning before the actual attack. In this phase, they want to collect all possible information about the target so that they can plan their attack accordingly. If we talk about scanning here they want to collect details like: • Which IP addresses are in use? • Which port/services are active on those IPs? • Which platform (Operating System) is in use? • What are the vulnerabilities & other similar kinds of information. • Now moving to some popular scan methods and ho

Bypassing Web Application Firewall Part - 2

WAF Bypassing with SQL Injection HTTP Parameter Pollution & Encoding Techniques HTTP Parameter Pollution is an attack where we have the ability to override or add HTTP GET/POST parameters by injecting string delimiters. HPP can be distinguished in two categories, client-side and server-side, and the exploitation of HPP can result in the following outcomes:  •Override existing hardcoded HTTP parameters  •Modify the application behaviors   •Access and potentially exploit uncontrollable variables  • Bypass input validation checkpoints and WAF rules HTTP Parameter Pollution – HPP   WAFs, which is the topic of interest, many times perform query string parsing before applying the filters to this string. This may result in the execution of a payload that an HTTP request can carry. Some WAFs analyze only one parameter from the string of the request, most of the times the first or the last, which may result in a bypass of the WAF filters, and execution of the payload in the server.  Let’s e

Bypassing Web Application Firewall Part - 4

Securing WAF and Conclusion DOM Based XSS DOM based XSS is another type of XSS that is also used widely, and we didn’t discuss it in module 3. The DOM, or Document Object Model, is the structural format used to represent documents in a browser. The DOM enables dynamic scripts such as JavaScript to reference components of the document such as a form field or a session cookie, and it is also a security feature that limits scripts on different domains from obtaining cookies for other domains. Now, the XSS attacks based on this is when the payload that we inject is executed as a result of modifying the DOM environment in the victim’s browser, so that the code runs in an unexpected way. By this we mean that in contrast with the other two attacks, here the page that the victim sees does not change, but the injected code is executed differently because of the modifications that have been done in the DOM environment, that we said earlier. In the other XSS attacks, we saw the injected code was