Fingerprinting Microsoft Defender for Identity Through Autodiscover: A Reconnaissance Deep-Dive

Hook

Before an attacker sends a single phishing email, they already know whether you're running Microsoft Defender for Identity. No login required, no exploitation needed—just public Microsoft infrastructure doing exactly what it was designed to do.

Context

Microsoft 365's autodiscover service exists to make life easier for legitimate users, automatically configuring email clients and discovering service endpoints without manual intervention. But this convenience comes at a cost: these same discovery mechanisms leak information about your security posture to anyone who asks.

Microsoft Defender for Identity (formerly Azure ATP) is Microsoft's behavioral analytics and threat detection solution for on-premises Active Directory environments. Organizations invest significantly in MDI deployments, hoping the advanced threat detection will catch sophisticated attacks. But here's the paradox: attackers can fingerprint whether you've deployed MDI before they ever touch your network. This reconnaissance capability fundamentally changes how red teams and threat actors approach target organizations. Knowing whether MDI is deployed allows attackers to adjust tactics, techniques, and procedures (TTPs) to avoid behavioral analytics or, conversely, to deprioritize targets with robust detection capabilities. The microsoft-defender-for-identity-check-instance repository, created by security researcher Thalpius, demonstrates exactly how this unauthenticated reconnaissance works, turning Microsoft's own service discovery infrastructure into an intelligence-gathering tool.

Technical Insight

The reconnaissance flow chains three publicly accessible Microsoft endpoints to build a complete picture of an organization's MDI deployment. First, the script queries the autodiscover service at https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc with a target email domain. This endpoint, designed to help email clients find their configuration, responds with all accepted domains for that Microsoft 365 tenant—including custom domains, initial onmicrosoft.com domains, and mail-enabled domain variations.

Once armed with the tenant's domains, the script extracts the tenant identifier (the portion before .onmicrosoft.com in the primary tenant domain). This identifier becomes the key to querying MDI-specific endpoints. The critical insight here is that Microsoft Defender for Identity instances follow a predictable naming convention: {tenantname}.atp.azure.com. The script simply constructs this URL and attempts to resolve it.

Here's the core detection logic from the repository:

# After obtaining tenant name from autodiscover
$MDIUrl = "https://$TenantName.atp.azure.com"

try {
    $Response = Invoke-WebRequest -Uri $MDIUrl -Method Head -UseBasicParsing -ErrorAction Stop
    if ($Response.StatusCode -eq 200) {
        Write-Host "[+] Microsoft Defender for Identity instance found: $MDIUrl" -ForegroundColor Green
        return $true
    }
} catch {
    if ($_.Exception.Response.StatusCode.Value__ -eq 404) {
        Write-Host "[-] No MDI instance found" -ForegroundColor Yellow
        return $false
    }
}

The elegance lies in what Microsoft's infrastructure reveals through HTTP status codes. A 200 OK response indicates an active MDI instance—the endpoint exists and responds. A 404 Not Found means no MDI deployment. A 401 Unauthorized would actually confirm existence (the endpoint exists but requires authentication). The script never needs credentials; it's simply asking Microsoft's DNS and web servers whether these services exist.

The autodiscover query itself deserves closer examination. The script constructs a SOAP envelope targeting a specific email address:

$AutodiscoverBody = @"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <GetFederationInformationRequest xmlns="http://schemas.microsoft.com/exchange/2010/Autodiscover">
      <Domain>$Domain</Domain>
    </GetFederationInformationRequest>
  </soap:Body>
</soap:Envelope>
"@

$Response = Invoke-WebRequest -Uri "https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc" `
    -Method Post `
    -Body $AutodiscoverBody `
    -ContentType "text/xml; charset=utf-8"

This GetFederationInformationRequest was designed for federated authentication scenarios, but it conveniently returns all accepted domains for the tenant. Microsoft intended this for legitimate service discovery, but from a reconnaissance perspective, it's a comprehensive domain enumeration endpoint that requires zero authentication. The XML response includes domains that might not be publicly documented, revealing the full scope of a tenant's Microsoft 365 footprint.

The architectural decision to use PowerShell's Invoke-WebRequest with -UseBasicParsing is noteworthy—it avoids dependencies on Internet Explorer's DOM parser, making the script more portable across Windows Server Core installations and environments where IE isn't configured. The -Method Head request minimizes bandwidth and log footprint when checking for MDI instances, though it still generates logs in Microsoft's infrastructure.

From a defensive perspective, understanding this reconnaissance technique reveals a broader truth about cloud service architectures: service discovery mechanisms inherently leak configuration details. Microsoft could make these endpoints authentication-required, but that would break legitimate autodiscover functionality for millions of users. The tension between usability and information disclosure is resolved in favor of usability, leaving this reconnaissance vector intact.

Gotcha

The most significant limitation is invisible until you actually use this tool in production: Microsoft absolutely logs these queries, and mature security operations centers may alert on repeated autodiscover enumeration attempts from single IP addresses. While the script itself is "passive" in the sense that it doesn't exploit vulnerabilities, it generates telemetry on Microsoft's side. If you're conducting authorized red team operations, these requests may tip off blue team members who monitor Microsoft 365 sign-in logs and tenant activity. The reconnaissance isn't as stealthy as you might assume from the "unauthenticated" description.

The repository's archived status presents another practical concern. Microsoft periodically adjusts their service discovery infrastructure, authentication requirements, and endpoint URLs. When Microsoft renamed Azure ATP to Microsoft Defender for Identity, the underlying atp.azure.com subdomain remained, but there's no guarantee this convention persists indefinitely. The script checks for atp.azure.com specifically, but Microsoft's product rebranding cycles and infrastructure migrations could render this detection logic obsolete. Without active maintenance, you're adopting code that may silently fail as Microsoft's infrastructure evolves. The last commit was before several significant Microsoft 365 security updates, meaning newer tenant configurations or conditional access policies might behave differently than when this tool was developed.

Verdict

Use if you're conducting external reconnaissance during authorized red team engagements and need to quickly fingerprint whether targets have deployed Microsoft Defender for Identity before investing in more intrusive techniques. This tool excels in purple team exercises where you want to demonstrate to stakeholders exactly what information leaks from their Microsoft 365 tenant without authentication—it's an excellent conversation starter about cloud service discovery risks. Also valuable for security researchers building threat intelligence profiles on organizations or for defenders who want to understand their own external attack surface from an adversary's perspective. Skip if you need an actively maintained tool that will keep pace with Microsoft's infrastructure changes, if you're operating in environments where reconnaissance activity is closely monitored (the logs this generates may burn your operation), or if you need comprehensive Microsoft 365 security posture assessment beyond just MDI detection. Given the archived status, treat this as a proof-of-concept and reference implementation rather than production tooling—you'll likely need to fork and maintain it yourself if Microsoft changes their endpoint structure. For ongoing reconnaissance needs, invest in broader frameworks like AADInternals or ROADtools that have active development communities.