When DKIM, SPF and DMARC Are Not Enough: Analysis of an AiTM Platform Abusing Google Infrastructure

Table of contents

1. Starting point: header analysis
2. The mechanism: source code analysis
3. First pivot: URLScan and the cluster
4. Second pivot: comparative forensic analysis
5. Third pivot: the real IP 45[.]92[.]1[.]158
6. Fourth pivot: Certificate Transparency (crt.sh)
7. Documented timeline
8. Open questions
9. Actionable IOCs
   • C2 domains · Real server IP · C2 paths · Google Sites lure pages · CF Tunnels · Fingerprint · Email IOCs · Infrastructure nexus
10. TTPs — MITRE ATT&CK
11. Why DKIM/SPF/DMARC are not enough
12. Updates
    • 2026-05-30 · third email · 2026-05-31 · C2 analysis · 2026-05-31 · infrastructure · 2026-06-04 · infrastructure suspended · 2026-06-09 · independent re-verification · 2026-07-04 · calibration note · 2026-08-21 · field re-verification · 2026-08-22 · YARA rule v6
13. Appendix: IOCs (plain text)

On May 29th I received an email from security-noreply@google.com. DKIM valid. SPF valid. DMARC valid. I decided to analyze it.

What started as a personal incident became a threat intelligence exercise that documented active infrastructure, two abuse vectors targeting Google services, and an operation with at least six months of confirmed activity — with associated infrastructure dating to at least 2023.

Starting point: header analysis

The email arrived on 2026-05-29 with this subject:

“Re: Account recovery initiated. Wasn’t you? Secure your account: sites[.]google[.]com/view/G-733828”

Other subjects injected through the same vector with the same C2 have been documented: “Re: Verification code from Google: A new sign-in from Miami, Florida - G-733828”. The variation in wording suggests the attacker is testing different pretexts or using multiple templates depending on the target. The injection mechanism is identical in all cases.

The authentication was flawless:

From:   security-noreply@google.com
IP:     209.85.220.69  (mail-sor-f69.google.com)
DKIM:   pass  →  header.i=@google.com
SPF:    pass  →  authorized sender
DMARC:  pass  →  p=REJECT
App-ID: s~google.com:roach-hotel

The email originated from legitimate Google infrastructure. The header X-Google-Appengine-App-Id: roach-hotel corresponds to an internal Google App Engine system that, by my reading, handles the account-notification auto-reply (the exact function of this app-id is not publicly documented). My hypothesis: someone triggered an Account Recovery flow and injected the URL into a field that the roach-hotel system reflects unsanitized in the auto-reply subject. The exact injection mechanism is unconfirmed: which specific field allows it and how it is triggered remains one of the open questions of this investigation.

The previous day a second email had arrived, also from @google.com, this time from Google Workspace via Marketo. Same pattern: text injected into a free-text field of a contact form, included verbatim in the auto-reply:

From:  Google Workspace <workspace@google.com>
Via:   Marketo (oak.mktdns.com, 199.15.214.195)
DKIM/SPF/DMARC: PASS
Injected text:
  "We noticed a new sign-in from Miami, Florida [...]
   secure your account: sites[.]google[.]com/view/g-733828"

Open and click tracking appears disabled (X-MSYS-API: open_tracking:false, click_tracking:false). Attribution here needs care: X-MSYS-API and X-MSFBL are SparkPost/Momentum headers (the MTA Marketo runs underneath), and those options are set by the sending platform’s template (Google’s), not by whoever fills out a contact form. Many transactional and auto-reply templates disable tracking by default, so this flag cannot be confidently attributed to a deliberate attacker action. I record it as an observation, not a confirmed evasion technique.

Two different vectors, same URL, 25 hours apart. Valid DKIM/SPF/DMARC on both.

On 2026-05-30, the same day this analysis was published, a third email arrived through the same Marketo vector: same C2 G-733828, same Marketo account 808-GJW-314, same open_tracking:false. The campaign was still active at the time of publication. The analysis is documented in the Updates section.

The mechanism: source code analysis

The URL pointed to sites[.]google[.]com/view/G-733828. HTML analysis revealed this block in the data-code field of the Google Sites embed:

<iframe
  src="hxxps://123753243[.]com/v3/identity/login"
  allow="clipboard-read; clipboard-write;"
  width="100%" height="100vh" border="none">
</iframe>

Google Sites used as a transparent proxy. The iframe covers the full screen with no borders. The allow attribute grants clipboard access — a non-trivial permission: a login page has no legitimate reason to read or write the clipboard unless the intent is to pre-populate the victim’s email from a previously obtained value, or to silently capture anything copied during the session. The path /v3/signin/identifier it redirects to mimics Google’s OAuth flow. The title of another page in the cluster confirms it: "Google - Sign in".

First pivot: URLScan and the cluster

A URLScan search on 123753243[.]com and Google Sites pages with title “Sign in” returned a consistent pattern of six pages. The question was whether they shared infrastructure or just the URL pattern. I retrieved the source of each and ran the comparison.

Second pivot: comparative forensic analysis

Two identifiers are identical across all six analyzed files:

productName: 6b8ce7c01e3dacd3d2c7a8cd322ff979
embed hash:  16cb204cf3a9d4d223a0a3fd8b0eec5d

The productName value is embedded in the Google Sites page metadata and appears to be a per-account or per-template identifier tied to the actor’s Google account. The embed hash is derived from the iframe configuration. Both are stable across the full cluster and are the most reliable hunting artifacts to search for additional pages not yet discovered.

C2s confirmed from source code:

G-733828, g-798225, g-624594  →  123753243[.]com
                                  registered 2026-05-23 (NICENIC, IANA 3765, HK)

case-159331                   →  view-requests[.]com
                                  registered 2026-03-14 (NICENIC, IANA 3765, HK)

ticket-179902, ticket-925681  →  Cloudflare Tunnels (ephemeral, historical)
                                  aimed-activities-erik-magnetic[.]trycloudflare[.]com
                                  nursing-nominations-spirituality-origin[.]trycloudflare[.]com

Same registrar for both registered C2 domains. The earliest indexed entry corresponds to ticket-925681, in December 2025.

Third pivot: the real IP 45[.]92[.]1[.]158

Calibration note (added 2026-07-04). The “real IP” heading should be read with caution. The 2026-06-09 re-verification (see Updates) suggests 45[.]92[.]1[.]158 is likely a shared Yandex Cloud layer (edge / anti-bot / balancer), not necessarily a dedicated server owned by the actor. The original analysis is kept below with the affected points flagged inline.

123753243[.]com resolves to Cloudflare anycast. Not actionable at the IP level. view-requests[.]com resolves directly to 45[.]92[.]1[.]158.

IP:      45[.]92[.]1[.]158
Country: Netherlands (Lelystad, Flevoland) — IP block geolocation
ASN:     AS210558
Owner:   1337 Services GmbH (org. registered in Hamburg, DE)
Announced prefixes: 25 global /24 ranges

Direct access confirmed: port 80 rejects TCP. Port 443 accepts and returns HTTP 406 Not Acceptable in 270ms. The server responds directly, not only through Cloudflare. Censys also reports port 22 (SSH) open on the IP; I initially read this as a dedicated server under direct actor management, but the 2026-06-09 re-verification leaves it unconfirmed (if the IP is shared Yandex edge, port 22 could belong to another host in the block or be stale collection data). The HTTP response includes headers that are not from 1337 Services GmbH:

x-yandex-req-id: ...-balancer-l7leveler-kubr-yp-klg-65-BAL
set-cookie: _yasc=... (Yandex anti-scraping)
set-cookie: bh=...   (Yandex session)

yp-klg is the Yandex Platform identifier for Kaliningrad. The -balancer-l7leveler- pattern corresponds to Yandex Cloud’s L7 balancer. The server responds with Yandex Cloud L7 balancer headers, indicating the traffic transits Yandex infrastructure — whether as a direct Yandex Cloud IaaS tenant (with 1337 Services GmbH as network transit) or as a reverse proxy layer in front of a dedicated server remains unresolved. Either way, this is a layer of infrastructure not visible in passive DNS analysis.

The 406 without Cloudflare headers (CF-Connecting-IP, CF-Ray) indicates the server actively validates traffic origin: it filters by headers, not by source IP.

OTX passive DNS shows view-requests[.]com pointing to this IP from the day after its registration (2026-03-15) through 2026-04-24. The same IP has an OTX record from 2023 (Internet Storm Center IOCs). Automated ISC collection activity, with no specific attribution to this campaign.

The nameservers of each C2 domain are distinct pairs. Cloudflare assigns an NS pair per zone from a pool; two domains using different pairs is consistent with distinct accounts, though it is not conclusive proof:

dig NS 123753243[.]com    → gabe.ns.cloudflare.com / lorna.ns.cloudflare.com
dig NS view-requests[.]com → thea.ns.cloudflare.com / yew.ns.cloudflare.com

Indication of infrastructure separation between domains.

Fourth pivot: Certificate Transparency (crt.sh)

CT log analysis adds two relevant data points on infrastructure and activity.

The cert for 123753243[.]com appears in CT logs at 22:26 UTC, 12 minutes after RDAP registration (22:14 UTC). In that same window, Cloudflare Universal SSL (Sectigo DV E36) and the origin cert (Let’s Encrypt E8) are both provisioned. Full infrastructure, from domain registration to two-layer TLS operational, in under 15 minutes. This points to automation.

Cloudflare Universal SSL certs (Sectigo/GTS) include wildcard by default for all their customers, so that reveals nothing about the actor. What is relevant is something else: the origin Let’s Encrypt certs also cover *.123753243[.]com and *.view-requests[.]com. LE requires explicit validation to issue wildcards. The actor configured subdomains on the origin server, not only at the Cloudflare layer.

The dual-CA pattern confirms the Cloudflare architecture:

• 123753243[.]com: Sectigo DV E36 (Cloudflare Universal SSL) + Let’s Encrypt E8 (origin)
• view-requests[.]com: Google Trust Services WE1 (Cloudflare Universal SSL) + Let’s Encrypt E8 (origin)

Each domain uses the Cloudflare CA provider corresponding to its account, consistent with the distinct NS pairs (gabe/lorna vs thea/yew).

On April 21st, view-requests[.]com issued new certs with a wildcard added and the key rotated. That date matches exactly the modified field in RDAP. This confirms maintenance activity during those 155 days without visibility: the actor was not inactive, they were updating their C2.

Public keys are not shared between domains: the actor generates unique pairs per domain. No additional domains were identified through this vector.

Documented timeline

2023         45[.]92[.]1[.]158 appears in OTX (ISC IOCs — no specific attribution)
2025-12-02   ticket-925681 → CF Tunnel aimed-activities-erik-magnetic
             ← 155-day gap (no URLScan visibility) →
2026-03-14   Registration of view-requests[.]com (NICENIC) + LE E8 cert (same day)
2026-03-15   view-requests[.]com → 45[.]92[.]1[.]158 (OTX passive DNS)
2026-04-21   view-requests[.]com cert renewal: wildcard added, key rotated (RDAP: modified)
2026-05-06   case-159331 → view-requests[.]com → title: "Google - Sign in"
2026-05-23   Registration of 123753243[.]com (NICENIC) + full TLS in <15 min (CT logs)
2026-05-28   Email 1 — Google Workspace Marketo abuse (808-GJW-314)
2026-05-29   g-624594, g-798225, ticket-179902 active (g-184629: no recoverable data)
2026-05-29   Email 2 — Account Recovery auto-reply abuse (subj: "Account recovery initiated [...] sites[.]google[.]com/view/G-733828")
2026-05-30   Email 3 — Google Workspace Marketo abuse, same C2 G-733828, same 808-GJW-314
2026-05-31   C2 analysis: custom kit "gats" confirmed (shim.js), Kameleo, API /api/sessions
2026-05-31   view-requests[.]com: Cloudflare proxy disabled → domain abandoned as active C2
2026-05-31   URLScan 019dfe9e independently confirms case-159331→view-requests[.]com→45[.]92[.]1[.]158 (2026-05-06)
2026-05-31   LevelBlue classifies view-requests[.]com as phishing
2026-06-04   123753243[.]com → NXDOMAIN; RDAP: clientHold — NICENIC suspends the domain
             Abuse report sent 2026-05-30 took effect in under 96 hours
             view-requests[.]com still resolves to 45[.]92[.]1[.]158 (no clientHold yet)
             45[.]92[.]1[.]158 unchanged — AbuseIPDB score 0, identical Yandex Cloud response

Open questions

The 155-day gap without URLScan visibility does not imply inactivity, only lack of visibility. The registration of view-requests[.]com in March 2026, within that period, confirms the operation was still running.

The 25 hours between the first two emails is notable, but there is no evidence this is a deliberate sequential reinforcement strategy. It could simply be that the attacker launches both vectors in parallel against multiple targets.

The Account Recovery vector’s injection mechanism remains unconfirmed in detail. The subject of the auto-reply contains the malicious URL, confirming that the roach-hotel system reflects it without apparent sanitization. The specific field in the flow that allows this has not been reproduced. If you have documented this vector in another context, correlation data would be welcome.

The subjects of both documented vectors include the same geolocation: “A new sign-in from Miami, Florida”. Two readings are possible. First: the attacker’s Kameleo profile performing the real Google login uses an exit node in Miami, and Google automatically generates that geolocation in the notification that roach-hotel returns. Second: the target victim has login history from Miami, and the pretext is personalized. The first reading would imply Miami is a Kameleo infrastructure indicator; the second, victim profile information. Unconfirmed.

The administration panel implied by the _theme cookie has a login endpoint not exposed by shim.js. A targeted scan of 45[.]92[.]1[.]158 for common admin panel paths (/admin, /panel, /dashboard, /login) could reveal the panel URL and potentially its framework. This pivot was not attempted to avoid active interaction with live attacker infrastructure; it remains open for researchers with appropriate authorization context.

Actionable IOCs

C2 domains

Lookups — 123753243[.]com: VirusTotal · URLScan | view-requests[.]com: VirusTotal · crt.sh

Real server IP

45[.]92[.]1[.]158  →  AS210558  1337 Services GmbH  Lelystad, NL

Actionable with caveats: if this is a shared Yandex Cloud edge layer (see 2026-06-09 calibration), a direct block may over-block legitimate traffic. Port 443 active (HTTP 406 with Yandex headers); port 22 (SSH) reported by Censys but unconfirmed as the actor’s. 123753243[.]com resolves via Cloudflare anycast and is not actionable at the IP level.

Lookups: Shodan · VirusTotal · AbuseIPDB

Direct HTTP fingerprint (port 443):

HTTP 406 Not Acceptable
x-yandex-req-id: ...-balancer-l7leveler-kubr-yp-klg-65-BAL
set-cookie: _yasc=... (Yandex anti-scraping)
set-cookie: bh=...   (Yandex session token)

C2 paths

/v3/identity/login       ← main entry point
/v3/signin/identifier    ← simulated OAuth flow

Google Sites lure pages

URL pattern:  sites[.]google[.]com/view/(g|G|ticket|case|portal|verify)-[0-9]{6,7}  · widened 2026-08-21, see Updates

Confirmed instances:
  G-733828    →  123753243[.]com  (active as of 2026-05-30)
  g-798225    →  123753243[.]com
  g-624594    →  123753243[.]com
  case-159331 →  view-requests[.]com
  ticket-179902  →  CF Tunnel (inactive)
  ticket-925681  →  CF Tunnel (inactive, first entry Dec 2025)

Historical Cloudflare Tunnels (inactive)

aimed-activities-erik-magnetic[.]trycloudflare[.]com
nursing-nominations-spirituality-origin[.]trycloudflare[.]com

Cluster fingerprint (code similarity)

These two values are identical across all six HTML files in the cluster. Useful for correlating additional pages not yet discovered.

productName:  6b8ce7c01e3dacd3d2c7a8cd322ff979
embed hash:   16cb204cf3a9d4d223a0a3fd8b0eec5d

The AiTM framework itself (shim.js, the “gats” kit) is the most reusable C2 fingerprint. Hash of the preserved file (16,613 bytes):

shim.js  SHA256  9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e
         SHA1    8b74b60567160b1753059452406638d27dce2c0a
         MD5     7bbd1d7d485b6f6ebbeb28b469970670

Email IOCs

Important — distinguish attacker IOC from abused-platform identifier. Several of the values below (roach-hotel, 808-GJW-314, security-noreply@google.com, workspace@google.com, oak.mktdns.com) are identifiers of Google’s own legitimate infrastructure, not the attacker’s. Used alone as block rules they generate false positives against legitimate Google mail. The genuinely distinctive artifact is the injected URL (sites.google.com/view/(g|G|ticket|case|portal|verify)-[0-9]{6,7}) reflected in subject or body; the values below only add value combined with that pattern.

Useful for SEG/SIEM rules (with the caveat above). All emails from the Marketo vector share:

Return-Path pattern:  808-GJW-314.*@google.com
X-MarketoID pattern:  808-GJW-314:*
X-MSYS-API (evasion): {"options":{"open_tracking":false,"click_tracking":false}}
Via (relay):          oak.mktdns.com  [199.15.214.195]

Account Recovery vector:

X-Google-Appengine-App-Id:  s~google.com:roach-hotel
From:                        security-noreply@google.com
Source IP:                   209.85.220.0/24  (mail-sor-*.google.com)

Victim tracking alias pattern in recipient:

+api[0-9]+   (e.g. +api4020596)

The presence of this suffix in Delivered-To indicates the attacker filled the form with a custom alias to track the victim individually.

Infrastructure nexus

NICENIC INTERNATIONAL GROUP CO. LTD  —  IANA ID 3765  —  Hong Kong

Common registrar for both C2 domains. RDAP searches on recent NICENIC domains with numeric patterns or legitimate-looking names may reveal additional infrastructure from the same operation.

TTPs — MITRE ATT&CK

Documented evasion techniques:

• X-MSYS-API: open_tracking:false, click_tracking:false: Marketo/SparkPost tracking disabled on the emails. Not confirmed as a deliberate attacker action: these options are set by the sending platform’s template, not by whoever fills out the form (see note in the header section)
• Gmail alias +api[id] in the form recipient field: manual victim tracking that bypasses Marketo systems
• Deliberate infrastructure separation: two distinct Cloudflare accounts (gabe/lorna vs thea/yew) for the two registered C2 domains
• Header validation at the origin server (HTTP 406 without CF headers): the server rejects direct researcher access

Why DKIM/SPF/DMARC are not enough

These protocols verify that the email originated from the declared server. They do not verify that the sending system was not abused to include arbitrary content. A technically perfect email from @google.com can be an attack vector if the attacker finds a Google service that returns to the user text they themselves control.

What helps, and what would not have changed anything here:

• BIMI would not have changed anything. The sending domain was legitimate. Google’s verified mark would have appeared, reinforcing trust in a malicious email.
• Header inspection would not have changed anything either. All controls passed. The detection vector was in the subject URL, not in sender authentication.
• What does help: email gateways that inspect destination URL content rather than just headers, detection of Google Sites used as proxies on URL reputation platforms, and user training focused on distrusting the final destination rather than the sender, regardless of how legitimate the email appears.

Operation reported to Google Safe Browsing, Google Cloud Abuse, Google Workspace and NICENIC.

If you have seen NICENIC-registered domains with a similar pattern, activity on AS210558, or Google Sites pages with the documented fingerprint, correlation data would help complete the picture.

Spanish version: Cuando DKIM, SPF y DMARC no son suficientes

Methodology note: the technical investigation (header analysis, IOC pivots, DNS/RDAP, and screenshots) is my own work. Analytical and attribution judgments (e.g., that “gats” does not match the public kits reviewed, or the assessment of the developer’s experience level) are my own reasoning, not AI-generated; AI assistance (Claude, Anthropic) was limited to drafting and editing the text once those conclusions were made. All technical claims were verified by me against the cited primary sources before publication.

Updates

2026-05-30 — Third email: second Marketo abuse, C2 still active

At 12:13 UTC on May 30th, a third email arrived through the same Marketo vector:

Delivered-To:  [redacted]+api4020596@gmail.com
From:          Google Workspace <workspace@google.com>
Via:           Marketo (oak.mktdns.com, 199.15.214.195)
DKIM/SPF/DMARC: PASS  (header.i=@google.com, s=20251104)
Subject:       Thanks for contacting Google Workspace!
X-MSYS-API:    open_tracking:false, click_tracking:false
MarketoID:     808-GJW-314:0:329287:3698760:20:843537:9:1299370:72882878-24
Payload:       ...please cancel within 24 hours:
               https://sites[.]google[.]com/view/G-733828...

The email arrived at [redacted]+api4020596@gmail.com. The +api4020596 suffix is not generated by Google: the attacker included it when filling out the form with the victim’s address plus that alias. The X-MSFBL header confirms this; its base64 content decodes to {"r":"[redacted]+API4020596@gmail.com","b":"dvp-199-15-214-195","u":"808-GJW-314:0:329287:..."}. Automation with per-target assigned IDs.

808-GJW-314 appears in the MarketoID, the Return-Path and the X-MSFBL of both documented Marketo emails. The attacker is using the same Google Workspace form across all iterations.

The URL sites[.]google[.]com/view/G-733828 was still operational two days after the first documented send. No infrastructure rotation across the three attempts.

2026-05-31 — Active C2 analysis: professional AiTM platform, not a phishing kit

The C2 123753243[.]com was still operational on May 31st. Direct access to /v3/signin/identifier served the login page without restriction. Analysis of the HTML and the external script /shim.js reveals that the initial “phishing” classification is insufficient: this is a custom-built AiTM (Adversary-in-the-Middle) platform, with real-time relay of all phases of the Google authentication flow.

The AiTM flow confirmed visually

The "Captcha solver coming soon" message deserves more than a caption. It is an internal development status string that was never stripped from the production UI — a direct window into the attacker’s roadmap. It confirms two things: the kit was deployed while still under active development (not a mature, polished operation), and the attacker considers CAPTCHA bypass a known gap they intend to close. Operations that expose internal state in victim-facing interfaces are usually moving fast and cutting corners on operational security.

shim.js: the framework core — codename “gats”

The kit’s internal codename is “gats”, consistently used across all components: SESSION_KEY = "gats-session", the global object window.gats, the CSS class gats-bouncing for the navigation bouncer, and the header comment identifying the file as “public/shim.js — shared client glue loaded by every sign-in template”. This name does not match the public PhaaS kits I reviewed (Evilginx, EvilProxy, Tycoon 2FA, Rockstar 2FA, and on a second pass Sneaky 2FA, Mamba 2FA, Greatness and ONNX/Caffeine — none share the API structure, JS session management pattern, or Kameleo integration documented here). Code style is a weak attribution signal on its own, so the prudent reading is: it does not match the public kits reviewed and shows in-house development, without ruling out a private PhaaS or an undocumented fork.

The /shim.js script loaded by all C2 templates exposes the complete architecture. The code is written in professional JavaScript, well-commented in English, with explicit handling of edge cases (Safari ITP, Chrome iframe partitioning, back button, deep links). The comment quality and edge-case coverage — specifically the note on mobile browser cookie partitioning and the explicit Kameleo profile management — indicate a developer with production deployment experience, not a script kiddie adapting an existing kit.

The C2 exposes four endpoints:

POST   /api/sessions               →  creates victim session, returns sessionId
GET    /api/sessions/:id/status    →  AiTM state (heartbeat every 800 ms)
POST   /api/sessions/:id/action    →  actions: retry_email, change_account, retry
DELETE /api/sessions/:id           →  deletes session

The full Google authentication flow is implemented:

/v3/signin/identifier                          email
/v3/signin/challenge/pwd                       password
/v3/signin/challenge/pwd/retry                 wrong password
/v3/signin/challenge/pwd/last                  last attempt before lockout
/v3/signin/challenge/selection                 2FA method selection
/v3/signin/challenge/totp                      Google Authenticator (TOTP)
/v3/signin/challenge/sc                        SMS / verification code
/v3/signin/challenge/dp                        device prompt (push)
/v3/signin/challenge/dp/number                 number matching
/v3/signin/challenge/bc                        backup codes
/v3/signin/challenge/ipe                       email identity proof
/v3/signin/challenge/ipe/collect               email code collection
/v3/signin/challenge/ipp                       phone identity proof
/v3/signin/challenge/kpp                       phone knowledge proof
/v3/signin/challenge/wa                        passkeys / WebAuthn
/v3/signin/speedbump/changepassword/...        forced password change
/v3/signin/verify                              AiTM wait (heartbeat)
/v3/signin/review                              post-login review
/v3/signin/review/done                         success
/v3/signin/rejected                            blocked / CAPTCHA

The relay handles all Google 2FA methods documented in the code: TOTP, SMS, device prompt, backup codes, email and phone identity proof. The path /v3/signin/challenge/wa indicates the framework accounts for the passkeys/WebAuthn challenge, though its real effectiveness is unconfirmed: WebAuthn has origin binding by design, which prevents transparent relay from a domain other than accounts.google.com. Most likely the framework manages fallback when Google requests WebAuthn and Kameleo cannot complete it, falling back to another available method.

The source code explicitly confirms Kameleo:

// retry_email action so the same Kameleo profile navigates
// back with the corrected email — no new profile.

Kameleo is an anti-detection browser the attacker runs locally. Each victim session corresponds to an independent Kameleo profile that performs the real Google login while the victim waits at /v3/signin/verify.

The _g parameter preserves the victim’s identity across all flow navigations, specifically designed to survive Safari (ITP) cookie restrictions and Chrome iframe partitioning. It was built to run inside Google Sites iframes.

The C2 has dark/light theme control via _theme cookie, implying an administration panel with its own authenticated session. This panel has a login endpoint that is not documented in shim.js — it is a potential additional hunting surface on 45[.]92[.]1[.]158 (see Open questions).

"Google" is constructed character by character in the code (["G","o","o","g","l","e"].join("")) to evade text-signature-based detection in phishing scanners.

Threat reclassification

MITRE ATT&CK is extended with T1111 — Multi-Factor Authentication Interception: the framework intercepts and retransmits in real time all confirmed Google 2FA methods: TOTP, SMS, device prompt and backup codes. The WebAuthn/passkeys challenge is not relayable by design. The framework manages fallback to other available methods.

2026-05-31 (late) — Infrastructure status and third-party evidence

C2 domain status as of publication date

123753243[.]com    → 172.67.132.95 / 104.21.12.192  (Cloudflare anycast — ACTIVE)
view-requests[.]com → 45[.]92[.]1[.]158               (direct IP — INACTIVE)

view-requests[.]com has Cloudflare nameservers (thea/yew) but the proxy is disabled: the A record returns the real server IP directly. Requests to the domain return 406 Not Acceptable with Yandex Cloud headers. The domain appears to have been abandoned as an active C2; the Cloudflare proxy that protected it was disabled. 123753243[.]com remains proxied and operational.

Independent verification: URLScan captures case-159331 on 2026-05-06

A URLScan.io scan dated 2026-05-06T18:48:24Z, 24 days before this investigation began, captured sites[.]google[.]com/view/case-159331 with title “Google - Sign in” and recorded the loaded resources. The list of contacted domains and IPs includes:

Domains: view-requests[.]com (among others from Google)
IPs:     172.67.69.226  (Cloudflare anycast)
         45[.]92[.]1[.]158    (origin server — real C2 IP)

Full result: urlscan.io/result/019dfe9e-581d-76ff-8500-fd9324483f08

Independent evidence, predating this investigation, confirming the full chain: Google Sites → view-requests[.]com → Cloudflare → 45[.]92[.]1[.]158.

Detections in reputation databases

view-requests[.]com in VirusTotal as of 2026-05-31:

45[.]92[.]1[.]158 in AbuseIPDB: score 0%, no reports in the last 90 days. Note: for this IP the Cloudflare proxy is disabled (view-requests[.]com resolves directly), so the low score is not explained by hiding behind Cloudflare. It fits better with a shared/edge IP or simply one not reported by scanners, which also returns 406 to any direct access.

2026-06-04 — 123753243[.]com suspended by NICENIC

Four days after the abuse report, the main C2 domain has been taken down.

Infrastructure status as of 2026-06-04

123753243[.]com     →  NXDOMAIN   (clientHold — suspended by NICENIC)
view-requests[.]com →  45[.]92[.]1[.]158  (CF proxy off, domain alive but inactive)
45[.]92[.]1[.]158   →  HTTP 406 Yandex Cloud (unchanged)

123753243[.]com returns NXDOMAIN. An RDAP query to NICENIC’s servers confirms the reason:

status: ["client delete prohibited", "client transfer prohibited", "client hold"]

clientHold is the standard EPP suspension: the domain remains registered (expires 2027-05-23) but has been removed from the DNS zone by the registrar. The abuse report sent on 2026-05-30 to abuse@nicenic.net and the Spamhaus DBL entry took effect in under 96 hours.

First VirusTotal query on 123753243[.]com with the domain already suspended: 2 suspicious detections (Fortinet and alphaMountain.ai, both as spam), 89 engines clean. VT passive DNS shows only Cloudflare anycast IPs (104.21.12.192, 172.67.132.95) — the real server IP was never exposed in commercial passive DNS. Assigned tags: dga, hex.

view-requests[.]com still resolves directly to 45[.]92[.]1[.]158 and remains registered until 2027-03-14 with no clientHold. Domain pending abuse report to NICENIC.

45[.]92[.]1[.]158 unchanged. AbuseIPDB: score 0%, no new reports in the last 90 days. The server returns HTTP 406 with identical Yandex Cloud headers as documented on 2026-05-31.

2026-06-09 — Independent re-verification (passive + active recon)

Ten days after publication the full pivot chain was repeated from scratch — authoritative Verisign RDAP, crt.sh, DNS and a single active access from an isolated node — to validate the persistence of the infrastructure and to calibrate the claims in the analysis. The entire technical body held up. Three new nuances:

Exact suspension timestamp. The clientHold on 123753243[.]com was applied on 2026-06-04T17:20:05Z (RDAP last changed), not in early June as initially estimated. The domain remains in clientHold (NXDOMAIN) and registered until 2027-05-23.

view-requests[.]com is not abandoned. It still carries no clientHold (RDAP last changed frozen at 2026-04-21T21:42:03Z, the cert renewal) and its origin gate still answers live: 45[.]92[.]1[.]158 returns HTTP/2 406 with identical Yandex Cloud headers. The layer that was switched off was the Cloudflare proxy, not the origin. The correct reading is “CF proxy disabled, origin gate active”, not “infrastructure abandoned”. The domain’s Let’s Encrypt E8 origin cert expires on 2026-06-12: its non-renewal would be the first real sign of abandonment.

The balancer’s datacenter identifier rotates. The x-yandex-req-id showed yp-vla- (Vladimir) and yp-klg- (Kaliningrad) in May, and yp-sas- (Sasovo) in this re-verification. Three distinct DCs across requests to the same IP confirm this is Yandex Cloud’s real multi-DC L7 balancer, not a fabricated static header — reinforcing the attribution of the infrastructure layer to Yandex.

Calibration on 45[.]92[.]1[.]158. The *.yandex.tr cert is served for any SNI (including raw-IP access) and the origin answers 406 to everything. This is consistent with a shared Yandex Cloud layer (edge / anti-bot / balancer), not necessarily a dedicated bare-metal server owned by the actor. The third pivot text already left this open (“remains unresolved”); the label “origin server — the C2’s real IP” should be read with that caveat. Along the same lines, port 22 (SSH) reported via Censys as an indicator of “direct management by the actor” is left as unconfirmed: if the IP is shared Yandex edge, it could belong to another host in the block or be stale collection data. Port 22 was not actively probed.

2026-07-04 — Calibration note and corrections

Editorial review of the analysis focused on precision and on the defensive usefulness of the IOCs. The technical body stands; several points are adjusted and one mapping corrected:

• MITRE T1584.001 corrected to T1583.001: the actor registers its own C2 domains at NICENIC (Acquire Infrastructure: Domains), it does not compromise third-party domains (Compromise Infrastructure).
• Email IOCs: clarified that roach-hotel, 808-GJW-314 and the @google.com addresses are identifiers of Google’s legitimate infrastructure, not the attacker’s. As standalone block rules they generate false positives; the distinctive indicator is the injected URL sites.google.com/view/....
• X-MSYS-API (tracking disabled): reclassified from an evasion technique to a non-attributable observation, because those options are set by the sending platform’s template (SparkPost/Momentum behind Marketo), not by whoever fills out the form.
• 45[.]92[.]1[.]158: the 2026-06-09 calibration is propagated to the earlier sections (likely a shared Yandex Cloud layer, not a confirmed dedicated server; port 22 unconfirmed as the actor’s).
• Kit confidence and Cloudflare NS: the “in-house development” classification is qualified with a broader PhaaS comparison, and the inference of distinct Cloudflare accounts moves from “means” to “consistent with”.
• The hash of the preserved shim.js is published (SHA256 9322530b...274a6e) as a reusable fingerprint of the “gats” kit.

2026-08-21 — Field re-verification (certificates, pace, cluster)

New field re-verification, executed from an isolated node to avoid any active interaction from my own IP. The infrastructure is unchanged, but this corrects the interpretation of two points from the previous note and adds a third:

The certificate renewals on view-requests[.]com do not demonstrate actor maintenance. The origin (45[.]92[.]1[.]158) still serves exclusively the *.yandex.tr Yandex/GlobalSign wildcard certificate — byte-identical to the one documented in June — with the Cloudflare proxy still off. No Let’s Encrypt certificate for view-requests[.]com is served at any observable point: the zone remains provisioned on Cloudflare, which is why it keeps issuing and rotating certificates roughly every 30 days, but that measures the registration staying paid, not the origin being maintained. As a control: 123753243[.]com, in clientHold since 2026-06-04 with zero capability for actor action, stopped renewing its certificates — they expire today, 2026-08-21, with no reissue. Certificate renewal on a Cloudflare-hosted zone tracks the zone’s lifecycle, not human action. The criterion set in the 2026-06-09 note (“non-renewal would be the first real sign of abandonment”) was consequently an invalid criterion for measuring that. The IOC table and appendix are corrected accordingly — view-requests[.]com moves from “inactive/abandoned” to “registered, zone active on Cloudflare, no C2 activity observed since 2026-05”.

The campaign’s pace has collapsed, not regenerated. Between July 23rd (the last previously known slug) and today only one new candidate page has appeared (ticket-747839, matching pattern and title, not confirmed by source-code hash). All previously known slugs remain indexed. There is no evidence of an active third wave of the campaign.

The lure-page pattern is widened. A second wave, indexed in July 2026, added the portal-/verify- prefixes and 7-digit lengths. Updated pattern: sites.google.com/view/(g|G|ticket|case|portal|verify)-[0-9]{6,7}. Only one page from that wave is confirmed by source-code comparison (ticket-7371564); the rest that match pattern and title are not elevated to confirmed IOC — publishing them as such would risk false attribution against pages that may belong to unrelated actors.

Additionally, the “LevelBlue: phishing” citation on view-requests[.]com is no longer verifiable on VirusTotal (0 malicious / 0 suspicious today) — it is removed from the IOC table.

YARA detection rule. Publishing the rule used to re-confirm the shim.js sample (download: gats_aitm.yar):

rule GATS_AiTM_shimjs
{
    meta:
        description = "Detects shim.js from the 'gats' AiTM kit (pedrojorge.info cluster, 2026-05). Includes Google context strings and backend API strings for extra specificity."
        author = "osint-lab"
        date = "2026-08-17"
        modified = "2026-08-22"
        version = "6"
        reference = "https://www.pedrojorge.info/posts/2026/05/dkim-spf-dmarc-phishing-google/"
        hash_sha256 = "9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e"
        confidence = "high"
        status = "experimental"
        tlp = "CLEAR"
        mitre = "T1566.002, T1111"
        level = "detection"
        fp_validation = "TP=1/1 known sample (36/36 declared strings match, byte-offset verified). FP=0/58,208 real-world .js/.mjs/.cjs/.ts/.jsx files, independent re-verification (2026-08-22, covering /home + /usr/share + /usr/lib) -- consistent with earlier smaller passes (FP=0/3000+, FP=0/2330 x2, 2026-08-21). Also measured against a 57,809-file non-JS corpus (md/html/json/xml/txt/log/py, 2026-08-22): 37 hits, ALL confirmed as this lab's own threat-intel material (this post, review reports, session caches) quoting the strings, not the actual sample -- zero third-party non-JS false positives -- see scope caveat and WARNING."
        scope = "Detects this specific shim.js build via literal strings, not a structural signature of the framework. Renaming the 'gats' codename removes every $s* string, but does NOT invalidate every leg: Leg 2 ($h1 and 1 of ($s*, $a*, $k1)) still fires on $h1 plus any single $a*/$k1 match, none of which contain 'gats' -- empirically confirmed ($h1+$a3, $h1+$a2, $h1+$k1 all fire with zero 'gats' strings present). Fully evading the rule requires also changing the header comment ($h1) and the Kameleo reference ($k1), not just the codename. $a1 (/api/sessions/:id/status), $g1 ([jsname=\"P1ekSe\"]) and $h1 itself all match, but their ONLY occurrence in the sample is inside the file's header comment block: $a1's real runtime call is a template literal (`/api/sessions/${s.id}/status`), which YARA cannot match literally, and $g1/$h1 simply aren't reused in code. $k1 ('Kameleo profile') is likewise comment-only (offsets 0x222f/0x251e). A minifier that strips comments (the common default, e.g. Terser) removes $a1/$g1/$h1/$k1 from a build without touching the behavior they describe. The remaining Google context strings ($g2-$g5) are specific to this clone build and DO survive comment-stripping, since they're also present in runtime code; if the actor changes the login template, they break before $s1-$s4/$a1-$a3 do. $a2 was originally declared as the literal path '/api/sessions/:id/action', which does NOT exist anywhere in the sample -- only as the same kind of unmatchable template literal; replaced with 'change_account', a literal action value that does exist in the sample (line 235) and is part of the kit's own action vocabulary (retry_email/change_account/retry). All strings are plain ascii/UTF-8 (confirmed with 'file' against the sample) -- the 'wide' modifier is not used, for lack of any UTF-16 evidence in this cluster. Does not verify file format. v6 removes the former Leg 4 (anchor + a single $a1/$a2 match): it was dead code, fully subsumed by Leg 1 -- any input satisfying it already satisfies Leg 1, since the anchor plus that one $a1/$a2 match are already 2 distinct members of Leg 1's own pool. WARNING: being literal kit strings, the rule also fires on TEXT describing the kit (writeups, threat-intel reports, this very post) -- do not use it to scan documentation/CTI corpora expecting a match to mean the sample is present; it is only reliable against code/binaries."

    strings:
        // Kit identifiers -- "gats" codename and state elements
        $s1 = "gats-session" ascii
        $s2 = "gats-bouncing" ascii
        $s3 = "gats-bouncer-style" ascii
        $s4 = "window.gats" ascii
        $s5 = "gatsCb" ascii

        // Google context -- selectors and paths from the cloned login flow.
        // $g1 exists ONLY inside the header comment (see $h1) -- same
        // comment-only fragility as $a1/$h1/$k1. $g2-$g5 are also present
        // in real code and survive comment-stripping.
        $g1 = "[jsname=\"P1ekSe\"]" ascii
        $g2 = "[jsname=\"OQ2Y6\"]" ascii
        $g3 = "sf-hidden" ascii
        $g4 = "/v3/signin/identifier" ascii
        $g5 = "/v3/signin/challenge/pwd" ascii

        // Kit backend API -- $a1/$a3 are literal paths, present verbatim in
        // the sample; $a2 is a literal action value, NOT a path (the real
        // "/api/sessions/:id/action" path never appears as a literal string
        // in this sample, only as a template literal with interpolation --
        // see scope for detail)
        $a1 = "/api/sessions/:id/status" ascii
        $a2 = "change_account" ascii
        $a3 = "/api/sessions" ascii

        // File header -- the most distinctive string, unique to the kit.
        // Comment-only occurrence, like $a1/$g1/$k1: lives in the file's
        // header block, not in runtime code -- see scope.
        $h1 = "shared client glue loaded by every sign-in template" ascii

        // Kameleo -- reference to the anti-detect browser used by the actor
        // (confirmed in comments in the real file, offsets 0x222f and 0x251e
        // of the original sample with $c1="Kameleo"; "Kameleo profile" is the
        // exact phrase appearing in both comments)
        $k1 = "Kameleo profile" ascii

    condition:
        // Leg 1: strong anchor ($s1/$s4) + at least one more string from the
        // pool (identity, API, Kameleo). The anchor itself counts toward the
        // "2 of" quantifier, so the effective minimum is anchor + 1 support,
        // not anchor + 2 as an earlier version of this comment implied --
        // e.g. $s1+$s2, or $k1+$s1, are enough. Still blocks a weak pair
        // like $s2+$s3 from firing without an anchor.
        (($s1 or $s4) and 2 of ($s*, $a*, $k1))

        // Leg 2: header string + at least one supporting string.
        // $h1 no longer fires alone.
        or ($h1 and 1 of ($s*, $a*, $k1))

        // Leg 3: strong anchor + 2 Google context strings. Confirms the file
        // carrying the kit identifiers is actually tied to the Google login
        // impersonation, not just a script reusing similar names elsewhere.
        or (1 of ($s1, $s4) and 2 of ($g*))

        // Leg 4: explicit mention of the Kameleo profile + 2 kit identifiers.
        // Rules out "Kameleo profile" alone (e.g. in documentation about the
        // anti-detect browser itself) triggering the rule. (Former Leg 4,
        // anchor + single $a1/$a2 match, was removed in v6: it was dead
        // code, fully subsumed by Leg 1 -- see scope.)
        or ($k1 and 2 of ($s*))
}

This is a same-build signature based on literal strings, not a structural signature of the framework. One important nuance v5 didn’t document well: renaming the "gats" codename removes every $s* string, but does not invalidate the whole rule — Leg 2 ($h1 + 1 of $s*/$a*/$k1) still fires on $h1 plus any $a*/$k1 match, none of which contain "gats" (empirically confirmed: $h1+$a3, $h1+$a2 and $h1+$k1 all fire with zero gats strings present). Fully evading the rule also requires changing the header comment ($h1) and the Kameleo reference ($k1), not just the codename. v6 also fixes two defects found during independent re-verification (Sonnet + Opus, 2026-08-22): the former Leg 4 was dead code — every case that fired it already fired Leg 1, so it’s removed — and the Leg 1 comment misdescribed its own logic (the anchor counts inside the 2 of quantifier, so the real minimum was always anchor + 1 support, not anchor + 2). Validated against the known sample (TP, 36/36 strings, byte-offset verified) and against 58,208 unrelated real-world .js/.mjs/.cjs/.ts/.jsx files (0 false positives). One real caveat, already observed in this repository and now precisely measured: being literal strings, the rule also fires on text describing the kit — across a 57,809-file non-JS corpus (docs, JSON, logs) there were 37 hits, all this lab’s own CTI material (this post, review reports), zero third-party. It is not a signal of “sample present” when run against a documentation or threat-intel corpus.

2026-08-22 — YARA rule re-verification (v6)

After publishing v5, the rule went through an adversarial review in two independent passes (Sonnet, then Opus with explicit instructions to try to refute both the rule and the first review) — both running real yara-python against the real sample, not just reading the file. Everything already published was confirmed (compilation, TP=1, the 36 hit offsets), and the FP check was re-run on a larger corpus: 0/58,208 real .js/.mjs/.cjs/.ts/.jsx files.

The second pass (Opus) found two real defects the first review missed:

1. Leg 4 was dead code. Testing all 32,768 possible combinations of the 15 strings, Leg 4 never fired as the sole matching leg — Leg 1 already covered every case it could catch. Removed in v6.
2. The rule’s scope made a false claim. It said renaming the "gats" codename invalidated every leg of the condition. It doesn’t: Leg 2 ($h1 + 1 supporting string) fires with zero "gats" strings present. Fixed in v6, along with the Leg 1 comment (which misdescribed its own threshold) and the scope’s list of comment-only strings ($g1 and $h1 added — both exist only inside the file’s commented header block, same as $a1/$k1).

Updated rule: gats_aitm.yar (v6, same download link as above). None of these changes alter what fires and what doesn’t against the real sample or the validation corpus — they’re documentation fixes and the removal of a redundant branch, not a behavior change.

Appendix: IOCs (plain text)

# ============================================================
# C2 DOMAINS
# ============================================================
123753243[.]com    # clientHold (NICENIC) since 2026-06-04T17:20:05Z — NXDOMAIN
view-requests[.]com  # registered, zone active on Cloudflare (proxy off), origin gate answers 406, no C2 activity observed since 2026-05 · updated 2026-08-21; registered until 2027-03-14

# ============================================================
# IP
# ============================================================
45[.]92[.]1[.]158  # AS210558 / 1337 Services GmbH / NL — origin gate; likely shared Yandex Cloud layer (dedicated server unconfirmed, see 2026-06-09)

# ============================================================
# C2 URLS / PATHS
# ============================================================
hxxps://123753243[.]com/v3/identity/login
hxxps://123753243[.]com/v3/signin/identifier
hxxps://view-requests[.]com/v3/identity/login
hxxps://view-requests[.]com/v3/signin/identifier

# Full AiTM paths (shim.js — 2026-05-31)
/v3/signin/challenge/pwd
/v3/signin/challenge/pwd/retry
/v3/signin/challenge/pwd/last
/v3/signin/challenge/selection
/v3/signin/challenge/totp
/v3/signin/challenge/sc
/v3/signin/challenge/dp
/v3/signin/challenge/dp/number
/v3/signin/challenge/bc
/v3/signin/challenge/ipe
/v3/signin/challenge/ipe/collect
/v3/signin/challenge/ipp
/v3/signin/challenge/kpp
/v3/signin/challenge/wa
/v3/signin/verify
/v3/signin/review
/v3/signin/review/done
/v3/signin/rejected

# C2 API (shim.js — 2026-05-31)
POST   /api/sessions
GET    /api/sessions/:id/status
POST   /api/sessions/:id/action
DELETE /api/sessions/:id

# AiTM framework script
/shim.js
# shim.js ("gats" kit, 16613 bytes)
#   SHA256 9322530b01376deb2cac6c35ad34a5e5405fdedb4a26fd71d7cbd9c778274a6e
#   SHA1   8b74b60567160b1753059452406638d27dce2c0a
#   MD5    7bbd1d7d485b6f6ebbeb28b469970670

# ============================================================
# LURE PAGES (Google Sites)
# ============================================================
sites[.]google[.]com/view/G-733828
sites[.]google[.]com/view/g-798225
sites[.]google[.]com/view/g-624594
sites[.]google[.]com/view/case-159331
sites[.]google[.]com/view/ticket-179902   # historical
sites[.]google[.]com/view/ticket-925681   # historical, first entry Dec 2025

# ============================================================
# CLOUDFLARE TUNNELS (historical, inactive)
# ============================================================
aimed-activities-erik-magnetic[.]trycloudflare[.]com
nursing-nominations-spirituality-origin[.]trycloudflare[.]com

# ============================================================
# FINGERPRINT — code similarity (Google Sites embed)
# ============================================================
productName: 6b8ce7c01e3dacd3d2c7a8cd322ff979
embed hash:  16cb204cf3a9d4d223a0a3fd8b0eec5d

# ============================================================
# EMAIL IOCs — Marketo vector (workspace@google.com)
# ============================================================
Return-Path: 808-GJW-314.*@google.com
X-MarketoID: 808-GJW-314:*
X-MSYS-API:  {"options":{"open_tracking":false,"click_tracking":false}}
Via relay:   oak.mktdns.com [199.15.214.195]

# ============================================================
# EMAIL IOCs — Account Recovery vector (security-noreply@google.com)
# ============================================================
X-Google-Appengine-App-Id: s~google.com:roach-hotel
From: security-noreply@google.com
Source IP: 209.85.220.0/24  (mail-sor-*.google.com)

# ============================================================
# VICTIM TRACKING PATTERN
# ============================================================
Delivered-To pattern: *+api[0-9]+@*  # Gmail alias with attacker-assigned tracking ID

# ============================================================
# HTTP FINGERPRINT — direct connection to origin server
# ============================================================
x-yandex-req-id: *-balancer-l7leveler-kubr-yp-klg-*  # Yandex Cloud L7 balancer
set-cookie: _yasc=*  # Yandex anti-scraping cookie
HTTP 406 on direct HTTPS access without Cloudflare headers (port 443 active)
Port 22 (SSH) reported by Censys — NOT confirmed as the actor's (possible shared Yandex edge, see 2026-06-09)
SSH host key SHA256: e0c79480147098369381f015c6861126f6ae386d499c8a63d04663b4090eb2d2

# ============================================================
# INFRASTRUCTURE NEXUS — for pivoting
# ============================================================
Registrar: NICENIC INTERNATIONAL GROUP CO. LTD  (IANA ID 3765)
ASN:       AS210558  (1337 Services GmbH)