Fuzzing is a technique in software testing where you generate a number of random inputs, and see how a program handles it. So what does a testing technique have to do with a process such as the Cyber Kill Chain as developed by Lockheed Martin? Easy! Just as fuzzing a software produces resilient software, fuzzing a process will produce a validated process. The Kill Chain takes about seven steps that adversaries must complete in order to achieve their goals, but will it always be the case? Can an attacker pull off a successful attack with just one step? Or three? That’s what we’re going to fuzz out …

So, how can we fuzz a process like the Kill Chain? We’ll turn it into a simulation where there’s an imaginary attacker that tries to breach an imaginary company, and he or she is using a specific sequence of steps from the Kill Chain. Then we’ll run multiple simulations and change the attacker steps each time, fuzzing our process to see how we will handle the different breach scenarios.

To make this more tangible, I’ve developed a Kill Chain Fuzzer in Python. You can download it here:


Running it is as simple as:

python killchainfuzzer.py 7 -o always_step_7.csv

So how does it work? The fuzzer takes two command line options: one or more step numbers (1-7) that must be enabled in every simulation result and an optional output filename (‘-o’, ‘—output-filename’). The output of the fuzzer is a CSV file (CSV files can be opened in Microsoft Excel, Open Office, Google Docs etc) where each column represents a different step of the kill chain and each row is a result of a simulation. In the example above, the fuzzer output will be a CSV filename called always_step_7.csv with all the simulation results that step #7 (i.e. Action on Objective) is enabled in it.

Going over the different results is an excellent tabletop exercise. Here are some interesting cases that I managed to identify:

Insider Threat (Only Step 7):

Row #65 is a breach scenario that is only made of Action on objective.

This is the case where there’s an inside threat that is trying to breach us and not an external threat actor. It may look natural that the only way to get to Step 7 is by traversing Step #1 to #6 first, but not for inside threats. This is why a security framework that makes the assumption you will catch an attacker (via a security control) at step 4 is not viable in this case. You must always validate all your assumptions, and be prepared to break every step of the kill chain. you should always validate your security controls separately. Assuming you will catch the attacker at step 4 because of a specific technology may not be relevant to all breach scenarios.

Spear Phishing (Steps 1, 3, 7):

Row #25 is a breach scenario that is made of Reconnaissance, Delivery and Action on Objectives.

Imagine the following, your CFO receives a phishing email from a financial institution, saying they are doing a routine password change and asking him to click on the password-changing-link that leads him to a fake website. In the fake website your CFO gives away his username, old password, and newly chosen password. The fake website congratulates him on a job well done, and the attacker is on his way to access the account. As you can see we only needed to go steps 1, 3, and 7. No exploits or backdoors, just good old social engineering.

Brute Forcing Passwords (Steps 1, 4, 7):

Row #29 is a breach scenario that is made of Reconnaissance, Exploitation and Action on Objectives.

Accessing servers remotely is probably the most common task there is for IT/DevOps etc. There are many protocols and programs that allows thisit: SSH, Telnet, RFB (VNC), RDP etc. Having said that, all of them are vulnerable to brute forcing. By scanning for remote access services (e.g. 22/tcp, 23/tcp, 3389/tcp etc.) and then brute-forcing the password of a known account such as: ‘root’, ‘admin’, ‘administrator’ etc, it’s possible for an attacker to get access. So for this scenario it’s only steps 1, 4, and 7. No need for weaponization (step #3) as this is a “built-in” vulnerability.

SQL Injection (Steps 1, 2, 3, 4, 7):

Row #5 is a breach scenario that is made of Reconnaissance, Weaponization, Exploitation, Delivery and Action on Objectives.

SQL injection is a vulnerability that allows an attacker to embed SQL commands by manipulating the user input. While there are many ways for an attacker to find and exploit it, a very common scenario is as follows: Running a scanner against a website, trying different SQL injection attacks, and with a bit of luck successfully exploiting a normal (or a blind) SQL injection. For this, steps 1, 2, 3, 4 and 7 are required while steps 5 and 6 (Installation and Command and control respectively) are skipped.

So, just like we need to continuously validate our security controllers — we also need to continuously challenge our own underlying assumptions and thoughts.

Subscribe to blog post