Cloud is certainly one of the most over used buzzwords on the Business side of the tech industry right now; However, it does exist and admins can use it for their environments. One of more mainstream solutions for businesses to effectively provide network administration in a cloud environment is Microsoft's Azure. At first glance, Azure's interface can certainly be overwhelming. Once we start to dig in and learn the flow of creating machines (VM's, firewalls, etc), it proves to be a fairly robust option. To be honest, that sweet, free $200 they give towards hosting is why I chose this platform as opposed to AWS or Google Cloud. Azure offers great features for Microsoft machines that includes the ability to upload your own VM and a segmented approach to providing all individual resources a network may need.
In this article, I'll just be going over how to set up a network on Azure, not the AD domain itself. The AD domain lies within the Windows server that will be on the network. "Brian, why ever would you just up and make something like this? It sounds gross and boring." Well I had an intern, who is awesome btw. This intern needed some form of deliverable to be shown to my bosses and I felt that for what I do this would allow him to experience a little taste of what he could've seen if he wasn't remote. This seemed like the perfect time to have the mutually beneficial situation of learning new platform while being able to refine my understanding of the fundamentals of offensive security by teaching. His deliverable consisted of moving through the cyber kill chain in a simulated active directory domain, minimizing the amount of noise he made on the "OP", and providing a small write up on how he did it. In this particular scenario, I needed a way of providing him the access to the network in a remote manner as I couldn't let him connect to anything at work, nor did I feel comfortable segmenting a piece of my home network and infrastructure for this. Cloud seemed to make the most sense here.
The previous image is projected layout of my network I started with. In a logical method, I mapped out where everything should be. For the non tech folks out there, this image is similar to a blueprint for a building. Forewarning, I failed to set up that ELK Server at the time of this article. I'm still trying to figure out how to get the full ELK stack up and running without costing a BAJILLION dollars for hosting a full cluster of VMs. We all fail at times, so sorry, not sorry.
From the diagram, we can see that I needed to create three hosts and one server. The server will join two machines to a domain, while the Foothold box stays outside of the domain. I wanted to keep it outside of the domain as the intern needed to figure out how to get on to a user account from the outside, lightly simulating a situation that very well could happen. The hosts were originally meant to be on different subnets; however, I got lazy and left User 1 and User 2 on the same subnet. The network server and Foothold box did, in fact, stay on other subnets.
The first step after signing up for an account with Azure and reaping that glorious $200 is to create a virtual network. As Microsoft puts it in their documentation, "Azure Virtual Network (VNet) is the fundamental building block for your private network in Azure." This should one of the first things Azure asks you to do. If not, hit all resources on the side panel and search for virtual network.
After naming your network, give the size of the address space you'd like your Class A address space to have. I just kept it at 10.0.1.0/16 since maybe I want to have a party with 65534 of my closest hosts, maybe not. Who knows, I could be feeling saucy today. Seriously though, this should allow for a good amount of space should I choose to spread my hosts out in the network. I also added as many subnets as needed (more can be added after creation).
I left these settings as disabled or basic since my goal is to have the intern mess with the network. He wasn't ready for an extremely difficult configuration, so it was best to allow him to learn without having a brick wall on his way to learning. Also, a bastion host allows for secure RDP and SSH connections without exposing the ports on the public facing IP address by only using the Azure portal for access. Seems like a nice feature, but this network will be beat up therefor no need.
This is my final configuration of the virtual network. From here, I just hit create and let Azure do it's thing.
The next step is to create a resource group. A resource group is a container that holds related resources (NSGs, VMs, Firewalls, etc.)
Now things will start to get tricky. I then added a Network Security Group. The purpose of the security group is to filter traffic within the virtual network use security rules. As any one who has worked with rules in networks knows, rules can make things hairy pretty quickly.
Give the security group a name and allocate it to a resource group. Once finished, I reviewed and created the NSG.
Now it's time to choose what traffic we want to allow. From the above, we can see that by default allows all inbound traffic from the virtual network as well as any traffic from the load balancer. Now most good firewalls will use an implicit deny at the end of the rule list. This is because when the NSG checks the traffic against the rule list from the top-down and nothing relates to the traffic, the firewall or, in this case, NSG can deny any traffic outside of the specified. Unless you are allowing the traffic, it will be denied. From above, I needed SSH access to the Foothold box so I allowed ssh traffic. Eventually, I added RDP in order to interact with the GUI of the Windows boxes.
Once the NSG was set up. I created the Foothold box (Ubuntu 18.04) with one VCPU and 2 GiB of RAM, the smallest possible configuration available. There wasn't a need for a ton of computing power since the purpose of this box is to just for use of proxychains through a SSH tunnel that leads in to the internal network (10.0.x.x). The IP address is obviously no longer for this box, I wouldn't have posted this if it was, so feel free to live dangerously and attack it. The connection test above signifies that a SSH connection should be possible. All of my ssh connections were started through Windows Subsystem for Linux. HIGHLY recommend if you don't have it yet. It creates a small Linux environment within Windows, stopping the need for having to spin up a full VM.
Another great feature about Azure is that it handles all the networking between machines for you by virtualizing the machine's Network Interface Card then using it to assign an IP to the box. From the subnets we created earlier, on start up, it will add the box to whichever subnet specified on creation.
Now, we need to add our server, which will serve as the domain controller. I found Microsoft's VM to be pretty straightforward. They seemed to have Windows Server 2016 backwards available for free. I went with Windows Server 2012 since it's fairly vulnerable OOTB.
Using the minimum processing configuration again, the picture shows the price of running this box. As you can see, it's not very expensive. However, imagine stepping up the resources and adding several servers and hosts for people to actually use in daily business-related functions. It certainly can be a large expense for many businesses. When evaluating whether or not your business should use Azure or its own physical infrastructure, consider how much you'll be needing the computing power or the up-time. For most small businesses, cloud is typically the way to go. For large enterprise/corporations, it's usually more cost effective to host it's own physical infrastructure as the load of large amounts of network traffic will raise the cost and strain on the machines.
At this point, it came time to add the host machines to which I chose to use Windows 7 and Windows 10. The purpose for the Windows 10 box is to step up the difficulty with the advent of AMSI on that particular OS. The basic configuration made the machine a bit slow though, so definitely step it up to 2 VCPUs if you need to use a Windows 10 machine. As mentioned before, the domain is on a separate subnet from the Foothold box and the two user boxes. The user boxes were placed in the NetSecInternal NSG and a new allow rule had to be added to allow traffic from the boxes on the other subnets. The server and the foothold box were placed in their own, respective NSGs that also had allow rules on the subnets. I ran into quite an issue with having a separate NSGs in this way since I moved forward into setting up the domain at this point without allowing the traffic from the others. It wasn't until I couldn't connect between the machines using RDP that I dug in and found this issue.
HUGE note: add the preferred DNS server as the internal IP of your Windows werver and the default azure DNS server as the secondary DNS server. The machine won't be able to connect with other machines on the network if it's not set. This took me about 4 hours to figure out. I call it the classic "Windows detour."
Once I finally had this all set, my network was functional and I could finish building my domain. As you can see, Azure has it's pros and cons. It is a great option for businesses to host their infrastructure. Personally, I think if your business traditionally uses Windows server for their network and domain administration, migrating it to Azure would allow for easy integration into a cloud environment. Microsoft has definitely created a scalable, yet reliable, in-depth platform. Also, as always, Microsoft's documentation is amazing. The surface-level cons I noticed include having a pretty steep learning curve for new users and having so many configurations available that troubleshooting can become extremely arduous. All in all it's a nice platform that I could definitely recommend to someone.