Chapter 5. Implementing Microsoft Advanced Threat Analytics

Scenario requirements for on-premises protection

Deploying ATA

Setting up the ATA environment

Leveraging ATA for threat mitigation and incident response

In Chapter 4, “Introducing Microsoft Advanced Threat Analytics,” you learned how Microsoft Threat Analytics (ATA) can be used to help meet the challenges of emerging threats. You learned about the requirements for the Gateway and Service server role in the ATA architecture and general planning considerations. To keep company data secure in the cloud and on the premises, you must mitigate potential threats before they compromise your systems. In a hybrid scenario, interaction with on-premises resources is common, and companies embracing enterprise mobility need to make it a priority to identify suspicious activities and properly respond to a security incident.

In this chapter, you adopt the persona of the senior enterprise administrator for Blue Yonder Airlines and work to address the on-premises protection requirements described at the end of Chapter 1, “Understanding Microsoft enterprise mobility solutions.” Remember that in this phase you’re responsible for preparing and successfully implementing Microsoft ATA for the company.

As a senior enterprise administrator for Blue Yonder Airlines, you’re ready to start the implementation. At the end of this phase, the following goals must be accomplished:

Monitor on-premises resources, and identify abnormal behavior in the network.

Detect attacks that exploit advanced tools and techniques in your on-premises environment.

Detect security issues and risks, and alert administrators that they are happening,

Reduce false-positive alerts to avoid creating unnecessary red flags and distraction from real issues.

You have some important considerations regarding this solution diagram:

Because of some constraints regarding the servers that should be domain-joined, Blue Yonder Airlines decided to not join the ATA servers to the corporate domain.

ATA servers are on the same subnet segment as the domain controllers.

The workstation shown in the diagram is the one that will be used for administrators to connect via remote desktop to ATA Center/Gateway.

Internet Information Services (IIS)

MongoDB

ATA Center service and ATA Console IIS site

Custom Performance Monitor data collection set

Self-signed certificates (if you selected this option during the installation)

Sign in to this server with an account that has local administrative privileges, and complete the following steps to start the installation:

1. Launch the Microsoft ATA Center Setup. On the Welcome page shown in Figure 5-2, select your preferred language and click Next.

2. Read the Microsoft Software License Terms, select I Accept The Microsoft Software License Terms to agree, and click Next to continue.

3. The ATA Center Configuration page appears as shown in Figure 5-3. This is an important setup option. You can customize how your ATA Center is configured, which has a direct impact on the system’s performance.

Consider the following recommendations and issues before making changes to these options:

For large deployments (more than 100,000 packets per second), it’s required that the database journal be located on a different disk then the database data.

Ideally, you should have a dedicated disk for data. If you do not, ensure that the disk where the database data is going to be located has more than 20 percent of free space. Be aware that if the disk’s free space reaches a minimum of either 20 percent or 100 GB, the oldest 24 hours of data will be deleted.

You can create self-signed certificates to be used during the installation and later replace it with a certificate from an internal Certification Authority (CA) to be used by the ATA Gateway. The ATA Center Services Certificate is the certificate used by the ATA Center service and the ATA Console SSL certificate is used by IIS.

Ensure that the ATA Center Services IP (the first IP bound to the interface) and port are correct before proceeding. This is the IP that listens for communication from the ATA Gateways.

Ensure that the ATA Console IP (the secondary IP in the same network interface card) address is correct. This is the IP address that is used by IIS for the ATA Console.

4. For this installation, select Create Self-Signed Certificate for both of the following options: ATA Center Services SSL Certificate and ATA Console SSL Certificate. Leave the other options as they are, and click Install. The progress page, shown in Figure 5-4, appears and requests that you restart the system when the installation is finished.

5. Click Finish to proceed, and click Restart Now in the dialog box that appears.

6. After the server restarts, sign in with the same account with which you started the installation. You will notice that the setup resumes and continues the installation, as shown in Figure 5-5.

7. After the setup process has completed, the Launch button is available in the right corner of the window. Click it to launch Microsoft ATA Center.

8. When you launch the ATA Console, Internet Explorer opens. Because the IP address of the site does not match the certificate’s subject name, Internet Explorer will exhibit a warning similar to the one shown in Figure 5-6.

9. Click Continue To This Website (Not Recommended). The login page for the ATA Console appears as shown in Figure 5-7.

At this point, you don’t need to log in. The intent here is to show how you can see that the ATA Center installation succeeded. Another validation you can do to ensure that the installation was successfully performed is to verify that the Microsoft Advanced Threat Analytics Center service is running. To verify this, click the Start button, type services.msc, and press Enter. You should be able to see the service in a running state, as shown in Figure 5-8.

1. Sign in at the ATA Center with the same user account that you used to install it.

2. Double-click the Microsoft ATA Console shortcut in the desktop.

3. In the MS ATA login page, type the ATA admin’s credentials and click Log In.

When this console is opened for the first time after you finish the setup, you are redirected to the ATA Gateway page, where you have the domain-connectivity settings as shown in Figure 5-9.

4. Type the read-only username and password, and type the complete Fully Qualified Domain Name (FQDN) of the domain where the user is located.

5. Click Save.

6. Click the Download ATA Gateway Setup button. Internet Explorer asks you to save a compressed (ZIP) file, as shown in Figure 5-10. This ZIP file contains the ATA Gateway installer and the configuration settings file with the required information to connect to the ATA Center. Click the down arrow beside Save, click Save As, and choose the location where you want to save the file. Click Save, and once the file is downloaded, close the ATA Console.

Another setting that should be adjusted before the ATA Gateway installation is the Domain Name System (DNS) suffix for the Management adapter. You should add the FQDN of the domain in which this server belongs. This setting is automatically configured if the ATA Gateway is domain-joined; however, in this example where the ATA Gateway is not domain-joined, you must add it manually. Figure 5-12 shows an example of how this was done for the Blue Yonder Airlines domain.

When these items are correctly configured and port mirroring is configured between the ATA Gateway and the domain controllers, you can start the installation. (See the “Infrastructure considerations” section in Chapter 4 for more information about port mirroring.)

Copy the ZIP file you downloaded in the last step of the previous section, extract it locally on the server, and complete the following steps to start the ATA Gateway installation:

1. Sign in at the ATA Gateway server using an account with local administrative privileges.

2. Open the folder where the ATA Gateway setup files were extracted from, and double-click the Microsoft ATA Gateway Setup.exe file.

3. If the Open File Security Warning dialog box appears, click Run.

4. On the Welcome page, select a language and click Next.

5. On the ATA Gateway Configuration page, you can customize the location where the files will be installed, as shown in Figure 5-13.

6. Review the following recommendations and issues before making changes to these options:

Select the certificate that will be used by the ATA Gateway, or select a self-signed certificate if you are not installing this in a production environment.

Review the user’s credentials to allow ATA Gateway to register with the ATA Center. This user must be a member of the Administrators group or the Microsoft Advanced Threat Analytics Administrators group on the local machine.

7. When you complete these fields, click Install.

8. The installation progress page appears. When this process is complete, you can click Finish and then click Restart Now to restart the server.

9. After the server restarts, sign in again using the same account you started the installation with. If the Open File Security Warning dialog box appears, click Run. You will notice that the setup will resume and continue the installation.

10. When the installation is complete, you can click Launch to open the ATA Console.

1. Sign in to the ATA Gateway server using an account with local administrator privileges.

2. When you open this console for the first time in the ATA Gateway, you will see the second part of the domain setting configuration, as shown in Figure 5-14.

3. Review the following recommendations and issues before making changes to these options:

The Description is optional; however, you might use it to describe this server’s role or something else.

In Port Mirrored Domain Controllers (FQDN), type the FQDN address of one or more domain controllers that will be monitored by the ATA Gateway. After typing an address, click the plus sign (+) to add it.

Be aware that the sync is load balanced among all domain controllers in this list.

Make sure that the first domain controller in the list is not a read-only domain controller (RODC). You can add an RODC to the list after the initial synchronization is completed. At least one domain controller in the list should be a Global Catalog (GC) server.

For Capture Network Adapter, select the network adapter that has Port Mirroring configured to obtain traffic from the domain controller.

4. Leave the remaining options as they are for now, click Save, and close the console.

These alerts include a link for system administrators (or whomever receives the notification) to directly view the detected suspicious activity. To configure this option, open the ATA Console (from ATA Center, ATA Gateway, or a workstation—using ATA’s FQDN), log in, and complete the following steps:

1. In the ATA Console, select the settings option on the toolbar and click Configuration, as shown in Figure 5-15.

2. In the left pane, click Alerts to open the Alert options, as shown in Figure 5-16.

3. Review the following recommendations and issues before making changes to these options:

The language you select to generate the alerts doesn’t influence the language used by the ATA Console.

By default, the level of log detail (verbosity) for the alert is set to Low. If you decide you need more information, you can change the verbosity to High. Here’s an example of how this will affect the amount of information that is sent: in a reconnaissance scenario for account enumeration, with low verbosity ATA sends a notification to the Security Information and Event Management (SIEM) server when the suspicious activity is created. With high verbosity, ATA will send a notification for each account attempted.

4. Blue Yonder Airlines decided to use Mail to send alerts. In this scenario, turn on Mail. You’ll see the options shown in Figure 5-17.

5. Review the following recommendations and issues before making changes to these options:

The SMTP Server Endpoint option should have the Mail Exchange (MX) record name for the SMTP Server you will use.

If this server requires SSL for SMTP connections, ensure that the SSL option is turned on.

If the SMTP Server requires authentication to allow a message to be sent, turn on Authentication and type the user’s credentials.

In the Send From box, type the email address that represents the user that will be sending the email. In your email server, you can create a read-only, mail-enabled user just to perform this action.

In the Send To box, add all recipients that should be receiving this email. You can also configure a distribution list in your email server and send this alert to this list.

6. When you have set all the options, click Save.

If your environment has an SIEM server, you can use the same Alert page to enable it. You will need to know the IP address or FQDN name of your SIEM server, as well as the transport protocol (TCP or UDP) and port number to communicate with that server. ATA will send data to the SIEM server using the format specified in Request For Comments (RFCs) 5424 or 3164. All messages sent to SIEM by ATA are formatted using a Common Event Formatting (CEF) standard.

To access the Health Center, click the Health Center icon on the menu bar, as shown in Figure 5-19.

After you access the Health Center, notice the filters available on the left side of the screen. If you select All, you see all alerts, including the ones that were already resolved. To see which ones are not resolved, click Open. When you resolve an issue and ATA detects that the issue persists, the issue is automatically moved back to the Open Issues list. If ATA detects that an open issue is resolved, it automatically moves it to the Resolved Issues list. The other category you have is Dismissed, which shows issues you do not want ATA to continue to check. In addition to the alert’s status, you can visualize the events by using the priority options: High, Medium, and Low.

The detection settings in ATA allow system administrators to set a list of IP addresses and subnets that have unusual circumstances and should be handled differently than other networks. To customize the detection settings, open the ATA Console, click Configuration in the toolbar, and click Detection in the left pane, as shown in Figure 5-20.

Review the following recommendations and issues before making changes to these options:

Short-term lease subnets Use this option to include subnetworks that have short-term DHCP leases, such as virtual private networks (VPNs) or Wi-Fi. This is particularly important for ATA, because it informs the system that the association between a computer and an IP address from these ranges will have a shorter period of time than it would for other IP addresses in other subnets.

Honeytoken account SIDs Honeytoken is an industry term used to specify a user account that should have no network activities. Use this account to trigger a suspicious activity if someone attempts to use this user account. ATA creates a suspicious activity as an indication of malicious activity. In this box, you should add the user account’s SID.

DNS Reconnaissance IP address exclusions Use this option to include hosts that belong to your network infrastructure and are authorized to perform DNS reconnaissance. Reconnaissance is the scanning of networks to discover valid information that can be used to map out the environment to assist hackers in their attacks. DNS reconnaissance uses this methodology to discover more information about the DNS servers. This technique is considered an attack, and ATA will trigger an alert if it detects this behavior; however, if you have some workstations in your environment that you use to perform this task, you should add these workstations to this exclusion list. A common scenario for that is when the company has an internal Pen Test (Penetration Test) team. This team can launch a DNS reconnaissance to test their security controls in place.

Pass-the-Ticket IP address exclusions Use this option to include hosts that belong to your network infrastructure and are authorized to perform Pass-the-Ticket. Pass-the-Ticket is a credentials-theft type of attack, in which the attacker steals a user’s Kerberos authentication ticket to impersonate the user to gain access to company resources. Again, if you have an internal team that needs to perform this type of attack internally (such as a Pen Test team), you need to add the IP addresses of the hosts that are authorized to perform this test to this list.

After making the changes according to your company’s needs, make sure to click Save to commit these changes.

Even though database maintenance might be something you rarely do, troubleshooting scenarios might occur in some instances. For some of these troubleshooting scenarios, you might need to access the database to visualize the records that were committed to the database. In this case, you can use the MongoDB shell commands, or use a Graphical User Interface (GUI) based utility, such as MongoVUE. By default, MongoDB will be listening on port 27017, and you can verify that by accessing the command prompt in the ATA Center and performing the following tasks:

1. Run netstat–nao.

2. Take note of the Process ID (PID) bound to the loopback address:process (127.0.0.1:27017).

3. Run tasklist to visualize the process that corresponds to the PID.

You should see that Mongod.exe is the process that is listening on this port, which is the MongoDB service shown in Figure 5-22.

The information explained previously is important if you need to use utilities such as MongoVUE to access the database, as shown in Figure 5-23.

At this point, all settings are configured and ATA is ready to act. It will start monitoring the environment and trigger alerts in cases where suspicious activities are discovered. In this first release of ATA, the following attacks¹ are identified:

¹ If you need a terminology glossary for these attacks, visit https://technet.microsoft.com/en-us/library/mt163704.aspx.

Category: Reconnaissance and Brute-Force Suspicious Activities

Reconnaissance using DNS

Reconnaissance using Account Enumeration

Brute force (LDAP, Kerberos)

Category: Identity-Theft Suspicious Activities

Pass-the-Ticket

Pass-the-Hash

Over-Pass-the-Hash

Skeleton Key

MS14-068 exploit (Forged PAC)

Remote Execution

Category: Abnormal-Behavior Suspicious Activities

Abnormal behavior based on resource access, source computers, and work hours (machine-learning algorithm)

Massive object deletion

Security Issues

Sensitive account exposed in plain text authentication

Service exposing accounts in plain text authentication

Broken trust

Honey Token accounts suspicious activity

When you select this option, you see a similar view to the one you saw when you accessed the Health Center. The difference is that, in this case, a timeline is created beside the event to assist you in understanding when such activity took place. Figure 5-25 has an example of a suspicious activity.

The suspicious activity in this case is an account enumeration, which can be considered an attack. The description says: “Suspicious account enumeration activity using Kerberos protocol, originating from YDW81DEVICE, was detected. The attacker performed a total of 157 guess attempts for account names. Two guess attempts matched existing account names in Active Directory.” This description shows precisely which device originated the attack (YDW81DEVICE) and what it was able to do. The second part of the alert (which is a medium alert—yellow and visible in Figure 5-26) shows a series of recommendations. In this case, the recommendations are as follows:

Disconnect YDW81DEVICE from the network, or move it into an isolated environment and start a forensics procedure by investigating the following: unknown processes, services, registry entries, unsigned files, and more.

Investigate the root cause on YDW81DEVICE.

Verify that all accounts under “Existing accounts” use a strong password.

You should address these recommendations right away to prevent this device from continuing to try to execute this reconnaissance process. At this point, you might even consider starting an incident response to handle these procedures in the target device.

This example shows an attacker using Bob’s user account from the host 10.0.0.200 and trying to exploit the vulnerability announced in Microsoft Security Bulletin MS14-068, “Kerberos Key Distribution Center vulnerability using a forged PAC.” The two main questions at this point are these:

Is Bob (a Blue Yonder Airlines full-time employee) really performing this attack, or has someone stolen his identity?

10.0.0.200 belongs to the Blue Yonder Airlines corporate network; therefore, this attack was initiated from a workstation that is located internally. Is this workstation compromised, or is it a spoofed address?

To answer these questions, you can follow the recommendations shown at the bottom of the alert, as you can see in Figure 5-26. These recommendations are important and, again, you can start an incident-response process at this point to perform a further investigation.