Android 17 OS-Wide ECH Rollout: What Encrypted Client Hello Means for SOC Visibility and How to Adapt Your Defenses

Google announced on Thursday that Android 17 will ship with a slate of new network security protections, headlined by operating-system-wide support for Encrypted Client Hello (ECH) — a TLS privacy standard that encrypts the Server Name Indication (SNI) field in the TLS handshake. In plain terms: once ECH is active, anyone passively observing network traffic — the cellular carrier, the ISP, the coffee-shop Wi-Fi operator — can no longer see which websites a user is visiting. They see a connection to a CDN or cloud front-end, nothing more.

This is a genuine win for user privacy, and it's paired with protections against cellular network vulnerabilities and safeguards for home network privacy. But I want to be direct with the defense side of the house: the same mechanism that blinds an eavesdropping carrier also blinds your security stack. SNI-based egress filtering, passive DNS-to-domain correlation, TLS fingerprinting pipelines, domain-category web filtering on network appliances, and a large chunk of threat intel matching done at the proxy layer all depend on cleartext SNI. OS-wide ECH on the fastest-growing mobile platform accelerates a visibility erosion that Chrome and Firefox already started at the browser level.

If your detection engineering assumes you can see destination domains on the wire, 2026 is the year that assumption breaks at scale. This post covers what ECH actually does, what visibility you lose, what you keep, and the concrete steps — policy, DNS architecture, and detection adjustments — to maintain defensible visibility on managed fleets without fighting the privacy standard itself.

Technical Analysis

What ECH Changes in the TLS Handshake

In a conventional TLS 1.3 handshake, the client's ClientHello carries the target hostname in cleartext via the SNI extension. Every middlebox — ISP DPI, carrier NAT logging, your firewall, your Zeek sensor — reads it. ECH (standardized in the IETF TLS working group, built on the encrypted_client_hello extension) splits the ClientHello into an outer hello containing only a benign "public name" (typically the CDN's ECH-facing hostname, e.g. cloudflare-ech.com) and an inner hello containing the real SNI, encrypted with the site's public ECH key.

The critical delivery mechanism defenders must understand: the ECH public key is distributed through DNS HTTPS (type 65) and SVCB resource records. A client resolves the domain, retrieves the ech= parameter from the HTTPS RR, and uses it to encrypt the inner ClientHello. This gives you two facts of operational significance:

1. ECH is DNS-gated. If your resolver strips or refuses HTTPS/SVCB records, ECH negotiation fails and clients fall back to cleartext SNI. This is the sanctioned enterprise control point — Chrome's own enterprise policy documentation acknowledges it.
2. ECH depends on encrypted transport only for key confidentiality, not reachability. Blocking DoH/DoT to public resolvers keeps DNS — and therefore ECH key distribution — inside infrastructure you control.

Scope of the Android 17 Change

• Affected platform: Android 17 (all apps using the platform network stack; previously ECH was available only in specific browsers like Chrome). OS-wide support means WebViews, third-party apps, and embedded HTTP clients inherit ECH automatically.
• Companion protections: mitigations for cellular network vulnerabilities (long-standing SS7/Diameter and rogue base-station class weaknesses) and home-network privacy safeguards — details of which matter for mobile device fleet policy.
• Exploitation status: This is not a vulnerability announcement. There is no CVE, no PoC, no CISA KEV entry. The "threat" here is architectural: a structural loss of network-layer visibility for defenders who rely on SNI, plus an expanded channel for malware C2 to hide behind legitimate CDN fronting with encrypted SNI.

The Attacker's Perspective (So You Can Defend Against It)

Threat actors get the same benefit carriers lose: commodity malware and C2 frameworks hosted behind ECH-enabled CDN frontends will no longer leak destination domains via SNI. Domain fronting — which major CDNs curtailed years ago — effectively returns in a standardized, sanctioned form. Your defenders will increasingly see: TLS session → Cloudflare/Google/Fastly IP, ECH extension present, real hostname unrecoverable from passive capture. Blocking decisions must move to endpoint telemetry, DNS-layer control (before ECH keys are fetched), JA4/JA4+ fingerprinting, and egress IP intelligence.

Detection & Response

You cannot "detect ECH" as malicious — it's a legitimate privacy standard. What you can and should do is (a) inventory where ECH is appearing in your environment so you know where SNI visibility is silently disappearing, and (b) detect clients bypassing enterprise DNS to fetch ECH keys via public DoH/DoT, which in a managed environment is a policy violation worth investigating regardless of intent.

Sigma Rules

---
title: DNS HTTPS SVCB Record Query Indicating ECH Key Retrieval
id: 3f8a1c42-7b5d-4e9a-b2f1-9c6d0e8a4b21
status: experimental
description: Detects DNS queries for HTTPS (type 65) or SVCB (type 64) resource records, which are used to distribute ECH configuration keys. Useful for inventorying where ECH negotiation is being attempted and for identifying unmanaged clients attempting ECH on networks where it is administratively disabled.
references:
  - https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
  - https://thehackernews.com/2026/08/android-17-adds-os-wide-ech-to-hide.html
author: Security Arsenal
date: 2026/08/14
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: dns
  product: windows
detection:
  selection:
    record_type:
      - 'HTTPS'
      - 'SVCB'
      - '65'
      - '64'
falsepositives:
  - Legitimate ECH adoption by modern browsers and Android 17 devices — this rule is for visibility inventory and policy enforcement, not maliciousness
level: low
---
title: Direct Encrypted DNS Connection to Public Resolver Bypassing Enterprise DNS
id: 9d2e7b15-4c8a-4f3d-a1e6-5b0c9d2e7f38
status: experimental
description: Detects outbound connections to DNS-over-TLS port 853 or known public DoH resolver IP addresses from endpoints other than designated DNS infrastructure. In managed environments, direct encrypted DNS bypasses enterprise resolution policy and enables unsanctioned retrieval of ECH keys.
references:
  - https://attack.mitre.org/techniques/T1071/004/
  - https://thehackernews.com/2026/08/android-17-adds-os-wide-ech-to-hide.html
author: Security Arsenal
date: 2026/08/14
tags:
  - attack.command_and_control
  - attack.t1071.004
  - attack.defense_evasion
  - attack.t1568
logsource:
  category: network_connection
  product: windows
detection:
  selection_dot:
    DestinationPort: 853
  selection_doh_ip:
    DestinationPort: 443
    DestinationIp:
      - '1.1.1.1'
      - '1.0.0.1'
      - '8.8.8.8'
      - '8.8.4.4'
      - '9.9.9.9'
      - '149.112.112.112'
  condition: selection_dot or selection_doh_ip
falsepositives:
  - Designated internal DNS forwarders performing upstream DoT/DoH — exclude resolver infrastructure by source IP
  - Mobile devices on guest/cellular segments outside enterprise DNS control
level: medium

Tune both rules against your environment: the HTTPS/SVCB rule is intentionally low — its value is trending over time ("how fast is ECH reaching our wire?"), not per-event alerting.

KQL — Microsoft Sentinel / Defender

This query hunts for clients fetching ECH configuration via HTTPS DNS records and for encrypted-DNS bypass of enterprise resolvers, using Defender endpoint telemetry and ingested firewall/syslog data:

// Hunt: ECH key retrieval via HTTPS/SVCB DNS records + encrypted DNS bypass of enterprise resolvers
let DesignatedResolvers = dynamic(["10.0.0.53", "10.0.1.53"]); // <-- replace with your DNS infra
let PublicDoH = dynamic(["1.1.1.1","1.0.0.1","8.8.8.8","8.8.4.4","9.9.9.9","149.112.112.112"]);
union isfuzzy=true
    (DeviceEvents
    | where ActionType == "DnsQueryResponse"
    | extend AdditionalFields = todynamic(AdditionalFields)
    | where tostring(AdditionalFields.DnsQueryType) in ("HTTPS", "SVCB", "65", "64")
    | summarize QueryCount = count(), Domains = make_set(tostring(AdditionalFields.DnsQueryString), 50)
        by DeviceName, RemoteIP, bin(TimeGenerated, 1h)
    | extend HuntSignal = "ECH HTTPS/SVCB record query"),
    (DeviceNetworkEvents
    | where TimeGenerated > ago(24h)
    | where RemotePort == 853 or (RemotePort == 443 and RemoteIP in (PublicDoH))
    | where not(IPv4Lookup matches) // placeholder: filter designated resolvers below
    | where LocalIP !in (DesignatedResolvers)
    | summarize ConnCount = count(), RemoteDests = make_set(RemoteIP, 25)
        by DeviceName, InitiatingProcessFileName, bin(TimeGenerated, 1h)
    | extend HuntSignal = "Encrypted DNS bypass of enterprise resolver")
| project TimeGenerated, HuntSignal, DeviceName, RemoteIP, InitiatingProcessFileName, QueryCount, ConnCount, Domains, RemoteDests
| order by TimeGenerated desc

If you ingest Zeek or Suricata via CEF/Syslog into Sentinel, add a second hunt for TLS handshakes carrying the ECH extension — Zeek's SSL log flags this, and a rising ECH ratio on your perimeter is a direct measurement of your SNI-visibility decay:

// Zeek/Suricata (CEF ingestion): track ECH-enabled TLS handshakes and SNI-visibility loss over time
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DeviceVendor in ("Zeek", "Suricata", "Corelight")
| extend Ext = todynamic(AdditionalExtensions)
| where tostring(Ext) has "encrypted_client_hello" or tostring(Ext) has "ech"
| summarize ECHSessions = count(), UniqueDests = dcount(DestinationIP) by bin(TimeGenerated, 1d), DeviceProduct
| order by TimeGenerated asc

Velociraptor VQL

Velociraptor doesn't run on Android, but your Windows/macOS fleet has the identical ECH-visibility problem via Chrome/Firefox. This artifact inventories endpoints making direct encrypted-DNS connections to public resolvers — the policy-violation side of the ECH equation:

-- Hunt: endpoints with active connections to public DoH/DoT resolvers (enterprise DNS bypass)
LET public_dns = ('1.1.1.1', '1.0.0.1', '8.8.8.8', '8.8.4.4', '9.9.9.9', '149.112.112.112')
SELECT Pid, Name, Ppid, Username, CommandLine,
       netstat().LocalIP AS LocalIP,
       netstat().RemoteIP AS RemoteIP,
       netstat().RemotePort AS RemotePort,
       netstat().Status AS ConnStatus
FROM pslist()
WHERE (netstat().RemotePort = 853
    OR (netstat().RemotePort = 443 AND netstat().RemoteIP in public_dns))
  AND ConnStatus = 'ESTABLISHED'

Hardening / Verification Script

Two tasks matter operationally: verifying whether your controlled DNS infrastructure strips ECH keys (the sanctioned enterprise control), and enforcing browser policy on managed Windows endpoints. Note the deliberate scope: this is for corporate-managed devices on corporate networks — do not deploy ECH suppression on BYOD or user-privacy contexts.

#!/usr/bin/env bash
# verify_ech_dns_policy.sh — confirm whether resolvers return HTTPS/SVCB (ECH key) records
# Run against each resolver your clients use. If ECH is administratively disabled,
# these queries should return NODATA/REFUSED for type65.
set -euo pipefail

RESOLVERS=("10.0.0.53" "10.0.1.53")   # <-- your managed resolvers
TEST_DOMAINS=("cloudflare-ech.com" "www.cloudflare.com" "www.google.com")

echo "=== ECH DNS Policy Verification ==="
for r in "${RESOLVERS[@]}"; do
  echo "--- Resolver: ${r} ---"
  for d in "${TEST_DOMAINS[@]}"; do
    answer=$(dig @"${r}" +short -t TYPE65 "${d}" 2>/dev/null || true)
    if [[ -n "${answer}" ]]; then
      if echo "${answer}" | grep -q "ech="; then
        echo "[ECH-ENABLED]  ${d} via ${r}: ${answer}"
      else
        echo "[HTTPS-RR]     ${d} via ${r}: record present, no ECH key"
      fi
    else
      echo "[STRIPPED]     ${d} via ${r}: no HTTPS/SVCB record (ECH negotiation will fail -> cleartext SNI fallback)"
    fi
  done
done

echo
echo "=== Client-side DoH reachability spot check (should FAIL on managed segments) ==="
for ip in 1.1.1.1 8.8.8.8 9.9.9.9; do
  if timeout 3 bash -c "</dev/tcp/${ip}/853" 2>/dev/null; then
    echo "[EXPOSED] DoT reachable: ${ip}:853 — egress policy gap"
  else
    echo "[BLOCKED] DoT blocked: ${ip}:853"
  fi
done

# Set-ECHBrowserPolicy.ps1 — enforce ECH policy on MANAGED Windows endpoints (corporate devices only)
# Chrome and Edge expose an enterprise policy to disable ECH where TLS inspection is contractually required.
#Requires -RunAsAdministrator

$policies = @(
    @{ Path = 'HKLM:\\\*software\\Policies\\Google\\Chrome';            Name = 'EncryptedClientHelloEnabled' },
    @{ Path = 'HKLM:\\SOFTWARE\\Policies\\Microsoft\\Edge';             Name = 'EncryptedClientHelloEnabled' }
)
foreach ($p in $policies) {
    if (-not (Test-Path $p.Path)) { New-Item -Path $p.Path -Force | Out-Null }
    Set-ItemProperty -Path $p.Path -Name $p.Name -Value 0 -Type DWord
    $current = (Get-ItemProperty -Path $p.Path -Name $p.Name).($p.Name)
    Write-Host "[$($p.Path)] $($p.Name) = $current (0 = ECH disabled via policy)"
}

# Verify corporate DNS strips HTTPS/SVCB records (sanctioned ECH control point)
$testDomain = 'cloudflare-ech.com'
$type65 = Resolve-DnsName -Name $testDomain -Type UNKNOWN -ErrorAction SilentlyContinue
Write-Host "\nManual check: dig -t TYPE65 $testDomain against your resolver — expect no 'ech=' parameter if ECH suppression is intended."
Write-Host "Reminder: apply ONLY to managed devices under your organization's acceptable-use policy."

Remediation

There is nothing to patch — but there is real architecture work. Prioritized actions for security teams:

1. Decide your ECH posture per segment, in writing. Managed corporate devices behind TLS inspection: ECH suppression via DNS HTTPS/SVCB filtering plus browser enterprise policy (EncryptedClientHelloEnabled=0) is the vendor-sanctioned path. BYOD and privacy-sensitive segments: accept ECH and compensate elsewhere. Do not silently let the decision make itself as Android 17 and desktop browsers roll out on their own schedules.
2. Fix egress DNS control first. Block outbound TCP/UDP 853 and UDP 443 (QUIC) from client segments to non-approved destinations, and block known public DoH resolver IPs. ECH key retrieval rides DNS — if clients can reach public encrypted resolvers, your HTTPS-RR filtering is decorative.
3. Rebase detection content off SNI. Audit your SIEM rules, proxy categories, and threat-intel matching for SNI/ServerName dependencies. Replace with: DNS-resolution correlation (pre-ECH, you still see the lookup on your resolver), JA4/JA4+ TLS client fingerprinting, destination IP/ASN intelligence, and — most importantly — endpoint telemetry (EDR process/network events carry the real destination domain from the process context, which no amount of TLS encryption hides from the endpoint).
4. Brief your web-filtering and DLP owners. Appliances doing domain categorization via SNI will degrade unevenly (ECH sites silently fall into "uncategorized"). Get vendor roadmaps now; most enterprise proxy vendors are shipping ECH-aware policy options in 2026.
5. Measure the drift. Deploy the trending KQL above. The percentage of ECH handshakes on your perimeter is a KPI for your network-visibility roadmap — report it to the CISO quarterly.
6. Mobile fleet: For corporate-owned Android 17 devices, review the accompanying cellular and home-network protections with your MDM team — Android Enterprise work-profile policies remain your enforcement layer regardless of OS-level privacy features.

The strategic takeaway: ECH is not an adversary to defeat — it's a standard that correctly assumes the network is hostile. The defensive response is to shift trust and telemetry to layers you legitimately control: the endpoint, the managed resolver, and explicit policy. Organizations that planned for the encrypted-hello era two years ago will barely notice Android 17. Everyone else should start that work this quarter.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub