Nine 'Attackers' Intercepting Our TLS Pins Turned Out to Be Google

After an outage caused by ACM's certificate rotation breaking leaf-level pinning, a mobile team rebuilt its pinning strategy around the root CAs and added a remotely toggleable report-only mode. Two days after enabling it, Sentry logged 74 SPKI mismatch events, all from a single device, showing certificate hashes that matched neither the app's real leaf, intermediate, nor root — clear evidence that something was terminating and re-signing TLS traffic in the middle.

The initial instinct was to treat this as harmless interception from corporate proxies or antivirus software and patch it with a backup pin. But questioning the assumption revealed the backup pin would change nothing: the probe code only compares pins after OS trust-store validation succeeds, and these events were failing at that first step, before any pin check ran. Digging into the device fingerprint exposed further anomalies — an x86 architecture claiming to be an ARM phone, an impossible screen resolution, and a CPU reporting zero frequency. The nine 'users' were fabricated, all created on the same day, running three app versions in one session, with no city data — the signature of data-center traffic, not real devices.

Since Sentry strips IPs as PII, the team correlated Sentry event timestamps against production API access logs (User-Agent and X-Forwarded-For) retained in CloudWatch. Every matching IP across three separate time windows belonged to Google. The interception wasn't malicious — it was Google Play's routine automated app-scanning infrastructure, which instruments and re-signs traffic during analysis. The incident underscores the value of pinning root CAs over leaf certificates, building in remote kill switches, and validating assumptions with hard log evidence rather than plausible-sounding reasoning.