Enterprise Mobility and Security Blog


Advanced Threat Analytics (ATA) detects a variety of suspicious activities (SA) in different phases of the attack-kill-chain. The information appears in the ATA console in a clear and efficient social network-type timeline that helps the security admin filter out noise to identify actual suspicious activities. ATA only raises alerts once it has aggregated suspicious activities by comparing the entity’s behavior to its own past behavior, as well as to the profiles of other entities in its interaction path. For a complete list of detections and their descriptions, see ATA Detections. ATA provides rich information on the entities involved in the suspicious activity as well as remediation steps for investigating the alert. We will explore both these topics in this blog.

SA Alert Components

The admin can share details on each alert raised via email for further investigation, export the details to Excel, or even add organization-specific notes. Alerts are classified as high, medium or low depending on the impact it can have in the enterprise.


Since ATA self-learns to adjust to the customer environment, some alerts may request input to enhance future detection of suspicious activities. In the below alert, ATA says that it has observed suspicious DNS activity originating from client1. If the admin toggles the response to “yes,” ATA will no longer send an alert if it detects a DNS zone transfer request from client1. It will, however, continue to monitor other suspicious activities from client1.


Since a device can move across multiple IPs within a few minutes in large corporate networks, it can be challenging to map the IP address back to the actual device at the time of attack. ATA uses a unique approach called Network Name Resolve to first resolve the IP address seen in the network traffic at the time of the event, and then connect the relevant user and computer account details. In the example below, we can see that ATA identified a privileged user as part of a Pass-the-Ticket attack. The ATA console displays the computer names involved.



By clicking the user or computer account in the alert, we can get much more detail on the entity itself:

  • OS details
  • Recent network activity
  • SPNs
  • Group memberships
  • Date of last password change



SA Alert Investigation

Customers often ask how they can investigate the alerts that ATA surfaces. For each suspicious activity or known attack identified, ATA provides basic recommendations for investigation and remediation. Let’s review some common suspicious activity alerts and the steps for investigating them.

In the previous example of a DNS reconnaissance alert, ATA identified client1 as initiating a zone transfer request even though its port settings do not identify it as DNS server. Remediation steps may include checking if Client1 is indeed a DNS server, and confirming whether zone transfer settings are configured properly on the source DNS server. As shown below, Windows can set the properties of the DNS zone to only allow zone transfers to specific servers.



Another type of reconnaissance activity is directory services enumeration. Security account manager remote protocol (SAMR) provides management functionality that is useful for manipulating an account database consisting of users, groups and other security principals. An attacker can potentially exploit this protocol to enumerate a list of accounts and groups as shown in the ATA alert below. In this case, client2 was used to run the commands “net user /domain” and “net group /domain” to discover the list of accounts/groups in the contoso.com domain. An investigation should include confirming whether running scanning tools is allowed from the computer in question, and whether the account itself is permitted to do so. It’s also important to investigate the source computer for unknown services or software that maybe initiating this process.



ATA raises the “Malicious replication of directory services” alert shown below when an attacker effectively “impersonates” a domain controller and requests account password data from the DC. Using third party tools, an attacker can discover the domain controllers in the environment and ask the domain controller to replicate the user credentials by leveraging the directory replication service (DRS) remote protocol. With the appropriate credentials, the attacker can pull password hashes from a DC over the network without ever interactively logging in to the DC. An investigation of this alert should confirm whether the source machine is a newly promoted domain controller or running replication tools such as Azure Active Directory Connect.



When it sees multiple Kerberos pre-authentication failed requests for a machine in a period of time, ATA detects a broken trust relationship, which means that group policy and security settings may not be applied to the computer.


When a computer is joined to the domain, a secure channel password is stored with the computer account on the domain controller. By default, this password is changed every 30 days. ATA may raise this alert when the secure channel password held by the computer does not match what is stored in AD. Before simply rejoining the computer to the domain, we can verify the issue remotely using the commandlet test-computersecurechannel as shown below.

Invoke-command -computer <broken trust computer name> -scriptblock {Test-computersecurechannel}



  1. How can I interact with ATA alerts programmatically?

There are multiple ways to address this. ATA logs all alerts to the Windows event log. To get a list of all suspicious activities generated today, we can use the PowerShell command below:

Get-winevent -Filterhashtable @{logname=’Microsoft ATA’; StartTime=(Get-Date).date.adddays(-7); EndTime=(get-date).date} | where-object {$_.ProviderName -eq ‘Suspicious Activity’} | fl


We can also pull a list of suspicious activities from the mongo database by running the command below from the mongoDB\bin folder on the ATA Center server:

Var mydate= Date();

Mongo ATA db.SuspiciousActivity.find({StartTime: myDate})


2.  How can we get a list of suspicious activities by user?

The below script will search for the id of a user alias and find all the related suspicious activities:

Mongo ATA

Var usrn = db.UniqueEntity.find({SamName: “UserAlias”}, {DisplayName: 1, _id: 1})

Db.SuspiciousActivity.find({SourceAccountId: usrn}, {StartTime: 1, TitleKey: 1, Status: 1})


3.  How can I bulk resolve some alerts?

The below script will find all alerts for Pass-the-Ticket and set status to resolved. You can run the script by placing it in a file and running mongo.exe ATA <file name> from the mongo\bin directory.


var SAType=”PassTheTicketSuspiciousActivity”;

SAs=db.SuspiciousActivity.find ({_t: SAType});

SAs.forEach(function(o) {

print (“Resolving SA with ID: “+o._id+” …”);

db.SuspiciousActivity.update( { _id: o._id } , {$set: {“Status” : “Resolved”} }) // Can be “Resolved”, “Dismissed” or “Open”



For questions or feedback contact me directly:

Shalini Pasupneti


Senior Program Manager

C+E Security CxP Team