Building Vulnerable Machines: Part 3 — JOY is More Than One (Machine)

(If you have not read Part 2, please click here.)

Let us now extend what we did in Parts 1 and 2 to more than one machine. After all, one machine teaches one set of skills; multiple machines can cover a range of skills. This, in effect, is building a cyber range. Before we jump into a cyber range for training purposes, let us cover a cyber range that has already been made so famous that even Facebook is on it: a Capture the Flag (CTF) environment.

CTFs

In short, CTFs are cyber competitions where security enthusiasts participate to solve a wide variety of challenges. These include challenges on network security, application security, cryptography… and all the way into the arcane arts of reverse engineering.

We already know that, but I need to highlight that CTFs are time-based; participants tend to solve challenges according to what they perceive is most efficient from a game-play standpoint (most points per unit time). Not everything gets attempted as a result, for a CTF large enough such that nobody feels bored because he or she has completed every challenge available.

CTFs are indeed great ways of building cyber skills and gamifying the skills-building process. But even a CTF needs planning. These plans matter no matter whether there exists a time limit, so let us suspend that and discuss the thought process behind building a cyber range. (The reason for suspending the time limit is immediately clear; penetration testing is not just exploitation.) I shall scope the discussion to black-box penetration testing cyber ranges initially, before building it up to more generalisable cyber ranges.

The Penetration Testing Cyber-Range: Ingredients for Machines

Parts 1 and 2 focused on the construction of a single vulnerable “boot to root” machine. Let us recap the ingredients required.

• A view from the outside (external attacker)
• A series of steps to gain low-level privileges
• A view from the low-level privilege shell
• A series of steps to gain root/administration privileges

These steps can be iterative, which means not all vulnerable machines require following of such a model for construction, but let us use this for simplicity in design.

There are different types of exploits and misconfigurations one can train a penetration testing team to spot. These can range from low-hanging fruit such as vulnerable services leading to administrator privileges (e.g. EternalBlue, EternalRed), to more gruelling tasks, such as searching for a vulnerable third-party service amidst a mountain of executable files.

A cyber range will incorporate a variety of such ingredients. Let us think of a simple set of skills we want to train a novice team of penetration testers. We may want to brush them up in:

• Web-based attacks (SQL injections, file upload vulnerabilities)
• Network-based attacks (buffer overflow exploiting vulnerable service)
• Privilege escalation (misconfigurations: e.g. SUID bit on text editor and kernel exploits)

Misconfigurations are simple to set. A privilege escalation guide like this will easily show one how to build common misconfigurations into vulnerable machines. While these are often the easiest to mitigate (simply set things right), it almost never happens. And sometimes, all it takes is one misconfiguration to ruin the security posture of an enterprise.

Exploits can range from easy to set up to annoyingly difficult. The setting of kernel exploits such as this can be far more difficult than what appears to be simply installing an outdated kernel. The question is not so much putting the exploit path in there, as opposed to ensuring only the intended kernel exploits work, and nothing else, to bring home the lesson of an important patch regime.

One might have realised that Exploit-db is one of my favourite places to look at for inspiration to build up machines. It quickly simplifies the construction of machines, because of the wide variety of exploits targetting all sorts of different aspects in penetration testing, ranging from exploiting web applications to unquoted service paths in third-party applications. I never fail to be wondered at the sheer diversity of vulnerable services, ranging from Fitbit Connect to vulnerable WordPress plug-ins.

Important caveat: No luck if you want to build a custom laboratory with this approach. For such laboratories, it is often too painful to build unless you build cyber ranges and/or CTF environments for profit.

By following Parts 1 and 2, and redoing those steps, one will get a primitive cyber-range. But is this necessarily realistic? We want to try harder. (One could also just download a plethora of machines from Vulnhub and put together a laundry list of lessons to learn, but still end up in the same situation.)

Better Ingredients: Realistic Network Layouts

Not all attacks in the wild feature a nice “boot to root” scenario where you are simply asked to obtain user shells and root shells. We want to mimic what enterprises do. Besides, this gives us some chance at adding new lessons to learn. Some of these ideas include:

• Configuring a network layout, including VLANs to demarcate different parts of the enterprise. This can be easily done through a hypervisor such as VMWare ESXi. A “poor-man” variant of this is to configure different subnets on VMWare Workstation.
  (Free bonus: with network layouts, we can now introduce some of the most important penetration testing skills for end-to-end pentesters: lateral movement skills such as port forwarding, maintain command and control by poking security holes in appliances.)
• Client-side attacks. While it is theoretically possible to introduce client-side attacks on a single VM, it is not the most realistic way. We often do better by spinning up new virtual machines that resemble clients that perform certain actions. The scope for this is endless. A simple example would be to script a client to log into a web application vulnerable to an XSS attack, facilitating training of turning XSS proof-of-concepts to Javascript exploits. We do this to simulate “client traffic”.
• Other dependencies, such as compromising of a whole domain through Kerberoasting, or compromising connected Windows machines through “pass the hash” attacks.

No matter what kind of dependencies introduced, the idea is to create a realistic “enterprise environment” to submerge the pentester in, training the pentester not only in terms of offensive technique, but also to think creatively.

Beyond Black-Box Laboratories: Local Environments for Testing

It is sometimes the case that pentesters need to simulate a local environment resembling that of a target. Perhaps one objective is to chain a variety of web application exploits to obtain a shell, but we do not know if our chain of exploits work. This requires a local environment we can revert at will (our exploits may crash the application and not give us a shell, ruining the entire penetration test). Another common objective is to rewrite a buffer overflow that works on an executable installed on one particular operating system, on another. The process of finding the correct return address requires a local environment to test on as well. A good cyber range will cater for an “attacker machine set”, which typically includes an attacking machine (e.g. a Kali Linux VM), local test environments (e.g. Windows 7/10 with your favourite debugger for buffer overflow testing, or minimum installs to replicate the process of installing local copies of software and testing it yourself).

A Short Digression on Attacker Tactics, Techniques and Procedures (TTPs)

Laboratories like these do not benefit merely the red team. A skillful red team will naturally be able to improve the blue team not just through breaches, but also through tracing out the steps the red team takes, and analysing the indicators of compromise (IoC) left behind.

The importance of realism cannot be understated; a realistic laboratory environment for red teamers is itself a treasure trove of data for blue teamers. Depending on your requirements, you may begin by installation of detection agents without an active response component to answer simple questions such as:

• How would a red-teamer attempt to break into a system? What are some of the steps the red-teamer performs that will trigger defences, and what defences will get triggered?
• Are there attacks that will successfully evade any detection mechanism?
• When a red-teamer performs command and control, what artefacts will be left behind? Where will these artefacts be typically placed? For a novice attacker (or perhaps an OSCP student), he or she will probably leave behind plenty of artefacts. How would the situation change if the red-teamer uses an exploitation framework like Metasploit? A meterpreter shell instead of a simple bind/reverse shell?

A host-based intrusion detection system, for instance, is immensely useful to train a beginner blue-teamer in cybersecurity aspects such as incident response and forensics, since it will track for changes within the file system (e.g. an attacker dropping a Mimikatz binary should be detected). Such lessons can even extend to system administrators, who are often the first human line of defence in identifying IoCs.

One can even train network engineers to understand basic security and basic security misconceptions. Is all encryption good? Maybe not, when the attackers also use encrypted channels to exfiltrate data?

In short, cyber ranges are not merely red-team training grounds. Blue-teamers will also be able to make use of red-team practice to generate data for analysis and their own training. It is always good to kill two birds with one stone.

The JOY of Building a Range of Machines

While I have dabbled in both Windows and Linux machines, licensing forbids me from sharing any Windows machine to the open-source community for free downloads. However, in my journey of building vulnerable machines and spinning them into training machines, I have now a total of five machines on Vulnhub, to give a flavour of how we can write a series of machines, with different difficulties, spanning across several simple ideas in a Linux environment. (some misconfigurations, some exploits, some sheer dumbness)

In rough chronological order of building these machines:
MERCY:
https://www.vulnhub.com/entry/digitalworldlocal-mercy-v2,263/
BRAVERY:
https://www.vulnhub.com/entry/digitalworldlocal-bravery,281/
DEVELOPMENT:
https://www.vulnhub.com/entry/digitalworldlocal-development,280/
TORMENT:
https://www.vulnhub.com/entry/digitalworldlocal_torment,299/
JOY:
https://www.vulnhub.com/entry/digitalworldlocal-joy,298/

For walkthroughs, you can download them here. The password can be found either on this page, or you should try harder to crack it. NOTE: These walkthroughs are NOT exhaustive; they will only document one possible method of rooting the machines.

Will There be a Part 4?

There is only so much we can discuss when it comes to building up things, before one has to go through the trial of fire by actually trying to build himself or herself. The first time is usually the hardest, but after the first time, things usually get easier. There is only so much one can “read” and absorb without trying out things. In short, no Part 4.

Besides, I have also some other series I hope I want to expand on in the “Digital and Cybersecure” series. The next series will be a shift away from the penetration testing domain, and will be targetted at a broader audience.

Next series: The “Irrational” User? Or Simply a Normal One?