Manually Web Application Penetration Testing: Fuzzing - Part 4

Introduction

When we test a web application, we do not test a single page, but a lot of pages of a single web application. Each page may have more than one variable, so technically you will be engaging with a ton of variables during your web application test. So when you inject anything into the input, it is good to know what kind of effect your injection has on the server. In this part of this series of articles, we will look at the importance of simple alphabetic injection along with the web page encoding technology and how it affects our testing and result.

Simple Alphabetic Injection

When you engage with many web pages and a ton of variables, it is good to find your input after you inject. When you give something to the web page as an input, your input will not be used in only one place, but it will be used for many variables and tons of places. One of the common ways to check which areas use a given input is to give a simple alphabetic injection. This simple alphabetic injection can be anything. As I said in an earlier article, I personally use Jonnybravo as a username and momma as a password. If I use any special characters within my input, it might get encoded/eliminated to prevent the injection attacks on that page. What encoding is and how it takes place I will cover later on. The reason for using simple alphabetic injection is because it will never be encoded or eliminated by the server and you can easily find your input within the response as well as the request.

CLICK HERE TO READ FULL ARTICLE

Manual Web Application Penetration Testing: Identifying Application Entry Points

Introduction

In this article, I will show you how to find injection points for your target host and how the webpage is encoded when it comes to the client side from the server.

Identifying Injection Points

If your web page is static, you cannot test it for security concern. You can test it at some sort of view but you can’t play with it much as compared to a dynamic page. The Nikto scanner is a good utility that works best in testing static sites. There has to be some interaction between client and server via login panel, comment section, register page, contact form, and so on.

To Read Full Article Click Here : http://resources.infosecinstitute.com/manual-web-application-penetration-testing-identifying-application-entry-points/

Manual Web Application Penetration Testing: Introduction

In this series of articles, I am going to demonstrate how you can manually exploit the vulnerability of a web application, compared to using any automation tool, in order to find vulnerabilities in the application. Almost all companies worldwide focus on manual testing of web application rather than running web application scanners, which limit your knowledge and skills and the scope of finding a vulnerability with your testing.
For the whole series I am going to use these programs:

1. NOWASP Mutiliadae
2. BURP Proxy
   Read full article at :  http://resources.infosecinstitute.com/manual-web-application-penetration-testing-introduction/

Deliver powershell payload using macro.

In past we saw method of direct shell code execution in Ms word or Excel using macro;but if document is closed then we will lose our shell so we have to migrate to other process and sometimes migration is pick up by AV. So in this tutorial we are going to use powershell payload.

Advantages of this method:-

(1)Persistence
(2)Migration is not needed
(3)AV bypass

(1)First we will generate powershell payload; for this purpose i used SET.You can also used Veil or powersploit.Open SET in terminal & select Social-Engineering Attacks and then Powershell Attack Vectors.Generate Powershell Alphanumeric Shellcode Injector.Fill LHOST & LPORT value.

Our generated powershell payload is located into /root/.set/reports/powershell/. Rename x86_powershell_injection.txt to x32.ps1.

(2)Now Clone git repository of code

root@bt:~# git clone https://github.com/enigma0x3/Old-Powershell-payload-Excel-Delivery

root@bt:~# cd Powershell-payload-Excel-Delivery/

(3)In Powershell-payload-Excel-Delivery folder; rename RemovePayload.bat to remove.bat. Now you have to host remove.bat and x32.ps1 to web-server.Then open persist.vbs file and change URL of x32.ps1 in line 13,33 to your hosted x32.ps1 `s URL. And now also host persist.vbs to web-server. I used localhost.

(4)Open Macrocode file from cloned folder & change URL in line 27,82,118 respectively to your hosted x32.ps1,persist.vbs and remove.bat `s URL.Now add this macro code into excel document as mentioned in previous tutorial.

(5)And last step is setup listener.

Now send this document to victim , as soon as he open document and run macro we will get shell. Once the payload is ran, it runs in the powershell process, so if the user closes excel, you keep your shell. You also remain in a stable process until reboot, so migration is not needed.

It then pulls down a persistence script, drops it, creates a registry key for autorun for the persistence script. Once done, it also drops a self-deleting bat file that removes the initial payload from the system.

Thanks to  enigma0x3 for this awesome method.

Update :- New-Powershell-Payload-Excel-Delivery

This is a VBA macro that uses Matt Graeber's Invoke-Shellcode to execute a powershell payload in memory as well as schedule a task for persistence(20 min onidle  you get shell).

root@bt:~# git clone https://github.com/enigma0x3/Powershell-Payload-Excel-Delivery.git
root@bt:~# cd Powershell-Payload-Excel-Delivery/

Open MacroCode file & change Download URL for Invoke-Shellcode file & change LHOST & LPORT option. Now add macro-code in Excel file & start-up listener.