Azure Sentinel To-Go (Part2): Integrating a Basic Windows Lab 🧪 via ARM Templates 🚀

Most of the time when we think about the basics of a detection research lab, it is an environment with Windows endpoints, audit policies configured, a log shipper, a server to centralize security event logs and an interface to query, correlate and visualize the data collected.

Recently, I started working with Azure Sentinel and even though there are various sources of data and platforms one could integrate it with, I wanted to learn and document how I could deploy an Azure Sentinel with a Windows lab environment in Azure for research purposes.

In this post, I show how to integrate an ARM template created in a previous post to deploy an Azure Sentinel solution with other templates to deploy a basic Windows network lab. The goal is to expedite the time it takes to get everything set up and ready-to-go before simulating a few adversary techniques.

This post is part of a four-part series where I show some of the use cases I am documenting through the open source project Azure Sentinel To-Go! . The other parts of this series can be found in the following links:

Azure Sentinel To-Go! (Part 1)_: A Lab with Prerecorded Data and a Custom Logs Pipeline via Azure Resource Manager Templates

Azure Sentinel To-Go?

In a previous post (part 1), I introduced the project Azure Sentinel To-Go to start documenting some of the use cases that one could use an Azure Sentinel solution for in a lab environment, and how it could all be deployed via Azure Resource Manager (ARM) templates to make it practical and modular enough for others in the community to use.

If you go to the project’s current deployment options, you can see some of the current scenarios you can play with. For this post, I am going to use the one highlighted below and explain how I created it:

First of all, I highly recommend to read these two blog post to get familiarized with the process of deploying Azure Sentinel via ARM templates:

Azure Sentinel To-Go! (Part 1)_: A Lab with Prerecorded Data and a Custom Logs Pipeline via Azure Resource Manager Templates :rocket:

It is Biceps Day! Flexing an ARM Template to deploy Azure Sentinel

A basic template to deploy an Azure Sentinel solution would look similar to the one available in the Blacksmith project:

https://github.com/OTRF/Blacksmith/blob/master/templates/azure/Log-Analytics-Workspace-Sentinel/azuredeploy.json

Extending The Basic Azure Sentinel Template

In order to integrate an Azure Windows lab environment with the basic Azure Sentinel ARM template, we need to enable and configure the following features in our Azure Sentinel workspace:

Enable the Azure Sentinel Security Events Data Connector to stream all security events (Microsoft-Windows-Security-Auditing event provider) to the Azure Sentinel workspace.

Enable and stream additional Windows event providers (i.e Microsoft-Windows-Sysmon/Operational or Microsoft-Windows-WMI-Activity/Operational) to increase the visibility from a data perspective.

Of course, we also need to download and install the Log Analytics agent (also known as the Microsoft Monitoring Agent or MMA) on the machines for which we want to stream security events into Azure Sentinel. We will take care of that after this section.

1) Azure Sentinel + Security Events Data Connector

If you have an Azure Sentinel instance running, all you would have to do is go to Azure Portal>Azure Sentinel Workspaces>Data connectors>Security Events > Open connector page

Then, you will have to select the events set you want to stream (All events, Common, Minimal or None)

If you want to know more about each event set, you can read more about it here. The image below shows all the events behind each event set.

https://docs.microsoft.com/en-us/azure/sentinel/connect-windows-security-events

Once you select an event set and click on Apply Changes, you will see the status of the data connector as Connected and a message indicating the change happened successfully.

If you go back to your data connectors view, you will see the Security Events one with a green bar next to it and again with the Connected status.

Azure Resource Manager (ARM) Translation

We can take all those manual steps and express them as code as shown in the template below:

https://github.com/OTRF/Azure-Sentinel2Go/blob/master/azure-sentinel/linkedtemplates/data-connectors/securityEvents.json

The main part in the template is the following resource of type Microsoft.OperationalInsights/workspaces/dataSources and of kind SecurityInsightsSecurityEventCollectionConfiguration . For more information about all the additional parameters and allowed values, I recommend to read this document.

{
  “type”: “Microsoft.OperationalInsights/workspaces/dataSources”,
  “apiVersion”: “2020-03-01-preview”,
  “location”: “[parameters(‘location’)]”,
  “name”: “<workspacename>/<datasource-name>”,
  “kind”: “SecurityInsightsSecurityEventCollectionConfiguration”,
  “properties”: {
    “tier”:  “<None,Minimal,Recommended,All>”,
    “tierSetMethod”: “Custom” 
  }
}

2) Azure Sentinel + Additional Win Event Providers

It is great to collect Windows Security Auditing events in a lab environment, but what about other event providers? What if I want to install Sysmon and stream telemetry from Microsoft-Windows-Sysmon/Operational? Or maybe Microsoft-Windows-WMI-Activity/Operational?

There is not an option to do it via the Azure Sentinel data connectors view, but you can do it through the Azure Sentinel Workspace advanced settings (Azure Portal>Azure Sentinel Workspaces>Azure Sentinel>{WorkspaceName} > Advanced Settings) as shown below:

We can manually add one by one by typing the names and clicking on the plus sign.

Azure Resource Manager (ARM) Translation

We can take all those manual steps and express them as code as shown in the template below:

https://github.com/OTRF/Azure-Sentinel2Go/blob/master/azure-sentinel/linkedtemplates/log-analytics/winDataSources.json

The main part in the template is the following resource of type Microsoft.OperationalInsights/workspaces/dataSources and of kind WindowsEvent. For more information about all the additional parameters and allowed values, I recommend to read this document.

{
  “type”: “Microsoft.OperationalInsights/workspaces/dataSources”,
  “apiVersion”: “2020-03-01-preview”,
  “location”: “[parameters(‘location’)]”,
  “name”: “<workspacename>/<datasource-name>”,
  “kind”: “WindowsEvent”,
  “properties”: {
    “eventLogName”: “”,
    “eventTypes”: [
      { “eventType”: “Error”},
      { “eventType”: “Warning”},
      { “eventType”: “Information”}
    ]
  }
}

In the template above, I use an ARM method called Resource Iteration to create multiple data sources and cover all the event providers I want to stream more telemetry from. By default these are the event providers I enable:

“System”
“Microsoft-Windows-Sysmon/Operational”,
“Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational”,
“Microsoft-Windows-Bits-Client/Operational”,
“Microsoft-Windows-TerminalServices-LocalSessionManager/Operational”,
“Directory Service”,
“Microsoft-Windows-DNS-Client/Operational”,
“Microsoft-Windows-Windows Firewall With Advanced Security/Firewall”,
“Windows PowerShell”,
“Microsoft-Windows-PowerShell/Operational”,
“Microsoft-Windows-WMI-Activity/Operational”
“Microsoft-Windows-TaskScheduler/Operational”

Executing The Extended Azure Sentinel Template

We need to merge or link the previous two templates to the initial template . You might be asking yourself:

“Why are the two previous templates on their own and not just embedded within one main template?”

That’s a great question. I initially did it that way, but when I started adding Linux and other platform integrations to it, the master template was getting too big and a little too complex to manage. Therefore, I decided to break the template into related templates, and then deploy them together through a new master template. This approach also helps me to create a few template combinations and cover more scenarios without having a long list of parameters and one master template only. I use the Linked Templates concept which you can read more about here.

These are the steps to execute the template:

1) Download current demo template

https://github.com/OTRF/Blacksmith/blob/master/templates/azure/Log-Analytics-Workspace-Sentinel/demos/LA-Sentinel-Windows-Settings.json

2) Create Resource Group (Azure CLI)

You do not have to create a resource group, but for a lab environment and to isolate it from other resources, I run the following command:

az group create -n AzSentinelDemo -l eastus

az group create : Create a resource group

-n : Name of the new resource group

-l : Location/region

3) Deploy ARM Template (Azure CLI)

az deployment group create -f ./LA-Sentinel-Windows-Settings.json -g AzSentinelDemo

az deployment group create: Start a deployment

-f : Template that I put together for this deployment.

-g: Name of the Azure Resource group

Monitor Deployment

As you can see in the image below, multiple deployments were executed after executing the master template for this demo.

Check Azure Sentinel Automatic Settings (Data Connector)

Check Azure Sentinel Automatic Settings (Win Event Providers)

Everything got deployed as expected and in less than 30 seconds!! Now, we are ready to integrate it with a Windows machine (i.e Azure Win10 VM).

Re-Using a Windows 10 ARM Template

Building a Windows 10 virtual machine via ARM templates, and from scratch, is a little bit out of scope for this blog post ( I am preparing a separate series for it), but I will highlight the main sections that allowed me to connect it with my Azure Sentinel lab instance.

A Win 10 ARM Template 101 Recipe

I created a basic template to deploy a Win10 VM environment in Azure. It does not install anything on the endpoint, and it uses the same ARM method called Resource Iteration , mentioned before, to create multiple Windows 10 VMs in the same virtual network.

https://github.com/OTRF/Blacksmith/blob/master/templates/azure/Win10/demos/Win10-101.json

Main Components/Resources:

A Network Security Policy

A Virtual Network and Subnet

A Public IP Address

A Network Interface

A Virtual Machine

One part of the virtual machine resource object that is important to get familiarized with is the imageReference properties section.

A Marketplace image in Azure has the following attributes:

Publisher: The organization that created the image. Examples: MicrosoftWindowsDesktop, MicrosoftWindowsServer

Offer: The name of a group of related images created by a publisher. Examples: Windows-10, WindowsServer

SKU: An instance of an offer, such as a major release of a distribution. Examples: 19h2-pro, 2019-Datacenter

Version: The version number of an image SKU.

How do we get some of those values? Once again, you can use the Azure Command-Line Interface (CLI) . For example, you can list all the offer values available for the MicrosoftWindowsDesktop publisher in your subscription with the following command:

> az vm image list-offers -p MicrosoftWindowsDesktop -o table

Location    Name
———-  ——————————————–
eastus      corevmtestoffer04
eastus      office-365
eastus      Test-offer-legacy-id
eastus      test_sj_win_client
eastus      Windows-10
eastus      windows-10-1607-vhd-client-prod-stage
eastus      windows-10-1803-vhd-client-prod-stage
eastus      windows-10-1809-vhd-client-office-prod-stage
eastus      windows-10-1809-vhd-client-prod-stage
eastus      windows-10-1903-vhd-client-office-prod-stage
eastus      windows-10-1903-vhd-client-prod-stage
eastus      windows-10-1909-vhd-client-office-prod-stage
eastus      windows-10-1909-vhd-client-prod-stage
eastus      windows-10-2004-vhd-client-office-prod-stage
eastus      windows-10-2004-vhd-client-prod-stage
eastus      windows-10-ppe
eastus      windows-7

Then, you can use a specific offer and get a list of SKU values:

> az vm image list-skus -l eastus -f Windows-10 -p MicrosoftWindowsDesktop -o table

Location    Name
———-  —————————
eastus      19h1-ent
eastus      19h1-ent-gensecond
eastus      19h1-entn
eastus      19h1-entn-gensecond
eastus      19h1-evd
eastus      19h1-pro
eastus      19h1-pro-gensecond
eastus      19h1-pro-zh-cn
eastus      19h1-pro-zh-cn-gensecond
eastus      19h1-pron
eastus      19h1-pron-gensecond

Execute the Win 10 ARM Template 101 Recipe (Optional)

Once again, you can run the template via the Azure CLI as shown below:

az deployment group create -f ./Win10-101.json -g AzSentinelDemo –parameters adminUsername=’wardog’ adminPassword='<PASSWORD>’ allowedIPAddresses=<YOUR-PUBLIC-IP

One thing to point out that is very important to remember is the use of the allowedIPAddresses parameter. That restricts the access to your network environment to only your Public IP address. I highly recommended to use it. You do not want to expose your VM to the world.

This will automate the creation of all the resources needed to have a Win 10 VM in azure. Usually one would need to create one resource at a time. I love to automate all that with an ARM template.

Once the deployment finishes, you can simply RDP to it by its Public IP address. You will land at the privacy settings setup step. This is a basic deployment. Later, I will provide a template that takes care of all that (Disables all those settings and prepares the box automatically).

You can delete all the resources via your Azure portal now to get ready for another deployment and continue with the next examples.

Extending the Basic Windows 10 ARM Template

In order to integrate the previous Win10 ARM template with the extended Azure Sentinel ARM template, developed earlier, we need to do the following while deploying our Windows 10 VM:

Download and install the Log Analytics agent (also known as the Microsoft Monitoring Agent or MMA) on the machines for which we want to stream security events into Azure Sentinel from.

Win 10 ARM Template + Log Analytics Agent

I put together the following template to allow a user to explicitly enable the monitoring agent and pass workspaceId and workspaceKey values as input to send/ship security events to a specific Azure Sentinel workspace.

https://github.com/OTRF/Blacksmith/blob/master/templates/azure/Win10/demos/Win10-Azure-Sentinel.json

The main change in the template is the following resource of type Microsoft.Compute/virtualMachines/extensions. Inside of the resource properties, I define the publisher as Microsoft.EnterpriseCloud.Monitoring and of type MicrosoftMonitoringAgent. Finally, I map the workspace settings to their respective input parameters as shown below:

{ 
  “name”: “<VM-NAME/EXTENSION-NAME>”,
  “type”: “Microsoft.Compute/virtualMachines/extensions”,
  “apiVersion”: “2019-12-01”,
  “location”: “[parameters(‘location’)]”,
  “properties”: {
    “publisher”: “Microsoft.EnterpriseCloud.Monitoring”,
    “type”: “MicrosoftMonitoringAgent”,
    “typeHandlerVersion”: “1.0”,
    “autoUpgradeMinorVersion”: true,
    “settings”: {
      “workspaceId”: “[parameters(‘workspaceId’)]”
    },
    “protectedSettings”: {
      “workspaceKey”: “[parameters(‘workspaceKey’)]”
    }
  }
}

Putting it All Together!

To recap, the following template should do the following now:

Deploy an Azure Sentinel solution

Enable the Azure Sentinel SecurityEvents data connector

Enable more Windows event providers to collect more telemetry

Deploy a Windows 10 virtual machine and its own virtual network.

Install the Log Analytics Agent (Microsoft Monitoring Agent) in the Windows 10 VM.

Executing the ARM Template (Azure CLI)

az deployment group create -n Win10Demo -f ./Win10-Azure-Sentinel-Basic.json -g Win10AzSentinel –parameters adminUsername=’wardog’ adminPassword='<PASSWORD>’ allowedIPAddresses=<PUBLIC-IP-ADDRESS>

Once the deployment finishes (~10mins), you can go to your Azure Sentinel dashboard, wait a few mins and you will start seeing security events flowing:

As you can see in the image above, we have events from SecurityEvent and Event tables. We can explore the events through the Logs option.

SecurityEvent

You can run the following query to validate and explore events flowing to the SecurityEvent table:

SecurityEvent
| limit 1

Event

The following basic query validates the consumption of more Windows event providers through the Event table:

Event
| summarize count() by EventLog, Source

That’s it! Very easy to deploy and in a few minutes.

Improving the Final Template! What? Why?

I wanted to automate the configuration and installation of a few more things:

New Firewall rules, Power options, Security Private settings, Disabling a few Windows 10 settings, PowerShell Remoting service, etc. I used the following script.

System Access Control List (SACL) known as Audit Rules on specific secured objects to generate more telemetry. I used the following script.

Setting a wallpaper via Bginfo. I used the following script.

Install AntiMalware extension on every Windows 10 VM via the following embedded resource. My way to configure Windows Defender exclusions.

Install Sysmon on every Windows 10 VM via this script.

Embed a Log Analytics Function option via the Azure Sentinel template to call a linked template and import a Sysmon function/parser.

[Optional] Azure bastion host set up.

[Optional] A Command and control (C2) framework. I wanted to have the option to deploy a C2 along with my setup and test a few things.

[Optional] Virtual Network Peering between the Windows 10 Virtual Network and the C2 Virtual Network.

This final official template is provided by the Azure Sentinel To-Go project and can be deployed by clicking on the “Deploy to Azure” button in the repository as shown below.

https://github.com/OTRF/Azure-Sentinel2Go

The Final Results!

Azure Sentinel

An Azure Sentinel with security events from several Windows event providers flowing right from a Win10 VM.

Windows 10 VM

A pre-configured Win10 VM ready-to-go with Sysmon installed and a wallpaper courtesy of the Open Threat Research community.

[Optional] Ubuntu — Empire Option Set

An Ubuntu 18 VM with Empire dockerized and ready-to-go. This is optional, but it helps me a lot to run a few simulations right away.

ssh wardog@<UBUNTU-PUBLIC-IP>

> sudo docker exec -ti empire ./empire

Having a lab environment that I can deploy right from GitHub and in a few minutes with One Click and a few parameters is a game changer.

What you do next is up to you and depends on your creativity. With the Sysmon function/parser automatically imported to the Azure Sentinel workspace, you can easily explore the Sysmon event provider and use the telemetry for additional context besides Windows Security auditing.

Sysmon
| summarize count() by EventID

FQA:

How much does it cost to host the last example in Azure?

Azure Sentinel (Receiving Logs), Win10VM (Shipping Logs) and Ubuntu VM running for 24 hours was ~$3–$4. I usually deploy the environment, run my test, play a little bit with the data, create some queries and destroy it. Thefore, it is usually less than a dollar every time I use it.

What about Windows Event Filtering? I want more flexibility

Great question! That is actually a feature in preview at the moment. You can read more about Azure Monitor Agent and Data Collection Rules Public Preview here. This is a sample data collection rule where you can specify specific events and event providers. I wrote a basic one for testing as shown below:

“dataSources”: {
  “windowsEventLogs”: [
    {
      “name”: “AuthenticationLog”,
      “streams”: [ 
        “Microsoft-WindowsEvent”
      ],
     “scheduledTransferPeriod”: “PT1M”,
     “xPathQueries”: [
        “Security!*[System[(EventID=4624)]]”
     ]
    }
   ]
}

That will be covered in another blog post once it is more mature and is GA. xPathQueries are powerful!

Am I exposing the lab environment to the World?

There is a parameter in every template that does not have a default value anymore which asks you to enter the only Public IP address you would like it to have access to it. This could be your organization or your house Public IP Address. There is also another option in the official templates (no demos) that allows you to deploy an Azure Bastion Host for your environment. This adds an additional resource to your environment so there will be a cost associated to it. The different with the Public IP address is that you access your environment via the Azure Portal directly (RDP and SSH).

That’s it! I hope you liked this tutorial. As you can see in the last part of this post, you can now deploy everything with one click and a few parameters and through the Azure Portal. That is what the Azure Sentinel To-Go project is about. Documenting and creating templates for a few lab scenarios and share them with the InfoSec community to expedite the deployment of Azure Sentinel and a few resources for research purposes.

Next time, I will go over a Linux environment deployment, so stay tuned!