How hackers break into sites and exploit vulnerabilities

How hackers break into sites and exploit vulnerabilities

Hacking sites is one of the most common types of attacks. If you are interested in how sites are cracked and what you need to pay attention to in order to protect your resource, this article is for you. We will parse the very beginning of the web pentest and show you how to work with popular engines by examples.

As of January 2020, there are 1.74 billion sites on the Internet, and many of them are vulnerable. Ten years ago, a study by Web Application Security Consortium showed that at least 13% of sites can be hacked automatically. Truly, there is a huge space for cybercriminals to act!

General principles of hacking sites.

By structure, sites are divided into three large classes:

    • Self-written (made manually in HTML, produced by a static generator like Jekyll or assembled in a constructor program like Adobe Dreamweaver);
    • made in online constructors (mainly business cards sites without any databases and transmitted fields);

working on ready-made CMS (Content Management System).

There are also self-made CMS, created for a particular site, but it has now become a rarity – only the largest resources can afford the support of their system, and to justify the associated costs is not easy.

At the heart of most modern sites – ready-made engines. For example, is no exception: it runs on the popular WordPress system (at least now, in 2020).

From the attacker’s point of view, the site engines are no different from other services and services. Their source code is usually in the public domain, and any researcher can analyze it for errors, including security holes. Therefore, sites on the CMS are rarely the victims of a targeted attack. More often, they are broken in bulk.

Such hacking is automated and usually follows the following pattern: the cracker finds a vulnerability (by himself or just Googling something fresh). Then he exploits or takes a ready one and writes a specialized bot. This bot searches for the specified hole on all sites in a given range and tries to exploit it.

It would seem that all you have to do to protect yourself from automated attacks is to keep your software up to date, but in reality the CMS becomes different add-ons, and it becomes difficult to keep track of all of them.

Pentesta has a slightly different task – to check a specific site for vulnerabilities. That is what we will talk about.


Before trying to attack a target, you need to collect information about it. The tool WhatWeb is a good fit. This utility provides detailed information about the CMS of the victim and the web tools used.

I suggest running WhatWeb with the -a key, followed by a value of 3 or 4. The only difference between them is that in the second case WhatWeb will also scan the subdirectories. Keep in mind that both options define an aggressive survey method – with all the logs that follow, or rather “flow” to the server.


Since WordPress is now the most popular CMS, let’s go straight to it. It has a very powerful scanner that can do magic, WPScan. At the time of writing, the current version was 3.7.8. This scanner can detect the version of the object being scanned, brute force the administrator (it even has its own built-in dictionary), look at vulnerable open directories, detect installed plugins and much more. It is also pre-installed in Kali Linux and in other pentester distributions. There is even a version in the docker container.

Before using WPScan for the first time it is necessary to update its database.

wpscan --update 

After that, we start scanning. WPScan itself, without keys, will give you the general information about the site only by superficially scanning the target.

wpscan --url

At the end of the line Interesting Finding(s): the very moments you should pay attention to begin:

    • WP version;
    • open directories;


  • Suspicions of vulnerabilities;
  • Links to resources where you can read about these vulnerabilities.

At the end of the output a red exclamation mark marks the lines that contradict the security rules. In our case, this is the wp-config.php configuration file that is protruding outward with the login and password to the database.

We keep digging and try to reset the login and password to the admin with the same software:

wpscan --url http://[IP-address] --passwords pass.txt --usernames user.txt

Brutforts very quickly thanks to multithreading. If the admin used standard accounts and set simple passwords, the result will not be long awaited.

We got the accounting data to the admin and the database without much trouble. For an average cracker, it would have been more than enough, but we have not yet checked everything. Next in line are plug-ins for WP and other popular entry points.

The scanner showed us that there are no plug-ins installed on the selected site, but this may be a false conclusion based on the limitations of the passive scanning method. For more reliable detection of plug-ins, you need to set an aggressive method of searching for them:

wpscan --url http://[IP-address] --enumerate ap --plugins-detection aggressive

The ap key will show all found plugins, while vp will show only vulnerable plugins. This procedure takes a decent amount of time. Speed will depend on the remoteness of the site, but even at best it will take at least 30 minutes.

It is necessary to look for other vulnerable WP add-ons with exactly the same actions. For more details, see --enumerate in the manual.


Joomla is also a rather popular CMS for which there is a scanner JoomScan. It was written by the Open Web Application Security Project (OWASP) guys. It is still up-to-date, although it has not been updated for a long time. The latest version 0.0.7 was released in September 2018.

It is essentially the same security scanner as WPScan, but a bit simpler. JoomScan is also pre-installed in most distributions for security professionals, and all his manual fits in a few lines.

It also supports an aggressive scanning method for installed components. The command to start scanning in aggressive mode looks like this:

joomscan --url --enumerate-components

Here is an example of analysis found on the Internet old and very leaky version of the site on Joomla.

As can be seen in the screenshot, the program gives a version of CMS, CVE found vulnerabilities and links to exploits that can be used to hack into the site. Also in the output are all found on the site directories and a link to the configuration file, if it was forgotten to hide.

Brutforsit administrator JoomScan can not. Today, to perform such a brute force, you need a serious tool that works with a chain of proxy servers. At least because on sites with Joomla often used a plugin brute force stop. When the number of failed authorization attempts reaches a specified number, it blocks the IP address of the attacker.

Drupal and other CMS.

With Drupal, everything is a bit more complicated, as with other unpopular CMS. There is simply no annual scanner that would find vulnerabilities on such sites. From the ready-made tools I could only find DroopeScan, but it only helps to quickly gather basic information about the victim.

The DroopeScan is installed via pip (of course, you must have Python installed).

pip install droopescan

Start scanning. Since it supports not only Drupal, it is desirable to specify explicitly which CMS we expect to meet on the site:

droopescan scan drupal -u http://url. 

The rest has to be found by hand and Google on the Internet. Sites with searchable vulnerability databases, e.g. CVEdetails, and ready-made exploits with PoC (you can find them on GitHub and on the Internet) are very helpful in this.

Hit self-written sites.

With the testing of self-written sites, everything is much more complicated. There is no specific scanner that would say: here is an old version of the web application, there is a known hole in it, here is a link to the exploit and a detailed description of its application. There is only a very extensive list of potential vulnerabilities that need to be checked. They conduct such pentests using OWASP methods or their own algorithms.

Penetration testing is a very creative process. It doesn’t have a strict framework and a list of mandatory tools, especially if they are onsensory. However, a security audit is a serious service, and some organizations try to structure its execution so that in flight of fancy the pentester does not miss anything.

If you need to check the possibility of hacking a self-written site, it is better to start with the same WhatWeb. Only now we are not watching the CMS, but all the discovered services and their versions.

There are many vulnerable versions of the frameworks themselves. For example, often obsolete versions of Ruby on Rails or Apache Tomcat are used. There are open source versions of Ruby on Rails or Apache Tomcat.

You should also pay attention to the versions of the programming languages themselves. For example, in PHP constantly find vulnerabilities, and from the moment of their detection to the update on the site may take more than one week.

The next step is to use security scanners. Even if they do not give a ready verdict, they will throw food for thought. For example, the program dirb will help to run through the open directories and return the response codes.

To test for typical vulnerabilities, use universal scanners: nikto, skipfish, w3af, skipfish.

For everything else there is Burp Suite. Usually it is used to perform more complex web application vulnerability search. As an example let’s consider SQL injection search and operation.

We install the Burp Suite (it is already pre-installed in Kali Linux), find the Repeater and run it. In a GET or POST query we look for a value to be sent to the server (like id=12) and throw it into Repeater.

Add a single quote to verify that no special characters are filtered in the value to be transmitted, and we see a message with a syntax error sql. The error indicates that the site is vulnerable to SQL injections. To automate the attack development we use sqlmap.

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

The -u key points to the target URL, and the --dbs key tells you to check the entire DBMS.

This SQL injection harvester will determine which peiload is right for you, and upon your commands, pull all the data you need from the database on the site. It will even offer to immediately determine passwords by hash if it finds them. This software is especially useful when using so-called blind SQL injections.

Protection tips.

If you are the owner of the site on the CMS, the best security strategy will be to abandon questionable additions, minimize the number of plugins and regularly update all the software. Web designers and programmers want to remind elementary rules of writing safe code – at least filter the special characters in database queries and check the scripts borrowed from the Internet.

If your site was written to order, you need to check all the used web components, remove the optional ones and timely update the remaining versions to current ones. So take care of the site support in advance.

Universal option – periodically order a search for vulnerabilities from a third-party specialist.

WARNING! All links in the articles may lead to malicious sites or contain viruses. Follow them at your own risk. Those who purposely visit the article know what they are doing. Do not click on everything thoughtlessly.


0 0 vote
Article Rating
Notify of
Inline Feedbacks
View all comments

Do NOT follow this link or you will be banned from the site!
Would love your thoughts, please comment.x

Spelling error report

The following text will be sent to our editors: