In this blog post, I will be talking about Azure advanced threat protection deployment, and walk you through my experience doing large implementation in an environment with virtual domain controllers hosted on VMware clusters. You can also read about Azure advanced threat protection lateral movement, Azure ATP and Windows Defender ATP integration, and Azure ATP vs ATA.

Azure advanced threat protection is a cloud service from Microsoft to detect advanced threats, and is considered a cloud evolution of the previous Microsoft ATA solution.

Cloud evolution for Microsoft ATA

AZURE ATP DEPLOYMENT OPTIONS

There are two Azure advanced threat protection deployment options, that is, you have two methods to collect logs from a domain controllers:

• Download an agent (Azure ATP sensor) on each domain controller in your environment, and that agent will send data directly to the cloud service.
• Configure a server (Azure standalone sensor), that receives a copy of all traffic sent to domain controllers via port mirroring.

OPTION 1: AZURE ATP SENSOR

[In the ATA world, this is called lightweight gateway]

The first option is the easiest option as all what you need to do is to install a small agent (Azure ATP sensor) on each domain controller. I usually do not like to install anything on my domain controllers as I treat them as shielded boxes. I even do not install the configuration manager agent on domain controllers, as the SCCM agent runs under SYSTEM, and this means that the SCCM admin can execute things using elevated domain privileges

Also, Azure ATP sensor will install .NET framework during the sensor installation process, which I do not like, as it means you will have more threat exposure on your domain controllers.

It’s worth mentioning that big companies have separate teams for security management and Identity management. If you go with Azure ATP sensor option, then the identity management team needs to do the sensor deployment, and troubleshoot if the service gets stopped, as the security team does not have domain admin rights to do such operations on the domain controllers. In my case, I want the security team to manage the whole deployment and maintenance of the ATP solution, so I prefer to give them admin right on the Azure ATP standalone sensor server and go with option 2 of the Azure advanced threat protection deployment options.

I also worry that Azure ATP sensor might affect the performance of my domain controller. But with the proper capacity planning, and with the performance improvements Microsoft did with the new Azure ATP sensor, I should not face any problem.

Microsoft re-engineered the Azure ATP sensor as it comes with up to 10 times performance improvement compared to the old ATA agent, thanks to the new parsing platform. Therefore, Microsoft decided to come with the (Sensor) name, to make it clear that this is a brand new enhanced agent and not just changing names. If you run both ATA lightweight gateway and Azure ATP sensor on a domain controller, which is absolutely possible, then you can see “according to Microsoft” huge performance improvement [up to 10 times] as shown below.

Note: picture taken from Microsoft Ignite presentation here.

Both ATA lightweight gateway and Azure ATP sensor have a resource limiting function that monitors the free resources on domain controllers, and make sure domain controllers have enough resources to operate and never get affected with the ATP sensor operations. If the domain controller gets busy, then Azure ATP sensor will limit the resources it consumes accordingly. Although this makes sure that the domain controller never gets under pressure, it will badly affect the Azure ATP sensor, as it will pause analyzing the traffic.

Thanks to Microsoft, Azure ATP sensor consumes way less resources than the old ATA lightweight gateway, which means you will rarely reach a point where the domain controller gets under pressure.

OPTION 2: AZURE ATP STANDALONE

[In the ATA world, this is called standalone gateway]

Here you can connect one or more domain controllers to a separate server (Azure ATP standalone), by sending the traffic through port mirroring, so that Azure ATP standalone sensor server can see the traffic without deploying anything on the domain controller itself.

Since we are not installing anything on domain controller servers, then capturing the traffic via port mirroring is not enough. We still need to get the Windows Event logs from those domain controllers. This can happen either by setting a Windows Event Forwarding from domain controllers to the Azure ATP standalone sensor server, or if you are already gathering domain controller’s event logs via SIEM system, then Azure ATP standalone can get events directly from the SIEM system.

Standalone Deployment

NETWORK CARDS ON AZURE ATP STANDALONE SENSOR SERVER

You might need two network card on the Azure ATP standalone sensor server, one with non-routable dummy IP and used for port mirroring and receiving copy of the domain controller’s traffic. Another NIC with valid routable IP and default gateway, used to send the traffic to Azure ATP service in the cloud.

Network and Mirroring Traffic

WHAT IF YOUR DOMAIN CONTROLLER IS RUNNING ON A VM?

I used to have VMware environment and all my domain controllers are actually running on VMs. I decided to go with the Azure ATP sensor standalone Azure advanced threat protection deployment option, and I was stuck with the port mirroring thing.

If you have VMware cluster with couple of hosts, then let me give you a recommendation [This actually worked form me]:

• For each domain controller VM, I deploy a separate VM with two NICs and I install Azure ATP standalone on it. So if I have ten domain controllers, I would install ten Azure ATP standalone sensor servers.

Why do you need a dedicated Azure ATP standalone sensor server per DC? why you don’t deploy one Azure ATP standalone for your two domain controllers in case you have two DCs in this site? Let us look at the image below and analyze the situation. In this data center we have two domain controllers and a VMware cluster with four hosts. Now if DC1, DC2 and the Azure standalone sensor server are all hosted on VMware Host 1, then you can configure port mirroring so that traffic coming from DC1 and DC2 are sent to the Azure standalone sensor server, but if DC2 for example is to be moved to VMware Host 2, then you cannot do port mirroring so that DC2 can send the traffic to the sensor server located in different VMware Host.

Of course, you can configure an affinity in VMware so that DC1, DC2, and the sensor server always move together between VMware hosts, but I am not sure it is a good idea to host two domain controllers inside the same VMware host, as you will have a single point of failure.

Instead, I have DC1 hosted on VMware Host 1, and DC2 hosted on VMware Host 3, and I would have two sensor servers, one hosted on VMware Host 1 with port mirroring from DC1, and one hosted on VMware Host 3 with port mirroring from DC2.

Vmware Cluster

• I configure an affinity between each domain controller and the corresponding Azure ATP sensor standalone VM, so that if the DC moves from host to another, the corresponding Azure ATP sensor standalone VM will move with it to the same host. This is needed for the VMware switch to do proper mirroring during host fail over.
• I then configure port mirroring on the VMware switch so that any traffic going to the DC VM, will be sent to one of the two NICs of corresponding the Azure ATP standalone VM.

Here we can see I have two domain controllers running as VMware VMs, so I had to install two Azure ATP standalone sensor servers.

Movement

If DC1 gets moved to VMware host 2 for any reason, then the corresponding Azure ATP standalone sensor server 1 will do the same. This will ensure that port mirroring actually works.

Port mirroring

What would be bad and not working, if DC1 gets moved to VMware host 2, while the corresponding Azure ATP standalone sensor server 1 still hosted on VMware host 1. This will cause port mirroring to fail.

Port mirroring fails

Finally, here is the VMware port mirroring configuration that works for me:

VMware port mirroring that works

OPTION 3: MIX OF BOTH

The goal here is to capture the traffic from all your domain controllers in your forest. It does not matter how you do that. You can have some of your domain controllers with Azure ATP sensor deployed on them (perhaps in remote offices where you do not want to have to build another server just for Azure ATP standalone sensor), and you can have other domain controllers sending their traffic to Azure ATP standalone sensor servers via port mirroring.

Just make sure you do not have the same domain controller sending traffic using both Azure ATP sensor, and via port mirroring to an Azure ATP standalone sensor server.

AZURE ATP CAPACITY PLANNING

Before considering deploying Azure advanced threat protection senors in your environment, make sure you read Microsoft documentation about Azure ATP capacity planning. Microsoft provides a sizing tool to help you do the proper capacity planning.

Azure capacity planning

AZURE ADVANCED THREAT PROTECTION DEPLOYMENT

There are many steps that we will go through to complete the Azure advanced threat protection deployment:

1. Choose an Azure advanced threat protection deployment option [discussed above].
2. Create an Azure ATP workplace.
3. Install Azure ATP sensor.
4. Additional Steps.

In this section, I will be deploying Azure ATP standalone sensor on a Windows 2012 R2 server, that is configured with port mirroring to capture the domain controller’s traffic. After going through Azure ATP architecture and prerequisites, we can go a head and start the Azure advanced threat protection deployment process.

CREATE AN AZURE ATP WORKPLACE

Azure ATP workplaces are something you really want to understand before starting the Azure advanced threat protection deployment process. You can think of a workplace as a unit of data storage, integration, and AD forest boundary as explained here:

• You can have multiple Azure ATP workplaces within the same tenant.
• A workplace helps you define the region where your data is stored: You can create a workplace to store Azure ATP data in a region, and another workplace to store different Azure ATP data in another region.
• Each workplace requires you to define the username and password for domain connectivity. This is a non-privileged account that needs to have read only access to your domain controller’s data.
• A workplace is the boundary for Active Directory forest. Therefore, if you have two forests on-premises, you have to create a different workplace for each forest. For the same forest, just keep using one workplace.
• A workplace is considered a unit of integration with Windows Defender Advanced Threat Protection (a.k.a Windows Defender ATP). Therefore, you can have multiple Azure ATP workplaces within one tenant, but only one workplace can be connected to Windows Defender ATP. In other worlds, there is a 1:1 relationship between Azure ATP and Windows ATP.

You can create a workplace by going to the Azure ATP portal here, and choose to create a workplace.

Create a new workplace

Primary workplace

The name you pick for your workplace, will be used to construct the URL for your workplace management portal. So, if your workplace name is ContosoATP, then when you access your workplace management portal, you will be using this URL: https://ContosoATP.atp.azure.com.

Next step is to provide an account that will be used by the Azure ATP sensor on-premises to access your domain controller. This account should only have read access to your AD. Also, you might want to give it extra permissions as specified here to configure SAM-R permissions and enable a feature called lateral movement paths.

Azure threat protection

Finally, we would then download the Sensor Setup. The same package is used to deploy Azure ATP standalone sensor server, and the Azure ATP sensor.

INSTALL AZURE ATP SENSOR

After downloading the package, go to your Azure ATP standalone sensor server, that is configured with port mirroring to capture domain controller’s traffic and run the installation. The installation will immediately detect that this server is not a domain controller, and will try to install Azure ATP standalone sensor server, and not the Azure ATP sensor. Note the access key that you will be use when completing the sensor installation process.

aramexatp

As you can see, .NET is required for Azure ATP sensor setup.

Azure ATP Sensor

Sensor deployment type

Sensor 2.0

Finally, when configuring the sensor, make sure to enter the access key you got from the management portal.

Configure the Sensor

Note:  Few considerations if you are running the installation on a VMWare VM, as you might need to configure the network card of the VM as shown below:

VMware virtual machine sensor issue

Networking and sharing center

There is also an issue with Azure ATP sensor and NIC teaming mentioned here, that you might want to look at. In my case, after installing the sensor on VMWare VM, the service won’t start, and I had to uninstall WinPcap from [Add Remove Programs] to sort out the issue.

You can also find the Azure ATP sensor logs located here [C:\Program Files\Azure Advanced Threat Protection Sensor\], which helped a lot sort out couple of problems.

Logs

Now, getting back to the Azure advanced threat protection management portal, we can see that the domain controller is now reporting the data back.

Domain Controller

ADDITIONAL STEPS

Now that you finished your Azure advanced threat protection deployment, there are couple of things that you can configure:

VPN INTEGRATION

One of the important pieces when doing investigation is the ability to have a view on VPN connections, like IP addresses and locations where connection originated. This complements the investigation by providing additional information on user activity as well as new detection for abnormal connection.

This integration is possible via RADIUS Accounting events that you can forward to Azure ATP sensors. This integration is based on standard RADIUS Accounting RFC 2866 which is supported by Microsoft, F5, Check Point, Cisco ASA.

From the Azure ATP management portal, you just need to turn on RADIUS Accounting, and type a Shared Secret. Full details about configuring the integration can be found here.

RADIUS Accounting

HONEYTOKEN ACCOUNTS

Honeytoken accounts are dummy accounts that you create with a name that attract hackers to attack first. Those accounts should not have any network activity, so when Azure ATP sees some noise coming from one of those accounts, you know that there are suspicious activities happening right now. Try to name such accounts with names like SQL Admin or Master Key.

You can tag accounts to be marked as honeytokens inside the Azure ATP management portal under Entity Tags.

Entity Tags

EXCLUSIONS

It makes sense that there will be some false positive alerts, like when Azure ATP generates alerts for your AAD Connect server because it is doing some AD replication traffic, which is normal as it is performing AD synchronization to Azure AD. The best way is to remove false positive for this server would be to exclude the AAD connect server from such alert category.  You can be so specific when doing some exclusions, in fact you can do exclusions per detection type as shown in the below figure. To configure exclusions, browse to the Exclusions section in the Azure ATP management portal.

Exclusions

SENSITIVE ACCOUNTS

Sensitive accounts can be tagged in two ways:

• Automatic tagging: the following groups and members of the groups will be automatically considered sensitive:
  • The following list of groups are considered Sensitive by Azure ATP. Any entity that is a member of these groups is considered sensitive:
    • Administrators
    • Power Users
      Account Operators
    • Server Operators
    • Print Operators
    • Backup Operators
    • Replicators
    • Remote Desktop Users
    • Network Configuration Operators
    • Incoming Forest Trust Builders
      Domain Admins
    • Domain Controllers
    • Group Policy Creator Owners
    • read-only Domain Controllers
    • Enterprise Read-only Domain Controllers
    • Schema Admins
    • Enterprise Admins
  • Manual tagging: where you can manually tag the CEO account for example as sensitive account, since he can access sensitive information. You can configure manual tagging from within the Azure ATP management portal under Entity Tagging. You can manually tag users and groups as sensitive accounts.

What is special about sensitive accounts? As far as I know, when you tag an account as sensitive, Azure ATP will do more detection techniques on those accounts like:

• Sensitive Group Modification Detection: notifies you when the group membership is changed I guess.
• Lateral Movement Path: when you look at the lateral movement graph from within the Azure ATP portal, you can see that the graph will always try to draw an attack route with a destination equals to one of those sensitive accounts. Every time a sensitive account logs on to a machine, Azure ATP sensors will try to connect to the machine using SAM-R protocol to learn who are the members of the local administrators group on that machine, and then will draw a lateral movement graph accordingly. In summary, if an account is marked as sensitive, then Azure ATP will consider it a target for its lateral movement detection and graphs.

Sensitive

ENABLE LATERAL MOVEMENT [CONFIGURE SAM-R PERMISSIONS]

There is a complete section on Microsoft documentation about configuring SAM-R permissions so that Azure ATP sensors can query the local admin on machines where sensitive accounts log on, in order to generate the lateral movement graph. I will post a detailed blog post talking about this.

CONFIGURE WINDOWS EVENT FORWARDING

One of the most important parts during your Azure advanced threat protection deployment is to configure event forwarding. If the sensor is installed directly on the DC, then nothing to worry about, but if you are using Azure ATP sensor standalone, then remember that you need to send some Windows Events from your DC to your Azure ATP sensor standalone server using either Windows Event Forwarding or via SIEM integration.

Why this matter? Because those events [4776, 4732, 4733, 4728, 4729, 4756, 4757, and 7045] are critical to:

• Enhance various detection for NTLM authentication [Event 4776]
• Necessary for sensitive group modification and service creation [Events 4732, 4733, 4728, 4729, 4756, 4757 and 7045]

Here is a document showing how to do Azure advanced threat protection deployment event forwarding.

CONFIGURE PROXY IF NEEDED

Azure advanced threat protection deployment might require you to consider your proxy configuration. It is always a proxy problem, and Azure ATP sensor can work with that problem. Here is Microsoft documentation about how to configure Azure ATP sensors to work with proxy.

REFERENCE DOCUMENTS

Finally, you can have a look at the prerequisites, architecture, and Azure advanced threat protection deployment documentation at Microsoft docs.

Reference: Hasayen, A. (2018). Azure Advanced Threat Protection Deployment.  Available at: https://blog.ahasayen.com/azure-advanced-threat-protection-lateral-movement/ [Accessed: 10 May 2018]