I’ve decided to do a quick write up of a series that the Ladies of London Hacking Society (LLHS) have set up (mainly just to help future me if I forget 😅).
This is part 1 of the #LLHS Cyber Kill Chain series.
If you enjoy reading this article, please feel free to share and give me some 👏🏻. Also, leave a comment below if you’d like to share any feedback!
DISCLAIMER: Please keep in mind I’m in no way a specialist or professional in hacking nevermind Cybersecurity — it’s simply something I’m very intrigued about and genuinely enjoy learning more about.
As a quick intro to those who aren’t familiar with LLHS — it’s a monthly meetup group organised by Eliza May Austin, Stephen Ridgway and their wonderful team. A special mention to Immersive Labs, for providing the educational labs for free in order for us LLHS members to learn and gain practical experience in ethical hacking. The content provided below was only possible thanks to Immersive Labs.
This series encompasses the sequence of events that happens during the Cyber Kill Chain (CKC), as shown in the screenshot above.
Reconnaissance
Imagine a thief trying to break into a house. What would be the most logical thing for them to do first?
Observe. Inspect. Investigate.
Similarly, the first stage of the CKC is known as ‘Reconnaissance’ — where a hacker uses resources available to them, to gain a better understanding of how to infiltrate their target victim’s network and systems.
Reconnaissance can take place in the form of being passive or active. Passive meaning that the hacker attempts to find out more about their victim without actually engaging with the victim’s systems. This could simply be in the form of a Google search or browsing through the victim’s website. On the other hand, active reconnaissance requires the hacker to obtain information in a way that may be known to the victim. This can include port scanning to find if the victim has any vulnerable ports that can be exploited. Although the victim is quite likely to be alerted when active reconnaissance takes place, there are many ways in which a hacker can conceal their actions. For instance, spoofing an IP address or using a VPN, Tor or proxychains.
The first lab that was covered in this series was focused on WordPress — a popular blogging platform on the Internet. As WordPress uses a lot of third-party themes and plugins, the goal of the lab was to identify any vulnerabilities as a result of using third-party code. We used a tool called WPScan (WordPress Port Scanner) to perform active reconnaissance against the target. Before starting off with port scanning, it’s crucial to have the URL / IP address of your target. For the purpose of the lab, we were given an example IP address that we could perform port scanning on. For all the following code snippets, place the target IP address or URL you’re working with, in lieu of [Target IPAddress/URL].
1. Version Verification
Using WPScan, the version of WordPress that is being used by the target can be detected by running the following code in the terminal:
From running this code, we get the below output:
As we can see, WPScan has detected that the target is using WordPress version 4.9.8.
2. Usernames & Accounts
The next step is to find out if there are any active accounts that are linked to the target. The code that we can run to find out this information is:
The ‘-e’ in the code represents enumerate, whilst ‘u’ represents usernames. By running the code above, we will be able to generate a list of usernames linked to the target:
In this example, we can see there are 4 usernames: admin, billibob, blessedrains, and johnjohnjohn.
3. Vulnerable Plugins & Themes
As mentioned before, as WordPress uses a lot of third-party themes and plugins, we can also identify any vulnerable plugins:
As we are using WPScan version 3.5.1, we will run the following code to change the method uses for detection:
This code will look for installed plugins used by the target that may be exposed, resulting in the output:
In the screenshot above, the specific plugin we’re looking at is Akismet. We can see that the output shows what approximate version of Akismet the target is using (2.5.0–3.1.4), as well as a vulnerability that has been detected — Unauthenticated Stored Cross-Site Scripting (XSS). The output also notifies that there is a fix in version 3.1.5 where this vulnerability is patched.
If you’d like to find out what themes are vulnerable, you can also run the code:
As you may have already guessed, the ‘t’ here represents themes.
The output in the terminal also references useful links if you’d like to read more about each individual vulnerability. In this case, it has provided the following links for the Akismet Unauthenticated Stored Cross-Site Scripting vulnerability:
These were the points that were covered throughout the first session of the #LLHS CKC series. To find out more about what happens during the CKC, feel free to follow me so that you’ll get notified when the next blog is published! Also if you’re based in London, identify as a female and am interested in Cybersecurity, feel free to come along to Ladies of London Hacking Society (LLHS) meetups!
