Skip to main content

Advanced Exploitation Techniques - Part 3



Walkthrough of Egg hunting with known vulnerability




Tutorial 1 – Boiling the Egg


Welcome to the third module of this advanced exploitation technique course. So far we have gone through discussing buffer overflows in depth, how egg hunters work and the core concepts on both of these topics. In this module we will be mainly focused on presenting how you can use egg hunters practically in an exploit code when you run short of memory space for your larger shell code.



Where to practice?


In the previous module we have shown how the “Mona.py” command is used to generate egg hunter code. However, we haven’t gone far from the initial stage which generates the need for egg hunters.

While spending more time on Ability FTP Server and Bison FTP Server, I realized that we will be able to get egg hunter working for both applications so I decided to go with Ability Server itself as we used that earlier in our workshop as well for explaining buffer overflows and it’s worthwhile to keep the same pace.

Let’s see how it goes with this application we are now using in this course. So far we have been playing with Ability FTP Server for buffer overflows. Let’s run how to code egg hunters while exploiting Ability FTP Server.

 What is the prerequisite?

If you have not completed the previous two modules and you are new to exploit development, it is strongly recommended that you should first complete the first two modules and practice exploit development for any of the two FTP servers we have been playing with and then jump here to have hands-on experience with egg hunters.



What is covered?


This module is focused on lab exercise so we are more inclined towards testing and exploiting here, as we believe that the core concepts have been presented in the previous two modules.

Tools Required

We will be using the following main tools to complete the lab exercise of this module for presenting the walkthrough on egg hunters. If you are not familiar with any of these tools so far then you are in the wrong room!

     ● Immunity Debugger
     ● Msfpayload Generation
     ● Ability FTP Server
     ● Mona.py

Exercise 1 – Mixing Egg Hunter

You can download the vulnerable application from the below link, however, don’t use the available exploit. Remember that you have to develop the exploit on your own if you really want to practice; this vulnerability is in APPE command.

Download link: http://www.exploit-db.com/exploits/693/ 

Fuzzing the Ability FTP Server

You should use the fuzzing technique we have discussed in detail in module one while exploiting the Ability FTP Server and utilize your skills to find the offset and return address on your own. However, we are squeezing the work as we have already tested this in our lab environment for the above two things.

Okay, let’s give the PoC Code for this vulnerability with the egg hunter added so that we can explain as well.





Don’t get worried with the new things shown in the PoC code we will explain this to you indeed.

PoC Explanation

As we have been explaining that egg hunting is basically staged shell code, you can notice we have two stages in the PoC code. Information we have prior to mix the egg hunter:

    ● Offset value which is 968 bytes
    ● Controlling EIP
    ● ESP pointer

What we need to mix the egg hunter code:

                  ● Typical egg hunter code (generated by mona.py)
                  ● Where to put egg hunter code
                  ● Add egg hunter code at top of larger shellcode
                  ● Most importantly arrange the stack to that our egg hunter search
                      the larger shellcode as explained above

We know the size of our egg hunter code is 32 bytes and the location to put this egg hunter code is before EIP register get overwritten so we will subtract 32 bytes from the offset value and add the egg hunter code before EIP gets overwritten as shown below.






That’s the code of my egg hunter which will look for tag w00tw00t and then execute the code after this tag.

Now stage one of my shell code given below

“myStage1 = junk1 + egg_hunter”

where junk1 is now 936 bytes + egg hunter code which makes the offset value again to 968 bytes after which EIP will be overwritten. So now we will add return address which you can generate by the following commands as shown below. At this stage one, our egg hunter code would be embedded in the memory to start the work.


Select any one value from the discovered values for jumping to ESP. Okay, now it’s time to worry about stage2 shell code. Again, you can use any size of shell code now as we are using egg hunter to execute this code, which is independent of memory. Now let’s look at stage2

“myStage2 = "w00tw00t" + nops + buf”

Here you can see the tag “w00tw00t” is added on top of the buffer then padding the stage2 with nops and then the actual shell code is added. This is the stage2 shell code, which will be sent sequential for exploitation. So time to use this code and get the results. We have exploited the Ability Server again with our advanced exploit PoC code and below is the result again as shown.



Now, was the egg hunter really executed? Well, it is indeed, or else the shell code at stage2 wouldn’t be launched.

That’s the demo for coding and mixing egg hunter in your exploit, see you in the next module.

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