Posted by Michalis Nicolaou
25 March 2020
Over the past year, we had a concept idea in mind, that got shelved due to the hesitation of the clients to have a device exposing their network to external 3rd parties, for an internal penetration testing engagement (which is fully understandable). However, due to the current circumstances (COVID-19 Lockdown), a lot of organizations are forced to adopt the work from home concept, which created the necessity for us to find a better way to perform our internal penetration tests efficiently and securely.


The basic idea was to add a device to the client’s premises, which would connect to our offices giving any member of our team the ability perform an Internal Pentest from the safety of our office or even the comfort of his/her home (provided that he has VPN access to our pentest lab). This way we could all work from home and still perform engagements that require our physical presence at the client’s premises. With the idea in mind we reached out to our head of Networks (menikos) and luckily for us, we had done “similar” implementations for some of our clients before, as a part of our IT managed services! He said: “Sure, no problem. It is just a simple EoIP over SSTP!”. Wait … what??


Technical Jargon

So, why SSTP and not any other VPN tunneling protocol? The answer is simple. Because it can pass through any firewall, compared to other VPN technologies, which might be filtered, may need to be enabled on a firewall to be able to traverse it correctly.


As Wikipedia states1, Secure Socket Tunneling Protocol (SSTP) is a form of virtual private network (VPN) tunnel that provides a mechanism to transport PPP traffic through an SSL/TLS channel. SSL/TLS provides transport-level security with key negotiation, encryption and traffic integrity checking. The use of SSL/TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers, except from authenticated web proxies. Information on how to configure SSTP on a RouterOS device can be found in Mikrotik’s wiki pages2.


Ethernet over IP (EoIP) Tunneling on the other hand, is a MikroTik RouterOS proprietary protocol (Cisco also has a similar protocol - Pseudowire) that creates an Ethernet tunnel between two routers on top of an IP connection. The EoIP tunnel may run over IPIP, GRE/PPTP, L2TP tunnels or any other connection capable of transporting IP. When the bridging function of the router is enabled, all Ethernet traffic (all Ethernet protocols) is bridged just as if the hosts were on the same physical switch (or VLAN across multiple switches). In our case, if as if we had a long Ethernet cable connecting the client’s LAN to our pentest LAN. More technical information on the EoIP protocol can be found on Mikrotik’s wiki pages3.


Not everything is perfect with SSTP though. The reason is the large overhead on the packet size, compared to other tunneling protocols. SSTP adds 120-bytes overhead, and if you add the rest of the packet headers (120-byte SSTP + 14-byte Ethernet + 20-byte IP), you have a whopping 154-byte overhead! This compared to GRE (42-byte) and L2TP (46-byte), looks huge, but with modern networks and bandwidths available, this doesn’t affect performance anymore.


For our setup, we used a MikroTik hAP ac2 router (RBD52G-5HacD2HnD-TC), whose purpose is to be deployed on the client’s premises and a virtual MikroTik instance (CHR4) on our VMware vCenter to be deployed in our isolated pentest lab. It should be noted that the same setup can be implemented exclusively on hardware devices. The reason for selecting this specific MikroTik appliance was:

  • first of all, it’s cool;
  • it has dual wireless (2.4GHz and 5GHz) radios;
  • it comes with 5 gig Ethernet ports;
  • it has a USB port that can be used for 3G/4G dongle;
  • it has IPSec hardware encryption (you never know when you will need it);
  • and it’s cheap for what it does.

When using a CHR on a VMware ESXi environment5, the vSwitch that is used for the CHR router and the customer-facing interface of the VMs, must be set to Promiscuous Mode. This is to accept and bridge the packets that are not destined for them. This is configurable under vSwitch properties, in the “Security” tab, where “Promiscuous Mode”, “MAC Address Changes” and “Forget Transmits” policy exceptions should be set to “Accept”.


We have also created three Virtual Machines, let’s call them FS01 (fileserver), NESSUS (our Nessus instance) and KALI (kali virtual machine). On these three virtual machines we will need two network interfaces. One will be used in the INTERNAL LAB network and the other one would be used each time we connect to the client’s network. When the “RoadWarrior” router is attached on client’s network, the VMs will get an IP address from client’s DHCP server, just like being physically attached to the clients; network! As explained earlier, with EoIP the networks are truly bridged (same broadcast domain), where all ARPs and broadcasts can reach both sides!


One of the cool things of this setup, is that it is plug and play! All the devices in our lab, will also get an IP from client’s DHCP server, when the the client-side Mikrotik “RoadWarrior” device is plugged to the client’s network!


We can even created additional EoIP over SSTP tunnels to the CHR MikroTik (pentest lab “RoadWarrior” device), one for each pentester. When a remote pentester connects his/her “RoadWarrior device on the network where he/she is located (e.g. at home), within 10 seconds the router boots and establishes the tunnel (you don’t have time for a quick smoke, sorry). When successfully connected, the EoIP tunnels (client “RoadWarrior”, pentest lab “RoadWarrior”, and remote pentester “RoadWarrior”), will be on the same broadcast domain as well. In simple words, they will be on the same network, just like if they were physically connected on client’s network! Now each of our team members can have one “RoadWarrior” and connect from everywhere (home-quarantine) and perform the internal penetration test with their laptop and our lab resources!

To summarize, RoadWarrior implementation provides full flexibility on how our team can be engaged in a penetration test! We can literally be on the same network as the client from multiple locations and at the same time have access to our own pentest lab resources. This setup can also reduce the use of product licensing since all our tools can be centralized in our own lab environment!


We hope that this blogpost will prove helpful for your penetration testing engagements and will give you another reason to stay home during this pandemic to help minimize the spread of the virus and keep use and our loved ones safe!