Phish Wire

Phish Wire - July 15, 2026

Written by Identity Automation | Jul 22, 2026 5:06:33 PM

Between July 02 and July 15, 2026, our team analyzed five phishing incidents targeting organizations across four U.S. states, with campaign activity distributed across the full two-week window rather than concentrated in a single burst. The dominant credential-capture patterns fell into two categories: HTML form POST submissions directed at attacker-controlled endpoints — in several cases using an err.html redirect pattern designed to prompt a second credential entry — and an adversary-in-the-middle relay kit against one target that implemented a full OAuth 2.0 session state machine capable of capturing MFA tokens and OTP codes across multiple authentication stages.

Impersonated brands and services identified from on-page evidence include Microsoft 365 and its Azure AD converged login flow, a Windows helpdesk support portal, the MyGift Visa prepaid card brand, and two AOL webmail sign-on portals. Infrastructure across the five incidents spanned Microsoft Azure Static Web Apps, a wildcard subdomain family under the attacker-controlled dpdns[.]org resolver, a lookalike consumer domain at my-mallgifts[.]com, and a pair of attacker-registered mail-themed domains at mailinusa[.]com and mailcst[.]com, with the Azure and dpdns[.]org cases both leveraging legitimate third-party infrastructure to inherit trust signals that enterprise controls extend to those platforms by default.

The most technically notable development this period is the consistent displacement of credential-capture logic away from inspectable HTML — into compiled JavaScript bundles, embedded base64 CSS payloads, third-party form-platform channels, and server-side POST handlers — a pattern that, taken together across five separate incidents, suggests operators are broadly aware of page-source inspection as a detection layer and are structuring their kits to ensure the actionable signals exist only in fetched assets or outbound POST traffic rather than in the landing page markup itself.

Domains Reviewed

  • viruswarning0715usagzgv5.z13.web.core.windows[.]net/?utm_medium=paid&utm... (12 variants)
  • office.swcdhrjtro.jujqjtdxvmxnwghuusfjcezwppupwfkymxf.dpdns[.]org/e/wSip...
  • my-mallgifts[.]com/home/?matchtype=e&msclkid=b590eaf85499134d14f880b6fe7...
  • signon.mailinusa[.]com/pass.html
  • signox.mailcst[.]com/pass.html

A credential-harvesting page impersonating a Windows helpdesk support portal targeted organizations in Connecticut, Illinois, Kentucky, Texas and Utah, delivered through paid Facebook advertising traffic as indicated by the utm_medium=paid and utm_source=fb parameters embedded in the landing URL. The activity period (July 2-15, 2026), across 12 separate detections, consistent with a paid social campaign running against a defined audience segment rather than a single phishing blast.

The page loads its functional logic entirely from a bundled JavaScript module at ./assets/index-DvsLmbh3[.]js, a Vite-compiled single-page application pattern that moves credential capture and form submission behavior out of the HTML and into an opaque hashed asset, making static inspection of the exfiltration endpoint dependent on analysis of that external script. The infrastructure is hosted on Azure Static Web Apps under the z13.web.core.windows.net subdomain, a Microsoft-operated service that carries inherent trust with enterprise security tooling and benefits from shared TLS validity with legitimate Microsoft properties.

Related subdomain variants:

  • message709js794y1d7o0.z13.web.core.windows[.]net
  • viruswarning0702usa8cwpd.z13.web.core.windows[.]net
  • viruswarning0708usa35i7m.z13.web.core.windows[.]net
  • viruswarning0709uslf7jhv.z13.web.core.windows[.]net
  • viruswarning0709uszj8tfv.z13.web.core.windows[.]net
  • viruswarning0710usb8qdo3.z13.web.core.windows[.]net
  • viruswarning0714uscs3vkt.z13.web.core.windows[.]net
  • viruswarning0714usta6fop.z13.web.core.windows[.]net
  • viruswarning0714usvk6v08.z13.web.core.windows[.]net
  • viruswarning0715usagzgv5.z13.web.core.windows[.]net
  • viruswarning0715usck5jzm.z13.web.core.windows[.]net

A credential-harvesting page impersonating Microsoft 365 sign-in targeted a Maryland organization, presenting a pixel-accurate replica of the Azure AD converged login flow under the attacker-controlled domain office.swcdhrjtro.jujqjtdxvmxnwghuusfjcezwppupwfkymxf.dpdns[.]org. Activity was confined to July 13, 2026, with a single observed event. Credential submission posts to /common/login on the same attacker-controlled domain, meaning the operator receives cleartext username and password before any redirect occurs, and the $Config JSON block embedded in the page configures a fully functional OAuth 2.0 session state machine — including endpoints for GetCredentialType, GetOneTimeCode, and session resumption — indicating the kit is built to handle MFA prompts and OTP capture as part of a continuous authentication relay rather than stopping at password collection alone.

The infrastructure is structured as a wildcard subdomain family under jujqjtdxvmxnwghuusfjcezwppupwfkymxf.dpdns[.]org, with distinct subdomains mimicking functionally separate Microsoft endpoints: ebqprupn for MSA OAuth authorization, bphkxnap as the landing redirect target, zprgxssn for password reset, and psdfuedc for MSA password reset flows, giving each stage of the authentication sequence its own plausible-looking host. The $Config block also surfaces a legitimate aadcdnjp.msftauth[.]net CDN reference for loading Microsoft's own authentication JavaScript bundles, meaning the page pulls real Microsoft UI assets to render correctly while routing all credential and token traffic through attacker infrastructure — a detail that undermines content-inspection approaches that check only for known-malicious resources in page loads.

A gift-card credential-harvesting page impersonating the MyGift Visa brand targeted a California organization, using a lookalike domain at my-mallgifts[.]com to simulate a legitimate card-balance or redemption portal. Activity was confined to July 08, 2026. The page loads a large base64-encoded WebP image payload embedded directly in CSS as a custom property, which serves as the visual lure while a Strikingly-style in-page channel node (the div carrying the data-channel-name attribute "in_page_channel_YcEJ9U") signals the use of a third-party form-builder or drag-and-drop site platform to handle data collection and likely exfiltration, offloading the credential-capture backend to that platform's infrastructure rather than attacker-owned endpoints.

The referrer policy is explicitly set to no-referrer, which suppresses the HTTP Referer header on any outbound request the page makes, limiting the ability of downstream logging to trace how a victim arrived at the page or where form data travels. Because the capture mechanism routes through a legitimate platform's form-handling layer, perimeter controls that block on attacker-registered domains will miss the exfiltration path entirely, and the no-referrer policy further degrades visibility in proxy and SIEM telemetry that relies on referrer chains to reconstruct user journeys.

A credential-harvesting page impersonating an AOL webmail sign-on targeted a Florida organization, presenting a stripped-down password-collection form that loads a logo and branding assets from attacker-controlled paths on signon.mailinusa[.]com and signon.mailcst.com. Activity was confined to July 06, 2026. The primary capture mechanism is a standard HTML form POST directed at err.html on the same host, a pattern where the submission endpoint doubles as a fake error redirect to sustain the illusion that login failed and encourage a second attempt.

The page also carries two hidden fields — one named "coding" with an empty value likely populated by JavaScript before submission, and one named "email" pre-seeded at page-load time via the id="email-primnt" paragraph element, indicating the kit expects to receive a victim email address as a URL parameter and embed it silently in the harvested POST body alongside the typed password. For defenders, the practical implication is that the form submits a credential bundle that includes a pre-keyed victim identifier, meaning the operator receives structured, pre-attributed data without any interactive step the victim would notice, and email gateway controls that strip or rewrite suspicious URL parameters in inbound links would degrade the kit's ability to pre-fill that field.

Recommendations

  • Configure proxy and SIEM alerting to flag authentication flows where a non-Microsoft host loads Microsoft authentication JavaScript bundles (such as assets from msftauth[.]net) while routing credential POST traffic to attacker-controlled infrastructure — the exact pattern observed in the dpdns[.]org kit, where real Microsoft CDN assets were used to render a convincing Azure AD page while all credential and token traffic transited attacker subdomains.
  • Treat *.web.core.windows[.]net and similar Microsoft-operated static hosting subdomains as requiring the same scrutiny as unknown external domains in web-content inspection pipelines; the z13.web.core.windows[.]net campaign demonstrated that shared TLS validity and Microsoft infrastructure provenance allow credential-harvesting pages to inherit institutional trust and bypass controls that allowlist by certificate authority or parent domain.
  • Extend phishing page analysis to fetched JavaScript assets rather than stopping at HTML source inspection; the z13.web.core.windows[.]net kit deferred all exfiltration logic to a Vite-compiled bundle at a hashed asset path, meaning any detection or sandboxing workflow that does not execute and inspect the loaded JS will return a clean verdict on a live harvesting page.
  • Instrument email gateway and proxy controls to rewrite or strip URL parameters matching credential-seeding patterns (e.g., query strings containing email addresses passed to login-themed pages), directly countering the pre-fill technique observed in the mailinusa[.]com and mailcst[.]com kits, where victim email addresses were injected at delivery time and silently embedded in harvested POST bodies without any visible user interaction.
  • Monitor for outbound form submissions directed at third-party platform infrastructure (site-builder and form-handler services) originating from pages that set a no-referrer referrer policy, as observed in the my-mallgifts[.]com incident; this combination is a reliable indicator that exfiltration is being offloaded to a legitimate platform to evade perimeter controls that block on attacker-registered domains.
  • Train users who interact with any Microsoft 365 or webmail sign-in flow to recognize multi-stage authentication prompts served from URLs that do not resolve to microsoft[.]com or a known organizational SSO domain — the dpdns[.]org kit replicated the full Azure AD converged login sequence including MFA and OTP prompts across structurally separate attacker subdomains, meaning a convincing second-factor prompt is not evidence that the session is legitimate.
  • For organizations running paid social advertising or whose brand is likely to attract impersonation, establish a monitoring workflow against Facebook ad transparency data for lookalike lure pages targeting specific geographies; the z13.web.core.windows[.]net campaign embedded utm_medium=paid and utm_source=fb parameters directly in its landing URL, confirming paid Facebook placement and indicating the operator was running audience-targeted delivery that would not appear in email telemetry at all.

Learn how PhishID can help protect your district from cutting-edge threats like these! Schedule a Demo