Inside HarvestGate: Redirect Chains, Device-Code Phishing, and Automated Device Registration

Key findings

• HarvestGate was uncovered through personalized HR-themed PDFs delivered via email. The phishing link was embedded in the PDF rather than the email body.
• Four delivery families, including compromised websites, HubSpot tracking links, purpose-built redirectors, and malvertising, converged on randomized HarvestGate landing hosts.
• The same landing hostname served the attacker-controlled Turnstile page, the phishing application, and the /api/harvester backend. Despite changes in branding and lure content, recovered pages retained the same core JavaScript workflow and backend endpoints.
• After the victim completed Microsoft’s legitimate device-code flow, Python-based tooling replayed the resulting tokens, registered three devices, and attempted device enrollment. Token use continued after the victim’s password was reset.

Vega Threat Research independently identified the device-code phishing kit we track as HarvestGate while investigating an HR-themed campaign in a Vega customer environment. The activity aligns with the kit documented by eSentire as GhostCode. Our investigation expands the public view of this family by mapping additional delivery methods, redirect infrastructure, traffic-routing behavior, victim-facing templates, JavaScript-level fingerprints, and post-authentication identity activity.

HarvestGate is not tied to a single lure, domain, or delivery method. Its deployments repeatedly converge on randomized landing hosts that serve the Turnstile gate, victim-facing phishing pages, and a consistent JavaScript and backend workflow. In the incident we investigated, successful device-code redemption was followed by token replay and automated device registration, demonstrating how a phishing interaction can lead to persistent identity access.

eSentire documented the same kit in a procurement-themed campaign using password-protected HTML attachments. Our investigation identified HR-themed lures delivered through personalized PDFs, with links routed through four delivery families. These paths converged on the same underlying phishing application. Shared infrastructure and identical harvester and Turnstile API paths establish that the two investigations examine the same kit family. In this report, we retain HarvestGate, the name assigned during Vega’s independent investigation.

How Vega customers are protected

Vega customers are protected by five detections spanning the stages of the HarvestGate attack chain:

• Outbound Request to an Authentication-Themed Host With a Randomized Token Label
  Identifies connections to authentication-themed hostnames containing randomized labels consistent with HarvestGate landing infrastructure.
• Outbound Web Request to a Device Code Harvester API Endpoint
  Detects requests to API patterns associated with the kit’s device-code generation and polling workflow.
• Device Code Sign-In Session From Multiple Source Addresses With an Unmanaged Device
  Identifies device-code authentication sessions that shift between source addresses and involve an unmanaged device.
• Authentication Broker Sign-In From a Scripted Client on an Unmanaged Device
  Detects scripted authentication activity involving an unmanaged device following successful sign-in.
• Multiple Entra ID Device Registrations for a Single Account in a Short Window
  Identifies rapid device registrations that may indicate an attacker establishing persistent access with stolen authorization.

Vega customers also receive a linked threat brief that brings together the related detections, investigation context, and indicators of compromise. These indicators are automatically scanned against each customer’s data, helping security teams identify both current exposure and relevant historical activity.

The following sections examine each stage of this chain, from the initial phishing email through post-authentication activity.

Figure 1 — Observed HarvestGate attack chain

Stage 1: Targeted phishing email delivers the lure

The messages impersonated recipients’ HR departments and used annual leave, vacation eligibility, and Q4 leave schedules as pretexts. Personalization extended beyond the recipient’s name: observed emails incorporated the target organization’s branding, including its logo, while attached PDFs used filenames such as Leave_Schedules_for_<firstname>.<lastname>.pdf.

Across the samples we analyzed, the operators rotated between several related subject-line templates and introduced accented characters and combining diacritics to create visually similar Unicode variants with different underlying character sequences. This was likely intended to evade static or exact-match detection rules and make consistent blocking and campaign clustering more difficult. Observed subject lines included:

• Approved lists of employees eligible for Q4 leave/vacation applications
• New batch-release for those eligible for annual vacation
• Information on Q4 Leave/Vacation dates from HR Team
• Annual vacation/leave dates are out for all applied employees

Despite the personalized content, several delivery artifacts remained consistent. Sender addresses followed an info@<domain> pattern, observed messages were sent through Amazon SES, and emails commonly included a small attachment-1.jfif image alongside the personalized PDF. The phishing URL itself was embedded in the PDF rather than placed directly in the email body.

Figure 2 — HR-themed phishing email (Toyota-branded)

Figure 3 — HR-themed phishing email (BT-branded)

Figure 4 — HR-themed phishing email (Q4 leave dates)

The HR-themed activity represented only one campaign linked to HarvestGate. We also identified document-sharing and Microsoft-themed lures associated with the same phishing kit.

The different delivery playbooks may reflect separate campaigns, operators, or configurations of a shared kit. The available evidence does not establish HarvestGate’s distribution model.

Stage 2: Personalized document moves the link beyond the email body

The PDFs varied visually. Some presented an HR notice with a clickable “Updated Staff Information” panel; others resembled internal document portals. Their purpose was the same: move the phishing link into an attachment and begin the redirect chain.

Figure 5 — PDF lure with Updated Staff Information panel

Figure 6 — PDF lure styled as an internal document portal

These artifacts were useful for scoping the campaign, but they were not sufficient to identify HarvestGate itself. The stronger association emerged at the infrastructure and application layers.

Stage 3: Redirect chains converge on HarvestGate

Victims were not directed immediately to the phishing page. The links passed through multiple redirect paths spanning four distinct delivery methods before converging on randomized HarvestGate landing hostnames. We use “HarvestGate landing host” for the hostname through which the operator serves the verification gate and phishing application. The page and routes are operator-controlled even when the hostname is proxied by Cloudflare or deployed beneath a compromised or third-party apex domain. “MailDashboard” is a distinctive application label exposed by the kit, not a separate type of host.

Delivery methods converging on HarvestGate

Several first hops were legitimate services being abused and should not be treated as attacker infrastructure or blocklist targets. We observed only one unique malvertising chain, so the evidence establishes malvertising as one observed route rather than a persistent delivery channel.

Dynamic routing through an attacker-controlled relay

The malvertising chain provided a particularly useful view into HarvestGate’s traffic-control behavior. We observed the same URL in two separate analysis environments: urlscan.io and ANY.RUN. In both observations, the legitimate ad-tech service redirected the browser to the same attacker-controlled relay, swiftoaic[.]com. The relay then returned different destinations:

urlscan: swiftoaic[.]com → verify-access-umjlvvrx[.]alltoyotatrucksuvparts[.]com/turnstile
ANY.RUN: swiftoaic[.]com → foundation.wikimedia.org/wiki/Policy:Privacy_policy

The differing outcomes are consistent with a Traffic Distribution System (TDS), which routes inbound traffic according to operator-defined criteria. In phishing operations, this can allow intended victims to reach malicious content while diverting scanners or other unwanted visitors to benign destinations.

The value 659 persisted across the chain, appearing as ta=659 on the advertising endpoint and ti=659 on the attacker-controlled relay. During the second retrieval, the relay carried ti=659 into the Wikimedia decoy, which became the terminal browser destination.

As a result, a security product performing a single retrieval could receive benign content and return a clean verdict for a URL that previously led to HarvestGate. We cannot determine what controlled the routing decision. Because both observations came from the same automated scanning service, attributing the behavior solely to sandbox detection would overstate the evidence. Other possibilities include campaign timing, link exhaustion, geography, or campaign state.

Stage 4: The gated application obtains a Microsoft device code

The HarvestGate landing host and Turnstile gate

Many confirmed landing hosts follow a recognizable pattern:

<role>-access-<8-character token>.<apex domain>

verify-access-umjlvvrx[.]alltoyotatrucksuvparts[.]com
signin-access-3qbuumoo[.]alltoyotatrucksuvparts[.]com

Related variants place the same eight-character token elsewhere or omit access, so the literal -access- sequence is not universal. The stronger artifact appears on the host itself:

/turnstile?return_url=<token>

HarvestGate embeds Cloudflare’s legitimate Turnstile widget in an operator-controlled verification page before exposing the phishing content. The landing hostname may resolve to Cloudflare edge IP addresses, but the /turnstile route, surrounding HTML, same-origin verification endpoint, and redirect behavior belong to the phishing application. The challenge likely restricts automated scanners while adding legitimacy to the workflow. Visitors who complete it are redirected through a relative return_url to the phishing application on the same hostname. The page also exposes the title Security Check · MailDashboard. “Security Check” is generic, while “MailDashboard” appears to be a developer-selected application label embedded in the kit.

Turnstile gate page title and script

Turnstile verification and return_url redirect

In the recovered device-code samples, that same HarvestGate landing hostname served the Turnstile page, the victim-facing phishing page, and the harvester backend. Two implementation details support this same-origin architecture: the gate’s return_url is relative, so it resolves against the current hostname, and the phishing page calls /api/harvester without specifying another host. The landing hostname is therefore not merely a CAPTCHA front end; it hosts the phishing application itself.

Device code lure variants

Once through the gate, the victim sees a branded verification workflow. Recovered variants impersonated OneDrive document sharing, Microsoft Teams meeting scheduling, Microsoft 365 identity verification, organization-branded document portals, and Adobe Secure lures.

Figure 7 — Microsoft 365 identity-verification lure

Figure 8 — OneDrive document-sharing lure

Figure 9 — Microsoft Teams meeting lure

Figure 10 — Adobe Secure Access lure

How the device code flow works

The underlying authentication technique is not unique to HarvestGate. Previous device-code phishing campaigns and kits have similarly abused Microsoft’s legitimate device authorization flow by generating a code for an attacker-controlled client, convincing the victim to redeem it through Microsoft’s authentication infrastructure, and obtaining the resulting tokens after successful authentication.

HarvestGate implements this established technique through its own backend workflow. On load, the page communicates with its backend in three stages. First, action=geoip returns the visitor’s location and proxy status for display on the phishing page. Recovered responses also contained proxy_active: true and a FlashProxy endpoint, indicating that this stage can support geography-aligned proxying of subsequent Microsoft requests rather than only populating the user interface. Next, action=get_code requests a real Microsoft device code and returns values including user_code, device_code, verification_uri, and expires_in. Finally, action=poll repeatedly asks whether the victim has completed authentication.

Harvester API constants

get_code request and stored flow values

poll request

HarvestGate paths and roles

This behavior has an important incident-response implication. A password reset alone does not invalidate tokens already issued through the device-code flow. In the incident we investigated, token replay continued after the victim’s password was reset. Containment must therefore include explicit revocation of active sessions and tokens.

Figure 11 — HarvestGate device-code phishing and token acquisition flow

A shared JavaScript core survives re-theming

The recovered pages look different, but their JavaScript provides a stronger fingerprint than their visual appearance. Across all lure variants, the same device-code workflow and implementation structure recur.

/api/harvester?action=geoip
/api/harvester?action=get_code
/api/harvester?action=poll
currentFlowID / currentDeviceCode / currentVerificationUri
device_code.substring(0, 16)
POLL_INTERVAL = 3000
EXPIRY_SECONDS = 900
userCodeDisplay
expiryFill
refreshCodeLink
copyCodeBtn
md_dcc_

Branding, pretext, layout, icons, button text, status messages, and popup names can change without altering this workflow. Each variant requests a Microsoft device code, displays it to the victim, opens the legitimate Microsoft verification page, and polls the same-origin backend for successful authentication. Individual strings such as currentFlowID are unusual, but they are most valuable when combined with /api/harvester, the associated element identifiers, and the fixed polling and expiration values. Together, these artifacts provide a stronger kit fingerprint than page branding, lure text, or individual domains.

The pages also contain a separate JavaScript block that limits device-code generation. It intercepts requests to /api/harvester?action=get_code, records the request count in sessionStorage, and eventually replaces the page with a fake Session Expired message. The counter uses the distinctive prefix md_dcc_ combined with the page’s ?t= parameter.

Device-code request limiter

Stage 5: Stolen authorization becomes persistent access

In the incident we investigated, successful device-code redemption was followed by scripted identity activity. Shortly after the victim clicked the phishing link, Python-based HTTP tooling began registering devices through the organization’s authentication broker. Three attacker-controlled devices were registered.

The device names were derived from the victim’s account rather than the organization’s normal fleet-naming convention. The first followed <upn-with-dashes>-<tenantprefix>, while the next two added -p01 and -p02. Account-derived names, sequential suffixes, a non-interactive Python HTTP-library user agent, and tightly grouped requests distinguish the activity from ordinary user-driven enrollment.

The automation also attempted device enrollment, indicating an effort to turn the stolen authorization into a more durable identity-plane foothold. The behavior is consistent with capabilities available in the public ROADtools and roadtx family.

What should defenders do?

• Restrict device-code authentication through Conditional Access where business requirements permit.
• Revoke active sessions and token grants after suspected device-code phishing; a password reset alone is insufficient.
• Disable and remove unauthorized registered devices, review Intune or other MDM enrollment, and investigate subsequent Microsoft Graph and mailbox activity.

MITRE ATT&CK

MITRE ATT&CK techniques

IOCs

The following list preserves the full set of observed indicators and their analytical context, including content-confirmed kit hosts, redirectors, sender domains, and infrastructure associated with token replay and device registration.

IPs

Kit origin

• 5[.]230[.]71[.]19

Token replay and python-requests device registration

• 5[.]230[.]248[.]158

Domains

Kit landing pages

• login-access-heof1k2t[.]androidpreneur[.]com
• signin-access-3qbuumoo[.]alltoyotatrucksuvparts[.]com
• session-access-hrh9axw6[.]androidpreneur[.]com
• signin-access-ltcpr2s7[.]breakingpandora[.]com
• secure-access-ht0ysxlq[.]alltoyotatrucksuvparts[.]com
• saml-access-hjg5zb1m[.]schuelerhvac[.]com
• signin-access-bpbippyw[.]geefjelevenkleur[.]com
• verify-access-umjlvvrx[.]alltoyotatrucksuvparts[.]com
• identity-access-1uuiiymd[.]atomzilla[.]com
• mfa-access-pyvxbnjc[.]atomzilla[.]com
• auth-access-iapr3p2l[.]atomzilla[.]com
• auth-access-rifupwpm[.]atomzilla[.]com
• authenticate-access-unb5gtsf[.]xhscyp[.]com
• signin-access-whtc5iq4[.]accudiodesign[.]com
• validate-access-kgcdauwc[.]xhscyp[.]com
• auth-access-5dofmtuh[.]atomzilla[.]com
• saml-access-haswvgv2[.]atomzilla[.]com
• signin-access-e4gut0dm[.]atomzilla[.]com
• mfa-access-ujmdufau[.]atomzilla[.]com
• login-access-4n34kpq9[.]atomzilla[.]com
• oidc-access-ykvs3i3i[.]atomzilla[.]com
• verify-access-6dlrv01r[.]adogabroad[.]com
• verify-access-vpmpmsb3[.]adogabroad[.]com
• saml-access-bgzdiwai[.]pelicol[.]com
• identity-access-1w2m8s2x[.]arlingtonhousecleaning[.]com
• cert-access-4kydqsdc[.]alltoyotatrucksuvparts[.]com
• signin-access-nlctvue6[.]adogabroad[.]com
• mfa-access-zknmk8p4[.]allurepure[.]com
• onestep-access-aosbgdan[.]tv-appspot[.]com

Redirectors (compromised WordPress, abused open redirect, actor-registered)

• naturespluslatex[.]com
• jennifertrently[.]org
• foesec[.]ma
• akive[.]com[.]br
• livefree[.]jp
• meeting[.]teams-video[.]invite[.]567eco[.]cc
• moon-sys-veem[.]magnoliamiracle[.]com
• docs-sys-veem[.]anneaudio[.]com
• dxdgbf04[.]na2[.]hubspotlinks[.]com
• dsp[.]adop[.]cc
• swiftoaic[.]com
• strninc[.]com

Decoy destination (legitimate domain)

• foundation[.]wikimedia[.]org

Phishing email sender domains

• faktu[.]cl
• email[.]ayra[.]cx
• bilbakalimm[.]com

Conclusion

HarvestGate demonstrates why phishing infrastructure should be investigated beyond the page a victim eventually sees. eSentire’s GhostCode analysis independently corroborates the kit’s core device-code workflow, while our investigation expands the public view of its delivery ecosystem, redirect behavior, selective traffic routing, same-origin application design, changing victim-facing templates, and JavaScript-level fingerprints. Email content, attached documents, branding, redirect paths, and landing hostnames can change between deployments, but the Turnstile route, harvester API, shared JavaScript structure, and device-code workflow provide more durable detection opportunities than any individual sender, file hash, or phishing domain.

Most importantly, a password reset alone may not contain a successful device-code phishing incident. In the incident we investigated, token replay continued after the victim’s password was reset, and the stolen authorization was used for automated device registration and attempted enrollment. Effective containment must include revocation of active sessions and token grants, removal of unauthorized registered devices and review of Intune or other MDM enrollment.

Vega protects customers across the HarvestGate attack chain, from randomized landing hosts to device-code abuse, scripted token use, and rapid device registration. Customers also receive a linked threat brief containing the associated detections and indicators, which Vega automatically scans against their data to surface relevant activity. This layered coverage remains effective as operators rotate infrastructure, branding, and lure templates.

Find detection queries, ideas, and a summary of this campaign at the Vega Threat Hub.