Windows Security Lab (Part 2): Attack Infrastructure

12 min readSep 25, 2018

This guide is intended to help beginners set up their own Red Team/Windows Pentesting lab using Oracle VM VirtualBox and Virtual Private Servers (VPSs).

In Part 1, we configure a basic Windows domain in VirtualBox. In Part 2, we setup our attack infrastructure using DigitalOcean Virtual Private Servers. In Part 3, we will perform a basic attack against our Windows Client machine in order to test our lab.

Introduction

In Part 1, we used Virtual Machines to build a basic Windows domain. In Part 2, we will configure our attack servers using DigitalOcean Virtual Private Servers, known as “Droplets”.

Refer once again to the planned layout of our network:

The first machine we will configure is our HTTP Command & Control (C2) server. This will be our primary C2 server. Its purpose is to maintain a foothold on our targets, as well as to launch some basic PowerShell attacks. This will be accomplished using PowerShell Empire, a powerful post-exploitation framework based on Python and PowerShell.

Afterwards, we will setup our first Redirector server. Its role will be to obfuscate the IP address of our C2 server. This will be accomplished by setting up an Apache Web server that redirects PowerShell Empire-related traffic between the target and our C2 server. In order to dissuade curious individuals, all other traffic will be sent to a legitimate website.

Our third server will be our DNS Command & Control (C2) Server. Using dnscat2, we will configure this server to accept reverse shells from the target using the DNS protocol. I am using Debian 9.5 for the DNS C2 Server because I have had issues running dnscat2 on Ubuntu 16.04.4 and Ubuntu 18.04.

The final server will be another Redirector server. This will be configured to redirect all UDP Port 53 traffic to our Shell Server, allowing us to obfuscate dnscat2 connections. To accomplish this, we need to purchase a domain name, and then identify our Redirector server as the domain’s authoritative name server.

The Free Option (VirtualBox)

Don’t want to spend money on Virtual Private Servers? Don’t care about setting up Redirector servers? You can still practice fundamentals using only VirtualBox. That being said, you should read through the rest of the article and I recommend trying it out with VPSs at least once.

For those of you who don’t want to setup Virtual Private Servers, download the Kali Linux 64-bit VirtualBox Image from the Offensive Security website. Import the image into VirtualBox, install PowerShell and PowerShell Empire, and then open the VM’s network settings.

If you’re mostly interested in penetration testing, then switch your VM’s network adapter to the “Host-Only” option. This will place you in the same subnet as the Windows domain so you can avoid wasting your time trying to get a foothold on the network.

If you’re interested in testing out phishing and other Red Team techniques, then configure the VM’s network adapter to use “Bridged Adapter”. Now change your pfSense firewall’s “NAT” adapter so that it instead uses “Bridged Adapter” mode. Your Windows domain is still hidden behind the firewall, but should now be able to reach out to any device on your home’s default subnet. Using this setup, you can pretend like your home subnet is “the Internet” and your Kali machine is an internet-facing server.

Creating the Virtual Private Servers

NOTE: Feel free to complete these steps using your preferred VPS provider. The reason that I use DigitalOcean is because their built-in Firewall saves me from having to configure firewalls directly on my servers.

Login to your DigitalOcean account and create a new project titled “ATTACK”. Click on the Project and select Get Started with a Droplet. You will be presented with the “Create Droplets” page.

Figure 2–2: Creating Droplets in DigitalOcean

Use the following settings for our first three servers:

Distribution: Ubuntu 16.04.4 x64
Size: 1 GB, 1vCPU, 25 GB, 1 TB
Datacenter region: *use the nearest datacenter*
How many Droplets?: 4 Droplets
Hostnames: c2, redirector1, redirector2

And use these settings for the DNS C2 server:

Distribution: Debian 9.5 x64
Size: 1 GB, 1vCPU, 25 GB, 1 TB
Datacenter region: *use the nearest datacenter*
How many Droplets?: 1 Droplet
Hostnames: dns

While we’re waiting for our VPSs to initialize, let’s configure several firewalls using DigitalOcean’s Cloud Firewalls feature. Select Networking from the left toolbar and you should see the Firewall option in the main window. Click on it and then select Create a Firewall.

Use the following settings for the first firewall:

Name: c2
Inbound Rules: SSH, HTTP, HTTPS
Apply to Droplets: c2, redirector1

Create a second firewall with these settings:

Name: DNS
Inbound Rules: SSH, Custom: UDP 53
Apply to Droplets: dns, redirector2

By now, you should have received login details for your servers via email. If not, wait 10 minutes and then request a password reset on your droplets. Assuming you have the passwords, SSH into your newly-created VPSs and change the passwords for root.

Configuring SSH

We will create a user named “attackman” on all of our servers, enable SSH key-based authentication for that user, and then deny any SSH authentication using passwords or the root account. It should go without saying that you will need a machine on which you can generate keys; I’m just using a Kali VM.

Create a new user on each of your remote servers and then create a directory for that user.

root@c2:~# useradd attackman && passwd attackman
Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully
root@c2:~# mkdir -p /home/attackman/.ssh
root@c2:~# touch /home/attackman/.ssh/authorized_keys
root@c2:~# chown -R attackman:attackman /home/attackman/
root@c2:~# chown root:root /home/attackman
root@c2:~# chmod 700 /home/attackman/.ssh
root@c2:~# su attackman
attackman@c2:/$ chmod 600 /home/attackman/.ssh/authorized_keys

On your local machine, generate an SSH key and copy it to the target servers.

root@kali:/~# ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
...
...
...
root@kali:~# ssh-copy-id attackman@C2_IPADDRESS
root@kali:~# ssh-copy-id attackman@R1_IPADDRESS
root@kali:~# ssh-copy-id attackman@DNS_PADDRESS
root@kali:~# ssh-copy-id attackman@R2_IPADDRESS

After you’ve finished copying the keys, confirm that you can login without a password using the following command:

ssh -i /.ssh/id_rsa attackman@IPADDRESS

After confirming that we can login as “attackman” using the SSH key, we need to disable password logins and root logins on each of our servers. Open /etc/ssh/sshd_config with Vim.

vi /etc/ssh/sshd_config

Press ‘a’ to enter Editor mode and edit the following lines as indicated:

PermitRootLogin no
...
...
...
PasswordAuthentication no

Press ‘Esc’ and write your changes with ‘:w’. Press ‘:q’ to quit. Restart the sshd service.

systemctl restart sshd

Verify that your servers no longer allow SSH login with passwords or as root.

HTTP C2 Server: PowerShell Empire

Before setting up the C2 server, it’s important to provide some detail as to why we’re going to be using PowerShell Empire.

Empire is an effective C2 framework because of the way that the server communicates with clients (‘agents’). Communication is performed through scheduled GET and POST requests. The obvious benefit is that this method of communication is less conspicuous than keeping a TCP connection open for several days or weeks.

The real advantage of using Empire is that it allows us to customize our traffic via “Communication Profiles”. These Communication Profiles can be used to customize the request URIs, headers, user agent string, and how frequently the agent calls back. This means that we can attempt to emulate other types of traffic and hopefully decrease suspicion.

NOTE: If you’re interested in building your own communication profiles, I recommend reading this article to start.

HTTP C2 Server: Configuration

Prior to setting up Empire, we will install Python 2.7 and PowerShell onto our C2 server. Although PowerShell isn’t required, we need it to take advantage of Empire’s integrated Invoke-Obfuscation functionality.

Issue the following commands:

root@c2:~# apt-get update
root@c2:~# apt install python
root@c2:~# wget -q https://packages.microsoft.com/config/ubuntu/16.04/packages-microsoft-prod.deb
root@c2:~# dpkg -i packages-microsoft-prod.deb
root@c2:~# apt-get update
root@c2:~# apt-get install -y powershell

Test that Python 2.7 and PowerShell work by using the commands ‘python’ and ‘pwsh’, then use Git to clone Empire from GitHub onto our machine.

root@c2:~# git clone https://github.com/EmpireProject/Empire.git

You will notice a new directory called Empire. Navigate to Empire’s ‘setup’ sub-directory and run the install.sh script.

root@c2:~# cd /Empire/setup
root@c2:~/Empire/setup# ./install.sh

If all goes well, you should be prompted for a server negotiation password. Create your own password or press Enter to generate a random one. We are now ready to setup our Communication Profile.

For our C2 server, I will be using Rashid Feroze’s “microsoft” Communication Profile, which he uses in this article. We are using this profile because it creates semi-convincing traffic without requiring us to create our own website. I recommend reading the article if you want a more in-depth explanation of what we’re doing with our C2 and Redirector1 servers.

Take a look at the Communication Profile and you will notice that it attempts to emulate Microsoft Live email traffic:

listeners
uselistener http
set Name microsoft
set DefaultJitter 0.6
set DefaultDelay 11
set DefaultProfile /owa/mail/inbox.srf,/owa/mail/drafts.srf,/owa/mail/archive.srf|Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; yie11; rv:11.0) like Gecko|Accept:*/*
set Host http://[Redirector1-IP]:80

You might also notice that the “Host” field is asking for the IP address of our Redirector1 server. As you’ll see in the next section, the plan is to configure the Redirector1 server to act as a proxy for all Empire-related traffic between our C2 server and its clients.

Anyways, to make things easier, I’ve uploaded the Communication Profile to Github. Copy it to your Empire directory.

root@c2:~/Empire# curl https://raw.githubusercontent.com/GarbageSec/Infra/master/C2/microsoft.profile > microsoft.profile

Now open microsoft.profile and edit the file so that Host value uses the IP address of Redirector1. Launch Empire with the microsoft profile using the following command:

root@c2:~/Empire# ./empire -r microsoft.profile

After Empire has launched, verify the profile’s settings with the ‘info’ command. Notice that you still need to edit the Host field. You can either do this using Vim or modify the profile after you’ve already loaded it into Empire by using the ‘set Host’ command.

(Empire: listeners/http) > info
(Empire: listeners/http) > set Host xxx.xxx.xxx.xxx:80

For now, ‘execute’ the listener to make sure that it works and then ‘kill’ it.

(Empire: listeners/http) > execute
(Empire: listeners/http) > kill microsoft

HTTP C2 Server: Obfuscation

NOTE: There seem to be ongoing issues with Empire’s integration of Invoke-Obfuscation. Stagers are not being generated properly. This also appears to affect certain persistence modules. I DO NOT recommend enabling obfuscation if you’re just starting out.

The purpose of Invoke-Obfuscation is to obfuscate PowerShell scripts so as to help avoid detection. Accordingly, Empire has integrated Invoke-Obfuscation for the purpose of obfuscating the built-in PowerShell scripts, which are used in Empire’s “modules”.

The following steps demonstrate how to enable global obfuscation and obfuscate all of PowerShell Empire’s module_source files:

(Empire) > set obfuscate True
[*] Obfuscating all future powershell commands run on all agents.
(Empire) > preobfuscate
[>] Preobfuscate all PowerShell module_source files using obfuscation command: "Token\All\1"?
This may take a substantial amount of time. [y/N] y
[>] Force reobfuscation of previously obfuscated modules? [y/N] y
[*] Obfuscating Exploit-EternalBlue.ps1...
[*] Obfuscating Exploit-Jenkins.ps1...
[*] Obfuscating Exploit-JBoss.ps1...
[*] Obfuscating Invoke-VoiceTroll.ps1...
[*] Obfuscating Set-Wallpaper.ps1...

If Empire’s integration of Invoke-Obfuscation is working fine on your C2 server, then you should now make a habit of setting the “Obfuscate” variable on every module you use to “True”.

Redirector #1

As stated in the previous section, we are going to configure the Redirector1 server to redirect all Empire-related HTTP traffic to our C2 server. To add an extra layer of defense, we will also redirect all other HTTP traffic to https://login.microsoftonline.com.

The idea is that if Empire’s Communication Profile doesn’t dissuade curious individuals, then anybody browsing to Redirector1's IP address will be presented with the Microsoft login page and (hopefully) be convinced that our server is legitimate. A better solution would be to setup a realistic website and have our Communication Profile mimic traffic to that website, but this might be enough to fool somebody.

In order to accomplish our goals, we need to install Apache and enable the mod_rewrite module.

root@redirector1:~# apt-get update
root@redirector1:~# apt-get install apache2
root@redirector1:~# a2enmod rewrite proxy proxy_http

Open up /etc/apache2/apache2.conf and change the “AllowOverride” value in /var/www to “All”.

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

Now place the following .htaccess file (taken from this article) in the root of our web directory (var/www/html):

RewriteEngine On#URL condition – Empire’s url structure
RewriteCond %{REQUEST_URI} ^/(owa/mail/inbox.srf|owa/mail/drafts.srf|owa/mail/archive.srf)/?$#UserAgent condition – Empire agent’s custom user agent
RewriteCond %{HTTP_USER_AGENT} ^Mozilla/5\.0\ \(Windows\ NT\ 6\.1;\ WOW64;\ Trident/7\.0;\ yie11;\ rv:11\.0\)\ like\ Gecko?$#Redirect the original C2 traffic to this host
RewriteRule ^.*$ http://[C2 server]%{REQUEST_URI} [P]# Redirect all other traffic here
RewriteRule ^.*$ https://login.microsoftonline.com/? [L,R=302]

This configuration file determines what kind of traffic gets redirected and where it gets redirected to. As you can see, this .htaccess file was designed to pick up our “Microsoft Live” traffic and redirect it to the C2 server. All other traffic is sent to https://login.microsoftonline.com.

I’ve also included a copy of this file on Github. Copy it to /var/www/html.

root@redirector1:/var/www/html# curl https://raw.githubusercontent.com/GarbageSec/Infra/master/Redirector/htaccess.txt > .htaccess

Now edit .htaccess using Vim so that it uses the IP address of your C2 server. Write your changes and restart Apache.

root@redirector1:/# systemctl restart apache2

Test the configuration by navigating to Redirector1’s IP address in your browser; you should be redirected to https://login.microsoftonline.com.

DNS C2 Server: dnscat2

The DNS Server will be used to receive reverse shells from our targets using the DNS protocol. Using DNS as a tunnel is advantageous because almost every network allows some form of outbound DNS traffic. We will be using the dnscat2 tool in order to accomplish this.

dnscat2 is a command-and-control tool that creates an encrypted tunnel using the DNS protocol. It provides a similar function to netcat, allowing our dnscat2 server to interact with the command line of dnscat2 clients.

The dnscat2 server is intended to be used on an authoritative name server, but it doesn’t have to be. If a target has unrestricted outbound DNS traffic, we can issue a dnscat2 instruction on the target machine to look for a specified domain at an IP address of our choosing. This non-authoritative method creates unconvincing DNS traffic, but it’s sufficient to bypass poorly-configured firewalls and network administrators who aren’t closely inspecting packets.

For the purpose of the lab, we will be using dnscat2 as intended. The benefit to using this method is that it passes as real DNS traffic and works even if the target is restricted to using trusted DNS servers. In my case, I have registered the domain “redirector2dns.fun” and will set my Redirector2 server as the domain’s authoritative name server.

DNS C2 Server: Configuration

We begin setting up our DNS C2 Server by installing prerequisites for dnscat2, cloning the dnscat2 repository, and then installing it.

root@dns:/# apt-get update
root@dns:/# apt-get -y install ruby-dev git make g++
root@dns:/# gem install bundler
root@dns:/# git clone https://github.com/iagox86/dnscat2.git
root@dns:/# cd dnscat2/server
root@dns:~/dnscat2/server# bundle install

Now issue the following command to open a dnscat2 server on port 53 for the domain “redirector2dns.fun”:

attackman@shell:~/dnscat2/server$ ruby ./dnscat2.rb redirector2dns.fun --no-cache

Verify that it launches without any error message. If everything looks good, stop the dnscat2 server and SSH into the Redirector2 server.

Redirector #2

If you haven’t done so already, purchase a domain name from a registrar of your choosing; I used Namecheap.

Once the purchase has been processed, create custom DNS settings so that your domain uses the following name servers:

ns1.redirector2dns.fun
ns2.redirector2dns.fun

Assuming your registrar allows you to associate these name servers with IP addresses, use Redirector2’s IP address. How you go about completing this process will depend on your registrar.

Afterwards, we need to install socat onto our Redirector2 server. This is a simple tool that allows us to redirect all traffic on a local port to another local or remote port.

root@redirector2:~# apt-get update
root@redirector2:~# apt-get install socat

The following command tells Redirector 2 to forward all traffic on UDP port 53 to UDP port 53 of our DNS C2 server:

root@redirector2:~# socat UDP4-LISTEN:53,fork UDP4:<DNS-IP-ADDRESS>:53

The idea is that we will command our target to start a dnscat2 session with “redirector2dns.fun”. Redirector 2 is listed as the authoritative name server for the “redirector2dns.fun” domain, so the target will automatically reach out to Redirector 2 on UDP port 53 in an attempt to resolve the domain name. The target’s traffic will then be redirected to our DNS C2 server, which will open a session with the target and provide us access to the target’s command line.

And that’s it! We’re finished setting up our servers. Feel free to close the socat connection on Redirector2 until you’re ready for Part 3.

Improving the Infrastructure

Although our setup is far from perfect, it’s sufficient for our needs and hopefully taught you a few things. If you’re interested in improving your attack infrastructure, I suggest the following:

Enable SSL on Redirector1 so that the connection between the target and Redirector1 is encrypted.
HTTP Redirector servers should serve actual websites and/or have convincing domain names. Create custom Empire Communication profiles that mimic traffic to those websites.
Build a “long-haul” C2 server running Empire. Configure agents to call back once every six hours (or longer).
Spread out your infrastructure between VPS providers.
Install the Metasploit Framework on one of your C2 servers and learn how to pass off sessions to and from Empire.
Use Veil to generate your Metasploit payloads.
Try out the Cobalt Strike C2 framework.

Next Section

Although our current lab is far from perfect, it should be sufficient for now. In Part 3, we will test out our newly configured Virtual Private Servers by performing a basic attack against our Windows Client machine.