Introduction to Microsoft Advanced Threat Analytics
Microsoft Advanced Threat Analytics (ATA) is an on-premises platform designed to detect advanced cyberattacks and insider threats targeting Active Directory environments. ATA analyzes network traffic from domain controllers, Windows event logs, and SIEM data to build a behavioral baseline for users, devices, and resources, then alerts when anomalous activity is detected. Although Microsoft has shifted its strategic focus toward the cloud-native Microsoft Defender for Identity (MDI), ATA remains deployed in many organizations that cannot yet move to cloud-connected solutions. This article covers ATA deployment on Windows Server 2022, its detection capabilities, health monitoring, and the migration path to Microsoft Defender for Identity.
ATA vs Microsoft Defender for Identity
Understanding the difference between ATA and MDI is important before committing to a deployment. ATA is fully on-premises: the ATA Center and ATA Gateways run on your own servers, data stays in your network, and there is no cloud dependency. MDI is a cloud-connected service where lightweight sensors are installed on domain controllers and data is sent to the Microsoft cloud for analysis. ATA reached end of support on January 12, 2021, meaning no new features are being developed and security patches are limited. MDI receives continuous updates including new detections for evolving attack techniques.
Key architectural differences:
Feature ATA MDI (Defender for Identity)
-----------------------------------------------------------------------------------
Deployment On-premises Cloud (Azure) + lightweight sensor
Database MongoDB (local) Microsoft cloud storage
Network analysis Port mirroring required Sensor reads directly on DC
Event log collection ATA Gateway/LWGW Sensor on DC
Lateral movement Detected Detected + enriched with cloud intel
Pass-the-Hash Detected Detected
Pass-the-Ticket Detected Detected
Golden Ticket Detected Detected
Cloud identity attacks Not supported Detected (Azure AD integration)
Active support End of life Current and actively developedATA Center System Requirements
Before installing ATA Center on Windows Server 2022, verify the following minimum requirements are met. Note that ATA was designed for Windows Server 2012 R2 through 2019, and Windows Server 2022 support is not officially documented by Microsoft — however, the installation typically succeeds and functions in practice for organizations maintaining existing deployments.
Component Minimum Recommended
---------------------------------------------------------------------
OS Windows Server 2012 R2 Windows Server 2016/2019
CPU 4 cores 8 cores
RAM 12 GB 96 GB (for large environments)
Storage (data) 100 GB Size based on ~1 KB/event/day
Storage (MongoDB) Fast SSD recommended NVMe SSD
.NET Framework 4.6.1 4.7.2
MongoDB Installed by ATA setup Version 3.6 (bundled)
NIC 1 Gbps 10 Gbps for high trafficThe ATA Center hosts the MongoDB database for storing learned behavior and alerts. For large environments (over 50,000 user objects), MongoDB performance becomes a limiting factor, which is one of the architectural reasons Microsoft moved to a cloud-hosted backend for MDI.
ATA Gateway vs ATA Lightweight Gateway
ATA provides two gateway types. The ATA Gateway is a dedicated server that receives domain controller traffic via port mirroring (SPAN or network TAP). The ATA Lightweight Gateway (LWGW) runs directly on the domain controller itself, eliminating the need for port mirroring but consuming resources on the DC. For Windows Server 2022 domain controllers, the Lightweight Gateway is strongly preferred.
ATA Gateway (dedicated server):
- Requires port mirroring configured on the switch or hypervisor
- Domain controller does not need to be modified
- Suitable when DCs cannot run additional software
- Traffic is copied to the gateway NIC via SPAN port
ATA Lightweight Gateway (on DC):
- Installed directly on the domain controller
- No port mirroring required
- Reads NDIS from the local NIC
- Resource overhead: ~5-10% CPU at peak, ~6 GB RAM reserved
- Supports automatic updates from ATA CenterConfiguring Port Mirroring for ATA Gateway
If using the ATA Gateway (not Lightweight), port mirroring must be configured so that all DC traffic is copied to the ATA Gateway NIC. Configuration varies by infrastructure:
For a VMware environment, configure the dvSwitch port mirror policy on the distributed virtual switch:
# On VMware vCenter, configure port mirroring via dvSwitch:
# Networking > Distributed Switch > Settings > Port Mirroring
# Add session: Encapsulated Remote Mirroring Source (L3)
# Source ports: domain controller vNIC port IDs
# Destination: ATA Gateway NIC port ID
# Verify traffic is arriving on the ATA Gateway capture NIC:
# The capture NIC should have no IP address assigned
# On ATA Gateway, run in elevated PowerShell:
Get-NetAdapter | Format-Table Name, Status, LinkSpeed, MacAddressFor physical switches (e.g., Cisco), configure a SPAN session:
! Cisco IOS SPAN configuration
monitor session 1 source interface GigabitEthernet0/1 both
monitor session 1 destination interface GigabitEthernet0/24 encapsulation replicateInstalling ATA Center
Download the ATA Center installer (Microsoft Advanced Threat Analytics 1.9.x) from the Microsoft Download Center. Run the installer as a local administrator:
# Silent installation of ATA Center (example)
Microsoft ATA Center Setup.exe /quiet NetFrameworkCommandLineArguments="/q" /l*v ata_install.log
# The setup installs:
# - MongoDB 3.6 (local database)
# - ATA Center service (Microsoft.Tri.Center.exe)
# - IIS-based management console (HTTPS on port 443 by default)
# - Self-signed certificate (replace with CA cert post-install)After installation, open the ATA management console at https://ATACenterServer/. During initial setup you will provide:
1. ATA Center URL (used by gateways to connect)
2. Certificate for the console (replace self-signed with CA cert)
3. Connect to Active Directory: provide a domain service account
- Account needs: Read access to all AD objects
- For event collection: local admin on DCs (for LWGW)
- Recommended: create a dedicated ATA service accountConfiguring the ATA MongoDB Database
ATA uses a bundled MongoDB 3.6 instance. For environments with more than 10,000 users or high event volume, MongoDB requires tuning. The MongoDB data directory defaults to C:Program FilesMicrosoft Advanced Threat AnalyticsCenterMongoDBbin. Move the data directory to a fast SSD volume if the default drive is slow:
# Stop ATA Center service
Stop-Service -Name ATACenter
# Move MongoDB data to D:ATAData
$mongoConfig = "C:Program FilesMicrosoft Advanced Threat AnalyticsCenterMongoDBbinmongod.cfg"
# Edit the dbPath in mongod.cfg:
# storage:
# dbPath: D:ATADataMongoDB
# Create the new directory
New-Item -ItemType Directory -Path "D:ATADataMongoDB" -Force
# Copy existing data
Copy-Item -Path "C:Program FilesMicrosoft Advanced Threat AnalyticsCenterMongoDBdata*" -Destination "D:ATADataMongoDB" -Recurse
# Start ATA Center
Start-Service -Name ATACenterTo check MongoDB status and database size:
# Connect to MongoDB shell (from ATA Center server)
cd "C:Program FilesMicrosoft Advanced Threat AnalyticsCenterMongoDBbin"
.mongo.exe --port 27017
# In MongoDB shell:
use ATA
db.stats()
db.collection.stats()ATA Detection Capabilities
ATA detects a wide range of attack techniques targeting Active Directory. Here is how each major detection works technically:
Pass-the-Hash (PtH): ATA detects NTLM authentication from a source where the hash was not obtained through an interactive logon on that device. It builds a map of legitimate NTLM usage patterns and alerts when an NTLM auth originates from an unusual source, particularly for privileged accounts.
Pass-the-Ticket (PtT): ATA analyzes Kerberos ticket traffic. When a Kerberos TGT or service ticket is used from a machine that did not originally receive it via a normal AS-REQ exchange, ATA flags this as a Pass-the-Ticket attempt. The detection relies on tracking ticket usage across the environment.
Golden Ticket: A Golden Ticket is a forged TGT signed with the krbtgt account hash. ATA detects these by identifying TGTs with abnormally long lifetimes (a Golden Ticket can be set to expire far in the future), TGTs with nonstandard encryption types, or TGTs used for services the account has never accessed before.
Reconnaissance: ATA detects DNS reconnaissance (bulk DNS queries), LDAP reconnaissance (unusual or bulk LDAP queries against AD), and network mapping (SMB session enumeration). The detection threshold is based on learned baselines for each entity.
ATA Detection Triggers (summary):
- Pass-the-Hash: Abnormal NTLM source detection
- Pass-the-Ticket: Kerberos ticket misuse
- Golden Ticket: Anomalous TGT attributes
- Overpass-the-Hash: NTLM > Kerberos upgrade from unusual source
- Skeleton Key: LSASS process injection detected via event logs
- Remote code execution: Suspicious remote WMI/PSExec/Scheduled Task
- Brute force: Multiple failed auth attempts
- Sensitive account exposure in clear-text auth (LDAP bind)ATA Health Alerts and Monitoring
ATA generates health alerts when components are not functioning correctly. These appear in the ATA console under the Health Center. Common health alerts and their remediation steps:
Alert: Gateway disconnected
Cause: ATA Gateway or LWGW cannot reach ATA Center
Fix: Check firewall rules for TCP 443 outbound from Gateway to Center
Verify ATA Center certificate is trusted by the Gateway
Alert: Some network traffic is not being analyzed
Cause: Port mirroring misconfigured (Gateway) or NIC saturation
Fix: Verify SPAN/mirror configuration; check gateway NIC utilization
Alert: Domain controller is not being monitored
Cause: LWGW not installed or stopped on that DC
Fix: Install or restart the LWGW service on the DC
Alert: MongoDB low disk space
Cause: Database volume running low
Fix: Reduce retention period in ATA settings or add storage
Alert: Windows events not being collected
Cause: WEF subscription failed or WMI connectivity issue
Fix: Verify service account permissions; check WEF if configuredCheck the ATA service logs on the Center server at:
C:Program FilesMicrosoft Advanced Threat AnalyticsCenterLogsMigrating from ATA to Microsoft Defender for Identity
Microsoft provides a migration guide from ATA to MDI. The core steps are:
Step 1: License MDI
- Requires Microsoft 365 E5, EMS E5, or MDI standalone license
- Assign licenses in Microsoft 365 admin center
Step 2: Create MDI instance
- Navigate to https://security.microsoft.com
- Go to Settings > Identities > Sensors
- Create the MDI workspace (tied to your Azure AD tenant)
Step 3: Install MDI sensor on domain controllers
- Download sensor from MDI portal
- Sensor requires: .NET 4.7.2, 6 GB RAM reserved, outbound HTTPS to *.atp.azure.com
- Install on each DC:
Azure ATP Sensor Setup.exe /quiet NetFrameworkCommandLineArguments="/q" AccessKey="YOUR_ACCESS_KEY"
Step 4: Configure Directory Service account
- Create a gMSA or standard account for MDI to use
- Grant "Read all" on the domain
Step 5: Validate sensor communication
- In MDI portal, verify all sensors show "Running"
- Check for any health issues
Step 6: Decommission ATA
- Once MDI is fully operational and you are satisfied with coverage,
uninstall ATA Gateways from DCs and the ATA Center from its serverMDI prerequisites include outbound HTTPS connectivity on port 443 from each domain controller to the MDI cloud endpoint. If your DCs cannot reach the internet directly, configure a proxy server in the MDI sensor settings. This is the primary blocker for organizations that maintain air-gapped or heavily firewalled DC environments.
ATA Reports and Forensic Investigation
ATA generates several built-in reports accessible from the Reports menu in the ATA console. These reports include summaries of sensitive groups modifications, plain-text password exposure events, lateral movement paths, and a full timeline of suspicious activities. For active incident investigation, the ATA Attack Timeline provides a chronological view of all detections, each with entity profiles showing the involved users, computers, and resources. Export investigation data from the ATA console for integration with a SIEM or ticketing system using the ATA SIEM integration (syslog or CEF format) configured under Configuration > Notifications and Reports.
