single series all timeline
         _         _            _        _   _        _            _
        /\ \      /\ \         /\ \     /\_\/\_\ _   /\ \         /\ \
       /  \ \    /  \ \        \ \ \   / / / / //\_\/  \ \       /  \ \
      / /\ \ \  / /\ \ \       /\ \_\ /\ \/ \ \/ / / /\ \ \     / /\ \ \
     / / /\ \_\/ / /\ \_\     / /\/_//  \____\__/ / / /\ \_\   / / /\ \_\
    / / /_/ / / / /_/ / /    / / /  / /\/________/ /_/_ \/_/  / / /_/ / /
   / / /__\/ / / /__\/ /    / / /  / / /\/_// / / /____/\    / / /__\/ /
  / / /_____/ / /_____/    / / /  / / /    / / / /\____\/   / / /_____/
 / / /     / / /\ \ \  ___/ / /__/ / /    / / / / /______  / / /\ \ \
/ / /     / / /  \ \ \/\__\/_/___\/_/    / / / / /_______\/ / /  \ \ \
\/_/      \/_/    \_\/\/_________/       \/_/\/__________/\/_/    \_\/


1) Run the OVA in a VM and connect to the webserver 2) Have Fun!

Made by


Thanks to

morbidick einball sarah

I would probably have never finished', this project without you guys ;)',


For hinting me to Erik Österberg's Terminal.js


For providing fuel in the form of fudge and premium grilled goods

More information:


A friend wanted to get into some simple exploits. I suggested starting out with web security, she was all for it. But when I started browsing vulnhub and the likes I couldn't find anything like I had in mind. So I wrote my own.


This is a story based challenge written in a style heavily inspired by Neil Stephensons Snow Crash and William Gibsons Sprawl Trilogy. Each chapter is unlocked by solving the puzzle. From hardcoded clear text javascript password checks, SQL-injections and cracking hashes to a simulated terminal. You only need to start the VM, a webserver will come up and you can connect with your browser. In fact you never have to leave the browser.


Teach some basic well known techniques and attacks. Spark some curiosity, make the user look at the source code and try to figure out what's going on behind the scenes. The main goal is to give a nice welcoming intro to the scene and hopefully also teach something about ethics and responsibility.

Change log

v1.0.1 - 2016-01-15: v1.0.0 - 2015-10-27:



A tool for teaching and learning about systems, networks and security

Authors: Carlos Perez & David Perez Date: 2016-11-03


NETinVM is a VMware virtual machine image that provides the user with a complete computer network. For this reason, NETinVM can be used for learning about operating systems, computer networks and system and network security.

In addition, since NETinVM is a VMware image, it can be used for demonstrations (i.e. in classrooms) that can be reproduced by students either in a laboratory or on their own laptop and thus, at home, at the library... For these reasons we present NETinVM as an educational tool.

Description of NETinVM

NETinVM is a VMware virtual machine image that contains, ready to run, a series of User-mode Linux (UML) virtual machines. When started, the UML virtual machines create a whole computer network; hence the name NETinVM, an acronym for NETwork in Virtual Machine. This virtual network has been called '' and has fully qualified domain names defined for the systems: '', '', etc.

All of the virtual machines use the Linux operating system. The VMware virtual machine is called 'base' and it runs openSUSE 13.2. User-mode Linux machines use Debian 6.0 and they have different names depending on their network location, because they are grouped into three different subnets: corporate, perimeter and external. The subnetworks are named 'int' (for internal network), 'dmz' (for DMZ or demilitarized zone, usually used as a synonym for perimeter network) and 'ext' (for external network).

One of the UML machines, 'fw', interconnects the three networks ('int, 'dmz' and 'ext'), allowing for communication and packet filtering. The rest of the UML machines have only one network interface, connected to the network they are named after:

int<X> + UMLs connected to the internal network. can take values from 'a' to 'f', both inclusive. These machines only offer SSH service by default.

dmz<X> + UMLs connected to the perimeter network (DMZ). They are supposed to be bastion nodes. Two preconfigured bastion nodes are provided, each one with its appropriate alias: + 'dmza' is aliased as '' and it offers HTTP and HTTPS services. + 'dmzb' is aliased as '' and it offers FTP.

ext<X> + UMLs connected to the external network (ie: Internet). Because a picture paints a thousand words, or so they say, the following figure shows NETinVM with all of the virtual machines running inside.

General view of NETinVM in VMware. The document example-net.pdf offers a detailed view.

All of the elements referenced before are shown in the image with their IP and ethernet addresses. The following rules have been used for assigning addresses:

  • IP addresses are of the form 10.5.., where is either 0 ('ext'), 1 ('dmz') or 2 ('int'), and is either 10 for 'exta', 'dmza' or 'inta', 11 for 'b' and so on up to 15 for 'f'.
  • Network masks are 24 bits (
  • Ethernet addresses are CA:FE:00:00:0:0, where is either 0, 1 or 2 (following the same domain rule as IP addressing) and is either a, b, c, d, e or f.
  • The interfaces of 'fw' use 254 for IP and FE for ethernet.
  • The interfaces of 'base' use 1 for IP and 01 for ethernet.

In addition to the computers and networks already described, the figure also shows the real computer where NETinVM runs ('REAL COMPUTER') and VMware Player's typical network interface ('vmnet8'), which optionally interconnects NETinVM's networks with the external word.

When they boot, all UML virtual machines get their network configuration from 'base', which provides DHCP and DNS services to the three NETinVM networks through its interfaces 'tap0', 'tap1' and 'tap2'.

Routing works as follows:

  • The default gateway for the internal and perimeter networks (machines 'int' and 'dmz') is 'fw' (more specifically, the IP address of 'fw' in the corresponding internal or perimeter subnet).
  • The default gateway for 'fw' is 'base' (its external network address). 'base' (its external network address) is also the default gateway for machines in the external network ('ext'), but they are configured to use 'fw' (external network address) as the gateway for accessing machines in the perimeter and internal networks.
  • 'fw' applies NAT (SNAT, Masquerading) to all network traffic coming into it from the internal and perimeter networks and going out through its interface in the external network. So, these packets get to the external network with a source IP address of (fw's IP address in the external network)
  • Thus, IP traffic exchanged among the three networks goes through 'fw', while traffic going out from NETinVM to the external world goes through 'fw' if (and only if) it comes from the internal or perimeter networks. All traffic going to the real world (outside NETinVM) exits through 'base' which, as 'fw' does, applies IP forwarding and NAT to this outgoing traffic.

Communication between 'base' and any UML machine, in both directions, is direct, without going through 'fw'. (When the communication is started from a UML machine, the IP address of the interface of 'base' in the corresponding network must be used.) This configuration permits access from 'base' to all UML machines using SSH independently of the packet filtering configuration at 'fw'.

As an additional consideration, please note that the SNAT configuration in 'fw' described above is necessary for responses to outgoing connections to the Internet originating from the internal or perimeter networks to come back through 'fw'. Otherwise they would be routed directly from 'base' to the UML machine through 'tap1' or 'tap2' without traversing 'fw'.


Our resident ROP ninja barrebas recently gave the team a bootcamp on Return Oriented Programming. The presentation was followed by a demo walkthrough on writing a ROP exploit on a vulnerable application. Since the presentation was well received, he’s decided to make the slides available to everyone. You can view them at

We hope you enjoy it!

Username: root
Password: toor

Username: level0
Password: warmup

ROP Primer

This VM is meant as a small introduction to 32-bit return-oriented-programming on Linux. It contains three vulnerable binaries, that must be exploited using ROP.

The machine is built and tested in VirtualBox 4.3.20. It's an Ubuntu 32 bit VM, with ASLR disabled. Useful tools like gdb-peda are installed. A description of the levels, including instructions, can be found on the webserver.

A big shout-out to my team mates of the Vulnhub CTF Team!

@barrebas, March 2015 & June 2015

MD5:  840c75497f54578497a6e44df2f96047
SHA1: 2cb14d78fd1ff7b5a7895447969fde8ca9c06ef3